On Wed, Mar 14, 2018 at 9:23 PM, Jacob Hoffman-Andrews <[email protected]> wrote: > On 03/12/2018 05:25 AM, Hugo Landau wrote: >> 3. Clarify the specification to state that the root certificate must >> not appear in the chain, and that roots must be retrieved using the >> AIA URL inside the final certificate in the chain if it is needed. >> This minimises the chance of clients for non-DANE applications >> messing up and provides a viable method for discovery of the root >> CA for applications which need it. > This seems fine to me.
MUST NOT is too strong. Advise against it in the same way that TLS does. Even point to TLS. Adding a note that when intended for a particular use (such as for securing HTTPS), the chain that is provided should be directly usable in that context and might need some assumptions about what relying parties in that context need. Don't require AIA or even use it. It's a mess and not widely deployed. It's mostly just a waste of bytes - it's not like you can remove it from a certificate once added (sure, if your intermediate has it, then that's fine, but I'd content that this is a mistake). You could use an "up" link relation (or whatever we decided works for that) on the response if you feel that providing a link to the root is necessary. > To push a little more on why it's required, though: In DANE, you might > indicate a trust anchor in your records. Presumably that trust anchor > could be either a self-signed root, or an intermediate issuer > certificate, right? DANE adds a whole new dimension to this problem. I think that if the expectation is that DANE is used, then the server will need to be told about this so that it can adjust as needed. Often that means a shorter chain. However, I think that this sort of optimization is an extension and doesn't really belong in the core spec (i.e., ship the damned thing already and stop messing with it). _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
