On Tuesday 03 June 2008 9:58 am, Peter Saint-Andre wrote:
> 15.2. Certificates
>
> Channel encryption of an XML stream using Transport Layer Security as
> described under Section 6, and in some cases also authentication as
> described under Section 7, is commonly based on a digital certificate
> presented by the receiving entity (or, in the case of mutual
> authentication, both the receiving entity and the initiating entity).
> This section describes best practices regarding the generation of
> digital certificates to be presented by XMPP entities and the
> verification of digital certificates presented by XMPP entities.
>
> 15.2.1. Certificate Generation
>
> 15.2.1.1. Server Certificates
>
> In a digital certificate to be presented by an XMPP server or service
> (i.e., a SERVER CERTIFICATE), it is RECOMMENDED for the certificate
> to include one or more JIDs (i.e., domain identifiers) associated
> with domains serviced at the server. The representations described
> in the following sections are RECOMMENDED. These representations are
> described in preference order.
>
> 15.2.1.1.1. Service Name
>
> A server's domain identifier SHOULD be represented as a service name,
> i.e., as an otherName field of type "id-on-dnsSRV" as specified in
> [X509-SRV].
>
> 15.2.1.1.2. DNS Name
>
> A server's domain identifier SHOULD be represented as a DNS name,
> i.e., as a subjectAltName extension of type dNSName.
>
> The DNS name MAY contain the wildcard character '*'. The wildcard
> character applies only to the left-most domain name component or
> component fragment and match any single component or component
> fragment. For instance, a DNS name of *.example.com matches
> foo.example.com but not bar.foo.example.com or example.com itself;
> similarly, a DNS name of im*.example.net matches im1.example.net and
> im2.example.net but not chat.example.net or example.net itself.
>
> 15.2.1.1.3. XMPP OID
>
> A server's domain identifier MAY be represented as an XMPP OID, i.e.,
> as a UTF8String within an otherName entity inside the subjectAltName,
> using the [ASN.1] Object Identifier "id-on-xmppAddr" specified under
> Section 15.2.1.3. In server certificates, this representation is
> included for the sake of backward-compatibility.
>
> 15.2.1.1.4. Common Name
>
> A server's domain identifier MUST NOT be represented as a Common
> Name; instead, the Common Name field MUST be reserved for
> representation of a human-friendly name.
I don't think we need to make this assertion. There's no mention of Common
Name in any of the validation rules that follow, so that would mean the field
is effectively unused for XMPP anyway.
If for some reason we want to help encourage proper use of the Common Name
field, let's go with "SHOULD NOT". I think "MUST NOT" is too ambitious here,
when many servers (or CAs for that matter) still actively populate the Common
Name with the domain and it would be too much to consider all of those certs
non-compliant for XMPP.
> 15.2.1.1.5. Examples
>
> For our first (relatively simple) example, consider a company called
> "Example Products, Inc." It hosts an XMPP service at
> "im.example.com" (i.e., user addresses at the service are of the form
> "[EMAIL PROTECTED]"), and SRV lookups for the xmpp-client and xmpp-
> server services at "im.example.com" yield one machine, called
> "x.example.com", as follows:
>
> _xmpp-client._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com
> _xmpp-server._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com
I'd probably make this example use 5269 for the server port, to avoid
potential distraction from the real topic.
> The certificate presented when connecting to x.example.com contains
> the following representations:
>
> subjectAltName=otherName:id-on-dnsSRV:_xmpp-client.im.example.com
> subjectAltName=otherName:id-on-dnsSRV:_xmpp-server.im.example.com
> subjectAltName=dNSName:im.example.com
> subjectAltName=otherName:id-on-xmppAddr;UTF8:im.example.com
> CN=Example Products, Inc.
>
> For our second (more complex) example, consider an ISP called
> "Example Internet Services". It hosts an XMPP service at
> "example.net" (i.e., user addresses at the service are of the form
> "[EMAIL PROTECTED]"), but SRV lookups for the xmpp-client and xmpp-
> server services at "example.net" yield two machines ("x1.example.net"
> and "x2.example.net") as follows:
>
> _xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net.
> _xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net.
> _xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net.
> _xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net.
5269.
> Example Internet Services also hosts chatrooms at chat.example.net,
> and provides SRV records for those services as well. It also may
> provide other such services in the future, so it wishes to represent
> a wildcard in its certificate to handle future growth.
>
> The certificate presented when connecting to either x1.example.net or
> x2.example.net contains the following representations:
>
> subjectAltName=otherName:id-on-dnsSRV:_xmpp-client.example.net
> subjectAltName=otherName:id-on-dnsSRV:_xmpp-client.chat.example.net
> subjectAltName=otherName:id-on-dnsSRV:_xmpp-server.example.net
> subjectAltName=otherName:id-on-dnsSRV:_xmpp-server.chat.example.net
> subjectAltName=dNSName:example.net
> subjectAltName=dNSName:*.example.net
> subjectAltName=otherName:id-on-xmppAddr;UTF8:example.net
> subjectAltName=otherName:id-on-xmppAddr;UTF8:chat.example.net
> CN=Example Internet Services
>
> 15.2.1.2. Client Certificates
>
> In a digital certificate to be presented by an XMPP client controlled
> by a human user (i.e., a CLIENT CERTIFICATE), it is RECOMMENDED for
> the certificate to include one or more JIDs associated with an XMPP
> user. If included, a JID MUST be represented as an XMPP OID, i.e.,
> as a UTF8String within an otherName entity inside the subjectAltName,
> using the [ASN.1] Object Identifier "id-on-xmppAddr" specified under
> Section 15.2.1.3.
>
> 15.2.1.3. ASN.1 Object Identifier
>
> The [ASN.1] Object Identifier "id-on-xmppAddr" (also called an XMPP
> OID) is defined as follows.
>
> id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
> dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
>
> id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
>
> id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 }
>
> XmppAddr ::= UTF8String
>
> As an alternative to the "id-on-xmppAddr" notation, this Object
> Identifier MAY be represented in dotted display format (i.e.,
> "1.3.6.1.5.5.7.8.5") or in the Uniform Resource Name notation
> specified in [URN-OID] (i.e., "urn:oid:1.3.6.1.5.5.7.8.5").
>
> Thus for example the JID "[EMAIL PROTECTED]" as included in a
> certificate could be formatted in any of the following three ways:
>
> id-on-xmppAddr:
> subjectAltName=otherName:id-on-xmppAddr;UTF8:[EMAIL PROTECTED]
> dotted display format: subjectAltName=otherName:
> 1.3.6.1.5.5.7.8.5;UTF8:[EMAIL PROTECTED]
> URN notation: subjectAltName=otherName:urn:oid:
> 1.3.6.1.5.5.7.8.5;UTF8:[EMAIL PROTECTED]
What is the difference between the dotted and URN notations?
> 15.2.2. Certificate Validation
>
> When an XMPP entity is presented with a server certificate or client
> certificate by a peer for the purpose of encryption or authentication
> as described under Section 6 and Section 7, the entity MUST validate
> the certificate in order to determine if the certificate shall be
> considered a TRUSTED CERTIFICATE, i.e., a certificate that is
> acceptable for encryption and authentication in accordance with the
> XMPP entity's local service policies or configured settings. The
> following rules apply.
>
> 15.2.2.1. Server Certificates
>
> When an XMPP entity (client or server) validates a certificate
> presented by a server, there are three possible cases, as discussed
> in the following sections.
>
> 15.2.2.1.1. Case #1
>
> If the server certificate appears to be certified by a chain of
> certificates terminating in a trust anchor (as described in Section
> 6.1 of [X509]), the entity SHOULD check the certificate for any
> instances of the service name, DNS name, and XMPP OID (in that order
> of preference) as described under Section 15.2.1.1.1,
> Section 15.2.1.1.2, and Section 15.2.1.1.3. There are three possible
> sub-cases:
>
> Sub-Case #1: The entity finds at least one service name, DNS name,
> or XMPP OID that matches the hostname to which it attempted to
> connect; the entity SHOULD use this represented domain identifier
> as the validated identity of the server. Note: the server
> certificate MUST be checked against the hostname as provided by
> the entity (client or server), not the hostname as resolved via
> the Domain Name System; e.g., if a user specifies a hostname of
> "example.net" but a [DNS-SRV] lookup returns "xmpp.example.net",
> the certificate MUST be checked as "example.net". A user-oriented
> client MAY provide a configuration setting that enables a human
> user to explicitly specify a hostname to be checked for connection
> purposes.
> Sub-Case #2: The entity finds no service name, DNS name, or XMPP OID
> that matches the hostname to which it attempted to connect and a
> human user has not permanently accepted the certificate during a
> previous connection attempt; the entity MUST NOT use the
> represented domain identifier (if any) as the validated identity
> of the server. Instead, if the connecting entity is a user-
> oriented client then it MUST either (1) automatically terminate
> the connection with a bad certificate error or (2) show the
> certificate (including the entire certificate chain) to the user
> and give the user the choice of terminating the connecting or
> accepting the certificate temporarily (i.e., for this connection
> attempt only) or permanently (i.e., for all future connection
> attempts) and then continuing with the connection; if a user
> permanently accepts a certificate in this way, the client MUST
> cache the certificate (or some non-forgeable representation such
> as a hash) and in future connection attempts behave as in Sub-Case
> #3. If the connecting entity is a server or an automated client,
> the application SHOULD terminate the connection (with a bad
> certificate error) and log the error to an appropriate audit log;
> a server or automated client MAY provide a configuration setting
> that disables this check, but MUST provide a setting that enables
> the check.
> Sub-Case #3: The entity finds no service name, DNS name, or XMPP OID
> that matches the hostname to which it attempted to connect but a
> human user has permanently accepted the certificate during a
> previous connection attempt; the entity MUST in verify that the
> cached certificate was presented and MUST notify the user if the
> certificate has changed.
"the entity MUST [then] verify" ?
> 15.2.2.1.2. Case #2
>
> If the server certificate is certified by a Certificate Authority not
> known to the entity, the entity MUST proceed as under Case #1, Sub-
> Case #2 or Case #1, Sub-Case #3 as appropriate.
>
> 15.2.2.1.3. Case #3
>
> If the server certificate is self-signed, the entity MUST proceed as
> under Case #1, Sub-Case #2 or Case #1, Sub-Case #3 as appropriate.
>
> 15.2.2.2. Client Certificates
>
> When a server validates a certificate presented by a client, there
> are three possible cases, as discussed in the following sections.
>
> 15.2.2.2.1. Case #1
>
> If the client certificate appears to be certified by a chain of
> certificates terminating in a trust anchor (as described in Section
> 6.1 of [X509]), the server SHOULD check the certificate for any
> instances of the XMPP OID as described under Section 15.2.1.3. There
> are three possible sub-cases:
>
> Sub-Case #1: The server finds one XMPP OID for which the domain
> identifier portion of the represented JID matches one of the
> configured hostnames of the server itself; the server SHOULD use
> this represented JID as the validated identity of the client.
> Sub-Case #2: The server finds more than one XMPP OID for which the
> domain identifier portion of the represented JID matches one of
> the configured hostnames of the server itself; the server SHOULD
> use one of these represented JIDs as the validated identity of the
> client, choosing among them according to local service policies.
> Sub-Case #3: The server finds no XMPP OIDs, or finds at least one
> XMPP OID but the domain identifier portion of the represented JID
> does not match one of the configured hostnames of the server
> itself; the server MUST NOT use the represented JID (if any) as
> the validated identity of the client and instead MUST either
> validate the identity the client using other means or inform the
> client that it is unvalidated by returning a bad certificate error
> and terminating the underlying TCP connection (including logging
> of the event to an appropriate audit log).
"either validate the identity [of] the client using"
Also, I didn't think there was a way to inform the client that it has a bad
certificate. The server can merely log the error and close the connection,
that's all.
> 15.2.2.2.2. Case #2
>
> If the client certificate is certified by a Certificate Authority not
> known to the server, the server MUST proceed as under Case #1, Sub-
> Case #3.
>
> 15.2.2.2.3. Case #3
>
> If the client certificate is self-signed, the server MUST proceed as
> under Case #1, Sub-Case #3.
In all, very nice detailed text.
-Justin
