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 <[email protected]>
>> 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 <[email protected]> replied..
>>>>>>>>
>>>>>>>> On 12/3/10 2:24 PM, "Ben Campbell" <[email protected]>
>>>>>>>> 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.
> 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.
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.
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.
=JeffH
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
