Still WFM. On Dec 8, 2010, at 5:55 PM, Peter Saint-Andre <[email protected]> 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 <[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. > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
