Re: cert:fingerprint ?

On 22 Nov 2011, at 18:12, Mo McRoberts wrote:

> 
> On 25 Oct 2011, at 19:53, Kingsley Idehen wrote:
> 
>> On 10/25/11 12:38 PM, Henry Story wrote:
>>> On 25 Oct 2011, at 18:33, Kingsley Idehen wrote:
>>> 
>>>> Henry,
>>>> 
>>>> Since we have cert:key, what about cert:fingerprint?
>>> How would you define it?
>> 
>> Good question since WOT [1] and these newer Key oriented ontologies aren't aligned. In addition, WOT is conflating public key and x.509 certificate. The fingerprint I am talking about is a hash (md4, md5, sha, sha256, sha512) of the entire x.509 Cert.
> 
> WoT's definition of 'fingerprint' is horribly underspecced — it really needs to specify (even if just by reference!) how the fingerprint is computed: otherwise, how can you ever perform a reliable comparison?

> For reference, a fingerprint which is included in an X.509 cert (e.g., is often used as subjectKeyIdentifier or authorityKeyIdentifier, and presented in many user interfaces) is actually the fingerprint of the DER-encoded public key data and *not* the rest of the cert.

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

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

So perhaps we can move the discussion of this nascent protocol to the foaf-protocols discussion, as I think it is sidetracking the work on WebID which we now understand very well. WebID with public keys was developed over 3 or 4 years of discussion before we moved to the W3C. HEre we are trying just to formalise and finish what we learnt from our experience.


  HEnry

> PGP does things slightly differently, but not significantly so (from RFC4880 §12.2):
> 
> “For a V3 key, the eight-octet Key ID consists of the low 64 bits of the public modulus of the RSA key.
> 
> “The fingerprint of a V3 key is formed by hashing the body (but not the two-octet length) of the MPIs that form the key material (public modulus n, followed by exponent e) with MD5.  Note that both V3 keys and MD5 are deprecated.
> 
> “A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field.  The Key ID is the low-order 64 bits of the fingerprint.”
> 
> Note that in neither case does the fingerprint contain any User ID packets (which are combined with the public key packet(s) to constitute a full “PGP Certificate” — the closest equivalent of an X.509 Certificate).
> 
> 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
> 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 22 November 2011 18:12:55 UTC