On Tue, Apr 11, 2017 at 07:33:47AM -0700, Sean Leonard wrote: > > As for the format of end-entity certificate data: if it’s in JSON > then it has to be some textual encoding. I am mostly indifferent > to RFC 7468 textual encoding vs. base64/base64url, but on balance > I think base64/base64url is better because that’s the same format > as the csr field, which means that clients and servers have to > process it anyway. Furthermore, we don’t want naive clients to > dump the contents of the certificate field into their web server > preferences, since that results in the same validation problem as > before in letting through more than just a single certificate. It’s > also smaller. (I don’t understand why base64url was chosen over > base64, is that some JWS requirement or something? Please help me > understand that.)
Well, JWS tends to use base64url. And dumping a array of base64url encoded certificates into "PEM" file is not difficult: 1) For each entry: 1a) Write "-----BEGIN CERTIFICATE-----" and linefeed 1b) Check that the string consists of only alphanumerics, - and _. 1c) Replace - with +, and _ with / in string. 1d) Pad to multiple of 4 with =. 1e) Write out the modified string, wrapping to 72 characters. 1f) Write "-----END CERTIFICATE-----" and linefeed. This method is not vulernable to special certificate types. > I can’t say whether support for multiple chains is necessary, > but several people have identified it as being useful. So that > should be some kind of array. Problem is, since multiple chains are involved, it becomes some sort of array of array. And if you dump all the certificates in chains there, assume lots of servers will end up with serving such "chains" (which break TLS 1.2 rules). > If URIs are used to retrieve the certificate chain(s), ACME > doesn’t currently specify what kinds of URIs clients and servers > need to support—the draft ought to say something about that. RFC > 5280 describes URI access mechanisms using HTTP, HTTPS, FTP, LDAP, > and X.500 without recommending any particular thing. I think the > same constellation of URIs ought to be supported (proposed text: > “Some URI schemes are documented in [RFC5280].” — not recommending > any particular thing). This is less work than people might think, > as many crypto stacks implement rudimentary HTTP/HTTPS, FTP, and > LDAP clients anyway (yes, even LDAP). If “enterprise” is a use > case for this protocol then LDAP should be supported anyway. (Note: > if the data: URI is also supported, then you have an option for > inlining in a different part of the software stack, not sure if folks want to go there as data: is base64 rather than base64url.) I presume URLs are all HTTPS. > The draft could also discuss that the caIssuers access method > (RFC 5280 Section 4.2.2.1) SHOULD be filled in the subject > certificate, and the clients are to follow those URIs to get any > CA certificate chains. Then you can just let the crypto stack > have at it. In MS CAPI it is just a flag (default is on) to > CertGetCertificateChain. Way too complicated for most clients. And didn't that kind of thing blow up rather badly when LE updated their intermediates (from X1/X2 to X3/X4)? > The protocol could allow both inlined certificate data (array of > base64(url)-encoded certs)) and URI options. This is more complicated, > but as pointed out above, URIs are mostly supported by crypto stacks > anyway. Again, it’s just one call in MS CAPI: CryptRetrieveObjectByUrl. > (See also CryptGetObjectUrl.) Doing something because MS CAPI makes it easy is a bad idea. Most users won't be using anything that has anything to do with CAPI. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
