[foaf-protocols] X509 Ontology for foaf+ssl

Melvin Carvalho melvincarvalho at gmail.com
Mon May 11 11:52:04 CEST 2009

On Thu, May 7, 2009 at 10:54 PM, Story Henry <henry.story at bblfish.net> wrote:
> 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?

Just throwing out ideas here, in case they catch on ...

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

After a SPARUL update using arc2, it is something like this:

  <rdf:Description rdf:nodeID="arc0509b5">
    <rdf:type rdf:resource="http://www.w3.org/ns/auth/rsa#RSAPublicKey"/>
    <ns2:identity rdf:resource="http://foaf.me/melvincarvalho#me"/>
    <ns3:modulus rdf:nodeID="arc0509b6"/>
    <ns3:public_exponent rdf:nodeID="arc0509b7"/>

  <rdf:Description rdf:nodeID="arc0509b6">

  <rdf:Description rdf:nodeID="arc0509b7">

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

No particular feedback, though I did think the SPARUL insert may be
easier.  And it may be possible to eliminate some bnodes.

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

If the default is set to 65537 then there should be no problem.  I
think this covers the vast majority of cases, if you want a different
exponent, you can fall back to the full format.  As an aside, if the
exponent is > 1 I'm not even sure if it's possible to have collisions.
 (I'll see if I can dig up a proof)

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

This is a good point.  I guess you have to weight the pros and cons,
if there's not great perceived gain having in a top level description,
that's fair enough.

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