Re: Encryption: Decryption Transform for XML Signature

Joseph,

Thank you for your comments.  Our replies are inlined below:

>My two comments are:
>1. I know this is counter to an early decision, but in reading this for
the
>first time for a while, I wonder if we should use an element name other
>that enc:DataReference. Since this parameter really has its own meaning as
>an excpetion, I'm think perhaps it would be better to call it et:Exception
>...

We don't persist in the use of the element, and if you and others think so,
we can change it to another.

>2. I think the process is well specified, but one of the things that's
>slightly unclear is the connection between the transform and the functions
>that are defined. If the input to the transform is a node-set, then I
>presume one applies noDecryptNodes(X, R) . Maybe this should be stated
more
>explicitly, or could be moved before the decrypt(X, e, C) function?

Agree.  Could you move the definition of noDecryptNodes() before that of
decrypt()?

>Also, is X in either function always the whole document, or can it be some
subset?

X is always the whole document.

> By the way, we have a concern about whether this transform supports
> decryption resulting in not an XML but an octet stream.  Do you have any
> idea?

I'm sorry, but this sentence may be a little confusing.  Our question is
whether this transform should support types other than Element or Content,
such as image/gif.  In that case, we have to change the processing rules
again.  Anyway, our replies to your comments are:

>3. To address your question above. To trace through an instance of an
>element that must be decrypted prior to signature validation using the
>example in section 5:
>
>1. Apply noDecryptNodes(X, R)
>1.1 The node e = <EncryptedData Id="enc2" /> is not in R, so we pass.
>1.2 The node e = <EncryptedData Id="enc2" />  is in R, so we decrypt(X, e,
>C)
>1.2.1 X is canoncalized into octets according to Canonical XML. (Do these
>processing rules permit any other serialization?)

Yes, because the octets will be wrapped with a parsing context at the next
step anyway.

>1.2.2 The octets are wrapped in dummy tags (as octets).
>1.2.3 "Decrypt the element corresponding to e and replace it with the
>resulting octet stream according to the XML Encryption"
>1.2.3.1 So we find the approriate offset into the octets? These octets are
>then decrypted, and the result is interprated as UTF-8 encoded character
>data.
>1.2.4. "Parse the decrypted octet stream." Ok, so it's parsed back into
>nodesets again.
>1.2.5  "Y is a node-set obtained by removing the root node, the dummy
>element node, and its associated set of attribute and namespace nodes"
>
>So I'm sure there's a reason I'm forgetting, but why is it that the in
>steps 1 and 4 of decrypt() that the document is serialized and parsed? Why
>not just do the wrapping with the dummy nodes at the node-set level?
(Which
>I think we would do in any case?)

Because we don't have a concept to replace nodes in a node-set with other
nodes whose owner is different from the one of the node-set.  To be
concrete, we cannot replace an EncryptedData element node with a node (or
nodes) obtained by parsing a fragment obtained by decrypting the
EncryptedData element.  Therefore, we decided to parse a document as a
whole to a new node-set.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com

Received on Tuesday, 18 September 2001 02:32:42 UTC