[Standards] XMPP Certificate checking algorithm

Peter Saint-Andre stpeter at stpeter.im
Thu Feb 21 17:49:16 UTC 2008

Peter Saint-Andre wrote:
> Shumon Huque wrote:
>> On Sun, Feb 17, 2008 at 06:59:53PM -0800, Justin Karneges wrote:
>>> On Sunday 17 February 2008 5:22 pm, Shumon Huque wrote:
>>> An easier solution is for me to ask my CA to create a certificate for 
>>> mydomain.com that contains an XMPP field of "mydomain.com" and doesn't use 
>>> the other domain identification fields.  Then I give this certificate (and 
>>> private key) to Google.  Admittedly we don't really have the infrastructure 
>>> for this either, but we are close.  I think the StartCom CA can populate the 
>>> XMPP field if you ask for it.  
> The XMPP ICA (with StartCom as the root) does populate this field,
> whether you request it or not.
>>> All it needs to do is leave out the other 
>>> fields and we are there.
> Why?
>> Yeah, I agree. RFC 4985 is new, and it will certainly take time to 
>> figure out if protocols, people, software implementors, and CAs will
>> actually use it in practice. But I'd be nice to keep the door open for
>> protocols to use things like this.

I've had a chance to read RFC 4985 (sometimes travel is a good thing!).
Here is my understanding...

According to this spec, a certificate presented by an XMPP service would
include an SRVName, i.e. an object identifier (OID) of id-on-dnsSRV,
where the SRVName takes the following form:


So what does this mean in practice?

First let's take Shumon's example of upenn.edu, which resolves via SRV
to jabber.upenn.edu. In this case, the certificate would include an
SRVName of _xmpp.jabber.upenn.edu, which would help the connecting
client (or server) to know that jabber.upenn.edu is the authorized
domain for connecting to the canonical XMPP service at upenn.edu (e.g.,
thus knowing that the DNS SRV lookup did not return poisoned results).

Now let's take another popular example: Google Talk. As I understand it,
if you connect to gmail.com or googlemail.com or any one of the many
Google Apps services, you would be presented with a certificate that
contains an SRVName of _xmpp.talk.google.com; thus you would know that
this "redirection" is acceptable.

>> If the XmppAddr otherName field is populated, I think we'd definitely
>> want language in the spec that says the subject CN and other fields
>> must be left blank (which I don't see in the current RFC). Otherwise 
>> you may not be able to enforce the constraint on the certificate's
>> use.
> rfc3920bis says that if id-on-xmppAddr is included, you must use that as
> the identity:
> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-05.html#security-validation
> How should the certificate be validated if it does not include a CN or
> dnsName and the validating application does not understand xmppAddr? And
> will a responsible CA even issue certificates without a CN? I know that
> the XMPP ICA / StartCom won't do that.

If we go down this path, then:

1. I think that we probably want to deprecate use of the id-on-xmppAddr
OID in server certificates, since the SRVName meets our needs (this
would not apply to clients).

2. I think that we probably want to deprecate use of the dnsName form in
server certificates.

3. I don't think we can tell CAs not to include a Common Name, since
many CAs probably have a policy that a certificate needs to include a CN
(as mentioned, I know this is true of StartCom, which is the root CA for
the XMPP ICA). However, I think we can specify that the relying party
(connecting client or server) must not treat the CN as a domain name for
purposes of certificate validation (even if it says something like
"jabber.org" or "upenn.edu"). In other words, the Common Name should be
a human-friendly name like "The Jabber.org Project" or "The University
of Pennsylvania", which is not used for certificate validation.

Open issue: should wee allow a certificate to contain multiple instances
of the SRVName? This seems advisable, since the result of an SRV lookup
can include multiple domain names. In this case, we need to specify the
matching rules (e.g., if any one domain matches then the relying party
should consider the certificate to be valid).

Or so it seems to me.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080221/9f48d824/attachment.bin>

More information about the Standards mailing list