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

Re: Decryption Transform processing question

From: merlin <merlin@baltimore.ie>
Date: Wed, 26 Jun 2002 00:20:48 +0100
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: reagle@w3.org, xml-encryption@w3.org
Message-Id: <20020625232048.9E22B4433E@yog-sothoth.ie.baltimore.com>

Hi Takeshi,

Thanks for the work on this. My comments are in-line below.
I apologize in advance if I am terse or express myself poorly;
I'm running into a few deadlines:

>          Merlin Hughes <[5]merlin@baltimore.ie>

[ thanks! ]

>   O = foo(N, E)

Maybe decryptTransform(N, E).

>          where N is a node-set and E is a set of exception URIs held by
>          URI attributes of dcrpt:Except elements. O is a node-set,
>          computed as follows:

I mildly prefer the separation of syntax (i.e., Except
elements) and semantics (i.e., a set of exception URIs)
adopted by exc c14n and xpath filter 2.0; however, this is
really a minor point.

>         2. Let Y be [69]bar(N, X).

Maybe decryptNodeSet(N, X)?

We don't state the 'type' of Y.

>         3. Convert N to an octet stream as described in [70]The
>            Reference Processing Model (section of the XML
>            Signature specification [[71]XML-Signature]; but, in place of
>            any decrypted xenc:EncryptedData element d and its
>            descendants, if O[d] from Y is a node-set, convert it to an
>            octet stream, and if it is already an octet stream, just emit
>            it as is. Let C be the resulting octet stream.

I wonder should this clarify that xenc:EncryptedData elements
may be replaced from N or from some replacement node set O[d].

>         5. Let O, the output of this function, be a node-set converted
>            from C as described in [75]The Reference Processing Model
>            (section of the XML Signature specification
>            [[76]XML-Signature].
>               o If parsing of C fails, then the implementation MAY
>                 signal a failure of the transform. Alternatively, it MAY
>                 also restart processing from the previous step without
>                 replacing any decrypted xenc:EncryptedData element
>                 causing a parsing error.

I don't understand why this MAY text is here. Surely the
implementation MUST signal a failure of the transform. It
cannot reasonably determine which EncryptedData caused the
parsing error (it will be parsing an octet streeam resulting
from canonicalizing multiple node sets); and, even if it could,
what's the reason for this?

>         1. Let D be a node-set containing all element nodes in N with
>            the type xenc:EncryptedData that are not identified by any
>            location-set in X.
>               o If N is a node-set yielded by decrypting an
>                 xenc:EncryptedData element, only location-sets in X
>                 resulting from exception URIs with a full XPointer
>                 "xpointer(id('ID'))" or bare name [[77]XPointer] are
>                 considered.

I think the second paragraph actually needs to go down below:
The recursive call to bar() must be made with a new exception
node set X because the original X will not identify any nodes
in a decrypted node set.

>         2. Let Y be {}, an empty set.
>         3. For each xenc:EncryptedData element d from D:
>           1. Decrypt d, without regard for which, if any, of its
>              descendants are in N, and process it in accordance with the
>              value of its Type attribute, resulting in a node-set or octet
>              stream O[d].
>               o For example, processing of an xenc:EncryptedData element
>                 with the Type attribute whose value is [78]&xenc;Element
>                 or [79]&xenc;Content is specified in [80]A Decrypt
>                 Implementation (section 4.3.1) of the XML Encryption
>                 specification [[81]XML-Encryption], and the result is a
>                 node-set.
>               o If the Type attribute is absent or its value is neither
>                 [82]&xenc;Element nor [83]&xenc;Content, the result is
>                 an octet stream in default. However, the implementation
>                 MAY process it further in accordance with its type, if
>                 any, resulting in a node-set.

I think that this is wrong, for the following reasons:
  . If the encrypted data are serialized XML, the encryptor
    should have used the correct type (Element or Content).
    If they have not used this type; then, on the balance
    of probability, the plaintext data are not serialized XML;
    something else is intended.
  . We have established that serialized XML matching the
    rules for Element or Content cannot be used as a
    plaintext replacement in the main canonicalization-
    with-replacement operation; the node set must be augmented
    with inherited XML attributes. This type of augmentation
    cannot be performed on an octet stream.
  . Essentially this breaks the Type system. While MimeType
    is advisory, Type is not; it is encrypted XML's strong
    typing system. For example, one of Joseph's standard Type
    examples is CompressedXML. When decrypted without regard
    for the Type, the result is serialized XML. However, this
    is not what the result of decryption should be. The result
    of decryption is the result of parsing this Compressed
    XML, uncompressing the data it holds and returning the
    resulting parsed node set, as specified in the definition
    of the Compressed Type URI.

Overall, I think that the decryptor MUST process the data in
accordance with the value of its Type attribute and the result
MUST be a node set. This is specifically a signature transform,
and signature processing is uniformly defined in terms of node
sets, so I think this is a reasonable restriction. In fact,
by placing this restriction we make the transform much more
powerful because it transparently handles new encryption Types
such as CompressedXML, SerializedJavaNodeSet, etc. We cleanly
punt the definition of this processing to the respective
Type specifications.

>               o If decryption of any xenc:EncryptedData element fails,
>                 then the implementation MAY signal a failure of the
>                 transform. Alternatively, it MAY also skip such
>                 xenc:EncryptedData element and continue processing.

As before, I don't understand why it MAY proceed. This will
mislead the recipient into thinking the data were modified
when in fact a decryption operation simply failed. We have a
defined exception mechanism that identifies what data should
not be decrypted. Why have this second, different exception

>           2. Replace Y with Y )U {O[d]}.

I like the union operator (I see it in mozilla/X11, Joseph) but
I'm not sure it's right; I think Y is a map from EncryptedData
elements to their replacement node sets. Using union might
suggest you merge the node sets, which is not the case.

>           3. If O[d] is a node-set:
>             1. Let Y' be [84]bar(O[d], X).
>             2. Replace Y with Y )U Y'.

I think that X should not be passed here, but X' which is
computed by dereferencing the barename XPointer exceptions into
the new node set. Further, because the new node set will not
be validated, I think that we need to explicitly state that X'
is constructed from only those EncryptedData elements with
a matching Id attribute.

This also means that E needs to get passed into this
function. Also, we might do better to construct the map Y in
the outer function and pass it into the inner function which
will populate it.

In the end, I'm not sure that the separation of functions
necessarily makes things clearer.

Also, I think that we should /only/ dereference barename
XPointers (#foo), and not full XPointers (#xpointer('foo')).
  . There is no benefit to using the latter form in an
    exception, so supporting them doesn't help anyone.
  . In my implementation (and I presume others), I simply
    pass the URI into my XPointer dereferencer. While I can
    easily identify barename XPointers at this outer level,
    I really don't want to have to parse the XPointer to
    determine whether it matches # S 'xpointer' S '(' S
    LITERAL S ')'.

>     * Super-encryption may cause problems if a super-encrypted
>       xenc:EncryptedData element uses same-document references, or if an
>       exceptional super-encrypted xenc:EncryptedData element is
>       referenced by a URI with an XPointer except a full XPointer
>       "xpointer(id('ID'))" and bare name.

Comment as above.

As before, I would like a separate binary mode for this
transform. I think that signing encrypted binary data is a
fundamentally different operation; the input can never have
been a plaintext node set, so I think this deserves its own
sub-URI. If it throws an error on multiple EncryptedData,
so be it; however, I think it should exist.

Received on Tuesday, 25 June 2002 19:21:26 UTC

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