On 06/03/2008 9:31 PM, Justin Karneges wrote: > 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.
Works for me. Changed.
>> 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
Copy and paste error. Fixed.
> 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.
Fixed.
>> 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?
None.
>> 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" ?
s/in//
>> 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"
Fixed.
> 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.
Hmm, probably not. I've removed the last clause.
>> 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.
Happy to hear it. :)
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
