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. > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
