[Standards] XMPP Certificate checking algorithm

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Mon Feb 18 06:26:45 UTC 2008


On Sunday 17 February 2008 8:15 pm, Peter Saint-Andre wrote:
> Shumon Huque wrote:
> > 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.

I don't think this needs to be forced.  If you want the constraint, just leave 
out the other fields.

> How should the certificate be validated if it does not include a CN or
> dnsName and the validating application does not understand xmppAddr?

You take your cert that has an XMPP field only, and you configure it into 
Apache for HTTPS.  Every browser will fail to validate the cert, which is the 
desired result. :)

> And will a responsible CA even issue certificates without a CN? I know that
> the XMPP ICA / StartCom won't do that.

The certificate could (and probably should) still have a CN, but it would be 
something that can't be parsed as a domain name, such as "XMPP Server 
Certificate for foo.com".  Technically, storing domain names in the CN field 
is deprecated (see RFC 2818), although everyone still does it for 
backwards-compatibility.

-Justin



More information about the Standards mailing list