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

Re: ACTION-300 Create sample to illustrate ECDH-ES with AES key wrap

From: Magnus Nyström <magnus@rsa.com>
Date: Tue, 9 Jun 2009 21:46:10 +0200 (W. Europe Daylight Time)
To: public-xmlsec@w3.org
Message-ID: <Pine.WNT.4.64.0906092143040.6960@W-JNISBETTEST-1.tablus.com>
Since Pratik was asking for it, here's how Kelvin's example would turn out
if one leveraged the KeyDerivationMethod type from the Derived Keys 

I'm arguing that leveraging the dkey:KeyDerivationMethod type is more 
generic and also more inline with existing practice in XMLSec of having a 
"...MethodType" (like EncryptionMethod in EncryptedData) where you specify 
the actual algorithm as a URI and then possibly have algorithm-specific 
parameters as a child element.

(If we merged XMLEnc 1.1 and DerivedKeys then the extra namespace would go 
away, of course).

So the example becomes:


   <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
   <!-- describes the encrypted AES content encryption key -->
       <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
       <!-- describes the key encryption key -->
         <xenc:AgreementMethod Algorithm="http://www.w3.org/2009/xmlenc11#ECDH-ES">
<!-- This is where the change starts -->
           <dkey:KeyDerivationMethod Algorithm="http://www.w3.org/2009/xmlenc11#SP80056AKDF">
               AlgorithmID="00" PartyUInfo="" PartyVInfo=""/>
<!-- This is where it ends -->
                 <!-- ephemeral ECC public key of the originator -->
               <!-- hint for the recipient's private key -->
         <xenc:CipherValue><!-- encrypted AES content encryption key --></xenc:CipherValue>

       <!-- encrypted data -->

Received on Tuesday, 9 June 2009 19:46:53 UTC

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