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

Re: digest requirement

From: Joseph Reagle <reagle@w3.org>
Date: Mon, 17 Sep 2001 18:05:30 -0400
To: Amir Herzberg <AMIR@newgenpay.com>, XML Encryption WG <xml-encryption@w3.org>
Message-Id: <20010917220531.E613487461@policy.w3.org>
On Sunday 16 September 2001 11:23, Amir Herzberg wrote:
> I think Joe's scenario would work. Few comments:
>
> 1. Don't we need to copy the ID's to the EncryptedData tags for the
> references to work, e.g.:
>
> <AlphabetiSphagetti>
>   <A id="a"/>
>   <EncryptedData id="b" xmlns='http://www.w3.org/2001/04/xmlenc#'
>    Type='http://www.w3.org/2001/04/xmlenc#Element'>
>     <CipherData>
>       ....

For the references to work to what end? For the Signature Transform [1], or 
something else?

[1] http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt


> 2. What if we want the signature to also include a regular (mandatory,
> not Manifest) SignedInfo for parts of the document which are never
> encrypted? E.g. suppose the document is:
>
> <AlphabetiSphagetti>
>   <NonEncrypted1/>
>   <A id="a"/>
>   <B id="b"/>
>   <C id="c"/>
>   <NonEncrypted2/>
> </AlphabetiSphagetti>
>
> and we want to always provide a signature for the non-encrypted parts,
> which also can validate the encrypted components (if available in
> plaintext).
>
> In this case I think we need to add to the <SignedInfo> a reference to
> the entire document with a transform to remove the encrypted elements. Do
> we have to use XPATH for this? I'm not so happy with requiring such a
> heavy - and optional to implement - mechanism.

I'm not sure I understand, "which also can validate the encrypted 
components (if available in plaintext)." You could still have a Reference 
which identified specific data as well as a manifest. Are you familiar with 
[1]? 

[1] http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt

> 3. Text discussing this should be added to XML Encryption and /or DSIG
> (even if we can put most of it in DSIG I think a short comment in XML
> Encrypt is necessary).

If we went this route, I think the Encryption spec is the right place .

> 4. I still think adding DigestValue as optional element to EncryptedData
> is simpler way to achieve this function. But as long as the functionality
> is there, I'm Ok.

Once I'm sure I've addressed your questions such that my scenario can 
satisfy the requirements, I'll poll the list.
Received on Monday, 17 September 2001 18:06:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:02 UTC