Re: Storing PKCS#12 inside FOAF profile for FOAF+SSL

Story Henry wrote:
> On 22 Feb 2010, at 15:07, Nathan wrote:
>> So I can just chain up multiple public key pairs in my FOAF profile ya?
>>> yes, you just need to tie them to your WebId.
>>>
>>> See my foaf, where I have two:
>>>
>>> http://bblfish.net/people/henry/card
>>>
>>> Henry
>> perfect - thanks :)
>>
>> next quick question; expired certificates - need to be removed from FOAF
>> profile yeah?
> 
> very good question. As we are just looking at improving the cert ontology ( http://www.w3.org/ns/auth/cert ) it would be worth looking at that 
> 
> So currently you are publishing a relation from your public key to the person who knows the public key:
> 
> :pk a rsa:RSAPublicKey;
>     cert:identity :me ;
>     rsa:public_exponent "65537"^cert:decimal ;
>     rsa:modulus """ba111346f7555ac5ad4378c73ce 0f921fc4f4dd69dcea003
>                   0b6d294e6f8b133ce29812e1cbfd8bcceb43c7d87a6083a9f
>                   1fdb67a267fe32ac7ff4643b7988d1f63bee924643fb33c5e
>                   16859b9b606b0242bc69e91069c6e93f4c4a2cc3fb12887b7
>                   190c675fcef24f10a05669f0e750d7fc9922e958b79d8f3e1
>                   30821123259f"""^cert:hex .
>                  
> 
> the cert:identity is really a relation between a public key and an agent that knows the private key for it. It is not a relation between a _certificate_ and the agent that knows its public key for its private key. You could have a number of certs each using the same public key that would expire at different dates. The SSL layer communicating with your browser would have to reject those certificates that had expired.
> 
> So it has been suggested that we have a better named relation between the agent and the public key. Perhaps cert:public_key, cert:controlsPublicKey, cert:knowsPrivateKeyOfthisPublicKey, cert:canOpen, cert:canUnlock ?
> 
> We could then write this
> 
> :me xxx:canUnlock :pk .
> 
> So what happens if your private key is stolen? Well now 
> 
> thief xxx:canUnlock :pk .
> 
> and both are true.
> 
> This brings me to the point that cert:identity is not quite the inverse of xxx:canUnlock. cert:identity is functional. It is saying that there is only one person who can unlock the key. This is important because otherwise one could not deduce from someone knowing the key, whom it identified. If you claim that a public key is your cert:identity, you are obliged to take precautions with your key and make sure that the statement remains true (or you are either irresponsible or a liar).
> 
> But as Bruno, just pointed out, you may still want to make a claim about there being a time at which you were cert:identified by the key, so that you can make claims about statements being made before a certain date. To do this we will need a notion of an identity on a time slice of a person. So we don't want to make cert:identity such a relation because it's nice an direct, and it covers most cases.
> 
> We would need something like this
> 
> :pk cert:timeIdentified [ a TimeSlice;
>                           of :me;
>                           from "2009-10-10..."^^xsd:dateTime;
>                           to "2010-01-01..."^^xsd:dateTime .
>                          ] .
> 
> It does not make sense to have time slices on a key, as that is a mathematical entity, very similar to a literal.

seems to me that a cert:Certificate should / could have Validity details
on there (issued-on, expires on) - it's all ready catered for in
certificates just needs expressed in the vocab.

?

Received on Monday, 22 February 2010 14:59:50 UTC