Thanks, Ben. I think we're close to declaring victory. :) Jeff and I will work to push out version -12 in the next 48 hours.
On 12/9/10 7:52 AM, Ben Campbell wrote: > Still WFM. > > On Dec 8, 2010, at 5:55 PM, Peter Saint-Andre <stpe...@stpeter.im> 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 <stpe...@stpeter.im> >>>>> 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 <peter.saintan...@webex.com> replied.. >>>>>>>>>>> >>>>>>>>>>> On 12/3/10 2:24 PM, "Ben Campbell" <b...@nostrum.com> >>>>>>>>>>> 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 >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
