- 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
r/IMAMU@jp.ibm.com/2002.07.31/14:29:30 >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. Merlin
Received on Thursday, 1 August 2002 12:56:04 UTC