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

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

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

Peter

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