- From: Takeshi Imamura <IMAMU@jp.ibm.com>
- Date: Tue, 15 Jan 2002 22:10:30 +0900
- To: reagle@w3.org
- Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xenc <xml-encryption@w3.org>
>> >Is this because you do not think the scenario is a compelling one, or it >> >isn't merely specified that way yet? Would you be opposed to >> > generalizing this to work for EncryptedKey or EncryptedData? (If we >> > don't support this, what does it mean when someone adds an EncryptedKey >> > to an XML instance that >> >has already been signed?) >> >> Sorry, I don't follow this. Do you expect the added EncryptedKey element >> is being decrypted if the element is not referenced from an Except >> element? If so, what happen when the element is decrypted? > >Sorry, I don't think I was being clear. We have this transform so that we >can validate a signature over a document that has EncryptedData's inserted >both before *and* after a signature. The transform tells us to decrypt the >EncryptedData's except for those that are specified in the Except -- >because they were signed in their encrypted form. > >My question is, can we imagine any scenarios where a document might have >EncryptedKeys added in a document both before *and* after a signature. >Would we want the capability to decrypt some but not others for Signature >Validation. > >I can imagine two answers this question: >1. There are no such scenarios. >2. Since EncryptedKey's are used for "internal" processing only, (they're a >"ends to a means"; they're not likely to be replacing any native data in >the original source document), they can stay in their Encrypted form >regardless. > >What do you think? There can be such scenarios and the transform can remove EncryptedKey elements added after a signature, but I'm not sure whether the transform is responsible for removing the EncryptedKey elements. For this reason, in Section 2.1.2 of the spec, it isn't recommended to detach any EncryptedKey elements from an EncryptedData element. But if there is a requirement for removal, I don't see any problem of supporting it. Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com
Received on Tuesday, 15 January 2002 09:11:10 UTC