Re: cert:fingerprint ?

On 11/22/11 1:12 PM, Henry Story wrote:
> 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

Of course it does [1].

>       its name space

It doesn't. It actually controls its data access address 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

No it doesn't.

Remember, the WWW is basically the worlds ultimate middleware. Thus, 
middleware techniques are native and natural. A proxy/wrapper URI is 
just about middleware packed into a link.

>     - the mime types of tweets is not well defined

Wrong, see comment above.
>     - tweets dissapear

Wrong, via API you always have access to your own tweets. You can always 
find a specific tweet via its ID and delete it. On the other hand, you 
can always make another tweet too. The costs are insignificant.

Starting with a Tweet is not about *sole* solution, it is about low 
escape velocity by planting seeds in dense user clusters on the Web. We 
call this principle: maximum incorporation of current and future 
innovations with minimum disruption to what exists. That's 100% better 
than "rip and replace" plus all the political battles that ensue.

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

You are wrong!

Twitter will only adopt WebID, in the manner you seek, after the 
opportunity costs of not adopting it become palpable. They are a 
business. That's how executive make business decision. They never make 
technology purity decisions. Even when they are technically capable.

> 2. it is not as if disk space was what was missing on the internet

That isn't the issue. Disk space isn't the constraint. Time and 
Attention are the constraints.

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

Huh? Again, where in all of this do you see loss of public key? 
Remember, in Linked Data graphs you can make lots of other claims e.g., 
owl:sameAs etc.. The power of Linked Data is about making claims about 
anything, whenever, and from wherever as long as you have access to a 
place where you have privileges to drop an EAV/SPO based claim.
> 4. there are then security issues that need to be looked at with hashes, since a lot of information is lost

You freaked out when Harry made this kind of comment, and now you are 
doing the same to make a point? What exactly is the security issue? 
Remember, this is about choosing a splice of a security token and using 
it in a "mirrored claim". What is this scary security vulnerability? Be 
specific now.


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

Yes, it doesn't need to happen here at all. Personally, best suited for 
RWW group as this isn't FOAF specific either.

> WebID with public keys was developed over 3 or 4 years of discussion before we moved to the W3C.

And nothing about what we are doing invalidates that. Come on now! 
What's with all this mutual exclusion mindset?

> HEre we are trying just to formalise and finish what we learnt from our experience.

Yes, and those interested in what we are doing can pick this up via the 
RWW group.

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


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen