[Standards] XMPP Certificate checking algorithm

Peter Saint-Andre stpeter at stpeter.im
Mon Feb 18 04:15:43 UTC 2008


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

Peter

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

-------------- 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/7e15cc6d/attachment.bin>


More information about the Standards mailing list