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

[=JeffH <[e-mail]>]

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.

=JeffH