digest requirement

Merlin said, 
> Just to clarify, my understanding of Amir's digest requirement is:
> 
> . To create a document with multiple encrypted parts.
More precisely, with one or more encrypted parts, as the hash (digest) of
the plaintext is required even if we need to sign a document with a single
encrypted part. 
> . To include a digest of the plaintext part in each EncryptedData.
> . To compute a signature over these digests.
> 
> The purpose of this is that you can validate the signature
> fully, and then selectively validate individual plaintexts
> depending on your needs.
Again, more precisely `... and then selectively validate the plaintext (or
individual plaintexts)...
> 
> I would suggest that this requirement is satisfied by
> XML signature manifests and our decryption transform:
> 
> . Create a document with multiple encrypted parts.
> . Create a manifest containing a reference to each EncryptedData
>   processed by our decryption transform.
> . Create a signature over this manifest.

This is exactly the alternate solution I described in the teleconf. I think
it can work, but 
I have the following minor issues with it:

1. Manifest is an optional element of DSIG. We'll require its use (even if
we sign a single encrypted document). 
2. I'm afraid implementors will not understand how and when to use this. At
least, I think this must be well documented - I think in XML encryption
spec. 
3. I'm not sure how the Reference elements in the Manifest will identify the
hashed elements. They need to refer to the decrypted value of an
EncryptedData element - how do you do this? 

Due to these issues I prefer to leave the DigestValue of the plaintext as an
optional element in EncryptedData. But if people prefer and if we can
resolve the above issues, I'm Ok with the alternate solution. 

Best, Amir Herzberg

Received on Wednesday, 12 September 2001 03:01:04 UTC