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

XML decryption transform number 13

From: merlin <merlin@baltimore.ie>
Date: Sat, 01 Jun 2002 00:42:08 +0100
To: xml-encryption@w3.org
Message-Id: <20020531234208.97BB54432D@yog-sothoth.ie.baltimore.com>


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 GMT

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