[Standards] rfc3920bis: proposed certificate text

[Peter Saint-Andre]

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
"user (AT) im (DOT) example.com"), 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
"user (AT) example (DOT) net"), 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 "juliet (AT) im (DOT) example.com" as included in a
certificate could be formatted in any of the following three ways:

id-on-xmppAddr:
subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet (AT) im (DOT) example.com
dotted display format: subjectAltName=otherName:
1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
URN notation: subjectAltName=otherName:urn:oid:
1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com

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.

[Justin Karneges]

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
> "user (AT) im (DOT) example.com"), 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
> "user (AT) example (DOT) net"), 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 "juliet (AT) im (DOT) example.com" as included in a
> certificate could be formatted in any of the following three ways:
>
> id-on-xmppAddr:
> subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet (AT) im (DOT) example.com
> dotted display format: subjectAltName=otherName:
> 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
> URN notation: subjectAltName=otherName:urn:oid:
> 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com

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

[Peter Saint-Andre]

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
>> "user (AT) im (DOT) example.com"), 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
>> "user (AT) example (DOT) net"), 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 "juliet (AT) im (DOT) example.com" as included in a
>> certificate could be formatted in any of the following three ways:
>>
>> id-on-xmppAddr:
>> subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet (AT) im (DOT) example.com
>> dotted display format: subjectAltName=otherName:
>> 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
>> URN notation: subjectAltName=otherName:urn:oid:
>> 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
>
> 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/

[Alexey Melnikov]

Justin Karneges wrote:

>On Tuesday 03 June 2008 9:58 am, Peter Saint-Andre wrote:
>
>
>>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 was about to suggest the same. People will ignore MUST NOT, if they
can't comply with it for practical reasons.

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

[Dave Cridland]

On Tue Jun 3 17:58:19 2008, Peter Saint-Andre wrote:
> 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 have a feeling this breaks sdrawkcab compatibility for some older
applications, and arguably a domain identifier is a reasonably human
friendly name, so I think SHOULD NOT/SHOULD is probably more
appropriate. (Also, RFC 2119 would suggest that as a MUST NOT/MUST
implies that ignoring it will prevent interoperability, it's the
wrong choice anyway).

> The certificate presented when connecting to x.example.com
> contains
> the following representations:


> The certificate presented when connecting to either
> x1.example.net or
> x2.example.net contains the following representations:

I'm mildly concerned that this might be taken to mean it's only the
"server certificate" in terms of the TLS client/server split. These
certificates are also presented as the client certificate of a S2S
session. Maybe sticking with "presented by", or really spelling it
out, might help.

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

The OID is just the ASN.1 object identifier, so this comes across as
a bit odd - you can't represent a JID as an OID, as such.

> 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 "juliet (AT) im (DOT) example.com" as included in a
> certificate could be formatted in any of the following three
> ways:
>
> id-on-xmppAddr:
>
> subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet (AT) im (DOT) example.com
> dotted display format: subjectAltName=otherName:
> 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
> URN notation: subjectAltName=otherName:urn:oid:
> 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
>
>
This bit is all weird - it's discussing some string representation
that I suspect is specific to OpenSSL, but I'm really not sure.
Either way, an OID in an X.509 certificate is represented as an OID -
it's a native type in BER, DER, or whatever it is that X.509
certificates use, so this discussion is a bit like discussing how to
represent an element in XML.

> 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.
>
>
Hmmm... Any certificate, or indeed no certificate at all, is
acceptable for encryption.

The discussion on what to do if the certificate is not suitable for
authentication is interesting, too - again, it's a case of confusing
whether a certificate provides authentication with whether it's a
sign of active tampering.

I think this stems from "HTTPS", where TLS is the only form of server
authentication, so if the server certificate doesn't validate, then
without an explicit go-ahead from a human, you mustn't continue. For
XMPP, aside from the fact that we have a history of trusting the DNS,
we also typically have other mechanisms for authenticating the
server, since we have SASL.

Ideally, clients faced with a certificate which does not validate
should use a mechanism providing both channel binding and mutual
authentication, but mutual authentication is the key here.

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) dave (DOT) cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Shumon Huque]

On Wed, Jun 04, 2008 at 02:57:16PM +0100, Dave Cridland wrote:
> On Tue Jun 3 17:58:19 2008, Peter Saint-Andre wrote:
> >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 have a feeling this breaks sdrawkcab compatibility for some older
> applications, and arguably a domain identifier is a reasonably human
> friendly name, so I think SHOULD NOT/SHOULD is probably more
> appropriate. (Also, RFC 2119 would suggest that as a MUST NOT/MUST
> implies that ignoring it will prevent interoperability, it's the
> wrong choice anyway).

I also agree with this. Much as we'd all like to denigrate the use
of Common Name for hostnames and hostname like things, I think it's
too much of a practical barrier at the current time to deployed
infrastructure to say MUST NOT.

> >subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet (AT) im (DOT) example.com
> > dotted display format: subjectAltName=otherName:
> > 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
> > URN notation: subjectAltName=otherName:urn:oid:
> > 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
> >
> >
> This bit is all weird - it's discussing some string representation
> that I suspect is specific to OpenSSL, but I'm really not sure.
> Either way, an OID in an X.509 certificate is represented as an OID -
> it's a native type in BER, DER, or whatever it is that X.509
> certificates use, so this discussion is a bit like discussing how to
> represent an element in XML.

Yup, I agree. The same OpenSSL configuration file style syntax
also appears in Section 15.2.1.1.5:

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.

It might be better to describe how the SAN fields should be populated,
without referring to an application specific syntax, eg.

otherName type of SRVName (id-on-dnsSRV) contains an IA5String
(ASCII) string of: "_xmpp-client.im.example.com"
otherName type of XmppAddr (id-on-xmppAddr) contains a UTF8
string of: "im.example.com"
dNSName contains an ASCII string of "im.example.com"

(PS. I don't think the Peter's syntax for SRVName works in current
versions of OpenSSL. I think you'd need to spell out the whole
OID and it's content type with:

subjectAltName=otherName:1.3.6.1.5.5.7.8.7;IA5STRI NG:_xmpp-client.im.example.com
)

--Shumon.

[Peter Saint-Andre]

On 06/04/2008 7:57 AM, Dave Cridland wrote:
> On Tue Jun 3 17:58:19 2008, Peter Saint-Andre wrote:
>> 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 have a feeling this breaks sdrawkcab compatibility for some older
> applications, and arguably a domain identifier is a reasonably human
> friendly name, so I think SHOULD NOT/SHOULD is probably more
> appropriate. (Also, RFC 2119 would suggest that as a MUST NOT/MUST
> implies that ignoring it will prevent interoperability, it's the wrong
> choice anyway).

It's SHOULD NOT in my working copy now.

>> The certificate presented when connecting to x.example.com contains
>> the following representations:
>
>
>> The certificate presented when connecting to either x1.example.net or
>> x2.example.net contains the following representations:
>
> I'm mildly concerned that this might be taken to mean it's only the
> "server certificate" in terms of the TLS client/server split. These
> certificates are also presented as the client certificate of a S2S
> session. Maybe sticking with "presented by", or really spelling it out,
> might help.

OK.

>> 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.
>
> The OID is just the ASN.1 object identifier, so this comes across as a
> bit odd - you can't represent a JID as an OID, as such.

Right, I was using "XMPP OID" as a shorthand term. Other suggestions are
welcome. Or we can refer to these three representations by their real
names as id-on-dnsSRV, dNSName, and id-on-xmppAddr if that is clearer.

>> 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 "juliet (AT) im (DOT) example.com" as included in a
>> certificate could be formatted in any of the following three ways:
>>
>> id-on-xmppAddr:
>> subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet (AT) im (DOT) example.com
>> dotted display format: subjectAltName=otherName:
>> 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
>> URN notation: subjectAltName=otherName:urn:oid:
>> 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
>>
>>
> This bit is all weird - it's discussing some string representation that
> I suspect is specific to OpenSSL, but I'm really not sure. Either way,
> an OID in an X.509 certificate is represented as an OID - it's a native
> type in BER, DER, or whatever it is that X.509 certificates use, so this
> discussion is a bit like discussing how to represent an element in XML.

That's more of an implementation note than anything else, but it is my
understanding that all three of those representations are equivalent and
that this is not just an OpenSSL issue. Would it help to recommend one
over the other?

>> 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.
>>
>>
> Hmmm... Any certificate, or indeed no certificate at all, is acceptable
> for encryption.

I don't follow.

> The discussion on what to do if the certificate is not suitable for
> authentication is interesting, too - again, it's a case of confusing
> whether a certificate provides authentication with whether it's a sign
> of active tampering.
>
> I think this stems from "HTTPS", where TLS is the only form of server
> authentication, so if the server certificate doesn't validate, then
> without an explicit go-ahead from a human, you mustn't continue. For
> XMPP, aside from the fact that we have a history of trusting the DNS, we
> also typically have other mechanisms for authenticating the server,
> since we have SASL.

But dialback is not a SASL mechanism. We could use DIGEST-MD5 I suppose
or any other password-based mechanism, but in practice that is not done
since it would require a prior agreement between the peers.

> Ideally, clients faced with a certificate which does not validate should
> use a mechanism providing both channel binding and mutual
> authentication, but mutual authentication is the key here.

Again I'm not sure I follow, but I am not an X.509 geek. :)

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Peter Saint-Andre]

On 06/04/2008 9:36 AM, Shumon Huque wrote:
> On Wed, Jun 04, 2008 at 02:57:16PM +0100, Dave Cridland wrote:
>> On Tue Jun 3 17:58:19 2008, Peter Saint-Andre wrote:
>>> 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 have a feeling this breaks sdrawkcab compatibility for some older
>> applications, and arguably a domain identifier is a reasonably human
>> friendly name, so I think SHOULD NOT/SHOULD is probably more
>> appropriate. (Also, RFC 2119 would suggest that as a MUST NOT/MUST
>> implies that ignoring it will prevent interoperability, it's the
>> wrong choice anyway).
>
> I also agree with this. Much as we'd all like to denigrate the use
> of Common Name for hostnames and hostname like things, I think it's
> too much of a practical barrier at the current time to deployed
> infrastructure to say MUST NOT.
>
>>> subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet (AT) im (DOT) example.com
>>> dotted display format: subjectAltName=otherName:
>>> 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
>>> URN notation: subjectAltName=otherName:urn:oid:
>>> 1.3.6.1.5.5.7.8.5;UTF8:juliet (AT) im (DOT) example.com
>>>
>>>
>> This bit is all weird - it's discussing some string representation
>> that I suspect is specific to OpenSSL, but I'm really not sure.
>> Either way, an OID in an X.509 certificate is represented as an OID -
>> it's a native type in BER, DER, or whatever it is that X.509
>> certificates use, so this discussion is a bit like discussing how to
>> represent an element in XML.
>
> Yup, I agree. The same OpenSSL configuration file style syntax
> also appears in Section 15.2.1.1.5:
>
> 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.
>
> It might be better to describe how the SAN fields should be populated,
> without referring to an application specific syntax, eg.
>
> otherName type of SRVName (id-on-dnsSRV) contains an IA5String
> (ASCII) string of: "_xmpp-client.im.example.com"
> otherName type of XmppAddr (id-on-xmppAddr) contains a UTF8
> string of: "im.example.com"
> dNSName contains an ASCII string of "im.example.com"

Yes I'll do that. I almost did the first time. :)

> (PS. I don't think the Peter's syntax for SRVName works in current
> versions of OpenSSL. I think you'd need to spell out the whole
> OID and it's content type with:
>
> subjectAltName=otherName:1.3.6.1.5.5.7.8.7;IA5STRI NG:_xmpp-client.im.example.com
> )

Yeah, the lines got too long so I arbitrarily truncated them to fit the
RFC text file format in a fit of pique because I wanted to submit the
damn I-D. :)

But using your suggested text will solve that problem anyway...

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Peter Saint-Andre]

BTW a diff with recent changes is here:

http://is.gd/qNk

Peter

--
Peter Saint-Andre
https://stpeter.im/