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

[Ben Campbell <[e-mail]>]

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