Re: Decryption transform interop samples

r/reagle@w3.org/2002.08.28/13:03:31
> [...]
>
>IMPLICATIONS
>
>"Full XPointers" appear as two "features." First, an Except URI might 
>include a full XPointer; this is because we say we inherit the profile of 
>Reference Processing specified in xmldsig. Second, when dereferencing a 
>full XPointer in the context of a replacement node-set, this requires some 
>additional tweaking/accommodation of one's code.
>
>So, presently, we only have one implementation (Merlin) that accommodates 
>full XPointers in the Exception URI? If so, we have three options:
>1. Be "strict" and say since we don't have two interoperable implementations 
>of this spec with full XPointer support, we drop both features.
>2. Be "flexible" and say that since the first feature is profile/inheritted 
>from xmldsig, and it is optional there, we should also consider it 
>optional, but the dereferencing into the replacement node is dropped.
>3. Be "loose" and continue with both.
>
>What do folks want do do? Presently, I'm somewhere between 1&2. I can 
>certainly see the use the full XPointer, but I also think we're doing 
>somewhat of a disservice to folks if they create signatures using this and 
>others can validate them. But then again, we're not doing anything that 
>already isn't done in xmldsig: some folks might not except such signatures.

I'm inclined to stick with what we have: Our processing
basically mirrors xmldsig (some customers do indeed need
XPointers), and we leave implementors the option of going
to great lengths to dereference XPointers into replacement
node sets if they want. This need will only arise in the case
that a decryption transform uses a full XPointer and partial
encryption subsequently occurs to break the exception. I
don't see this being a common problem. There are many ways
that partial encryption may break a signature, and this is
just another of those cases; we provide a warning about the
use of XPointers in such cases.

In the ideal world, if this dereferencing was easy to do,
this would be the 'right thing'; it's a fairly clearly defined
problem to which there is a solution. However, it's not a
simple solution and so we recognize this fact by leaving it
at MAY: At some point we have to give up and admit that we
can't handle all cases of signatures over documents that are
subsequently encrypted and manipulated.

>Also, the spec says, "Unlike XML Signature [XML-Signature], the exception 
>URI may be evaluated against a different document from the signature 
>document. If the input is a different document then, as per XPointer 
>[XPointer], use of the here() function is an error." I've forgotten what 
>this means with respect to xmldsig. What, exactly in xmldsig, is different?

In XMLDSIG, the URI #foo is always evaluated in the context of
the signature document. In DCRPT, the exception URI #foo is
evaluated in the context of the input document to the transform
which may be a different document if the Reference references
a different document or transforms have happened. Basically
it's a warning that the following three URIs, even if they occur
in the same signature, my evaluate to different things.

  <Reference URI="#foo">...
  <Except URI="#foo">...
  <Except URI="#foo">...

The same URI in any Reference will always evaluate to the
same thing.

Merlin

Received on Wednesday, 11 September 2002 14:47:06 UTC