Re: Decryption Transform processing question

r/arik@phaos.com/2002.05.02/12:16:13
>I strongly prefer number 2. I don't see the problem, though, with 
>processing multiple levels of encryption. The outer iteration, as defined 
>in the processing rules for decryptIncludedNodes(X, R), just has us select 
>an EncryptedData element e in X. Since the result of decryptXML(X, e, C) 
>replaces X, the next loop of the outer iteration begins with a new X and is 
>free to select an EncryptedData element e that was not in X at the start of 
>the previous iteration. If decryptIncludedNodes(X, R) continues until no e 
>can be selected, then multiple levels of encryption can be successfully 
>handled.

I prefer #2 as well; I think perhaps some of the problems of
same-document references are simply insoluble, and we should
probably provide a statement to that effect.

My problem with iteration is:
  <Foo Id="foo">
    <EncryptedData>
  <!-- what was formerly
      <Bar>
      <EncryptedData Id="enc-1" />
      <EncryptedData Id="enc-2" /> -->
    </EncryptedData>
  </Foo>

I can't run this through:
  Signature URI="#foo"
    Decrypt-Transform Except="#enc-2"

During round 1, we get back a new node set with the original
pair of EncryptedData, but the URI #enc-2 will no longer resolve
because round 2 is processing a different document. So,
suggesting that this transform can handle multiple encryption
will only mislead people without a warning that Except elements
won't work for multiply-encrypted data. Somewhat more to the
point; because our Except references will no longer apply to
the new document, round 2 will try and decrypt every
EncryptedData that was excepted from round 1.

Single iteration isn't perfect. If, for example, there are
EncryptedData that use same-document RetrievalMethods, or
cipher references, and then someone goes off and encrypts
the target of those references, then things will break. We
really need a statement along the lines of: Don't encrypt
data that are the target of same-document references if
processing will require resolving those references.

What about the following formulation:

----

Z = decryptIncludedNodes(X, R)

where X is a node-set and R is a set of dcrpt:Except elements
specified as a parameter of the transform. Z is a node-set or octet
sequence obtained by the following steps:

       1. Within X, select E, the set of all element nodes with the type
xenc:EncryptedData, such that none are referenced by any dcrpt:Except
elements in R.
       2. If the value of the Type attribute of any element, e, in E is
neither &xenc;Element nor &xenc;Content, then e MUST be the sole
member of E (or else failure MUST be signaled), and processing should
be as follows:
             1. Let Y' be decryptOctets(X, e).
             2. If this function succeeds, then let Z, the result of
this transform, be the octet sequence Y'.
             3. If this function fails, then the implementation MUST
signal a failure of this transform.
       3. Otherwise, the value of the Type attribute of each element
e in E (there may be zero or more) is either &xenc;Element or &xenc;Content:
             1. Let C be a parsing context of X including all inherited
namespace nodes and any general entities defined in the document.
             2. Let Y be decryptXML(X, E, C).
             3. If this function succeeds, then let Z, the result of
this transform, be the octet node set Y.
             4. If this function fails, then the implementation MUST
signal a failure of this transform.

Y = decryptXML(X, E, C)

where X is a node-set, E is a possibly empty set of element nodes with
the type xenc:EncryptedData in X, and C is a parsing context of X. Y is
a node-set obtained by the following steps:

    1. Decrypt each element, e, in E (without regard to
which of its descendants are present in X) according to the XML
Encryption specification [XML-Encryption]. The result is an octet
stream corresponding to UTF-8 serialized XML data.
    2. Convert X to an octet stream as described in The Reference
Processing Model (section 4.3.3.2) of the XML Signature specification
[XML-Signature], but in place of each element e and its
descendants, insert the corresponding octet stream obtained in step 1.
    3. Wrap the resulting octet stream in the context C as
specified in Text Wrapping (Appendix A).
    4. Parse the wrapped octet stream as described in The Reference
Processing Model (section 4.3.3.2) of the XML Signature specification
[XML-Signature], resulting in a node-set.
    5. Y is the node-set obtained by removing the root node, the
wrapping element node, and its associated set of attribute and namespace
nodes from the node-set obtained in Step 4.
    6. Return Y.

Y' = decryptOctets(X, e)

where X is a node-set and e is an element node with the type
xenc:EncryptedData in X. Y' is an octet stream obtained by the following
steps:

       1. Decrypt the element corresponding to e (without regard
to which of its descendants are present in X) according to the XML
Encryption specification [XML-Encryption].
       2. Return Y', the resulting plaintext octet sequence.

If any of the above steps in decryptXML() or decryptOctets() fails for
whatever reasons (e.g., the decryption key cannot be located, parsing
fails, etc.), the function also fails.

----

Where this differs from the spec is that we do one pass, and all
EncryptedData are decrypted in that pass. We also signal an error
if any decryption fails (because to do otherwise seems to invite
problems). And, we serialize/parse even of there are no
EncryptedData in the input node set. This is important for
consistency: the output is always from a new document.

Also, although X must be single-rooted on input (otherwise wrapping
becomes quite complex), the output need not be; that means we don't
need all the restrictions on types.

Merlin


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com

Received on Thursday, 2 May 2002 13:22:44 UTC