W3C home > Mailing lists > Public > public-lod@w3.org > February 2010

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

From: Story Henry <henry.story@bblfish.net>
Date: Mon, 22 Feb 2010 15:48:08 +0100
Cc: Linked Data community <public-lod@w3.org>
Message-Id: <CCDB4689-70A8-4B6B-B710-B384E904720C@bblfish.net>
To: nathan@webr3.org, foaf-protocols@lists.foaf-project.org

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

Now if someone has some good suggestions of time slice ontologies to use, I think we could document how to do that. For the moment we have not had the need for it.


. It makes the claim that the object of the relation is the only agent that can unlock the key. So when someone steals your private key then

:pk cert:identity :thief, :me .
Received on Monday, 22 February 2010 14:48:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:03 UTC