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

Re: using ASN.1 formats for WebID description

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 26 Jan 2011 20:25:07 +0100
Cc: "<danbri@danbri.org>" <danbri@danbri.org>, "<public-xg-webid@w3.org>" <public-xg-webid@w3.org>
Message-Id: <0D2A71FF-81A9-4CB4-868F-B412DAB07B53@bblfish.net>
To: Peter Williams <home_pw@msn.com>
Ok so you want to allow there to be a ASN.1 based representation
at the WebID URL, in addition to the RDFa, RDF/XML, and other
representations in section 2.3 of the current spec

  http://www.w3.org/2005/Incubator/webid/ED-spec-20110121/

Some things that would be required:

 1. To have a format that allows multiple keys in the file
    (so a user can have multiple certs, one for each browser)
 2. A format that is widely used by many tools, I think people 
    claimed PEM was
 3. A way to add metadata from that file to richer versions of
   the file. A seeAlso to the RDFa  (that's html marked up
   with RDF) representation or another access controlled file
 4. the semantics of such a file format. There is no GRDDL for
    ASN.1 yet, and so this would require some work
 
When you speak of this helping new users trying to understand the
protocol, you of course mean *developers*. And not any kind of 
developer, but security tuned developers, with a liking of command
line tools, who feel more comfortable seeing ASN.1, written out in
a special version of BASE-64, wrapped with headers. 

Mom and pops users would of course never go close such files, and no
company with a support department would ever want them to. User 
want their WebID to land them on a page with pictures and human 
readable text, with forms they can edit. They want to be able to
change their picture with a point and click form.

Browsers will want much richer formats that what is possible in ASN.1
For example I can imagine a very good browser enhancement, where the
browser would fetch the graph from the WebID found in a cert in order
to improve the cert selector by filling it up with information from the
graph: say the picutre or logo of the user, his name, sex, ... I can
also imagine the browser showing the user which cert he is using on each
site and giving him a link to his PersonalProfile (WebID). Clicking this
he could edit all his information.

Now the protocol we have makes it completely possible to have what
you want. I would be interested to see if that really makes some 
people want to deploy WebID more, or if this is just a way to sidetrack us
into supporting and maintaining an old format. It is difficult to say.

I would not be against putting some proposal on the wiki for something 
like that. We can then see how much enthusiasm it generates in terms
of real implementations. And we can also document the pros and cons in
detail over time.

Henry


On 26 Jan 2011, at 18:20, Peter Williams wrote:

> No. The problem is that a new user tying to understand the protocol material currently has to understand the many steps of getting ready to use the protocol, before seeing it's value.
> 
> Folks need to be able to experiment with the core flow, without having to first get their own foaf card, keys, or certs.
> 
> Having seen a self-asserted credential scheme in action, they can then get their own credential set using some very, very technical websites.
> 
> To be convinced that the core flow is viable, the main use cases need to be on display.
> 
> 1 initial access, where cert picker correctly displays
> 2 return access to same site (no cert dialog)
> 3 access where cert is itself sent over ssl to hide presentation of webid from snooping (prove using proxy snoop, such as fiddlertool)
> 4 addressing corporate https snooping points ? By showing they are intercepting? (
> 5 ...
> 
> Don't lead with foaf generators, semweb caching, cert generators, or API info for cgi processes. Ensure the security model is on display, and folks can believe in non ca issued client cert credentials. After all, it's quite a claim...
> 
> 
> 
> On Jan 26, 2011, at 5:37 AM, Henry Story <henry.story@bblfish.net> wrote:
> 
>> What is the problem you are trying to solve?
>> 
>>  On reading this perhaps too quickly it seems that the problem is how to 
>> move certificates with private key from one browser to the next. Is this right?
>> 
>> Henry
>> 
>> On 26 Jan 2011, at 14:17, Peter Williams wrote:
>> 
>>> PKCS#x is a series of semi-standards. One of them is about storing keys, certs and cert properties, being defined as a UNIX-era stream using ASN.1 types and associated value notations. The stream is stored by web convention in a file, of extension .pfx. Being a file, it can be referenced by an http URI and downloaded  by HTTP retaining (file) type information. If the file is downloaded using a web browser to a local file on a PC file store and then this store is referenced by a (IE) browser using a file: URI, the browser will load keys & associated certs into the key/cert container used by the browser. (Users may well be challenged to know a password.)  Once done, web sites requesting the browser's user participate in the webid protocol can induce the browser to show the user a client cert picker/dialog, enabling the user to self-assert a foaf card to the site (for the purposes of access control). The same website can automatically induce the browser to re-assert the same card without the display of the dialog - for some use cases.
>>> 
>>> to generate a .pfx file in IE, one "exports" the cert (and associated keys) using the relevant browser application's menu option&preferences. IE has Windows construct the relevant PKCS#x-conforming data stream, and the browser manufactures a local file container for the data stream. I believe Mozilla browser does something very similar, and uses the same stream definition (PKCS#x) for file import/export. Please, just name the file: <something>.pfx to promote the convention.
>>> 
>>> The art is now to make 5 really good demo .pfx files. Each of the 5 should lead a novice though a set of experiments that she can replicate, very easily. Each should characterize an important use case.
>>> 
>>> The 2 .pfx files I generated 12+ months ago were research-grade use cases and used research grade tooling.  They may not be good cases for teaching. 5 well-thought out uses cases and the associated .pfx file would allow the new user to try out the "ideal" use cases, learning about the distinctions being drawn in each use cases as she goes through the list replicating the trials using her browser.
>>> 
>>> The 2 .pfx file I referenced could be trials #4 and #5, "advanced". This group needs to decide if the uses cases that they demo are even conforming to the design concept. Are they something to be advocated to new users, even if valid? Arguably, what I was doing is too experimental. The experiments sought to link the 2 certs and 2 foaf cards, showcasing that 2 different foaf cards could be being referenced by 2 distinct webids (stored in 2 distinct certs), where the certs in each case and the cards similarly in each case shared a common RSA public key. This is not a classical use case. A futher experiment built into those trials showed something that might appeal to IETF WG PKIX however. Each of the cert correctly uses certificate policy fields, that are also URIs. The presence of these fields arms (in IE) a feature of the the browser's certificate display dialog: the so-called "issuer policy" button. Press the button, when armed, and a browser will navigate to the resource referenced by the policy URI, using the webid protocol is required.
>>> 
>>> Perhaps we each make a foaf card, store it on the web, reference its URI in the cert using our favorite tools, and then export the key/cert stream in PKCS#x file format, calling the resulting file demo<me>.pfx. 
>>> 
>>> Then publish the URL to the demo<me>.pfx file. As a group, we evaluate what each trial claims to demo as a use case. Those that pass muster can be  sequence into a teaching about ideal use cases, allowing the user to learn one use case at a time. In a trial of each use case, the user can actually replicate the experiment easily - while also seeing the end product of the webid protocol: use SSL to get authorization to access a remote web resource. To help teach, one webid-capable resource server should be exposing 5 access controlled resources reinforcing the use case of the particular lesson. Ideally, this would be W3C hosted in a research space, so the W3C brand carries some weight.
>>> 
>>> 
>>> 
>>>> Date: Wed, 26 Jan 2011 08:12:18 +0100
>>>> Subject: Re: test and comment on FOAF+SSL material
>>>> From: danbri@danbri.org
>>>> To: home_pw@msn.com
>>>> CC: public-xg-webid@w3.org
>>>> 
>>>> Looking up .pfx I get a wikipedia ref to
>>>> http://en.wikipedia.org/wiki/PKCS ... are distinctions of version and
>>>> name here important, or you just mean anything that'll store the info
>>>> that the relevant user's browser can actually read?
>>>> 
>>>> Perhaps say 5 fictional users (whose keys/passwords etc are all a
>>>> matter of public record) would be useful for testing and exploration.
>>>> Perhaps avoiding the names 'Alice' & 'Bob'...
>>>> 
>>>> cheers,
>>>> 
>>>> Dan
>>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 

Social Web Architect
http://bblfish.net/
Received on Wednesday, 26 January 2011 19:25:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 26 January 2011 19:25:45 GMT