Re: cert:fingerprint ?

On 11/22/11 2:43 PM, Mo McRoberts wrote:
> On 22 Nov 2011, at 19:24, Kingsley Idehen wrote:
>
>> Please look at the footer section, you have a plethora of data representation formats at your disposal. I opted to share an HTML document :-)
> Ah, brilliant, thanks! Displaying the URL somewhere would be pretty useful all the same, FWIW.
Yes, we also do it via:

1. <link/> in <head/>
2. "Link:" response headers.

We've used all the options the Web gives us, but sometimes its still not 
enough :-)

>
>> You have to explore the TBox (ontology links).
> I did, and because I couldn't see anything, I read the RDF behind it, too. It may be non-obviously-linked, but as far as I could see there is no spec nor human-readable description of what the fingerprint is meant to contain according to your schema, except for its datatype (string), range (hex) and domain (a certificate). How can one verify or even generate a fingerprint when there's nothing that tells you what the rules are?

In the case of WebID, post successful TLS handshake, there is a lookup 
against modulus and exponent (public key components) of the cert. used 
in the handshake. All we are doing is adding a fingerprint lookup to 
this process. That's it :-)

> It has to -come- from somewhere, right? It’s not self-describing or self-explanatory. A fingerprint which has no generation rules has, by definition, no use.

Correct, but that isn't the case re. WebID protocol. The "mirrored 
claims" based proof is driven by the fact that an association exists in 
an IdP space that associates a cert. subject (Identified using WebID) 
with a certificate (the one used in the TLS handshake). Thus, modulus 
and exponent and/or fingerprint (hash of the cert which is part of the 
cert used in the handshake) == fine.

>
>> Think a little different. It is about letting you use a tweet to publish claims associated a verifiable identifier (aka. WebID). It also enables a simple tweet deletion to invalidate a certificate in a keystore/keychain e.g. when you PC, notebook, tablet, phone gets stolen.
> Right… okay, that's a really horrid use of Twitter (I mean, technologically it's neat, but as a -user- it amounts to abuse of the medium and, more importantly, abuse of the people who follow me).

Twitter is a public space. You tweet what you like. Folks subscribe to 
your tweets or tune out. They have the freedom to do that. The 
fundamental goal here is to place a claim in a space you own/control. It 
works for Tweets, Blog Posts, LinkedIn posts, Facebook etc..
>
>>> Your original point was "there's conflation between certs and keys going on", which I don't doubt — because everything which talks about 'fingerprints' tends to not specify *what* binary data is being hashed and how, but all of the real-world uses of fingerprints in their various guises seem to be key-oriented, not cert-oriented, even if they pretend otherwise by being attached to certificates and certificate-related things.
>> Yes, and be it public key components (modulus and exponent) or an entire certificate hash, the end game is use of "mirrored claims" and security tokens as mechanism for verifying subjects.
> You’re either missing or ignoring my point: as underdocumented as the properties may be, no uses of “fingerprint” in the real world appear to be “certificate hashes” — they’re all key hashes.

I am not missing your point. My point is simply this: we had a specific 
need, we tweaked in our own namespace, and its optional to everyone 
else. Here's what I haven't stated or imply: everyone must do this :-)


>
> M.


-- 

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