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

Re: Decryption Transform processing question

From: merlin <merlin@baltimore.ie>
Date: Tue, 30 Jul 2002 21:59:35 +0100
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: xml-encryption@w3.org
Message-Id: <20020730205935.CCC8043C1D@yog-sothoth.ie.baltimore.com>

r/IMAMU@jp.ibm.com/2002.07.29/17:54:02
>My intent was not to solve the problem but rather to enable to use the
>decryption transform in any places.  I can easily think of cases where the
>decryption transform has to be performed first.  For such cases, I don't
>think that we should suppose any place where the decryption transform is
>placed.

The decryption transform can be used in any place, subject to
some limitations that we document. One of these limitations is
that the input node-set cannot contain undecryptable sections,
which seems reasonable. We consequently recommend that XPaths
appear first, if they are utilized, to solve the problem that
you have highlighted. If this is inappropriate or undesirable,
people are free to do whatever they need.

I just don't understand how the MAY proceed text solves any
problem.

Saying that implementors MAY support full XPointers solves a
problem: It optionally allows the added feature of XPointer
handling.

Saying that implementors MAY proceed if decryption fails
doesn't optionally allow any added feature, it simply means
that processing is ambiguous. If we are to go this route,
we should document that they MUST proceed; that way all
compliant decryption transforms will work. I personally
don't think that we should proceed if decryption has failed.

>>I'm not proposing the prohibition of full XPointers, I'm
>>proposing that we limit our super-encryption hack to just
>>handle barename XPointers. In the normal case, full XPointers
>>are processed fine. If, however, someone has an exception
>>URI that points into a super-encrypted block, then normal
>>XPointer processing cannot be performed and we have to
>>fall into a hack, which is to identify super-encrypted
>>EncryptedData elements based on their Id attribute and barename
>>XPointers. We're no longer doing XPointer evaluation, we're
>>doing a hack; I want to keep this hack simple, because the
>>added complexity of handling #xpointer(id('foo')) XPointers
>>doesn't buy us anything.
>>
>>Handling full XPointers in main-document exceptions is really
>>useful. Extending this into our hack isn't useful; it has
>>cost with absolutely no benefit.
>
>So I'm proposing to make it recommended or optional to implement.
>Considering that support of full XPointers in main-document exceptions is
>optional, it seems natural to make support of them in sub-document
>exceptions optional.  However, I don't have so strong opinion on this, so I
>can take yours.

How about the following text:

  3.1 Processing Rules
  ...
  Y = decryptNodeSet(N,E) <-- NB: there's still a stricken X in the draft
  1. Let D...
    o When dereferencing ...
    o When dereferencing an exception URI in the context of a
    replacement node-set, <strike>only</strike> bare name [XPointer]
    exception URIs are used to locate xenc:EncryptedData elements
    with matching Id attributes. <ins>Implementors MAY attempt
    to resolve full XPointers into replacement node-sets using
    appropriate techniques to take into account the location of
    the replacement node-set in the input document.</ins>

Implementors can then add full XPointer support as they see fit.

Merlin
Received on Tuesday, 30 July 2002 17:00:08 GMT

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