Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11

[Ben Campbell <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art