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/
smime.p7s
Description: S/MIME Cryptographic Signature
