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 "[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]
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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
