W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2002

Re: Minor comments for Last Call drafts of 20011018

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Wed, 16 Jan 2002 14:44:34 +0900
To: reagle@w3.org
Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xenc <xml-encryption@w3.org>
Message-ID: <OF535498E7.933D308C-ON49256B43.001F2084@LocalDomain>

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

Tokyo Research Laboratory
IBM Research
Received on Wednesday, 16 January 2002 00:44:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:07 UTC