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

Re: Decryption Transform processing question

From: merlin <merlin@baltimore.ie>
Date: Thu, 01 Aug 2002 17:55:32 +0100
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: xml-encryption@w3.org
Message-Id: <20020801165532.9EAD143C1D@yog-sothoth.ie.baltimore.com>

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

I'm not convinced that the transform must deal with arbitrary
random encryption of documents. Encryption will be performed
according to a workflow process that will, by definition,
have been created with XML security in mind; and, as such,
it will be defined in a manner that works (i.e., transforms
will be created and ordered as necessary).

The current text does not prohibit placing an XPath transform
after a decryption transform if that is necessary, which will
solve the very likely case that you propose.

The case that we do not solve is one that I do not consider
very likely: Decryptable super encryption of XML data that
include undecryptable data that are not covered by an exception
and happen to fall into a part that is removed by an XPath
transform that cannot occur before the decryption transform.
I admit to not being familiar with workflow processes, but
is this genuinely probable?

Leaving the choice up to the application is not interoperable;
if I receive a signed document I cannot, in general, know what
to do with it. I don't think that a new parameter selecting
between auto-fail and auto-continue is workable. We wind
up with two choices for interoperability: MUST fail or MUST
proceed. I'll let you choose because, despite the amount that
I write, I'm not particularly concerned about this case, as
long as the result is interoperable.

Received on Thursday, 1 August 2002 12:56:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:04 UTC