ACTION-301: Example of KEM message and how to create it

This is an attempt to respond to ACTION-301 that I got yesterday. Given 
the schema in my earlier proposal

http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0056.html

one can construct the following example <xenc:EncryptedKey> element:

<xenc:EncryptedKey
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:dsig11="http://www.w3.org/2009/xmldsig11#"
   xmlns:dkey="http://www.w3.org/2009/xmlsec-dkey#"
   xmlns:kem="http://www.w3.org/2009/xmlsec-kem#">
   <xenc:EncryptionMethod
     Algorithm="http://www.w3.org/2009/xmlenc11#GenericHybridCipher">
     <kem:GenericHybridCipherMethod>
       <kem:KeyEncapsulationMethod
         Algorithm="http://www.w3.org/2009/xmlenc11#EC-KEM-KTS">
         <dkey:KeyDerivationMethod Algorithm="KDF2"/>
         <kem:KeyLen>16</kem:KeyLen>
       </kem:KeyEncapsulationMethod>
       <kem:DataEncapsulationMethod
         Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
     </kem:GenericHybridCipherMethod>
   </xenc:EncryptionMethod>
   <ds:KeyInfo>
     <dsig11:ECKeyValue>
       <dsig11:NamedCurve URI="urn:oid:1.2.840.10045.3.1.7"/>
       <dsig11:PublicKey>MIIB</dsig11:PublicKey>
     </dsig11:ECKeyValue>
   </ds:KeyInfo>
   <xenc:CipherData>
     <xenc:CipherValue>DEADBEEF</xenc:CipherValue>
   </xenc:CipherData>
</xenc:EncryptedKey>

In the above, what has happened is:

1) EncryptionMethod is "GenericHybrid" - as in ISO/IEC 18033 and S/MIME
2) There is a parameter set for GenericHybrid that gives
    a) the key encapsulation method (EC-KEM-KTS for Elliptic Curve Key
       Encapsulation Method - Key Transport Scheme (since we're doing key
       wrapping here), along with its params (derived key length and key
       derivation method, leveraging the DerivedKeys schema)
    b) the data encapsulation method (AES key wrap in this case)
3) The key info does *not* need the AgreementMethod even though I
    suggested this earlier. I realized it is not needed as we have already
    specified the encapsulation scheme as EC-KEM-KTS, and so this
    element simply contains an ECKeyValue that is the recipient's public key
4) The CipherData is the concatenation of the ephemeral public key of the
    originator (as an octet string) and the wrapped key.

For RSA, we would have the same structure, it is just that instead of the 
(algorithm identifier being RSA-KEM-KTS and the) ephemeral key we would 
have the CipherData consisting of the concatenation of the public-key 
encrypted random value and the wrapped key.

(And in addition this structure brings us pretty close to "ordinary" RSA 
key transport as Pratik was asking for.)

-- Magnus

Received on Wednesday, 3 June 2009 10:53:35 UTC