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

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

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.

We could say "and if the server hosts more than one domain then the
certificate presented is typically based..."

Peter

-- 
Peter Saint-Andre
https://stpeter.im/