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

Re: Decryption Transform processing question

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Thu, 13 Jun 2002 00:44:20 +0900
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org
Message-ID: <OFE2343462.BEB5785C-ON49256BD6.005506DC@LocalDomain>


Hi Merlin,

>>>2) Encryptor-specified superdecryption
>>>
>>>   c) The encryptor super-encrypts unexceptional EncryptedData,
>>>      mindful of the potential problems. It indicates this by
>>>      using the SuperEncryptedData Type, and utilizing
>>>      mechanisms to overcome the problems if necessary.
>>
>>As I pointed out before, this is not possible when a signature is not
>>given.  Also, when encrypting exceptional and unexceptional EncryptedData
>>elements together, how should we do so?
>>
>>However, I agree with you that, if a signature is given, an encryptor can
>>decide which EncryptedData element should be decrypted.  So how about the
>>following, which is opposite to 2):
>>
>>3) Encryptor-specified super-undecryption
>>
>>Decrypt all the EncryptedData elements recursively except for those
>>specified by the super-encrypting EncryptedData element.  Those could be
>>specified by decrypt:Except elements specified as encryption properties.
>>The mechanisms you proposed could be used in order to the problems.
>>
>>This provides the same function as 2), but it would suit the concept of
>>decryption transform much better.  This means that we don't have to
>>reimplement the transform from scratch.  How do you feel?
>
>I think that this is a good option. But, I trust that you are
>speaking broadly in the context of the modified description
>of the decrypt transform (#13b)? If so, I will try and draw
>up some more explicit text.

I probably understand your text, but am I speaking anything strange?
Anyway, more explicit text would be helpful.  I will try to make some text
on my proposal, too.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com
Received on Wednesday, 12 June 2002 12:44:21 UTC

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