Signing and Encryption

The discussion on combining encryption and signing and how to verify a signature
in this case is interesting. Given the complexity of the combinations possible -
signatures with multiple references combined with pre and post encryption on
referenced content - I'm not sure there is a simple answer possible without
introducing new information.

I assume that an encryptor may be subsequent in the workflow to a signer, and
not be able to modify a signature (since the information is signed with a key
they do not have access to). Otherwise the signature reference could be updated
to reflect the encryption.

As a result I think we need three pieces of information when signing and
encrypting portions of XML:
- Signing information (in the Signature elements)
- Encryption information (in the EncryptedData and EncryptedKey elements)
- Document meta information (regarding the document as a whole and interactions)

The third item is only needed when the interactions exist and are potentially
ambiguous.

It is necessary to establish which encrypted elements correspond to the
references in the Signatures (not entirely clear to the application) as well as
ordering of operations.

I propose a new element which the encryption service or signing service is
required to include in the result when that service knows there is an
interaction between signing and encryption. This element should enable a
subsequent decryption or signature verification service to determine
unambiguously the relation between signing and encryption when it has occurred.

< Frederick

Assume the document to be verified is created as follows:

1. Party A creates the document, e.g.
<example><a Id="a">something</a></example>

2. Party A signs the "a" element creating a detached signature. The reference
URI in the signature might be:
<Reference URI='http://www.someplace.com/example.xml@xpointer(id("a"))'>

The document and the signature are passed to party B.

3. B encrypts element a in the document, for confidentiality. This causes the
element to be replaced with a new element, resulting in:
<example><xenc:EncryptedData Id="a">,,,</enc:EncryptedData></example>

Assume here that the EncryptedData element has the same Id as the element it
replaced.

4. Assume party C receives the document with the encrypted element and the
signature and wishes to verify the signature. The reference is valid since the
encrypted element has the "a" Id, so the signature could be over the encrypted
element or over the unencrypted element. One approach would be to attempt verify
the signature with the reference to the encrypted element - this is the correct
behaviour since this is what the reference refers to. If it fails, the verifier
could detect that the element was encrypted, decrypt it, and try again.

If the id were different, more likely, the verifier would be forced to fail
unless it decrypted every encrypted element to check the resulting id.

Alternatively, upon encryption in step 3, if the encryptor could generate a new
signature,
they could change the reference to include the attribute 'Type="encrypted"' and
the new id. This would make it clear that decryption is necessary, but would not
work if the encryptor were a party other than the signer, a likely case.

Received on Monday, 22 January 2001 13:01:18 UTC