Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Marc-André Moreau
    @awakecoding
    and returns a not found (obviously)
    unless I need to install it in step-ca server
    Michael Malone
    @mmalone
    what command did you run?
    Mariano Cano
    @maraino
    @mmalone @awakecoding Another more verbose option would be to run step-ca with:
    GODEBUG=http1debug=2,http2debug=2 bin/step-ca ~/.step/config/ca.json
    Michael Malone
    @mmalone
    ^- yea, that might be the easiest way to get detailed logs without having to run a proxy / ngrok
    Marc-André Moreau
    @awakecoding
    and I replaced the step-ca root_ca.crt with the one from digicert, I was able to get a token and use it to get my cert
    Michael Malone
    @mmalone
    ha… that’s prolly gonna break all sorts of other stuff but :shrug:
    if it’s just for debugging / dev then whatevs
    Marc-André Moreau
    @awakecoding
    image.png
    it's probably all broken now, but hey, I can see some traffic in there ;)
    Michael Malone
    @mmalone
    lol awesome
    Marc-André Moreau
    @awakecoding
    @mmalone i'm writing a specification document for my own PKI service, and one thing I'm trying to figure out once and for all is how to correctly deal with 3 potential formats for all PKI data types: binary (ASN.1 DER), a base64 string without newlines and labels, and the PEM-formatted variant with newlines and labels. looking at wireshark traffic, it looks like you are using mostly JSON payloads, and PEM formatting
    I found a bunch of mime types that can be used to correctly identify different formats for binary representation and PEM-formatting. as for base64, the best way I could find for HTTP is to use Content-Transfer-Encoding: base64
    however I'd be happy if it could be a special mime type instead, and deal only with mime types
    one format which has always been lacking and that I find particularly annoying is a non-PEM representation of multiple X.509 certificates, as close as possible to their binary representation
    base64 works for a single certificate, but I had an idea: how about using a special mime type to indicate a base64 chain of certificates separated by a non-base64 char, like ','
    the logic would be relatively simple: split by ',' then base64-decode, and you've got your X.509 certificate chain without having to deal with newlines and labels and all that stuff which is all but nice to deal with when trying to pass the value in environment variables or command-line arguments
    all of this to say, I'd like to bounce these ideas with you and see what would be your preference on: 1) new mime-type for base64 encoding of PKI data types, or just use Content-Transfer-Encoding: base64? and 2) got any ideas for a simple format to transfer X.509 certificate chains without newlines and labels. does my idea of "base64csv" seem legit to you?
    Marc-André Moreau
    @awakecoding
    of course, all of this would let applications chose the format they which to deal with using mime types in HTTP requests/response. basically a chose-the-format-that-is-less-painful-for-you
    Michael Malone
    @mmalone
    @awakecoding here are my thoughts: cert & key encoding is terrible. It’s poorly standardized or not standardize at all. There are a bunch of formats and encodings and they’re all pretty terrible for developers. There actually are ways to encode multiple X.509 certificates using DER — PKCS#7 and PKCS#12 I think both do that. But these formats are really difficult to deal with and converting between them is hard (mostly b/c of poor tooling and lack of labeling and documentation indicating what format you’re looking at and what format your application needs). It seems like newer stuff is mostly using PEM, so that’s what we’ve focused on at smallstep. You can also send multiple newline-separated PEM-encoded certs in one payload. I’d avoid inventing a new format, however simple that format is. If you want to transmit a list of certificates and don’t want to use newline-separators I’d just put them in a JSON list.
    might be helpful…
    we mostly transmit certs and keys and whatnot embedded in JSON, so I don’t think we’ve invertigated a MIME type for this stuff
    but if there’s a registered mime type it should be in the IANA media type assignments, I guess? https://www.iana.org/assignments/media-types/media-types.xhtml
    but it looks like there might not be one: ietf-wg-acme/acme#120
    oops, scratch that, looks like ACME might have defined one recently: https://tools.ietf.org/html/rfc8555
    which was gonna be my next suggestion — look at what ACME does for a taste of a more modern API that’s trying to work with X.509
    and you didn’t ask about keys… for those we also use PEM / PKCS#8… but I really like JWK https://tools.ietf.org/html/rfc7517
    the problem is you need to work with existing crypto libraries… so it doesn’t really matter what you want to do, if you’re gonna provide a good experience for developers who are using standard libraries you don’t have many options :/
    Marc-André Moreau
    @awakecoding
    thanks for the input. I know PKCS#7 and PKCS#12 can encode multiple certificates, but they require wrapping them in another ASN.1 container, so really not an easy way to do equivalent of PEM
    I want to avoid encapsulating most of the PKI data types in HTTP request/responses as much as possible when not necessary. when sending a PKCS#10 certificate signing request, why bother sending it as PEM? application/pkcs10 is a proper mime type and works with binary, or base64 encoding when used with Content-Transfer-Encoding
    same for pushing and fetching certificates. application/x-pem-file seems to be the best mime type to indicate "pem"
    but there is also application/pkix-cert, which by default is the binary representation of a single X.509 cert, so unsuitable for chains
    JWK is ok... but honestly I'd rather deal with the ASN.1 variant and load the keys directly instead of loading and saving to a JSON format
    Michael Malone
    @mmalone
    idunno, raw binary is annoying to deal with (e.g., logging & debugging)… and the cost of PEM is just a few bits & bytes & cycles here and there… but ultimately this is pretty subjective I guess.
    I like formats that work for me… let the computers do the hard work :)
    Marc-André Moreau
    @awakecoding
    yeah. my problem with PEM is it doesn't go well in environment variables because of the newlines, and then you need to handle all sorts of cases where applications may or may not insert a newline at the end, and that's putting aside potential issues with file encoding if users open notepad and paste a PEM in it
    Michael Malone
    @mmalone
    ^- that is true.
    Marc-André Moreau
    @awakecoding
    When I have something documented and public for my new design I'll send it to you, maybe there are some parts you'd like to integrate
    Michael Malone
    @mmalone
    Ultimately the problem is X.509. There are no good options. Just different bad options that optimize for certain scenarios at the expense of others.
    I’d love to take a look… send over when you’re ready!
    Marc-André Moreau
    @awakecoding
    this is for the elaborate design with HTTP signatures and using X.509 certificates for peer-to-peer HTTP request authentication from a web application :)
    we're cleaning up our ASN.1 serde framework, it just solves the ASN.1 encoding/decoding problem for us (given you use Rust, but it compiles to WebAssembly)
    Michael Malone
    @mmalone
    Yea… maybe don’t use X.509 at all ;) idunno.
    Marc-André Moreau
    @awakecoding
    I'll have more to show in a month, maybe sooner
    Michael Malone
    @mmalone
    very cool
    Christian Fischer
    @nachtfisch
    Good day everyone. Evaluating smallstep to fix a few issues we have with our current ssh setup. In a nutshell: many nodes globally, central identity provider based on Oauth, different people have access to different machines (usera -> node1, userb -> node1 and node2, useradmin -> all nodes). I didn't find any information on how to solve the authorization puzzle using smallstep. in particular if the ca authority server can be configured with some sort of access control mechanism (RBAC, ACL, anything). Any pointers where to find info on that would be appreciated.
    Sebastian Tiedtke
    @sourishkrout
    Hey @nachtfisch. Glad to hear you’re looking into step. It is possible to to build something on top of the step ssh certificates which you’re are describing as the authorization puzzle. However, as it stands step does not come with flexible authorization options out of the box. Since environments and requirements are often different and fragemented for different users we do have conversations invidually with anybody who’s looking for a solution as part of our early access program (https://smallstep.com/sso-ssh/) which is outside of what’s available open source. Please feel free to fill out the form.
    We do have enhancements planned for step’s ssh certificate support which is largely centered around making client and host configuration easier and add functionality to reduce the friction of ssh certificate usage.