Combining signing and encrypting

XML Signing and Encrypting

At the workshop, I promised to send a couple paragraphs on minimum requirements 
around handling documents with both encryption and signatures (sorry about the 
delay, I've been moving and on vacation).

In general, both signature and encryption operations may be performed on an XML 
document.  Depending on the usage case (see below), a signature may be applied 
to plaintext or ciphertext portions of documents.   To verify a signature, the 
recipient must know whether to decrypt before or after signature verification 
(possibly differently for different encrypted portions).  In order to enable 
efficient and automated signature validation, a goal of the design should be to 
allow well-behaved applications to indicate to the verifier/recipient how to 
unambiguously figure out in which order to perform decryption and signature 
validation operations (ill-behaved applications may always cause things to 
break). [Note: the suggestion is to add this last sentence to the requirements 
document.]

Some examples of usage include:
- Initial device generates transaction information with certain encrypted 
elements.  Intermediate application constructs full transaction and signs it or 
adds signature to original transaction (source authentication).  Result is that 
signature covers ciphertext and recipient must verify, then decrypt.

- Signed document/transaction is received and must be archived.  Sensitive 
information in document is to be protected by encrypting while allowing 
search/filter on plaintext elements.  Result is that elements must be decrypted 
before verification.

- Signed transactions are passed within a department/workgroup environment with 
a secured network.  Certain transactions must be forwarded outside the 
department at which time sensitive data is encrypted.  Recipient must decrypt, 
then verify

- A document is generated from a collection of XML document, some of which 
contain encrypted portions.  The new document is signed.  Recipient must verify 
signature prior to any decryption.

- Various multiple combinations based on the earlier sign/encrypt thread.

Possible approaches
Its probably a reasonable assumption that in many cases, the application will 
have a priori knowledge of how to handle the document (e.g., its always 
decrypt/verify).  I'm not sure if there's a way to indicate this in a schema 
description.  
An alternative suggestion, made originally by Jim Schaad, is to define a "don't 
decrypt" transform.  Coupled with a rule that says, in general "decrypt then 
verify", this would allow the signer to indicate an exception.  An implication 
of this is that signing applications need to be encryption aware.