Re: Minor comments for Last Call drafts of 20011018

On Tuesday 15 January 2002 08:10, Takeshi Imamura wrote:
> 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.

Good. We could include these if we had the requirement, but it hasn't 
appeared yet. Otherwise, as you say, section 2.1.1 is clear on this note, 
"This transform does not deal with any detached enc:EncryptedKey elements." 
However, I'm concerned the term "detached" might be confused in the 
signature context. Would you be ok with the following text:

3. This transform does not include enc:EncryptedKey elements within its 
scope of specifically indicating elements, and their exceptions, that 
should be decrypted. An enc:EncryptedKey that exists as a descendent of 
enc:EncryptedData might be decrypted and will be removed from the original 
document as part of processing its ancestor enc:EncryptedData with this 
transform. However, a lone enc:EncryptedKey will be processed like any 
other data: a signature is presumed to be over that literal element and not 
its decrypted form. Consequently, we recommend that enc:EncryptedKey 
elements always be a child of an enc:EncryptedData's ds:KeyInfo when they 
fall within the scope of a signature.


-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Tuesday, 15 January 2002 15:31:13 UTC