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

RE: Signing and Encryption

From: Yongge Wang <ywang@certicom.com>
Date: Tue, 23 Jan 2001 13:25:01 -0500
To: xml-encryption@w3.org
Message-ID: <852569DD.00650CDF.00@smtpmail.certicom.com>

> I think the attack was probably brought up in the RSA meetings on PKCS.

Thanks for this info... I have never been to RSA PKCS meetings.. so not know
this attack...

> The real problem with sign after encrypt was the scope of the signature,
> which failed to include the key data, since fixed. There is no intrinsic
> problem with the order of the processes, it is simply a matter of doing the
> job right instead of wrong.
>
> Note that encrypt after sign still requires the signature blob to be
> encrypted to do the job properly.

That is correct. If encrypt after signature, the signature MUST be encrypted
(Simon Blake-Wilson has just told me this also). The problem is that XML-DSIG
and XML-ENCRYPT are two different standards.. and when you encrypt something,
you might not know it has been signed somewhere.

I fully agree with you that the right model may be the one which combines
signing and encryption (e.g., as you have mentioned, have a <crypto>
container)..

Regards,
Yongge


> Maybe what this is pointing to is that the model of separating signing and
> encryption might not be as neat as people thought... We may need an element
> <crypto> as container for all the signature and encryption data.







Philip Hallam-Baker <pbaker@verisign.com> on 01/23/2001 12:01:05 PM

To:   Yongge Wang/Certicom@Certicom, xml-encryption@w3.org
cc:

Subject:  RE: Signing and Encryption




I think the attack was probably brought up in the RSA meetings on PKCS.

The real problem with sign after encrypt was the scope of the signature,
which failed to include the key data, since fixed. There is no intrinsic
problem with the order of the processes, it is simply a matter of doing the
job right instead of wrong.

Note that encrypt after sign still requires the signature blob to be
encrypted to do the job properly.

Maybe what this is pointing to is that the model of separating signing and
encryption might not be as neat as people thought... We may need an element
<crypto> as container for all the signature and encryption data.


     Phill
Received on Tuesday, 23 January 2001 13:30:26 GMT

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