[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:Description rdf:nodeID="arc0509b6">
    <ns2:hex>9373DDE736A2EA0B89BFAF85B83D0443F457CF7830132C2B88DA530D97E3DE65849821D94EA7E04DE3ED25CF890E36D03901635D782FE12393A0CCEE6A981936F0D375B77828169A7462B151C4081DCEC8EC2E1F588F726B1394D59A7AA660C5EFB52E45AD40873BCBE3295DD2E09EB722D6C68F19BB0D333D3F240A05BBCBCA640D761E98753703C52CE1FB090E4096E9804F648EFDFAFD809EC73092EEDF56D20C0CF9B9C2B267733FC132F6F05F2ACE04EE8F61483F6159784436311A607AE8DA5202017522CDAE9BC8A4D78DB92D859D503DE0966E7A648724A68AA2FEC8877BE4525E4BA7C0C91BFAC1DCFC5F8FDA39A5F2E772E448B3EBA01962106159</ns2:hex>
  </rdf:Description>

  <rdf:Description rdf:nodeID="arc0509b7">
    <ns2:decimal>65537</ns2:decimal>
  </rdf:Description>

>
>>  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.
>>>
>>>
>>> WHAT WE NEED
>>> ------------
>>>
>>> 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
>>>
>>>
>>>
>>> SKETCH OF AN X509 ONTOLOGY
>>> --------------------------
>>>
>>> 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)
>>>
>>>
>>> WHAT SHOULD ONE PUBLISH?
>>> ------------------------
>>>
>>> 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