- From: merlin <merlin@baltimore.ie>
- Date: Sat, 01 Jun 2002 00:42:08 +0100
- To: xml-encryption@w3.org
I know it must appear that I have verbal diarrhoea but I
have a proposal that solves the dummy element, types and
super encryption. Joseph's input was valuable to this:
====
= Merlin's 13th stab at the problem
====
. Define two decrypt transforms:
&decrypt;Binary
&decrypt;XML
. The &decrypt;Binary transform operates so:
o Decrypt each unexceptional EncryptedData in document
order and process it in accordance with the specification
of the Type attribute, or fail if that is unknown.
o Return the concatenation of the plaintexts.
. The &decrypt;XML transform operates so:
o Decrypt every unexceptional EncryptedData in the node set
and process it in accordance with the specification of the
Type attribute, or fail if that is unknown. For example,
Type &gzip-xml; will be gunzipped; type &python-xml-pickle;
will be executed in python; type &xenc;(Content|Element);
will be untouched. Wrap the resulting octet stream in
a parsing context of the EncryptedData element (i.e.,
...<dummy...), parse this, trim it and save the result.
These will be the node sets that should replace the
EncryptedData elements; they may be element or element
content.
o Canonicalize the input node set but, in place of every
unexceptional EncryptedData, canonicalize the replacement
node set. Note that the result may not be in canonical
form.
o Parse the resulting octet stream.
Notes:
. The input node set must be single-rooted. The resulting
node set will NOT be rooted by a dummy element. If the
input node set is rooted at an EncryptedData then that must
comprise a valid XML document (e.g., element type).
. Every EncryptedData in XML mode must consist of valid XML
data that, after decryption and processing in accordance
with the Type attribute, can be parsed in a parsing context
of the EncryptedData element. This is simply a requirement
that we place on apps that encrypt data that are subject to
&decrypt;XML. Use another transform if you don't like this.
. A smart implementation will realize that, if this processing
is followed by a canonicalization transform (e.g., if this
is the last transform and the next step is digest) and it
can formulate its replacement node-set canonicalization to
be *identical* to what canonicalization of that node set
in-place would be, then it can omit the redundant parse
and c14n steps.
. In terms of performance, we parse the content of each
EncryptedData once, and then do a c14n/parse step on the
whole node set, so this will be reasonably efficient;
particularly if the previous point is followed.
Super encryption:
. We define a new EncryptedData Type in the decrypt spec,
&decrypt;SuperEncrypted, the processing of which is
as follows:
o Decrypt the EncryptedData element.
o Wrap and parse the plaintext.
o Decrypt-and-replace any EncryptedData elements in this
node set.
o Serialize the result.
o Define the decrypt-and-replace operation of this type
to decrypt-and-replace any child EncryptedData elements.
. If an application is super-encrypting data that are
subject to a decryption transform, then it is responsible
for using this type so that the decryption transform
can operate, and it must understand that superencrypted
EncryptedData cannot make same-document references
during their processing.
. There is one issue that may or may not need addressing:
o Superencrypting excepted EncryptedData: Just don't
use the SuperEncrypted type.
o Superencrypting both excepted and non-excepted
EncryptedData: Either just don't do it or identify them
through a new EncryptionProperty. Is that going too
far? It does exercise our EncryptionProperty framework.
Merlin
Received on Friday, 31 May 2002 19:43:24 UTC