Re: Decryption Transform processing question

Joseph,

I implemented the decryption transform using the following interpretations 
of the spec:

1) XPointer support that is OPTIONAL in Signature remains OPTIONAL in 
Decryption.

The Phaos implementation does not currently support the OPTIONAL XPointer 
syntax, but I saw no reason to preclude other implementations from 
supporting it.

2) The description of the process of selecting e in X but not in R implies 
that the iteration continues until no EncryptedData element satisfying the 
condition can be selected. I.e., the contents of super-encrypted elements 
are automatically decrypted (in an arbitrary order relative to other 
top-level EncryptedData elements).

I had not considered the sort of document structure that Merlin used to 
illustrate potential ambiguities arising from the processing rules. Merlin 
makes a good point on this subject -- I'm just not sure I understand his 
proposal for dealing with super-encrypted elements by using multiple 
DecryptTransform elements in the dsig:Reference.

Ari


At 12:13 PM 5/30/02 -0400, Joseph Reagle wrote:

>On Wednesday 29 May 2002 07:36 pm, merlin wrote:
> > However, all these changes boil down to a large refactoring
> > of the decryption transform spec; and, if I am unique in
> > my viewpoint, then I am at an impasse and must cede to the
> > majority view and stand by my former stated views on the
> > subject.
>
>I think this is a great discussion; it's what happens when "implementors
>hit the spec." <smile/> Beyond your new requirement which I'll address in a
>separate email, I'm generally happy with the direction of what you propose,
>but I'm most interested in the thoughts of other implementors, which at
>this point [1] include IBM and Phaos
>
>[1] http://www.w3.org/Encryption/2002/02-xenc-interop.html
>
>1. In the present WD, we say we support the xmldsig profile XPtr (which is
>same-document XPointers '#xpointer(/)' and '#xpointer(id('ID'))'. Anything
>else is optional. You seem to be using more sophisticate pointers, are you
>advocating a change in this level of support? (BTW: I think I've heard that
>folks are reviving the XPtr work by breaking it into different
>profiles/specs.) I'd prefer to keep this real simple and rely upon IDs.
>2. In decryptIncludedNodes() why did you switch the order of steps 2 and 3?
>(Makes it difficult to see the diffs, but maybe you had a reason.)
>3. In decryptXML, if I have three elements I'm decrypted, via process one
>do they all go into one octet stream, or is a group of 3 octets sets?
>
>--
>
>Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
>W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Thursday, 30 May 2002 13:22:11 UTC