WFM On Dec 8, 2010, at 4:11 PM, Peter Saint-Andre wrote:
> On 12/8/10 2:04 PM, =JeffH wrote: >> stpete replied.. >>> >>> On 12/7/10 8:01 AM, Paul Hoffman wrote: >>>> [[ 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. >>> >>> Sigh. I don't particularly want to add a long informational note that >>> qualifies eight words in the spec, but you're right. :) >> >> agreed. > > Possible text for the Security Considerations: > > ### > > 5.4. Multiple Identifiers > > This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a > certificate, but discourages multiple CN-IDs. The inclusion in the > Common Name of multiple strings whose form matches that of a fully- > qualified DNS domain name (e.g., "www.example.com") makes it more > difficult to parse the Common Name and increases the likelihood of > false positives in the identity verification process. Although it > would be preferable to forbid multiple CN-IDs entirely, there are > several reasons why this specification states that they SHOULD NOT > (instead of MUST NOT) be included: > > o At least one significant technology community of interest > explicitly allows multiple CN-IDs [EV-CERTS]. > > o At least one significant certification authority is known to issue > certificates containing multiple CN-IDs. > > o Many service providers often deem inclusion of multiple CN-IDs > necessary in "virtual hosting" environments because at least one > widely-deployed operating system does not yet support the Server > Name Indication extension [TLS-EXT] > > It is hoped that the recommendation in this specification can be > further tightened in the future. > > ### > > To be referenced from bullet #6 in Section 3.1: > > 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or > URI-ID (but SHOULD NOT contain more than one CN-ID, as further > explained under Section 5.4). > > /psa > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
