PeterSA replied.. > > 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: >>>>>>>
<snippage type="major"/> >>>> 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. thx. > >> 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. super. > >> 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: <snip/> >> >> 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. > > ### excellent smithing there, thanks. =JeffH _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
