Syntax issue - reference/object

Since I think this is a critical issue, I wanted to move it to a
separate thread.  I'd also like to see if there are other thoughts. 
From what we've discussed in terms of usage, I think we need to have a
signature mechanism that either stops with hashing the encapsulated data
(which may just be a pointer and digest to an external document) or
recalculates the digest over the one item referenced.  In addition to
dealing with messaging and other detached signatures, I think this may
help to solve the c14n question.

With respect to your suggestion that rather than having two elements
(object and reference), we indicate the processing distinction via an
attribute in resource or signedObject, I agree.  You're right, the
processing distinction should be independent of whether the thing signed
is the complete document or a reference.

Dave

> > Richard D. Brown Wrote:
> >
> > 2.2- I would not distinguish between obejct and reference
> > at this level. From a model standpoint, the signature is applied to a
> > resource, which one can be given by reference or by value. The
> > distinction should be done further down the tree.
> >
> > David Solo Responded:
> >
> > I think this is the biggest issue we need to debate.  If validation
> > always stops with the encapsulated item then I agree we only need one
> > type here.  The challenge is how to handle the usage
> > scenarios where the
> > signature element is added to the thing its signing:
> >
> > <package>
> >   <signedthing/>
> >   <signature/>  (with ref, including digest, to signed thing)
> > </package>
> >
> > The goal of the reference type (and the processing rule you comment on
> > in point 17) is to try to accomodate the expectation that the default
> > behavior of a detached sigature (or non-encapsulating signature) will
> > actually check the digest over the thing begin pointed to
> > (i.e. validate
> > the integrity and authenticity of the signed thing, not just
> > the ref).
> > While I continue to agree with the assertion in Boston and
> > Oslo that we
> > don't recurse for links/resources in manifests and other documents; I
> > think we need to address this particular case.
> >
> 
> I strongly feel that it is an application-level issue. Nonetheless, if we
> were to address this problem in the current specification, I would rather
> use some 'attribute' on the resource element to do so. It is not because I
> am making use of a reference (by opposite to embedded) that I necessarily
> want the resource to be verified. Therefore, the distinction should be more
> specific.
>

Received on Monday, 16 August 1999 10:47:13 UTC