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.
We could say "and if the server hosts more than one domain then the certificate presented is typically based..." Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
