[cap-talk] Re: First point of consensus - agreed? Any more dissent?

[Tyler Close]

On Feb 21, 2005, at 7:21 PM, Sandro Magi wrote:

> I'm not sure where all this perceived effort is coming from. It was 
> pretty
> easy for me to visit my bank site after installing the petname bar, and
> type in 'Easyweb' to acknowledge I have some sort of trust relationship
> with this site.
>
> Unfortunately, due to the way the site is designed (round robin DNS, 
> with
> each host having its own cert), after login the petname bar displays
> 'untrusted' since the (domain name, CA public key) pair doesn't match 
> an
> existing entry. I'm not sure if this particular situation can be 
> trivially
> addressed within Firefox petname toolbar. It may simply be an
> implementation artifact.

Interesting, that's exactly the same thing I did after creating the 
petname toolbar. I also bank with TD.

The structure of the TD web banking site is an unfortunate, but 
inevitable consequence of the design of the WWW PKI. A cautious 
security design gives each server its own identity. This way, if one 
server gets hacked, the others may still be secure. Unfortunately, 
since the WWW PKI only lets you apply for an end entity certificate, 
there's no way to create a certificate hierarchy that reveals the fact 
that all the physical servers may be considered to be a single logical 
server. If you look at the certificate chain for one of the physical TD 
servers, its only 2 levels deep. The RSA certificate directly vouches 
for one of the TD physical server certificates.

I've designed the HTTPSY protocol to better address this problem. Using 
HTTPSY, you'ld create a CA certificate for the web banking application. 
This key pair would only be used to sign a certificate issued to a 
physical server. The httpsy URL for the web banking application would 
contain the fingerprint of the CA public key. Using this design, each 
physical server can still have its own unique certificate, but the 
hierarchy expresses the fact that they all form a single logical 
server. The petname toolbar would bind the petname to the CA public 
key, so the same petname would be used, regardless of which physical 
server you were currently connected to.

For today, the best we can do is assign a petname to the TD login 
server, which is always the same. This petname lets us recognize the TD 
login server. Since the TD login server redirects us to one of the 
physical application servers, we know that we're talking to a server 
that TD wants us to talk to. We don't get the same warm fuzzy feeling 
of always having a petname displayed, but there's enough information to 
be confident we aren't talking to a spoof site. It's not perfect, but I 
think it's the best we can do with the current certificate layout.

The current WWW PKI is just so pathetic. We really need HTTPSY.

Tyler

---
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/