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. 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
