RE: Signing and Encryption

I guess there is a conflict between potential business workflow requirements and
technology requirements.

The business workflow model suggests that a document may be passed around among
parties who arbitrarily sign and/or encrypt portions of the XML - like the
previous example of the DoD signing an element, and then later, independently,
the CIA deciding to encrypt a portion. A user may have reasons for doing these
things without concern for the technology.

On the other hand, from a security technology perspective, there are rules about
combining encryption and signing in a secure manner, which limits what should be
done, or perhaps suggests that additional encryption/signing be performed when
needed.

The suggestion that the management of signing and encryption is separate from
the individual signing and encryption standards makes sense - maybe that is
application dependent.

< Frederick


> -----Original Message-----
> From: xml-encryption-request@w3.org
> [mailto:xml-encryption-request@w3.org]On Behalf Of Joseph Ashwood
> Sent: Monday, January 22, 2001 6:17 PM
> To: xml-encryption@w3.org
> Subject: Re: Signing and Encryption
>
>
> 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
> interactions)
> >
> > The third item is only needed when the interactions exist and are
> potentially
> > 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.
>                         Joe
>
>

Received on Tuesday, 23 January 2001 09:56:19 UTC