RE: [foaf-protocols] WebID Tool

 Its good to see someone use the same core rationale as me : that keygen (and websites) are not always what one wants. This upsets some folks, who want a world in which website ownsers control user keys. Some folks still think of the web as a PC-world, one device, one web. Its not, for most of us. On my e-book reader (that posts to twitter, does DRM etc), I dont even have any choice, since its web-powered, but there is no web "browser". In military key management, you dont do online key management. Period. (Although even thats changing a bit, after 20 years experience with internet-style PKI. GSM/UTMS these days does CRMF/CMS-style initial trust anchor (self-signed cert) loading, but NOT keygen, note) > Date: Wed, 10 Aug 2011 00:08:48 +0200
> From: bergi@axolotlfarm.org
> To: home_pw@msn.com
> CC: foaf-protocols@lists.foaf-project.org; public-xg-webid@w3.org
> Subject: Re: [foaf-protocols] WebID Tool
> 
> 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
> > 
>