W3C home > Mailing lists > Public > public-xmlsec@w3.org > June 2009

Re: key encapsulation draft comments

From: Magnus Nyström <magnus@rsa.com>
Date: Tue, 23 Jun 2009 15:09:45 +0200 (W. Europe Daylight Time)
To: Frederick Hirsch <frederick.hirsch@nokia.com>
cc: XMLSec WG Public List <public-xmlsec@w3.org>
Message-ID: <Pine.WNT.4.64.0906231450250.4396@W-JNISBETTEST-1.tablus.com>
Thanks for reviewing, Frederick.

On Mon, 22 Jun 2009, Frederick Hirsch wrote:

> Some initial comments on key encapsulation draft at 
> http://www.w3.org/2008/xmlsec/Drafts/key-encapsulation/key-encapsulation.html
> Substantive
> (1) I assume that the entire specification can be optional, so MUSTs only 
> apply when adherence to the specification is claimed.

Yes, that was my intent. The MUSTs apply in the context of the 

> (2) I'm not sure why Key Transport is listed in  4.1 and suggest this be 
> removed since no URI is being defined here. Use for Key Transport should be 
> clear from used of EncryptedKey element, isn't that right? Likewise I'm not 
> sure why we have section 4.4.1.

The intent of section 4.4 was to make it clearer how to use generic hybrid 
with a key encapsulation mechanism and a key wrapping mechanism to perform 
key transport. I agree 4.4.1 could go away but would like to keep 4.4.

> (3) The draft mentions "tight security proofs" but don't all modern 
> security algorithms have definitions, assumptions and proofs? What is 
> special in this case?  (I think what is meant here is that the 
> "definition" provides security for a combination of key encapsulation 
> combined with subsequent encryption, thus addressing in a stronger way a 
> requirement for that combination, and having a corresponding proof). 
> We might want a more explicit statement and/or reference to the proofs 
> (actually that is in section 6, so maybe link to that section).

Adding a reference to section 6 is fine with me. The security proofs rely 
on the actual KEM constructs and so this could (or should) be clarified 
> (4) Is there another reference than ISO/IEC 18033-2 which requires a fee? 
> This makes the material hard to review.

I don't know of any freely available standard describing KEM/Generic 
Hybrid, unfortunately.

> Editorial
> (1) Abstract, in "Generic hybrid ciphers allows for a consistent treatment of 
> asymmetric ciphers when encrypting data and consists of a key encapsulation " 
> change "allows" to "allow" and "consists" to "consist" to match plural
> (2) Abstract, change "XML security" to "XML Security"
> (3) Section 3, in "Generic hybrid ciphers allows" change "allows" to "allow"

Yes to 1 - 3

> (4) The reference for ISO18033-2 does not lead to the document but rather the 
> entire ISO site.

Should I remove the link? As one cannot link to the document itself I just 
referenced ISO.

> (5) In 4.3.2 link  ISO/IEC 18033-2 seems to be broken:
> http://www.w3.org/2008/xmlsec/Drafts/key-encapsulation/key-encapsulation.html#ref-ISO18033-2


Will check in an update to resolve 1 - 3) and 5) above.

Thanks again,
-- Magnus
Received on Tuesday, 23 June 2009 13:10:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:11 UTC