Smallstep: End-to-end encryption for distributed applications and the people who manage them. (we’re on Pacific Time)
unless I need to install it in step-ca server
if it’s just for debugging / dev then whatevs
it's probably all broken now, but hey, I can see some traffic in there ;)
@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?
@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.
I wrote a bit about these formats here: https://smallstep.com/blog/everything-pki/#x-509-asn-1-oids-der-pem-pkcs-oh-my
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 :/
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
I like formats that work for me… let the computers do the hard work :)
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
I’d love to take a look… send over when you’re ready!
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)
I'll have more to show in a month, maybe sooner
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.
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.