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

Re: Signing encrypted data

From: Joseph Ashwood <jashwood@arcot.com>
Date: Mon, 26 Mar 2001 11:47:48 -0800
Message-ID: <00c301c0b62d$b15cdad0$2a0210ac@livermore>
To: "Amir Herzberg" <AMIR@newgenpay.com>, <xml-encryption@w3.org>
----- Original Message -----
From: "Amir Herzberg" <AMIR@newgenpay.com>
> Actually, MAC provides authentication but not non-repudiation.

That's where you're wrong. A MAC supplies different things based on how the
key was generated. For example if I simply use DH and distill a MAC key it
means "Either someone who knows my private key or someone who knows the
private key I targetted did this" in some situations that is better, for
example I could prove to you that I did X (since I don't know your private
key), but you can't prove to anyone else (because you do know your private
key).

> The
> (standard) technique I suggested provides non-repudiation, where
> confidentiality may need to be sacrified when presenting the proof.

The problem with your method is that it can't be verified without having
confientiality sacrificed.

> Two comments:
> 1. Revealing the plaintext to `prove` is done only as needed and when
> needed, and possibly only to a somewhat-trusted entity (judge). [No
offense
> intended :-)]

Or whenever else the signature needs to be verified. All other decryptions
are beyond the scope of Encryption vs Signature.

> 2. The signature can also contain components which are not encrypted. Some
> entities may be able to authenticate only the non-encrypted parts and the
> ciphertext.

This implies that the signature will be on data that has been previously
encrypted, which is allowed by the spec (or if not should be).
                    Joe
Received on Monday, 26 March 2001 14:48:48 GMT

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