On Sunday 17 February 2008 5:22 pm, Shumon Huque wrote: > On Sun, Feb 17, 2008 at 04:39:17PM -0800, Justin Karneges wrote: > > On Sunday 17 February 2008 2:23 pm, Shumon Huque wrote: > > > In a later message in the same thread, I brought up the additional > > > possibility of using RFC 4985 to perform certificate checks: > > > > IMO, this is totally goofy. A CA creating such a certificate would need > > authorization from both the certificate owner and the target service. > > Maybe this could be useful for some internal organization, but it is > > probably not very useful on the open internet. RFC 4985 is certainly no > > solution for talk.google.com, which is what this explicit trust stuff is > > usually about... > > 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. > 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. 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. > This is a general problem (although many people don't realize it). > The predominant certification model in the Internet today is to > issue certificates for hostnames. The problem is that a given > host/domain-name may be providing many services, and for proper > compartmentalization of security, there needs to be way to more > granularly specify what entity a certificate is actually for (such > as a specific service running on a host). Indeed. I didn't realize what you were asking at first. You're right, it is a general problem. At least XMPP does have a non-general solution. -Justin
