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
