W3C home > Mailing lists > Public > xml-encryption@w3.org > May 2002

Re: Decryption Transform processing question

From: Ari Kermaier <arik@phaos.com>
Date: Wed, 01 May 2002 11:47:41 -0400
Message-Id: <5.1.0.14.2.20020501111621.02b06dd0@verio.phaos.com>
To: reagle@w3.org, "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org

>On Wednesday 01 May 2002 10:52, Ari Kermaier wrote:
> > Y = decryptXML(X, e, C)
> >
> >          where X is a node-set, e is an element node 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 e and replace it with the resulting octet stream
> >          according to the XML Encryption specification [XML-Encryption]
> >          (which may require serializing X).
>
>If e is an elemenote node in X, how am I replacing it with octets? (Also,
>is the serialization *any* serialization, or stil the one in xmldsig?)

Well, XML-Enc doesn't really specify exactly how the encrypt-and-replace is 
to be accomplished. I'm thinking that in a DOM environment, it could be 
done by replacing the EncryptedData element node with the result of parsing 
the decrypted octets into a DOM tree. Or, it could be done by serializing 
the document to an octet stream containing UTF-8 character data and 
replacing the octets representing the EncryptedData element with the 
decrypted octets. That's why I'm thinking language like "may require 
serializing" might be appropriate. Using XML-DSig serialization (C14N) 
works for this, but I think any well-formed XML serialization that results 
in UTF-8 encoded XML character data would work just as well.

> > 2.      Wrap the result of Step 2 in the context of C as specified in
> > Text Wrapping (Appendix A).
>
>This is step 2, maybe this should be step one now?

I don't think correct decryption depends on the parsing context C. The way 
I understand it, the purpose of C is to provide entity definitions and 
namespace declarations that might be needed to parse the *result* of the 
decryption -- so wrapping wouldn't be necessary until after the 
decrypt-and-replace.


Ari Kermaier    arik@phaos.com
Senior Software Engineer
Phaos Technology Corp.    http://www.phaos.com/
Received on Wednesday, 1 May 2002 12:10:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:21 GMT