RE: [foaf-protocols] WebID Tool

 in the windows world, folks have a full API in javascript. To be truthful (and this is the web, where folks lie by omission all the time), cryptopolitics means you have to download and install the "browser" component for this API separately. Its not included in the browser download package (though could be, like any of the other signed module "components" that compromise a "browser install"). Now "full" is relative. First the API is constrained according to the whitehouse-community 2000-era compromise - that held off mandatory trusted third party [key escrow] for 10 years - to allow for generation of an eco-system and demand curve. (10 years is up, BTW, as reflected in the work of the NSTIC). Second, less the stellar integration with browser pipelines is facilitated. Browser's could be allowing javascript libraries chosen by the user to insert behaviours into the DOM/javascript processing. But the vendors uniformly dont allow this (since it makes API-based crypto far too "useful").    From: home_pw@msn.com
To: bergi@axolotlfarm.org
CC: foaf-protocols@lists.foaf-project.org; public-xg-webid@w3.org
Subject: RE: [foaf-protocols] WebID Tool
Date: Tue, 9 Aug 2011 21:24:06 -0700









 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
> > 
>