[cap-talk] A petname toolbar for Firefox

[Trevor Perrin]

At 02:03 AM 2/19/2005 -0800, David Wagner wrote:
>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.

Yes.

>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.

I wouldn't stop users from storing or displaying (fingerprint, domain 
name), if they consider the domain name useful metadata or a "nickname" for 
the fingerprint (the self-authenticating name).  But it's nice if the 
self-authenticating name is as small and self-contained as possible, since 
users will probably have to manipulate it to some extent (sharing it, 
typing it, comparing it, etc.).

But this is just a useability point.


> >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.

Yes, but I thought your proposal was for servers to switch to presenting 
their raw end-entity public key or cert at some point, without a CA cert, 
which will cause problems too.


> >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.

Agree completely, particularly with the last sentence.  It's useful to 
separate acquisition of a crypto-identity from maintenance of the temporal 
integrity of that crypto-identity ("being introduced to a site" vs. 
"identifying that it is the same site that you visited last time"), or 
even, perhaps, ("public key distribution" vs. "private key management").

As you point out, one could use certificates for both.  A certificate from 
a trusted 3rd party might convince a relying party of the subject's crypto 
identity.  A certificate from the subject's "master key" to a "subkey" 
helps maintain integrity of the master key.

The point I was trying to make was a slightly weird one.  It was this: in 
your paragraphs above, you assume the server's crypto-identity is his 
long-term public key.  However, a crypto-identity could be a more "virtual" 
concept, which includes public key(s) possessed by 3rd parties whom the 
owner of the crypto-identity trusts.

In other words, I believe 3rd-party CAs could help with "maintenance of 
temporal integrity" as well as introductions (and I believe they currently 
do - Verisign doesn't only do introductions, it helps with key revocation 
and replacement; these are very different functions, and it's bad to 
combine them in a single authority as PKI does.  Nonetheless we should take 
this into account when analyzing PKI and how to replace it).

For maintaining the integrity of his crypto-identity, the subject (i.e. the 
creator and owner of the crypto-identity) would choose some CAs whom he 
trusts to authenticate him and issue him subkey certificates.  Presumably, 
he would choose these CAs instead of a maintaining his own long-term key 
because they have better key-management practices than he himself is 
capable of (physical security, backup, auditing, or online 
availability).  Then he can hash the CA keys plus some usage rules into his 
fingerprint.  The fingerprint becomes, then, the interface between the 
private-key-management and public-key-distribution domains.

Anyways, as you end by pointing out, "there are other ways to be introduced 
to a site" than relying-party-trusted CAs.  I agree wholeheartedly (see 
Tyler's YURLs or my cryptoURLs).  I'd just like to add that 
*subject-trusted* CAs may still have a place in future 
petname/self-authenticating-name systems.


Trevor