> On Apr 11, 2017, at 10:21 AM, Ilari Liusvaara <[email protected]> > wrote: > > On Tue, Apr 11, 2017 at 09:10:15AM -0700, Sean Leonard wrote: >> >>> On Apr 11, 2017, at 8:34 AM, Ilari Liusvaara <[email protected]> >>> wrote: >>> >>> On Tue, Apr 11, 2017 at 07:33:47AM -0700, Sean Leonard wrote: >>>> >>> >>>> 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. >> >> …which is not a problem, since that’s what it is anyway, regardless >> of whether it’s a JSON [ [ “” ] ] or something else. Nested structures >> are just fine. >> >>> >>> 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). >> >> Less sure about this one, I would think a naive implementation would >> just pick the first chain in the array of chains, and not do any >> checking (as opposed to doing validation checking before putting into >> production). > > Oops, that was phrased in unclear way. I meant that if all the > certificates are dumped into one array, you will likely get those > kinds of chains sent from TLS servers. > > If it is array of arrays, and ACME client picks the first one, then > obviously only that chain gets sent.
Yes, it is an array of arrays. > > And I expect number of ACME clients that do no validation before > throwing cert into production to outnumber the ones that do even > some validation. An old Russian proverb: “Trust, but verify.” This is not just about verification in the narrow certificate validation sense: it’s about sanitizing your inputs (verify in the broad sense). Implementations (currently) do not have to verify the input from the server. They should verify in the broad sense (making sure that the returned data is “certificates, and only certificates”); they should also also verify in the narrow sense (validate the certificate chains to a TA and is currently good). But I am not going to push for the latter too hard because I am not so sure everyone around here is going to implement that, so the blood is on their hands if they throw a cert into production and millions of clients fail out. > >>> >>>> 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. >> >> I don’t think that presumption is warranted. Besides, they could >> be straight HTTP, it avoids circularity problems if you can’t >> validate the server cert or client cert for mutual auth because >> somehow your validation depends on ACME or this-and-that (hand wave). > > Is this about servers fetching their existing certificates from CA on > startup? I don't think that would be in scope for ACME. No, I was referring to the once-a-year (or quarter or whatever) certificate update, which is in-scope for ACME. I was not envisioning that servers fetch existing certificates on software startup. *** As for the rest: it sounds like there is value in separating the subject certificate in one field (base64url encoded), and the intermediate CA certificate chains (plural) in another field, which may, or may not, include the root. There is some value in inlining the certificate chains (arrays of arrays of base64url-encoded certificates), and some value in referencing certificate chains by URIs (arrays of URIs). I think that as long as the ACME client has flexibility in terms of how to determine the appropriate certificate chains that it wants to put into production (and that the ACME draft says so), then it is fine. The subject certificate is fixed, but the ACME client can use any intermediate cert chain when in production, or figure out its own custom thing. In terms of the format of certificate chains, I am in favor of a chain being an array of base64url-encoded certificates, and the “chains” field being an array of such chain arrays. This is mainly because I really don’t see certificate chains changing during the lifetime of a subject certificate, and it’s not difficult for an ACME server to serve the same static data in response to a dynamic request. For resource- or time-constrained ACME clients, this also leads to the most predictable and rapid behavior. Note: if you want both by-value and by-reference, a base64url certificate always begins with “M”, while an absolute URI always contains “:”. Therefore you can overload the field so that it can be a URI or a string depending on whether these factors are present (specifically, if “:” is in the string). But then again you can also just say data:application/pkix-cert;base64,MIICAS… and get the same effect if they are always URIs. Sean _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
