Re: [cap-talk] A petname toolbar for Firefox

[David Wagner]

Tyler Close writes:
>On Feb 18, 2005, at 8:36 AM, Ka-Ping Yee wrote:
>> Why do you store the petname keyed by
>> the root CA's fingerprint instead of the site's fingerprint?
>> (I see that you still use the domain name so that different
>> domains signed by the same CA are distinct, but i don't see why
>> the CA's certificate needs to be involved at all.)
>
>Under HTTPS, the end entity certificate typically has a lifetime of only
>1 year. The only persistent identifier for the site is the ( domain
>name, CA public key ) pair.
>
>Binding the petname to a non-persistent site identifier would suck, as
>the binding would regularly become invalid, producing a situation much
>like a spoofing attack. This interaction model would desensitize the
>user to broken petnames, undermining the protection model.

You mean that the public key isn't a persistent identifier?  Are you
saying that HTTPS website administrators generally change their public key
every year when they get a new cert?  I didn't know that.  Yuck!
Tell me it's not so...

Well, if that is how the world works, I guess we have to deal with it.
Here is an idea for a small extension to your scheme.  What if you
allowed a match on either site fingerprint or (CA pubkey, domain name)?

More specifically: When we create a new petname, we store both the
public key fingerprint and the (CA pubkey, domain name).  If we are
visiting a site and want to see if we have any petname for it, we first
check whether there is any known petname with a matching fingerprint.
If yes, we have a petname that identifies this site.  If not, we then
check whether we have any known petname with a matching value of (CA
pubkey, domain name).  If yes, we have a petname.  Otherwise, no petname.

This gives the public key fingerprint precedence over CAs, reducing
dependence on CAs.  For instance, if I run a site and next year I decide
not to pay another $395 to renew my certificate, I'd like my site to
continue working for users who have registered my site as a petname.
So long as I don't change my public key, this works fine.

It might also make sense to have an option that turns off matching on
CAs, for users who want to reduce their vulnerability to incompetent CAs.
As a security engineer, the idea of identifying endpoints by (CA, domain
name) rather than by their public key sounds ugly.  But, I think you
are making the right decision to prioritize useability over security
against incompetent CAs.  Of course, it is still the case that all too
many of the usual CAs are incompetent -- witness the way Verisign signed
a Microsoft cert for someone who was not Microsoft -- but today security
failures due to phishing are much more prevalent than security failures
due to incompetent or malicious CAs.

What do you think?


P.S. I like the suggestion Ping made of having our browsers try HTTPS by
default, and encouraging websites to use self-signed HTTPS certificates
for all transactions.  (Was it Ping who made this suggestion?)  I've used
self-signed certs on a Redhat Linux box.  It is easy and painless, and
I have yet to encounter any good reason to go back to plain old HTTP.
I'm sure some websites would dislike the performance hit, but I like it.