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

Re: Signing and Encryption

From: Yongge Wang <ywang@certicom.com>
Date: Mon, 22 Jan 2001 16:55:38 -0500
To: xml-encryption@w3.org
Message-ID: <852569DC.007800F9.00@smtpmail.certicom.com>
Frederick J. Hirsch wrote:

> 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 guess the problem is that we have already had an XML-DSIG recommendation,
and there is no such kind of information in that recommendation.

Also the problem is that when a person try to sign an XML document, s/he
does not know whether some of the elements will be encrypted in the future.
Consider the following scenario: Some XML document has been generated by
US DoD, and the leader has signed the document. when the document is sent to
CIA, CIA feels some elment should be encrypted, and thus encrypts it. Of course,
CIA can encrypt it and send it back to DoD so that DoD can resign it.

There might also be the scenary that when CIA encrypts some element,
CIA is not aware that this document has been signed by DoD...(XML-DSIG
can reference-point-- to some exterior document)

Indeed, this might more be a management problem in the future instead of
XML-DSIG or XML-Encryption standard problem.


But generally, in order to be secure, the rule is: encryption first, sign
second (there are some provable security results in this area).

Yongge

>
> 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.
Received on Monday, 22 January 2001 16:56:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:18 GMT