On Jun 14, 2010, at 7:55 PM, Paul Hoffman wrote: > At 4:12 PM +0200 6/14/10, Martin Rex wrote: >> Paul Hoffman wrote: >>> >>>> 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName >>>> identifier of type dNSName). >>> >>> . . . >>> >>>> Therefore, if and only if the identity set does not include >>>> subjectAltName extensions of type dNSName, SRVName, or >>>> uniformResourceIdentifier (or any application-specific subjectAltName >>>> extensions supported by the client), the client MAY as a fallback >>>> check for a fully-qualified DNS domain name in the last Common Name >>>> RDN in the sequence of RDNs making up the Distinguished Name within >>>> the certificate's subjectName (where the term "last" refers to the >>>> DER order, which is often not the string order presented to a user; >>>> the order that is applied here MUST be the DER order). >>> >>> Bzzzzzt! All of 3.4.4 is bogus, given that DNS-ID is required. Please >>> remove it. >> >> I think this needs to stay. >> >> The document under discussion is supposed to be a BCP (Best current practice) >> document, and it will have to describe how clients should deal with >> server certificates that do no have subjectAltNames. It does so by >> describing the common practice that has been in use for certs that >> do not have subjectAltNames. > > That goes counter to the MUST-level statements in the document. You either > need to downgrade the MUST-level requirements, or get rid of the sections > that say, in essence, "if this MUST-level requirement is not met, then do > this". > > The fact that this is a BCP is irrelevant. BCPs are standards-track > documents. Being a BCP doesn't make it OK to have conflicting requirements.
The section in question describes what one party is supposed to do if the other party does the wrong thing. I see nothing inconsistent or inappropriate about that. It's just sad that the current (actual, not best) practice is to do "the wrong thing" so often that we need to worry about it so much. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [email protected], or [email protected] _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
