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

[Peter Saint-Andre <[e-mail]>]

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