- From: Magnus Nystrom <mnystrom@microsoft.com>
- Date: Wed, 24 Feb 2010 06:50:04 +0000
- To: "XMLSec WG Public List (public-xmlsec@w3.org)" <public-xmlsec@w3.org>
- Message-ID: <D744D68428430B4F9C81DE8A4D595068070B313F@TK5EX14MBXW602.wingroup.windeploy.ntde>
Dear All, Here's the result of Burt Kaliski's review with my suggested changes to the doc. * NIST has some specific requirements for KDF and OtherInfo - may want to reflect these Suggest adding a reference to the Key Derivation text in XML Enc 1.1 where we deal with this. * RSAES-KEM: o Step 1. The random number r can be 0 (doesn't affect the result in practice, but it's allowed within the security proof) Suggest clarifying in accordance with Burt's recommendation. o Step 3. RSAEP operates on integers not octet strings, so should be applied as c1 = RSAEP ((n,e), r), then C1 = I2OSP (c1, len(n)). Suggest doing this correction. * ECIES-KEM o Notation. EC points are usually capitalized. The use of g / h / G / H is possibly confusing. I'd suggest: P / Q / Qe / Z (where Qe is the ephemeral public key), but perhaps check what other EC documents use. Here, I tried to stay close to the notation in 18033-2, and so I suggest no change. o Step 1. Editorial: Reword consistent with step 1 of RSAES-KEM (where r correctly can't be 0 in this case) Suggest clarifying in accordance with Burt's recommendation. o Step 5. "public key h" should be "public key H" Actually, it should be just "the elliptic curve point H". Suggest doing this change. * Section 6.1. Consider adding a "real" example (these are hard to find for KEM ...) Yes, they are. While this would be good I am not able to do this right now. * Decryption operations need to be added. Yes, this should be added (even if it is just the reverse of the encapsulation). If the group agrees with the above I can take an action to update the document. -- Magnus
Received on Wednesday, 24 February 2010 06:51:04 UTC