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.
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
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.
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]
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.
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).
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.
smime.p7s
Description: S/MIME Cryptographic Signature
