Re: Decryption Transform processing question

Merlin,

>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 concerned about a case where a part that is being selected by an XPath
is totally encrypted.  The case is very likely to occur, and for the case
one may place the decryption transform prior to the XPath filtering.  As a
result, the problem that I raised before can occur.

I don't think that the limitation that the input node-set cannot contain
undecryptable parts is reasonable because it is natural to contain such
parts, especially in scenarios like workflow.  The purpose of the
decryption transform is to maximize signature verifiability in such
scenarios, and for the purpose the decryption transform should proceed even
if decryption fails.

I admit that 'MAY' makes processing ambiguous, but 'MUST' seems too strong.
It may be appropriate to have applications choose processing (i.e., proceed
or not) if decryption fails.

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

I'm happy to take your text.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com

Received on Wednesday, 31 July 2002 01:29:42 UTC