Re: Using ASN.1 formats at Personal Profile Doc -- was: virtual hosting in modern browsers

One thing folks are missing is that a pem file (misnamed, because there is no such thing in the ietf doc family) is a bag (of certs). Sometimes, the bag may contain a private key, or crls, added to the non-file-format. It's a horrid mess that is, defined by noone, and uses the term "pem" in amateur land because it has takes some standard elements from rfc 1421 for file content encodings and structures. It's open source at it's worst - that which folks do. It creates what the uk govt calls a class 4 crypto product (crap).

What is competent, and standardized by  pkix (and rsa and MIT consortium), is the .p7c file. It has very well defined elements, done by professional type, value and type/value notation designers with as much if not more formal methods skills than folk here. It's also a bag (of certs). It too is often abused, to imply order of certs in a chain. Such is the world of low assurance, commodity crypto. Call it class 3, and class 2 when delivered by a firm like rsa itself.

I'm only half serious when wondering if the webid should point to a .p7c (containing a bag of keys) rather than a .rdf card (containing a bag of keys). It's serious side is that it offers a proof technique.

What Im missing in general  is the security semantics of the webid protocol - what is being claimed as true  expressed in the language of assurance claims (for comms security).

 What the cert bag vs rdf bag case offers is the ability to assert: the core authentication claims of each protocol runs are the same (whatever they are). Or, the rdf case is a strict superset of the . P7c case claims. Either is useful (to an formalist in communications security).

We have to remember that our flow is subject to proof - that a subject is authenticated merely as a result of ssl server testing a self-signed file proposed by an anonymous party has keys used also by the ssl client auth procedure. If we proffer this, is it also satisfied by the p7c case?

Are write acls ( and their enforcement by the rdf guard) necessary to those claims?

I don't care about p7c case per se - I care about its serving us as a Logician's "device" in differentiating and proving the core claim. It's a stalking horse definition, there to force the core claim into proof in language that well trained assurance evaluators will accept (and then test for rigor).

If we decide the core claim about "peer entity authentication" ( which is sematically distinct from "data origin authentication", "signed" statements, "non-repudiable" statements) is satisfied by either case (a good thing, I suspect)  we can fix that claim (as a theorem). then we go on to identify what additional security claims we make due to all the additional information in the rdf file, or inferences drawn from the facts when related to the servers own triple store (with lots more facts, in interesting relations to those in the rdf file).


On Jan 28, 2011, at 12:05 AM, Henry Story <henry.story@bblfish.net> wrote:

> [ just extracting a piece of a thread on foaf-protocols list that can be turned into something
>  useful here and tied to an issue ]
> 
> On 27 Jan 2011, at 19:18, Peter Williams wrote on the foaf-protocols list:
> 
>> one thing folks are going to have to answer is a question setup like this (as this is how security evaluators/auditors handling assurance claims think):
>> 
>> so suppose one has done a run of the webid protocols, with client certs flying, Ssl handshakes with client auth signatures foaf card readings, rdf parsings, inverse functionalisms computed, owl reasoning closings; all overliad by a bit of facebook managed like-this! button pressing for feedback. As a result, folk have been granted access to web resources, using the authorization extensions of the protocol courtesy of its good integration with the semweb. The claim is that the channel between user and resources is as strongly-secure as is the openid protocol used by yahoo to log subscribers onto fox news' discussion forums site, say. Or its as good as the ws-federation tokens that log a half billion hotmail users similarly onto the same news media site.
>> 
>> I come along and make myself a new cert, which has in the ISO URI field as https pointer to the .crt file of that cert. I used it much as above ,and the website confirms that the .crt picked up from the uri is equivalent to the client cert used in the SSL client auth-enabled handshake.
> 
> [ note: .crt files are the extension for PEM files that are understood by Windows, and so have been 
> also adopted by Apple's OSX ]
> 
> This is indeed the protocol enhancement I describe in ISSUE-6 
> "using ASN.1 formats for WebID description"
> 
>> 
>> What is the security service (known as semantics in ISO security culture) difference between the 2 cases?
>> 
>> Is there any? if so, what is it?
> 
> Semantically there are a few differences. For one in the case of a file containing a number of certificates, you have to think of those certificates as signed statements, ie: as statements
> made by someone else. You may not be able to merge the statements made by those people unless you
> trust them. That is a foaf file is of the form
> 
> ----
> Jack is a Man. He like Jane. Joe is his friend.
> Jack has public keys 123123123 and 3212312312.
> ---
> 
> A Profile Page consisting of certificates says
> 
> ---
> Robox certifies that Jack is an Agent and that his public key is 123123123 .
> Robox2 certifies that Jack is an Agent and that his public key is 3212312312 .
> ----
> 
> If Robox == Robox2 
> 
> The you can merge both and say
> 
> ---
> Robox certifies that Jack is an Agent and that his public key is 123123123 and 3212312312
> ---
> 
> So that still leaves the indirection via Robox. I am not yet sure exactly how problematic that
> is if at all, but the point is the semantics are somewhat different.
> 
>> 1 answer is: there is no difference so far - as the difference only comes along when handling the relations in the graph. If this is true, its an important claim to make.
> 
> In any case it should not matter for the case at hand as described. 
> 
> But it would be useful to understand formally of a GRDDL for PEM files: ie to think
> of PEM as just another semantic notation to write something out in a not very flexible
> and long in the tooth, difficult to read and to parse, full of dangerous holes with lurking
> dragons.... (Just see Dan Kaminsky's HAR talk "X.509 considered harmful" among others where
> he has a good time with ASN.1 quirks finding security holes)
> 
> 
>> 
>> Then I come along again acting like Nathan acts, and use the first webid protocol run as specified initially (which has a URI pointing to a foaf card, rather than a URI to a .crt file). I place in the From: header of each HTTP request first my webid, a URL pointing to the .crt file. In a second From: field I place another webid, a URI to my "alternative" foaf card.
>> [snip]
> 
> Don't think any of that is necessary. Or if it is it's a completely different topic.
> 
> Henry
>

Received on Saturday, 29 January 2011 00:27:33 UTC