Re: Key Transport with ECC keys in XML Encryption 1.1

Pratik,

I think what you're asking for is what would (could) be achieved with the 
ECC KEM-KTS I suggested on the list in 
http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0043.html

The ISO/IEC 18033-2 key encapsulation method is in fact ECIES and so a 
natural path to take for us would be to use ECIES-KEM-KTS for ECC and 
RSAES-KEM-KTS for RSA.

If you recall my posting, in the case of ECC, the AgreementMethod could 
contain the EC public key of the recipient as well as the (ephemeral) 
public key of the sender, and the CipherData would be the (wrapped) key.

As an alternative, and to be closer to ISO/IEC 18033, one could leave out 
the ephemeral key and instead let the CipherData be C0 | C1 where C0 would 
be the ephemeral key. Another advantage of this would be that the same 
format would be used for ECC as for RSA for transporting the KEM info.

To also stay closer to ISO/IEC 18033 in schema, one could do something 
like:

<element name="GenericHybridCipherMethod" type="kem:GenericHybridCipherMethodType"/>
<complexType name="GenericHybridCipherMethodType">
   <sequence>
     <element name="KeyEncapsulationMethod" type="kem:KeyEncapsulationMethodType"/>
     <element name="DataEncapsulationMethod" type="xenc:EncryptionMethodType"/>
   </sequence>
</complexType>

<complexType name="KeyEncapsulationMethodType">
   <sequence>
     <element ref="dkey:KeyDerivationMethod"/>
     <element name="KeyLen" type="positiveInteger"/>
     <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
   </sequence>
   <attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>

In actual instances then, for the <EncryptedKey> element, the <CipherData> 
could be the C0 | C1 as per above and the <EncryptionMethod> would specify 
"KEM" (or similar) as the Algorithm attribute and then, using the 
extensibility, have the "GenericHybridCipherMethod" at the extensibility 
point. The <keyInfo> would be as before. <DataEncapsulationMethod> would 
specify a key wrapping algorithm.

Probably we should discuss this further on the next call.

-- Magnus

On Wed, 20 May 2009, Pratik Datta wrote:

> For XML Encryption 1.1, we added a ECC Key agreement scheme ECDH-ES. 
> Can't we also add a Key Transport scheme - like ECIES?  However I think 
> that NIST Suite B does not allow ECIES.
>
> I am thinking of how hard it is to uptake ECC in higher level specs like 
> WS-Security.  For encryption there is often an assumption that the data 
> will be encrypted using an <EncryptedKey>, and this EncryptedKey is 
> encrypted with a public key. To do this with elliptic keys, we need a 
> Key Transport mechanism that supports Elliptic Keys. ECDH Key Agreement 
> cannot be used here.
>
> Note:  ECDSA signatures can be used in WS-Security with no schema 
> changes. WS-Security uses <BinarySecurityToken> to represent X509 
> certificates. So this token can also represent ECC X509 certs, and data 
> can be signed using this token.  But ECDH KeyAgreement cannot be that 
> easily used in WS-Security - as most encryption scenarios in WS-Security 
> use an EncrpytedKey.

Received on Thursday, 28 May 2009 10:28:46 UTC