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

[Ben Campbell <[e-mail]>]

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.


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