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

Re: More inter samples

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Wed, 13 Mar 2002 21:32:30 +0900
To: Jiandong Guo <jguo@phaos.com>
Cc: xml-encryption@w3.org
Message-ID: <OF55379C0E.7F9E6D17-ON49256B7B.0043352A@LocalDomain>


>> >> However, I found that it succeeded in decrypting your
>> >> bad-type example.  That is reasonable to me because the decryptor is
not
>> >> required to perform validation on the serialized XML and hence our
>> >> implementation does not.  Should we include this example in test
>> vectors?
>> >
>> >My intention is that if you do the decrypt and replace, the type
>> information
>> >should be needed.
>> >In other words, it should cause you trouble when you replace the
>> EncryptedData
>> >element with
>> >the decrypted data if the the type attribute is not set correctly.
>>
>> I don't know how you have implemented this process, but the spec says:
>>
>> >The decryptor is NOT REQUIRED to perform validation on the serialized
XML.
>>
>> and also says:
>>
>> >The decryptor is NOT REQUIRED to perform validation on the result of
this
>> replacement operation.
>>
>> and hence I don't think that the implementation has to fail to decrypt
this
>> example.  In that sense, I asked this question.  Note, I don't say that
>> your implementation is wrong.  Such validation would be value-add.
>
>I think you are right. It more depends on the implementation with the
cuerrent
>document.
>My question is that if the type attribute is inconsistant with the data
>encrypted, should we require to treat this as an error
>or let it go if we can decrypt the encrypted data?

I think that it may be treated as an error, but I don't think that it is
required to be.  This is a case similar to the case where it is not
required to check if the MimeType attribute is inconsistent with the data
encrypted.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com
Received on Wednesday, 13 March 2002 09:03:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:20 GMT