Re: cert:fingerprint ?

On 22 Nov 2011, at 18:12, Henry Story wrote:

> Thanks that is very useful. That means that it is a lot less certificate dependent than I thought. It is ASN.1 dependent though. I think PGP also uses ASN.1 right? So the same public key would have the same signature in both, perhaps....

No… PGP is different, not ASN.1-based. In some ways better, in some ways worse...

For any given RSA key (and RSA keys easiest to deal with for illustration, but this applies to other kinds too), you can find your fingerprint might be generated in one of three ways — at least:

- The PKCS canonical form (DER-encoded SEQUENCE)
- The PGP v3 public key packet fingerprint
- The PGP v4 public key packet fingerprint

All three of these are perfectly valid *for exactly the same key material*. i.e., you can generate a binary sequence to be hashed given the appropriate data in some form (such as a cert:RSAPublicKey instance) and generate any one — or all three of these fingerprints — from it.

Thus, anything which talks about a fingerprint must specify *precisely* what fingerprint it canonically means.

> 
> My issues with publishing hashes of keys is that 
> 1. it is being pushed because of the use case of publishing on twitter and the lack of space of a tweet. But I don't believe in that use case

Ahhhh, that's the use-case. Ick. Sending in a DM, maybe, but as somebody who uses Twitter *a lot*… that's… horrible.

>   - the use case does not contain a WebID: one has to assume there is a webid that twitter would give each user - but it is twitter that controls
>     its name space
>   - it requires one to use the twitter json interface to go from imaginary webid to the hash, so the protocol ends up being completely twitter specific
>   - the mime types of tweets is not well defined
>   - tweets dissapear
>   - if twitter wanted to allow WEbID's it would take them no time at all to allow them by following the specification we are putting together here
> 2. it is not as if disk space was what was missing on the internet
> 3. publishing the hash looses the advantage of being able to then use the public key for all kinds of other tasks such as verifying signatures etc...
> 4. there are then security issues that need to be looked at with hashes, since a lot of information is lost

These are not such a big deal necessarily. PGP keyservers allow lookup by "key ID", which is derived from the hash. You can then pick the one which has signed a certificate (in this case, a PGP certificate) naming the person you're dealing with. A *purposeful* hash collision in this scenario vary from the “not possible to exploit” to the “entirely hypothetical”, depending on your algorithm choice.

In an ideal world, you'd never bother with fingerprints, but where you need human comparison to take place, it's an acceptable tradeoff to date.

M.

-- 
Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ

Received on Tuesday, 22 November 2011 18:44:30 UTC