[cap-talk] A petname toolbar for Firefox

[David Wagner]

Trevor Perrin writes:
>An alternative is to form a fingerprint by hashing (CA pubkey || domain 
>name).  If you don't want to use a 3rd-party CA, you can make your own.

That's equivalent to storing (CA pubkey, domain name), from a security
point of view.  The only point in displaying H(X) rather than X itself is
perhaps for useability reasons, to reduce the amount of information
presented to the user.  But I'd rather store X instead of H(X); it gives
me more flexibility.  And in this case, there is an argument that perhaps
you'd rather display (CA pubkey, domain name) rather than a hash, in case
users find it meaningful to examine the domain name associated with some
given petname.

>Wouldn't it achieve the same thing if the client just ignored cert validity 
>intervals?  If the server wishes to stop depending on the CA, it simply 
>stops renewing its certificate (which highlights that your proposal 
>eliminates the usefulness of validity intervals in reducing the damage done 
>by a compromised key).

In theory, that works, but in practice, I suspect it's not viable.
The server would have to keep presenting its expired certificate to all
comers.  However, I believe this will cause most modern browsers to pop
up a scary-looking "certificate expired" window, and that might be reason
enough to cause the server administrator to be reluctant to continue
using the expired certificate.

>In an ideal world, it might be better to form a fingerprint by hashing (CA1 
>pubkey, CA2 pubkey, domain name, "either of [1,2] must sign a subkey 
>certificate to make it valid under this fingerprint").

I don't know.  In my ideal world, I'd sign only the server's long-term
public key.  In essence, the server would act as its own CA.  If the server
wants to change its SSL key, it can do so by producing a new self-signed
certificate (signed by its CA key, and containing its SSL key).  The petname
scheme could store the server's long-term key (i.e., its CA key), and accept
any SSL key signed by that CA key as a valid identifier for that site.
This would eliminate the vulnerability to incompetent or malicious CAs.

The only purpose of a CA is to introduce you to a site.  But maybe there
are other ways to be introduced to a site, too.  (For instance, we could
have an extended-style URL which contains both a https: URL as well as a
public key to use when authenticating the corresponding server.)  And it
seems that we could probably separate the "being introduced to a site" from
the "identifying that it is the same site that you visited the last time"
functionality.