RE: support for signing plaintext and ciphertext

Joe said:
> From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
> At 09:48 5/15/2001 +0300, Amir Herzberg wrote:
> I was trying to focus on the added features of the proposal, 
> so when you say:
> 
> >-- A recipient with the decryption key can validate that the entire
message
> >(including the  encrypted part) was signed
> 
> When used with XML Signature? (When you say encrypted part, do you mean
the 
> plain or cipher data?)
When using XML DSIG; and validation is for the plaintext. 
> 
> >-- A recipient without the decryption key can only validate the
> >non-encrypted parts of the message.
> 
> Well, he can validate the whole document, which is the version with 
> EncryptedData included.
Of course. I meant, that this recipient is not able to validate (or see) the
plaintext. 

<skip>
> There's really two parts of this proposal which I'd like to break apart:
> 1. Integrity: hashOfRandomized (let's call it DigestMethod and DigestValue

> in CipherData)
> 2. Morphing Feature: changing Encryption information without 
> breaking the signature.

Agreed. But there's a third feature, which you may consider just a variant
on Morphing:
2.1 Trimming: removing (most of the) Encryption information without breaking
the signature, creating a version of the message which does not contain the
encrypted information. 
> 
> The first part, I think makes sense and is fairly straightforward.

I can add, that for the applications I have in mind currently, only
Integrity, and to lesser extent Trimming, are applicable. 
> 
> The morphing necessitates a transform, but just to start with natural 
> language:
> (1. Resolve the Reference URI).
> 2. Find any EncryptedData children with a HashOfRandomized child.
> 3. Replace the EncryptedData element with its HashofRandomized child.
> 
> My tenative concerns with this approach:
> 1. How would this interact with the encrypt-sign transform, any
side-effects 
> or does it become unwieldy and complex when  you consider both?
Sorry, I lost reference to encrypt-sign transform, please re-send it so I
can review this. 
> 2. Performance?
This proposal should allow removal of encrypted data for performance
reasons. The transform should not be too heavy, and anyway is optional, of
course. 
> 3. It's clear we need a more complete specification.
For the tranform, yes, but I think this can and should be done after we
agree on allowing the HashOfRandomized (or better name) element. As you
said, this tag can be used also for achieving just the Integrity goal; for
that the transform is not needed. 

Best regards, 
Amir Herzberg
CTO, NewGenPay Inc.  

See demo and lectures/overviews/tutorials on crypto-security for mobile,
e-commerce, etc. in http://www.newgenpay.com/mpay/course/course.html

Received on Sunday, 20 May 2001 02:18:10 UTC