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

Re: XML decryption transform number 13

From: merlin <merlin@baltimore.ie>
Date: Sat, 01 Jun 2002 01:23:50 +0100
To: xml-encryption@w3.org
Message-Id: <20020601002350.BE8864432D@yog-sothoth.ie.baltimore.com>

>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:
. 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

  o Parse the resulting octet stream.


. 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.

Received on Saturday, 1 June 2002 15:41:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:09 UTC