[foaf-protocols] The case for massive simplification and foaf:key

Melvin Carvalho melvincarvalho at gmail.com
Tue Sep 21 13:52:42 CEST 2010


On 21 September 2010 11:13, Henry Story <henry.story at bblfish.net> wrote:

>
> On 21 Sep 2010, at 01:24, Nathan wrote:
>
> > Hi All,
> >
> > I've been discussing off-list with Melvin and various others over the
> past few months about many future uses of webid, public keys and various
> implications of the way we are currently doing things.
> >
> > To start, here's the proposal:
> >
> > :me foaf:key "DER-formatted-public-key"^^xsd:base64Binary .
> >
> > Verbally:
> > To remove all usage of cert,rsa etc from the webid protocol and replace
> with a single foaf:key property, the value of which is a DER formatted
> Public Key.
> >
> > Recognition:
> > Henry, in no way does this reflect poorly or undermine you or your work,
> I'm sure I won't be alone in saying that you've made an outstanding effort
> thus far, with much personal sacrifice to bring something to the web which
> we will all be forever grateful for, it's not often somebody can "change the
> game" as much as you have. Similarly this is just a proposal for discussion
> and every con/objection should be aired. (Can you tell I feel a bit awkward
> making such a big suggestion)
>
> I hope this bit of flattery still allows me to say something :-|
>
> You seem to be suggesting here that you think you may be hurting my
> feelings, that I may
> be attached to some way of doing things a certain way because I did them,
> more than
> because I have been trying to think about them in detail.  Let me assure
> you that my aim
> is more to get at the reasons for why we do things, and make sure they are
>  good ones that
> can stand up to inspection by the ever growing community.
>
> Thanks for making the proposal. I hope you will take the following answer
> seriously
> and answer it as carefully as I am here.
>
> > Reasons:
> > Only one triple, thus greatly simplifying the webid protocol for users,
> implementers, adopters and implementations, it's very very easy to
> understand and execute for all.
>
> That is true it is simple to write out.
>

The simplicity of this solution does seem to stand out, to my mind.

Now that we have the ASN.1 parser in PHP I'll be happy to support this
structured format, with the proviso that the namespace is not yet decided,
tho foaf sounds logical to me.  (I was even mailed an offer to patch
libAuth, this morning)

That is in addition to any formats that makes it into the WebID Protocol
spec (which Im assuming is still a work in progress).

As an implementor I'd try an support as many formulations of a public key as
time allows, and that I have a parser for.


>
> > it speeds up implementations of the webid protocol exponentially,
>
> I think we need to look at this in more detail. You are making a strong
> claim here.
>
> First this type of thing is really important only for very large
> installations
> such as Google, and they tend to have good engineers to solve these
> problems.
> So your argument has to be about it necessarily being exponentially more
> complicated.
>
> Now think of Google or Identi.ca or any place with a lot of good engineers.
> They will
> when this starts getting big want to place the WebID server side reasoning
> as close as
> possible to the SSL layer. At that layer the parsing of the x.509 cert has
> already been
> done, because TLS requires the extraction of modulus/exponent from the key!
> So they
> have two BigInts there already.
>
> They can then query that graph, that will often be cached, for the modulus
> which they
> already have and is most likely unique. So that is one query. Then the
> verification
> of the exponent is the only extra step that was required.
>
> That is not to me exponential complexity increase! It is one more query,
> and that
> could be optimised of course, by finding a notation to put both in one
> relation
> such as "mod:exp", if needed.
>
> At that point it is unlikely that many frameworks have access to a PEM/DER
> encoded
> cert.
>
> > creating a very small memory footprint. To expand:
> > - the current rsa+cert representation requires the entire document to be
> parsed and stored in memory in order to 'query' for a matching webid, often
> this will include a dependency on sparql,
>
> Don't think there is a dependency on SPARQL at all.
>
> > and when done with only native code procedurally is quite complex
> (although do-able), this is relatively heavy and can produce a high memory
> footprint.
>
> We have all done it, in all the languages I believe.
>
> > - the suggested foaf:key proposal requires no data storage or sparql
> implementation, all that is required is an RDF Parser, further if that
> parser implements a streaming API then (this part of the) webid protocol can
> be implemented with no more than a simple parser filter along the lines of:
> > if(t.property = 'foaf:key' && t.subject = webid && t.object = key)
> >   return true;
> > return false;
>
> Ok so you are now relying on the PEM/DER encoding of a certificate.
>
> > This will exponentially decrease both the memory footprint of
> implementations and execution time of a webid implementation.
> > - if a streaming api is not used then this part of the protocol can be
> implemented with a simple fast existential quantification test, such as:
> >  RDFStore.some(filterFromAbove);
> > again this offers significant speed increases and removes any real or
> implied sparql dependency / usage.
>
> So finding your public key now is a one query operation, but you have to
> parse it to find the
> modulus and exponent. So you have replaced a simple lookup with a few
> parsing operations: the
> transformation of the hex string to DER, the parsing of the DER, the
> finding of the modulus and
> hex.  Do those parsing operations outweigh the query to the store?
>
> Only if you want to force the use of PEM/DER certificate encoding. But then
> you loose out
> on potential PGP/GPG encoding as done by WOT. Those also have a lot of
> advantages.
>
> > - if sparql is used, then a very simply ASK query can be used to see if
> the triple { webid foaf:name key } exists.
>
> And what if the person as we all have now publishes the modulus and
> exponent? What about things like
> XML-DSIG that publish it in that form? What about other people who publish
> their keys in PGP format,
> as the WOT ontology does? The point of WebID is that we can integrate these
> ways of doing things too.
>
> > WebID protocol already has a dependency on FOAF the FOAF vocabulary is
> wide spread, introducing foaf:key and thus WebID protocol in to foaf will
> increase the exposure of WebID protocol massively.
>
> That would be ok, but my fear is you think that this means simple string
> comparison on a certificate will be all that is needed.
>
> Btw, WebID protocol does not have a dependency on FOAF. And that is really
> not at all because we don't like foaf - the wiki is all under foaf+ssl! - it
> is more in order to simplify the discussion when dealing with people in
> standards committees - The less hooks they have to criticise,
> the easier it is to get through! And this is not an issue about the W3C or
> anywhere else.
> It is good engineering. If you look at the stack of protocols one always
> tries to reduce dependencies
> as much as possible.
>
> But that does not mean that a reasoner could not use foaf:key . Since all
> those formats by default
> have rsa/dsa keys in them, they can be inferred by a reasoning engine.
>
> > WebID Protocol and foaf:key will bring many benefits to FOAF, including
> adding addition weight to the "how do I use this in a user system?" and "why
> should I use this?" questions would be adopters have.
>
> Yes, but I also mentioned a few times in the proceeding thread that users
> don't then see
> immediately the relation to their certificate.
>
> > allows users to get going with web 3.0 / decentralized social networking
> (FOAF+SSL!) with a single familiar and easy to use ontology.
> > Placing in FOAF means it's at least 2 less ontologies to dereference at
> runtime, and for implementers to support and understand.
>
> I hope you don't constantly dereference all the ontologies you come across.
> I don't...
> Or perhaps only at compile time.
>
> But implementers will have to understand RSA/DSA. Now you are forcing them
> to also understand
> ASN.1.  In any case the libraries to do this already exist now.
>
> > It's a natural home!
>
> Well I am not against a relation you describe in foaf.
> But it's not really any more natural there than elsewhere.
>
> >
> > DER is a near ubiquitous defacto format for public keys and widely
> supported in almost every language / runtime.
> > PEM *is* DER wrapped in some human readable text, strip the text and you
> have a DER (hence the above statement).
>
> What about PGP?
>
> > DER allows us to simplify down to a single triple.
> > Implementations will often have to do no heavy lifting / parsing as the
> native language libs or runtime will offer PEM/DER formatted Public Key
> support.
> >
> > Compatibility, two fold, in one sense as mentioned it allows the public
> key to be used thus allow serendipitous invention of new and brilliant uses
> of the foaf:key, in another sense it means webid protocol is natively
> compatible with many other public key based "things" from github/hg through
> to full WOT and all in between; complementing this it points everything
> towards FOAF profiles and a web of linked data, get a profile, stick your
> key in it, use it for anything!
>
> But you can do that with the public key alone. All the magic of encryption
> is in the
> rsa mod/exponent not in the certificates. It is the RSA mod/exponent
> algorithm that
> can be printed on the back of T-shirts.
>
> http://www.cypherspace.org/adam/shirt/
>
> The magic is not in the ASN.1 encoding which is just a legacy (pre-XML)
> notation.
>
>
> > As a simple example of scope, I could simply pull your foaf:key, use it
> to seal a message and then save it in public on the web, knowing that only
> you could view the sealed data.
>
> But you can do that with the RSA key alone!
>
> > I could sign documents I've created on the web (where i am dc:creator)
> and simply stick the hash in my FOAF
> >  { http://ex.org/some#post :signature "FD.." }
>
> Again you don't need the DER encoding for that either.
>
> > then everybody on the web could verify that I did indeed create/own the
> document and that it hadn't been tampered with. Millions of other use cases,
> many of which will be far more exciting and clever than these.
>
> I think you need to read up a bit more about public key cryptography. You
> seem to think this
> can only be done using PEM/DER. But all that can be done using just the
> public key.
>
> Look at XML-DSIG. RSA/DSA those are they key pieces of maths:
>
>   http://www.w3.org/TR/xmldsig-core/#sec-KeyValue
>
> >
> > I'm sure there are more benefit and some cons (can't really think of any
> tbh, maybe BC but there are how many of use with webid's and support?),
>  hopefully that's enough for us to consider the proposal and get discussing.
>
> Well thanks for the proposal.
>
> I think I can see that your proposal is coloured by the way Apache is
> sending you the key in its
> environmental variables. Other platforms don't see that at all. So we
> should be careful to
> make a protocol that depends on such contingent factors, that could well be
> different in differnt
> platforms.
>
> I hope those answers make sense.
>
> >
> > Best,
> >
> > Nathan
>
> Social Web Architect
> http://bblfish.net/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100921/9c3999d4/attachment.htm 


More information about the foaf-protocols mailing list