Combining signing and encrypting from david.solo@citicorp.com on 2000-11-20 (xml-encryption@w3.org from November 2000) (original) (raw)

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.