[[ Much abbreviated ]] At 9:10 PM -0700 12/6/10, Peter Saint-Andre wrote: > >>> -- 3.1, rule 6: >>>> > >>> Can you motivate why this is not a MUST NOT? > > The reason for allowing this wiggle-room is that (for better or worse).. >> >> 1. the CA/Browser Forum Extended Validation (EV) Certificate Guidelines >> explicitly allow for multiple CN-IDs >> >> 2. It's a not-totally-uncommon current practice to have certs that do >> have >> mutiple CN-IDs, eg from Comodo (whether EV or DV (domain valivdated)). >> >> 3. Virtual hosting multiple distinct-domain TLS servers on one entity is >> difficult today if one desires wide desktop client support because >> a certain vendor's older-but-still-widely-deployed-OS does not (yet?) >> support the TLS Server Name Indication extension. Thus having one >> cert with all the domains jammed in it (as either/both CN-IDs or/and >> DNS-IDs) is a workaround (eg Content Delivery Networks use this). >> >> >> So some argue that if we MUST NOT multiple CN-IDs at this point, it is >> flying in the face of present reality and might contribute to acquiring >> an attained reputation for this BCP that is lower than we desire. >> >> There is also concern on the part of CA folk about client-side TLS libs >> and their support for name matching (ie some (old?) one(s) will only >> match on CN-ID). >> >> For a CA perspective on all the above, see... >> >> Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data >> http://www.ietf.org/mail-archive/web/certid/current/msg00502.html > >+1 to all that.
Putting an explanation such as the above in the document will help future IETFs to decide when to make this a MUST NOT. It might also help the CA/Browser Forum and specific CAs see that they should stop doing this ASAP, and maybe even convince a particular legacy OS vendor to support TLS SNI. --Paul Hoffman, Director --VPN Consortium _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
