[foaf-protocols] Why exponent/modulus

Melvin Carvalho melvincarvalho at gmail.com
Sun Sep 19 14:00:31 CEST 2010


On 19 September 2010 11:09, Toby Inkster <tai at g5n.co.uk> wrote:

> On Fri, 17 Sep 2010 22:26:23 +0200
> Melvin Carvalho <melvincarvalho at gmail.com> wrote:
>
> > By the way we already have in WOT
>
> In my initial thoughts on FOAF+TLS I suggested using an updated WOT:
>
> http://lists.w3.org/Archives/Public/semantic-web/2008Mar/0207.html
>

I do think it's time for WOT 0.2, in particular the link from a User (now
WebID) to a PubKey

What do you think is better?

1. The WOT style linking of a User to a PubKey e.g.

webid wot:hasKey <PubKey>

2. The CERT style linking of a PubKey to a cert, and then to a user (WebID)

as per the cert ontology

3. Two way linking, ie both?

I strikes me that we need (1) independent of any X.509 certificate
ontology?


>
> I do think Henry's RSA vocab is a better way though.
>
> Placing (or linking to) a PEM/DER-encoded certificate in ones FOAF file
> would hit upon issues of canonicalisation. If you performed a naive
> string comparison between the certificate used in the TLS connection,
> and the one found in the FOAF file, you'd probably come along instances
> where the strings differ but the certificates are essentially
> equivalent.
>
> So we're going to need to canonicalise values before we do a
> comparison. Better to perform the canonicalisation in a space we
> clearly understand (hexadecimal integers) rather than one we do not
> understand so well (base64-encoded DER-serialised ASN1 structures).
>
> In other news, I've just uploaded a developer version of my Perl
> CGI::Auth::FOAF_SSL library which no longer depends on parsing the
> command-line output of the OpenSSL binaries, amongst other improvements.
>
> --
> Toby A Inkster
> <mailto:mail at tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100919/c50a061d/attachment.htm 


More information about the foaf-protocols mailing list