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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
