Peter Saint-Andre wrote: > 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.
I've had a chance to read RFC 4985 (sometimes travel is a good thing!). Here is my understanding... According to this spec, a certificate presented by an XMPP service would include an SRVName, i.e. an object identifier (OID) of id-on-dnsSRV, where the SRVName takes the following form: _xmpp.domain So what does this mean in practice? First let's take Shumon's example of upenn.edu, which resolves via SRV to jabber.upenn.edu. In this case, the certificate would include an SRVName of _xmpp.jabber.upenn.edu, which would help the connecting client (or server) to know that jabber.upenn.edu is the authorized domain for connecting to the canonical XMPP service at upenn.edu (e.g., thus knowing that the DNS SRV lookup did not return poisoned results). Now let's take another popular example: Google Talk. As I understand it, if you connect to gmail.com or googlemail.com or any one of the many Google Apps services, you would be presented with a certificate that contains an SRVName of _xmpp.talk.google.com; thus you would know that this "redirection" is acceptable. >> 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. If we go down this path, then: 1. I think that we probably want to deprecate use of the id-on-xmppAddr OID in server certificates, since the SRVName meets our needs (this would not apply to clients). 2. I think that we probably want to deprecate use of the dnsName form in server certificates. 3. I don't think we can tell CAs not to include a Common Name, since many CAs probably have a policy that a certificate needs to include a CN (as mentioned, I know this is true of StartCom, which is the root CA for the XMPP ICA). However, I think we can specify that the relying party (connecting client or server) must not treat the CN as a domain name for purposes of certificate validation (even if it says something like "jabber.org" or "upenn.edu"). In other words, the Common Name should be a human-friendly name like "The Jabber.org Project" or "The University of Pennsylvania", which is not used for certificate validation. Open issue: should wee allow a certificate to contain multiple instances of the SRVName? This seems advisable, since the result of an SRV lookup can include multiple domain names. In this case, we need to specify the matching rules (e.g., if any one domain matches then the relying party should consider the certificate to be valid). Or so it seems to me. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
