Re: DSIG Spec 4.3.3.1 - missing URI

Now that I'm clear on what a Reference without a URI does, here's what
I was trying to ask in #2 and #3.

A generic DSIG verifier would presumably be passed a document and
would come back with a pass/fail result.  When this generic code came
across a Reference without a URI, it would have no way to follow the
Reference, no way to verify the hash, and therefore no way to verify
the signature.  The application would have no way to pass in a URI
parameter or octets.

I suspect a similar problem with a signer.

This is based on my guess on how a signer/verifier would work.  I'd
like to hear opinions from people who have implemented, or plan to
implement, a DSIG signer or verifier.  Do you plan to handle a
Reference without a URI attribute?

> X-Sender: reagle@localhost
> Date: Tue, 07 Nov 2000 15:48:44 -0500
> From: "Joseph M. Reagle Jr." <reagle@w3.org>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> At 15:59 11/6/2000 -0500, Ken Goldman wrote:
> >The application proposes to use the feature of DSIG where the
> >Reference does not have a URI attribute.  Paragraph 4.3.3.1 says that
> >"the identity of the object is part of the application context."
> >
> >I have a set of questions.
> >
> >1 Is this another way of saying "it's up to the application to figure
> >out what the Reference points to."
> 
> Yes.
> http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/#sec-URI
> 
> While I give my best answer to the following as an editor, I'd like to defer 
> to the advocates and implementors of this feature...
> 
> >2
> >
> >If #1's answer is "yes", would I be correct to assume that such an
> >application could not use a generic DSIG compatible signer or
> >verifier, because this generic software could not resolve the
> >reference?
> 
> I'm not sure I completely follow and I suspect it would depend on how you 
> implement your DSig compliant signer/verifier. The processing rules require 
> that the data be obtained, but doesn't say HOW that must happen:
> __
> 
> >3.1.1 Reference Generation
> >For each data object being signed:
> >1. Apply the Transforms, as determined by the application, to the data 
> >object.
> >2. Calculate the digest value over the resulting data object.
> >3. Create a Reference element, including the (optional) identification of 
> >the data object, any (optional) transform elements, the digest algorithm 
> >and the DigestValue.
> 
> 
> >3.2.1 Reference Validation
> >For each Reference in SignedInfo:
> >1. Canonicalize the SignedInfo element based on the CanonicalizationMethod 
> >in SignedInfo.
> >2. Obtain the data object to be digested. (The signature application may 
> >rely upon the identification (URI) and Transforms provided by the signer in 
> >the Reference element, or it may obtain the content through other means 
> >such as a local cache.)
> __
> 
> >3
> >
> >If #2's answer is "yes", isn't this a fairly strong argument for NOT
> >using the "Reference without a URI attribute" feature.
> 
> I expected an app wanting to use this feature would have an implementation 
> that permitted the object to be passed in via a parameter as well. However, 
> I think you have a legitimate point about what exactly we are requiring with 
> respect to conformance (and I'd like to hear others thoughts.)
> 
> >4
> >
> >If #2's answer is "no", is this because there is an unwritten
> >convention for resolving a Reference without a URI?  For example,
> >would a generic signer/verifier assume it points to the whole
> >document, the first element, or something like that?
> 
> I don't think so, I assume the app had some other way of passing octets in.
> 
> 
> 
> __
> Joseph Reagle Jr.
> W3C Policy Analyst                mailto:reagle@w3.org
> IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
> 
> 


-- 
Ken Goldman   kgold@watson.ibm.com   914-784-7646

Received on Wednesday, 8 November 2000 16:51:18 UTC