W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2001

Re: Signing and Encryption

From: Joseph Ashwood <jashwood@arcot.com>
Date: Mon, 22 Jan 2001 15:16:55 -0800
Message-ID: <03de01c084cb$c82fd7a0$2a0210ac@livermore>
To: <xml-encryption@w3.org>
From: "Frederick J. Hirsch" <hirsch@caveosystems.com>
> 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
> The third item is only needed when the interactions exist and are
> ambiguous.

I don't see any ambiguous cases. If portions of the document are encrypted
after the document (or a subset of it) has been signed, the encryption
itself is an alteration, so the encryption should void the signature until
the encryption is removed. If the document is encrypted before signing, the
encrypted data is what has been signed, by decrypting it you should
invalidate the signature. Whether or not we can unambiguously assign an
ordering to these is not an issue. The issue is a program one, or rather an
ambiguous understanding of the requirements of the program, it has been
shown that encrypting before signing is bad (ref. PKCS #1 v1.0 was broken
when it was shown that you could alter the data that was signed by changing
the RSA key for the encryption, and the signature remained valid), by
forcing the encryption/decryption of data to invalidate the signature we
enforce this issue, the statement about the encrypted data is "This
encrypted data has been certified as untampered" if the key is also
certified then the statement is stronger, however if the key is signed then
the order of operations is unambiguous, the encryption happened before the
signing. I believe the (semi-)ambiguous cases should not be addressed,
perhaps specifically left unaddressed, because the statement that is made is
by nature ambiguous.
Received on Monday, 22 January 2001 18:34:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:01 UTC