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