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