Re: Minor comments for Last Call drafts of 20011018

>> 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.

Thank you for suggesting text.  I'm OK with the text except that "a child"
would be "children".

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com

Received on Wednesday, 16 January 2002 00:44:43 UTC