RE: Difficulties with URI="" and IDREF

Ah, when I read "The URI/IDREF attribute identifies a data object using a
URI [URI] or IDREF [XML]", I assumed that the author intended an
inclusive-logic 'or' whereas under Gregor's interpretation it is an
'either-or' or exclusive-or. The reason for my assumption that IDREF and URI
would coexist is so that one could IDREF into documents other than the
self-document.

Note to editors: If exclusive-or was intended, then perhaps the word
'either' can be inserted to clear that up, and if inclusive-or was intended,
then perhaps 'or both' can be appended.

Still, assume that use of IDREF implies URI="". The point I'm making about
IDREF stands, and the problem with URI="" can still occur.  URI="" is
problematic unless we assume that a c14n occurs between the processing of
URI="" and digesting the final byte stream.  When we have URI="nonempty",
the understanding is that we will execute some scheme like http or ftp to
obtain a set of bytes.  However, URI="" has no scheme, so presumably the
application is being asked to provide the document's bytes, and presumably
it will do so in an application-specific way.

So, like IDREF, the bytes corresponding to URI="" would seem to be
application-specific, which is bad for interoperable signatures.

Currently, URI="" cannot be used without some kind of transform to exclude
SignatureValue.  Since the XPath transform is currently written in such a
way that W3C c14n is required, there will be no problems.  However, it would
seem that any transform (such as XSLT or Java) that takes URI="" as input
will have a problem.  This is why we must still consider the URI="" problem.
One simple solution would be to eliminate all transforms other than c14n,
base64 decode, xpath and xpointer.

Furthermore, Andreas recommended that dropping SignatureValue should be done
automatically.  I would agree insofar as this is precisely what we did when
defining XFDL's signature methodology. However, doing this automatic
omission increases the number of signatures that will be created using
URI="" but notransforms, which means no c14n, which means troubles of the
type described above.  Thus, it is probably a good idea to have the
SignatureValue omission spelled out (esp. since the work of omitting
SignatureValue must be done even if the document doesn't spell it out).

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Andreas Schmidt
Sent: Tuesday, January 04, 2000 3:08 AM
To: Gregor.Karlinger@iaik.at; XMLDSig WG mailing list
Subject: Re: Difficulties with URI="" and IDREF


Gregor Karlinger wrote:

> Andreas Schmidt wrote:
>
> >> URI="" must be used in conjunction with either IDREF or an XPath
transform.
>
> > Either that or it is core behavior to omit the contents of
> > SignatureValue in
> > that case.
>
> I think it should be clear that in this case an additional XPath transform
> has to be applied to exclude the Signature. I don't think it is necessary
to
> state this as core behaviour.

The only thing which is clear is that self-referential sigantures will never
validate. I
think this problem and any solution the standard provides should be
explained somewhere
- may it be core behavior definition, a recommendation to application
designers, or at
least application examples.

Nevertheless, since signing 'this' document seems to me to be a quite common
case, so
why not provide standard means to cope with it? To define exclusion of
SignatureValue as
core behavior is the simplest way to achieve this.

> > Btw two minor editing points:
> >
> > 1. sec. 2.3 defines URI/IDREF as exclusive alternatives
> >
> >    <Reference (URI=|IDREF=)? Type=?>
> >
> > in contrast to sec. 3.3.3
>
> I don't see a contradiction here. In [1], sec. 3.3.3. you can find:
>
> "The URI/IDREF attribute identifies a data object using a URI [URI] or
IDREF [XML]."

Right. This was only in  conflict with John's idea of using URI and IDREF
jointly to
solve the problem above.

> [1] http://www.w3.org/Signature/Drafts/WD-xmldsig-core-20000104/

Received on Tuesday, 4 January 2000 13:42:15 UTC