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

[=JeffH <[e-mail]>]

PeterSA replied..
 >
 > And the wordsmithing continues...
 >
 > On 12/8/10 3:52 PM, =JeffH wrote:
 >> see way below...
 >>
 >> PeterSA wrote on Wed, 08 Dec 2010 07:54:52 -0700 (06:54 PST)
 >>>
 >>> On 12/8/10 7:37 AM, Ben Campbell wrote:
 >>>>
 >>>>
 >>>> On Dec 8, 2010, at 7:10 AM, Peter Saint-Andre <[e-mail]>
 >>>> wrote:
 >>>>
 >>>>> On 12/7/10 10:45 PM, Ben Campbell wrote:
 >>>>>>
 >>>>>> On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote:
 >>>>>>
 >>>>>>> On 12/7/10 6:35 PM, Ben Campbell wrote:
 >>>>>>>>
 >>>>>>>> On Dec 6, 2010, at 7:00 PM, =JeffH wrote:
 >>>>>>>>
 >>>>>>>>> Peter Saint-Andre <[e-mail]> replied..
 >>>>>>>>>>
 >>>>>>>>>> On 12/3/10 2:24 PM, "Ben Campbell" <[e-mail]>
 >>>>>>>>>> wrote:
 >>>>>>>

<snippage type="major"/>


 >>>> Do you think server_name extension use is actually common enough to
 >>>> call typical? I'm not saying it's not--I don't really know one way or
 >>>> another. Otherwise, WFM.
 >>
 >> I don't think the TLS server_name extension (aka SNI) is in common
 >> enough use yet to call it "typical". There's a certain
 >> still-widely-deployed version of a certain desktop OS that doesn't
 >> support it, unfortunately.
 >
 > I had changed it to:
 >
 >       if the server hosts more than one domain then the certificate it
 >       presents might be based on a DNS domain name specified by the
 >       client when initiating communication (e.g., using a Server Name
 >       Indication during TLS negotiation as described in [TLS-EXT]).
 >
 > That seems suitably vague about how common SNI is. But per your message
 > I think this might belong in a different place.
 >
 >>> We could say "and if the server hosts more than one domain then the
 >>> certificate presented is typically based..."
 >>
 >> Upon re-reading what we presently have in -11 for [S1.1], I don't think
 >> we need to introduce in that intro paragraph the notion of
 >> disambiguating names in a multi-domain situation. I'd leave that para
 >> as-is.
 >
 > Yes, I'd already removed any mention of SNI from Section 1.1.


thx.




 >
 >> in terms of the defn for "presented identifier" in [S1.5], I'd update it
 >> like so (I don't think mentioning SNI is reasonable in that defn proper)..
 >>
 >>  presented identifier:  An identifier that is presented by a server
 >>  to a client within a PKIX certificate when the client attempts to
 >>  establish a secure connection with the server; the certificate can
 >>  include one or more presented identifiers of different types, and
 >>  if the server hosts more than one domain then the certificate might
 >>  present distinct identifiers for each domain.
 >
 > WFM.


super.



 >
 >> I'm wondering if we ought to add an "implementation note" at the end of
 >> [S3.1] where we mention why one might have a cert with multiple
 >> presented identifiers or a client may employ SNI.
 >>
 >>
 >> Implementation Note:  <snip/>
 >>
 >> of course, the FDA notes that the above will require generous
 >> wordsmithing before use.
 >
 > Wordsmithed as follows:
 >
 > ##
 >
 > 5.4.  Multiple Identifiers
 >
 >    A given application service might be addressed by multiple DNS domain
 >    names for a variety of reasons, and a given deployment might service
 >    multiple domains (e.g., in so-called "virtual hosting" environments).
 >    In the default TLS handshake exchange, the client is not able to
 >    indicate the DNS domain name with which it wants to communicate, and
 >    the TLS server returns only one certificate for itself.  Absent an
 >    extension to TLS, a typical workaround used to facilitate mapping an
 >    application service to multiple DNS domain names is to embed all of
 >    the domain names into a single certificate.
 >
 >    A more recent approach, formally specified in [TLS-EXT], is for the
 >    client to use the TLS "Server Name Indication" (SNI) extension when
 >    sending the client_hello message, stipulating the DNS domain name it
 >    desires or expects of the service.  The service can then return the
 >    appropriate certificate in its Certificate message, and that
 >    certificate can represent a single DNS domain name.
 >
 >    To accommodate the workaround that was needed before the development
 >    of the SNI extension, this specification allows multiple DNS-IDs,
 >    SRV-IDs, or URI-IDs in a certificate; however, it explicitly
 >    discourages multiple CN-IDs.  Although it would be preferable to
 >    forbid multiple CN-IDs entirely, there are several reasons at this
 >    time 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 SNI
 >       extension [TLS-EXT].
 >
 >    It is hoped that the recommendation regarding multiple CN-IDs can be
 >    further tightened in the future.
 >
 > ###

excellent smithing there, thanks.

=JeffH