On Wed, Oct 11, 2017 at 10:33 AM, Daniel Margolis <[email protected]> wrote:
> Hey, Ivan, > > Comments inline: > > On Wed, Oct 11, 2017 at 12:42 AM, Viktor Dukhovni <[email protected]> > wrote: > >> On Tue, Oct 10, 2017 at 10:03:29PM +0100, Ivan Ristic wrote: >> >> > I think dropping CNs altogether would bring this RFC in line with how >> PKI >> > is used elsewhere and reduce complexities and opportunities for security >> > issues without losing any functionality. >> >> No objections to that, provided that CNs are in practice being >> deprecated from HTTPS (which I would applaud). >> > > IIRC we talked about this before and concluded that we should keep the > same behavior as in 6215, i.e. CNs are accepted only if SANs are not > present--only I forgot to update the draft accordingly! > > Because STS is intended to work with existing certs, it seems problematic > to me to force people who may already have a CN-only cert to go get a new > one--but you probably have a better idea than I do about how common that > actually would be, if I remember your research properly. Are people > generally already all migrated to SANs? Are we likely to have people who > have an existing cert that relies on CN matching? > Viktor and Hanno already said what I would have. I think just deferring to 6125 is a safe choice, certainly other relevant RFCs already do. For example, the HSTS RFC does. - As a final small point, in at least one place the spec gives a very vague >> explanation of how certificates are verified: "The certificate presented by >> the receiving MX MUST chain to a root CA that is trusted by the sending MTA >> and be non-expired." I am afraid that this incomplete guidance might give >> some people idea that it's not necessary to perform any other checks (such >> as KU/EKU, pathlen, name constraints, check that the signature algorithms >> are acceptable, and so on). > > > Yes, the intent is, as you say, to check certs "as implemented elsewhere." > Do you have a suggested reference that's a more thorough specification for > all the things "elsewhere" entails? I think you're right that this is in > some places underspecified, but of course we don't want to be specifying > behavior de novo--I'd much rather defer to some common understanding of > what hoops you should jump through (hence the reference to 6215, at least, > but perhaps this is insufficient or we are not referencing it in the right > places). > I was afraid you might ask that. Frankly, I don't think there's a good one source, perhaps this is one area where a fresh RFC to provide a summary of best practices. Below is the language from the HSTS RFC; I was actually surprised at how vague it is: "8.4. Errors in Secure Transport Establishment When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 ("User Agent Implementation Advice")) if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport. For example, this includes any errors found in certificate validity checking that UAs employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC2560], as well as via TLS server identity checking [RFC6125]." I think something similar to this is fine, perhaps just emphasising that a publicly-trusted certificate is required. Yes, that's vague, but I think it will be understood. (And see below for a further comment about that.) As an unrelated thought, have you considered standardising on the root store? I admit not thinking a lot about it, but it's tempting. Given that there is currently little proper certificate validation in SMTP, I suspect that many clients and servers use stores that are not up to date. Saying something like "you must use Mozilla's root store and you must update it at least once a day/week/month", would preempt a great number of problems in practice IMO. Of course, politics might get in the way, and attaching to any one store is dangerous, but at least Mozilla have been doing a good job, historically. _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > > -- Ivan
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
