Re: key encapsulation draft comments

No, I think we should keep ISO site link, so people can get to the  
document.

Regarding 4.4 it just seemed odd to have a list of URIs and then some  
other material. Perhaps text regarding intent/transition would help  
here.

regards, Frederick

Frederick Hirsch
Nokia



On Jun 23, 2009, at 9:09 AM, ext Magnus Nyström wrote:

> 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
> specification.
>
>> (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
> too.
>>
>> (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
>
> Yes.
>
> Will check in an update to resolve 1 - 3) and 5) above.
>
> Thanks again,
> -- Magnus

Received on Tuesday, 23 June 2009 13:24:29 UTC