RE: Comments on S2ML 0.8a

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

Hi Prateek,
Thanks for your response. I am still worried about the strength of 
using URIs for compound assertions. Let me try to elaborate below.
Regards,
Nigel.

> 
> I guess the general question is: is a URI sufficiently secure link for
> compound assertions to work?
> 
> ++++++++++++++++++++++
>  
> One strong requirement in the specification is that each assertion has
> a unique identifier associated with it (the <ID> element). This unique
> identifier happens
> to be a URI. There is no sense of location or binding to an 
> actual web page
> or anything
> of that type associated with URIs. The <DependsOn> element from p.13,
> Section 4, refers
> to the unique identifier of an name assertion. Given that all 
> assertion
> elements must be
> a cryptographically bound to an issuer, I see no security 
> vulnerability
> here.

What I am trying to do is to explore the boundaries of the system and
understand what it depends on. As I understand it, compound assertions do 
make use of URIs and are therefore depend on the the particular URI being 
used. URIs can he http URLs, but I don't think HTTP URLs work. So the 
question is what kind of URIs will work?

To take an example consider an entitlement that will grant put/post
access on the S2ML spec. This entitlement is linked with the following URI 
in the <DependOn> element to a Name Assertion:
http://www.foo.com/PrateekMishra

Both the Name Assertion and Entitlement are cryptographically bound to their
issuer
(i.e. signed).

Suppose there is another entitlement that will grant read access to the S2ML
spec.
This entitlement is linked to the following URI for a Name Assertion:
http://www.foo.com/NigelEdwards

If somebody manages to hack the web server and switch the objects at
http://www.foo.com/PrateekMishra and http://www.foo.com/NigelEdwards then
the
system has broken.

Similarly if sombody breaks the DNS system to fool a host into wrongly
resolving
www.foo.com, the system might also break.

I believe it is possible to come up with URI schemes that are not vulnerable
to the
above problems, possibly by including a hash of the the object to which the
URI is 
pointing as part of the URI scheme. 

>  
> 3.
>  
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> I am also worried about the linkage between AzResponse and 
> AzRequest. Again
> a URI is used to make the linkage, and the authorization 
> question is not
> repeated in the AzResponse. I think this could be made 
> stronger by including
> the question element from AzRequest in AzResponse.
> 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Similar to the comment above, Request and Response pairs 
> carry unique <ID>s.
> Further, each
> Response message carries a <InResponseTo> element describing 
> the <ID> of the
> corresponding
> <Request> message. The URI in question is precisely the <ID> 
> element of the
> Request. The
> specification suggests that Request and Response elements be 
> authenticated
> and
> secured using standard techniques tho' it does mandate the 
> use of signing. 
> 
>  

I think it's OK if AzRequest and AzResponse documents are exchanged over a
secure
session (e.g. HTTP/SSL) in which it is possible to match request-reply pairs
and the documents are ephemeral - never stored for future use. However, if
these documents are stored and linked via URIs, then unless I am missing
something,
the security of the system is dependent on the robustness of the URI scheme,

as discussed above.