- From: merlin <merlin@baltimore.ie>
- Date: Sat, 01 Jun 2002 01:23:50 +0100
- To: xml-encryption@w3.org
r/merlin@baltimore.ie/2002.06.01/00:42:08
>I know it must appear that I have verbal diarrhoea [...]
I do. I botched the Type handling. Here, I use Type
in a useful manner.
====
= Merlin's 13th stab at the problem rev 2
====
. Define two decrypt transforms:
&decrypt;Binary
&decrypt;XML
. The &decrypt;Binary transform operates so:
o Decrypt each unexceptional EncryptedData in document
order. No Type-based processing is performed (Ref: &xmlenc;
MUST be able to return the raw plaintext.)
o Return the concatenation of the plaintexts. (Aside: Yes,
I am sneaking in the solution to a requirement of mine!)
. The &decrypt;XML transform operates so:
o For each unexceptional EncryptedData in the node set:
* If its Type is &xenc;(Content|Element) then decrypt
it, wrap it in the parsing context of the EncryptedData
element, parse this and trim it. (Aside: I think that
this definition of the processing of these Types
should be in the xmlenc spec. We could then allow
decrypt-and-replace mode to operate uniformly on any
Type whose "processing" result is a node set. I am not
asking for wrap/parse/trim to be their specification,
just that the "result" of processing these types is
defined to be a node set, a non-normative implementation
of which is wrap/parse/trim.)
* Otherwise, decrypt the EncryptedData and process it
in accordance with the specification of its Type
attribute, or fail if this is unknown. The result must
be a node set. For example, if its type is &gzip-xml;
then it will be gunzipped, wrapped, parsed and trimmed.
If its type is &python-xml-pickle; will be executed in
python and the result will be a node set.
* Save these node sets; they will be the replacements for
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, after decryption
and processing in accordance with the Type attribute, result
in a node set. This is simply a requirement that we place on
apps that encrypt data for subjection 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 Return the resulting node set.
o Define the decrypt-and-replace operation of SuperEncrypted
to decrypt-and-replace any child EncryptedData elements.
If the xmlenc spec defined decrypt-and-replace mode
generally to work on any Type that, after processing
the plaintext, produced a node set, then this would
be free and I'd delete this point.
. 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 Saturday, 1 June 2002 15:41:46 UTC