- From: Takeshi Imamura <IMAMU@jp.ibm.com>
- Date: Fri, 15 Feb 2002 01:00:33 +0900
- To: reagle@w3.org
- Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
Joseph, >The matrix is now available at [1]. While I was creating it, I was also >doing some minor tweaks to the spec to make things more clear with respect >to conformance. Some of these things need some test-vectors. I think we can provide some of them, but we are now working on our implementation for the latest draft and that still needs some time. By what time do you expect to have them? >For instance, >is anyone ready to exchange actual examples for encryption/decryption? Any >volunteers to provide some test vectors? Other optional features (such as >ReferenceList) don't have an interop test but we still need reports as to >whether those features are supported -- otherwise we will drop them. > >Examples of tweaks to the spec include section 3.2.1 (CipherReference) >which now has some text [2] on conformance. I also did some tweaking to the >processing rules. I broke some text off in the Encryption rules and >included it as a 3.4. Also, I wonder if my tweaks to Decryption/3/4 is in >keeping with everyone else's understanding [3]? (Before, it just said if it >was a KeyValue, is it correct to limit it to the decrypted text of >EncryptedKeys?) I don't see any problem, but if "key value" is changed to "CipherData of EncryptedKey", shouldn't "data" be also changed to "CipherData of EncryptedData"? >Also, I don't include some of the MUSTs of the crypto algorithms since >they are so straightforward. For example, in DH Key Agreement, "The size of >p MUST be at least 512 bits and g at least 160 bits." > >Finally, since xmldsig is a SHOULD, I also include the Decryption Transform >as a SHOULD. > > >[1] http://www.w3.org/Encryption/2002/02-xenc-interop.html >[2] http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/ >$Revision: 1.133 $ on $Date: 2002/02/12 20:19:11 $ GMT by $Author: reagle $ >[3] "If the CipherData is a child of EncryptedKey, the cleartext octet >sequence represents a key value and is used in decrypting other >EncryptedType element(s). The decryptor MUST support passing this key value >and Type (if any) to the application for subsequent processing. If it >represents data then processing as described below is required. [Are my >tweaks correct? -JR]" Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com
Received on Thursday, 14 February 2002 11:16:50 UTC