On Sun, Feb 17, 2008 at 06:59:53PM -0800, Justin Karneges wrote: > On Sunday 17 February 2008 5:22 pm, Shumon Huque wrote: > > > > Why is it goofy? The problem I'm trying to solve, is that I > > want to deploy an SSL/TLS protected XMPP service at the domain > > name "upenn.edu", which hosts many other SSL/TLS protected > > non-XMPP services. And I want to do it in such a way that the > > XMPP service cannot use it's X.509 key+certificate to impersonate > > any of the other services (either intentionally or as a result > > of compromise). > > For this you can use an XMPP OtherName field of "upenn.edu" and not use the > other domain identification fields (DnsName or CommonName). Now the > certificate will be XMPP only. However, I now see what you mean. RFC 4985 > is a much more generalized solution than requiring every protocol to have a > special field like XMPP does.
Ah, right. I missed the XmppAddr otherName type in my first reading of RFC 3920. Thanks for letting me know about that! Although a more generalized solution would be preferable. I wonder if it's actually used in practice? And are there any implementations that parse that field for certificate validation purposes. > > I think it could potentially be a solution for talk.google.com if > > everyone adopted it. > > So Google asks its CA for a talk.google.com certificate that contains > _xmpp-client.mydomain.com, which it could then present to XMPP clients that > request the "mydomain.com" domain. The CA would need to get my authorization > before making such a certificate (three parties involved in one transaction). > > I think we're far away from having the infrastructure for this. I guess that depends on what policies the CA has. We have a central office that manages all CSR submissions to our commercial CA, with appropriate vetting. So we could stuff a variety of things into the subjectAltName extension without any additional authorization or interaction with the CA. However I'm not sure if the CA will actually issue certs with such extensions, since I haven't tried yet! > 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. All it needs to do is leave out the other > fields and we are there. 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. --Shumon.
