- 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