W3C home > Mailing lists > Public > public-xg-webid@w3.org > August 2011

Re: [foaf-protocols] WebID Tool

From: bergi <bergi@axolotlfarm.org>
Date: Wed, 10 Aug 2011 00:08:48 +0200
Message-ID: <4E41AFF0.4040003@axolotlfarm.org>
To: Peter Williams <home_pw@msn.com>
CC: foaf-protocols@lists.foaf-project.org, "public-xg-webid@w3.org" <public-xg-webid@w3.org>
Mainly I created this tool to help developers/testers who have deal with
more than one browser. Currently many people maintain their FOAF file
manually. So there are two options if you generate your WebID with HTML
<keygen>: Add a public key for every browser to your FOAF file or
export/import your certificate. With the tool you only have to import
the PKCS12, which is usually easier. Also you get a minimal FOAF for
your WebID. If you have already some PKCS12 on your disk and you want to
know which one contains which URI, the tool can also open existing files.

For a broader acceptance I think there is now way besides HTML <keygen>.
Everything else we have now is to complicated for most people.

Nowadays more and more JavaScript programs use cryptographic functions.
I expect browser vendors will provide an API for their crypto stores
soon or later. Let's the how this API will look like.

Am 09.08.2011 19:50, schrieb Peter Williams:
> 
> are you assuming that the browser imports the keying material from
> the PKCS#12 output, rather than use keygen? if so I like the design.
> Its waht I advocated - use offline key management, divorced from the
> web. Its the original CA model (in fact), which assumed NO online
> presence for a CA, given the disaster that follows given its nature,
> if its signing key are compromised (by leakage through the online
> protocol). PKCS#12 is quite general. There is really no reason why
> one of its tagged streams could be be including the RDF within the
> stream. Thus the rdf stream is indirectly signed, etc. one could
> imagine a mozilla plugin being able to read the objects within the
> PKCS#12 stream, and use the profile information, while the browser
> engine itself uses the evil (asn.1 encoded) cert and private key
> streams. This would require Mozilla to open up access to the stream
> objects in its crypto store to plugins. Im not sure DOD will allow
> them to do this, though. DoD have the browser vendors lock up the
> API, so it reduces the crypto capabilities to what these agencies
> things consumers OUGHT to have.
>> Date: Mon, 8 Aug 2011 22:26:35 +0200 From: bergi@axolotlfarm.org 
>> To: foaf-protocols@lists.foaf-project.org; public-xg-webid@w3.org 
>> Subject: [foaf-protocols] WebID Tool
>> 
>> As side-product of the WebID test suite I've created a little
>> command line tool to generate WebID certificates and FOAF files.
>> Last weekend I added a simple GUI.
>> 
>> Screenshot: https://resourceme.bergnet.org/files/WebIDTool.png
>> 
>> Download: 
>> https://resourceme.bergnet.org/downloads/WebIDTool-20110808.zip
>> 
>> 
>> the bergi _______________________________________________ 
>> foaf-protocols mailing list foaf-protocols@lists.foaf-project.org 
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> 
Received on Tuesday, 9 August 2011 22:09:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 9 August 2011 22:09:14 GMT