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... > > -Justin
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). RFC 4985 provides a way to do this. And actually, I think it could potentially be a solution for talk.google.com if everyone adopted it. 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). Another security compartmentalization reason one might want certificates tied to hostnames and authorized to provide a specific service is: if an SRV record points to 50 backend hosts, then you can revoke the certificate of a single compromised host, instead of having to revoke one shared certificate, and taking down the whole system. This of course assumes that revoking a certificate actually does something in the real world :-) In case it wasn't clear, I was proposing this only as an optional certificate validation method for those organizations that want to use it. --Shumon.
