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

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

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:
>>>>>>
>>>>>> <snip/>
>>>>>>
>>>>>>>>>> -- 3.1, 1st paragraph:
>>>>>>>>>>
>>>>>>>>>> It's probably worth emphasizing that the rules are
>>>>>>>>>> often cumulative.  I think someone thinking about these
>>>>>>>>>> for the first time might not grasp that until they see
>>>>>>>>>> examples later in the doc.
>>>>>>>>>
>>>>>>>>> I've added the second sentence to this paragraph:
>>>>>>>>>
>>>>>>>>> When a certification authority issues a certificate based
>>>>>>>>> on the fully-qualified DNS domain name at which the
>>>>>>>>> application service provider will provide the relevant
>>>>>>>>> application, the following rules apply to the
>>>>>>>>> representation of application service identities.  The
>>>>>>>>> reader needs to be aware that some of these rules are
>>>>>>>>> cumulative and can interact in important ways that are
>>>>>>>>> illustrated later in this document.
>>>>>>>>
>>>>>>>> LGTM.
>>>>>>>
>>>>>>> WFM
>>>>>>>
>>>>>>> In fact, as I was re-reading RFC 5922, it occurred to me to
>>>>>>> wonder if people need guidance one way or another on the idea
>>>>>>> of "multi-purpose" certs that might have any number of
>>>>>>> subjectAltName entries for different purposes. I'm talking
>>>>>>> about virtual domain hosting, or multi-protocol hosts. I
>>>>>>> assume in the latter case, you would expect a host to use
>>>>>>> different certs for different protocols. In the first case,
>>>>>>> is their any guidance to give. I can't remember, do you
>>>>>>> mention the TLS server_name extension?
>>>>>>>
>>>>>>> (I don't mean to suggest any real action here--just thinking
>>>>>>> out loud about something that would have been much better to
>>>>>>> bring up well before IETF LC. :-)  )
>>>>>>
>>>>>> Those scenarios are important, but IMHO how the server
>>>>>> determines which certificate to present (e.g., based on the SNI
>>>>>> or something else, such as the 'to' address on an XMPP stream
>>>>>> header) is something that an application protocol specification
>>>>>> needs to define.
>>>>>
>>>>> Agreed. Does this draft need to say that, or do we just take it
>>>>> as given?
>>>>
>>>> I think it's appropriate to add a few words about that. I
>>>> suggest...
>>>>
>>>> 1.1
>>>>
>>>> ... When a client connects to an application service using
>>>> Transport Layer Security [TLS] or Datagram Transport Layer Security
>>>> [DTLS], it references some notion of the server's identity while
>>>> attempting to establish a secure connection (e.g., "the website at
>>>> example.com") and typically specifies at least the DNS domain name
>>>> with which it is trying to communicate (e.g., using a Server Name
>>>> Indication during TLS negotiation as described in [TLS-EXT]).
>>>>
>>>> 1.5
>>>>
>>>> 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
>>>> the certificate presented is typically 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]).
>>>>
>>>
>>> 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.

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

> 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:  A given application service may be addressed by
> multiple domain names for a variety of reasons. In the default [TLS]
> handshake exchange,
> there is no indication by the client as to the domain name the client
> trying to connect to, and the TLS server returns only one certificate
> for itself. Thus absent an extension to [TLS], a typical workaround used
> to facilitate mapping an application service to multiple domain names is
> to embed the said domain names into the returned application service
> certificate. Another approach, more recent and formally specified, is
> for the client to use the TLS "Server Name Indication" extension, when
> sending the client_hello message, stipulating the domain name the client
> used to connect with the application service. The application service
> can then return the appropriate certificate in its Certificate message.
> This latter certificate could thus contain a single domain name.
> 
> 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.

###