[cap-talk] A petname toolbar for Firefox

[Trevor Perrin]

At 07:39 PM 2/18/2005 -0800, David Wagner wrote:
>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?

Good question!  I don't know, but tried to find out.  It seems keys are 
often re-used but you can't count on it.

For renewal, administrators just send another CSR (certificate signing 
request).  Whether it's based on a new key or old key is a matter of 
choice.  It seems leaving the old key intact is easier, so that's more 
often done.  People often recommend new keys, though (see end of mail).


>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)?

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.

This gives a single fingerprint for the relationship, which is easier to 
exchange or view than the triple (fingerprint, 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.

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 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").  Call all the data 
in parentheses a "criteria".  A server could choose CA1 = some 3rd party, 
and CA2 = a key held by himself.  Then the server could authenticate 
himself by presenting the criteria (which the client matches against the 
fingerprint) and his current subkey certificate.

This would allow the fingerprint creator to distribute responsibility for 
his crypto-identity across two parties, reducing dependence on 
either.  Sadly, I don't see how you could twist X.509 / SSL to support this.


Trevor


(Quotes on certificate renewal):

 From VeriSign's Certificate Practice Statement:
"Prior to the expiration of an existing Subscriber's Certificate, it is 
necessary for the Subscriber to obtain a new certificate to maintain 
continuity of Certificate usage.  VeriSign generally requires that the 
Subscriber generate a new key pair to replace the expiring key pair 
(technically defined as "rekey").  However, in certain cases (i.e., for web 
server certificates) VeriSign permits Subscribers to request a new 
certificate for an existing key pair (technically defined as "renewal")."
http://www.verisign.com/repository/CPS2.3/VeriSignCPS2.3.pdf

 From popup on Thawte's site:
"Usually, before you can renew a Certificate, a new Key/CSR pair will has 
to be generated off the server, the Key must then be backed up and then the 
newly created CSR has to be submitted through the renewal process.

But, when renewing a Certificate requested for any of the Server Software 
Platforms listed below, you will not need to submit a new or renewal CSR in 
order to get your renewal Certificate. It will use your old CSR for your 
renewal Certificate." (following is a list of many servers; IIS is missing).
http://www.thawte.com/renew/

 From Carlisle Adams' PKI book, recommending against putting the same key 
in multiple certs:
"It is too easy to "slip up" and not hold all other important aspects of 
these multiple certificates constant. [...]  If a single public key is 
contained in multiple certificates and the private key is compromised (or 
other circumstances occur that require revocation), it must be "remembered" 
(or discovered) which certificates contain this key so that they may all be 
revoked. [...] Having the same public key in multiple certificates can 
complicate the administrative processes involved in certificate management."
http://www.amazon.com/exec/obidos/ASIN/0672323915/104-7451273-2110334