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

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

Thanks, Ben. I think we're close to declaring victory. :)  Jeff and I
will work to push out version -12 in the next 48 hours.

On 12/9/10 7:52 AM, Ben Campbell wrote:
> Still WFM.
> 
> On Dec 8, 2010, at 5:55 PM, Peter Saint-Andre <[e-mail]> wrote:
> 
>> 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.
>>
>> ###
>>
>>
>>
>> _______________________________________________
>> Gen-art mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/gen-art