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

[ 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 Friday, 28 January 2011 08:05:45 UTC