Re: Decryption transform interop samples

On Monday 26 August 2002 05:02 am, Takeshi Imamura wrote:
> ... I just implemented the latest spec and tried
> your samples below.  

Great, the report is updated!

>Though I didn't try the ones using XPointer because
> I didn't support it, I succeeded in the others.

I presume this means the following two cases, but all others pass? (Also, 
you would not be able to validate the signature used in the example of 
section 3.3?)

FIRST
> . decrypt-xml-except-xpointer.xml
>   XML-mode decryption transform with XPointer exception (non-mandatory)

You don't support the following sort of expression because you don't support 
full XPointer in the Except?

  <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML">
    <dcrpt:Except xmlns:dcrpt="http://www.w3.org/2002/07/decrypt#" 
URI="#xmlns(po=http://example.org/po)xpointer(/po:PurchaseOrder/po:PaymentInfo/*[last()])"/>
  </dsig:Transform>

SECOND
> . decrypt-xml-except-unresolvable-xpointer.xml
>   XML-mode decryption transform with irrelevant but unresolvable
> exception

Again, you don't support the following (and even if you did, it's intended 
to fail! <smile/>)

  <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML">
    <dcrpt:Except xmlns:dcrpt="http://www.w3.org/2002/07/decrypt#"
                URI="#xpointer(/Nothing/To/Resolve)" />
  </dsig:Transform>

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.

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?

Received on Wednesday, 28 August 2002 13:04:11 UTC