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

[Paul Hoffman <[e-mail]>]

[[ 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