At 7:09 AM +0200 7/13/10, Kaspar Brand wrote: >On 12.07.2010 19:22, Peter Saint-Andre wrote: >> On 7/7/10 12:41 AM, Kaspar Brand wrote: >>> Clarifying/fixing that blurry "(most specific)" statement from RFC 2818 >>> would be highly desirable for the new BCP, IMO. If by this we can get >>> away with a term whose meaning isn't intuitively clear (compare this >>> e.g. to "left-most DNS label"), then I would definitely consider that a >>> plus. >> >> Would removing all mention of "(most specific)" qualify as clarification? > >-08 looks good to me, generally speaking, but in addition to the >implementation note at the end of 2.2 I would add some wording to 4.4.4 >which states that a) if multiple CN-IDs are found in the subject, all of >them should be checked
Wait, wait. The spec says in a few places that there must only be a single CN. If you add that (which was taken out of -08), you have to change all of them. I propose that we stay with the current MUST for a single CN. > and b) this deliberately allows broader matching >than the one originally "specified" in [HTTP-TLS] and [GIST]. Yes, saying that would be good. >(Finally, let me add that browsers such as MSIE, Opera or Safari already >implement this kind of multi-CN checking - if there is no subjectAltName >extension, they will go through all CNs and look for a match [1]). That doesn't make it a best current practice. --Paul Hoffman, Director --VPN Consortium _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
