[Standards] XMPP Certificate checking algorithm

Peter Saint-Andre stpeter at stpeter.im
Mon Feb 18 04:59:16 UTC 2008

Shumon Huque wrote:
> On Sun, Feb 17, 2008 at 09:15:43PM -0700, Peter Saint-Andre wrote:
>> 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.
> What string is in the XmppAddr field? 

In your case, I think that would be "jabber.upenn.edu" (that's the
JabberID of the xmpp service running at your institution).

> Looks like the spec says a
> "JID", 

A server has a JID, such as "jabber.org" or "xmpp.example.com".

> so in theory the domain identifier portion of that JID
> could be used. But yes, there's a backward compatibility problem
> with clients that don't understand the extension.

We really really like to presence backwards-compatibility. :)

> If the CN or dnsName includes a name, then it may be possible to
> steal the certificate and reuse it to impersonate other services
> at that name, assuming client software for those services just
> ignore XmppAddr because they don't understand it. That's a security
> problem in my opinion.


> I still think RFC 4985 provides a more elegant solution to this.
> That will allow inclusion of the hostname of the machine actually
> providing the service and an otherName specifying the service. And
> I think avoids the backward compatibility issue.

I'll take a closer look at RFC 4985 soon.


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/20080217/3d0fa764/attachment.bin>

More information about the Standards mailing list