[foaf-protocols] X509 Ontology for foaf+ssl

Story Henry henry.story at bblfish.net
Thu May 7 22:54:25 CEST 2009

On 7 May 2009, at 14:33, Melvin Carvalho wrote:
> I've been wondering if it might be possible to have a "shorthand"
> version of the public key representation (under perhaps the "cert" of
> "foaf" namespace?) which uses some sensible defaults, during the
> adoption phase, much in the same way that we use "foaf:openid" as a
> shorthand for an open id account
> Ideal would be to have it as a single triple,

What is simple is never easy. Finding another way to serialise the key  
could take a lot of time. And if we find
them, then we have to update all of our servers simultaneously, which  
would then become more complex too, which could also
slow adoption, as it would leave more space for bugs.

Why do you feel the need for this?

> thereby allowing
> relatively straightforward serialization into RDFa or RDF/XML.

Can you show me the rdfa and rdf/xml serialisations you are using?  
Perhaps there are simpler ways to write them out?
Perhaps this will point to an evident flaw.

>  This could perhaps get a lot of websites or identity pages up and  
> running
> as web ID providers, quite quickly.

Why do you think the serialisation is a problem? Have you had feedback  
from someone?
Crypto is always a bit of a learning curve to get started.

> I think the exponent check could be set to a default as you're not
> going to have identical public keys with different exponents.

I don't think the exponent is optional, at least that is what I  
understood when I read the wikipedia entry for RSA.
I don't think a shortcut there is going to be a big advantage.

> Thoughts?

I don't think that the adoption has to do with the serialisation  
problems. Look at the weird atom format that comes out
of twitter for example. Adoption for these things just takes time. I'd  
say we are getting a lot of exposure, and things
are moving nicely. If we try to 'simplify' without good reason, we may  
well make a lot of other things more complicated.


Cycling through Europe just now.

> 2008/10/13 Story Henry <henry.story at bblfish.net>:
>> So to get foaf+ssl basics going it should help if we have develop a  
>> little
>> X509 ontology. Perhaps we can get a very basic one going, with just  
>> the
>> classes we need for our protocol. We can then add more later as we  
>> need
>> them. I am not sure how much we need/can integrate this with the wot
>> ontology.
>> ------------
>> This is what we have been using currently, and it seems to be  
>> enough to get
>> us going. I am using as a prefix for the ontology that we are  
>> working on.
>> :me is xxx:identity of [ a xxx:x509Certificate;
>>                         xxx:sigType xxx:md5WithRSAEncryption;
>>                         xxx:sigValue
>> "4d85aae9e4c4afc0384fc10b56a9cd61125e804717c0bbe324a7c85d2c9da14696a0c9eb7714e3d375a2ff0edf363c484c5dfcd779985de8ed9f29c6926f827778553bc2984276fea9c69d051ef6c7579fc610fee67feebd112c800664dc86bbc9f1794ae0d0b79f6f502fcda5c4bd24026312f1faabbc2aaae2ec35c2f5244c";
>>                          ];
>> Ie we need :
>>  - a relation from an X509 Certificate to the thing it is  
>> identifying (
>> xxx:identity ) ( :me )
>>    [ the ' ... is REL of ... construction is another way of  
>> speaking of the
>> inverse relation to REL ]
>>  - a way of specifying a unique identifying feature of that  
>> certificate
>>     this requires two things it seems:
>>          + the value of the signature
>>          + the type of the signature
>>    ( Are there other ways of identifying X509 certificates? Hex ids  
>> perhaps?
>> )
>>    We need this in order to help link a person to their certificate  
>> when the
>> server gets the key
>> --------------------------
>> Here is a first attempt to sketch out an ontology for X509 in UML  
>> with the
>> help of Bruno Harbulot
>> @prefix time: <http://www.w3.org/2006/time#> .
>> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>> Notes:
>>   - In an X509 certificate the certificate is usually (I think)  
>> about an
>> agent. But I imagine that one could
>>     certify information about anything. So I tried to be a bit more  
>> general.
>> Perhaps I should not.
>>   - it does not look like there is much that hangs above on the  
>> particular
>> X509 documents in the above. It looks like one can get a good  
>> general idea
>> of a certificate.
>>   - should the signature link to the signee ? It does indirectly  
>> via the
>> public key that verifies it.
>>   - the public key identifies the agent, because the agent knows  
>> the private
>> key
>>   - any better name for the relation between a public key and a  
>> private key?
>>     the following rule needs to hold
>>      { ?pubkey :identifies ?agent } => { ?agent :knows ? 
>> privateKey . ?pubKey
>> :private ?privateKey }
>>   - the PGP public key is a subclass of a certificate because it  
>> signs a
>> number of statements about a subject
>>     (usually at least his email address and his public key)
>> ------------------------
>> In our current examples we are publishing the relation in the foaf  
>> of the
>> person to their certificate signature.
>> :me is xxx:identity of
>>      [ a xxx:x509Certificate;
>>        xxx:sigType xxx:md5WithRSAEncryption;
>>        xxx:sigValue
>> "4d85aae9e4c4afc0384fc10b56a9cd61125e804717c0bbe324a7c85d2c9d...";
>>      ].
>> Should one not rather just be publishing the relation from the  
>> person to
>> their public key(s)? So using the
>> ontology sketched in the UML diagram [1]
>> :me is uml:identity of
>>      [ a uml:PublicKey, uml:RSAKey;
>>        uml:modulus  
>> "00:b3:a1:b3:3d:a9:b1:b4:87:32:97:86:9f:c4:9e:...";
>>        uml:exponent "65537"
>>      ] .
>> This would be both a useful way to publish one's public key, and a  
>> way to
>> help confirm the relation between the foaf file and the x509  
>> certificate.
>> Now if one then used the Public key to sign one's own foaf file,  
>> then in a
>> sense the foaf file would turn out to be a uml:Certificate.
>> I am still just finding my way through this space. So I may have  
>> got a lot
>> wrong. Don't hesitate to correct me.
>> Henry
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

More information about the foaf-protocols mailing list