RE: Key Transport with ECC keys in XML Encryption 1.1


I wanted to mention that the lawsuit between Certicom and Sony was dismissed on May 27, 2009, according to reports.

This may have an impact on the decision next week.

Regards, Cynthia

-----Original Message-----
From: [] On Behalf Of Pratik Datta
Sent: Thursday, May 28, 2009 4:20 PM
To: Magnus Nyström
Cc: XMLSec WG Public List
Subject: Re: Key Transport with ECC keys in XML Encryption 1.1

Can't we do ECC encryption that is analogous to the plain RSA v1.5 which 
doesn't do any KeyEncapsulation?

What I was hoping is if we could support a mode where an xml encrypted 
with a ECC key looks exactly similar to one with RSA 1.5 encryption, 
just with different URIs and different X509 certs. This would simplify 
the implementation immensely. In our implementation (and probably many 
other implementations too) the xml marshalling/unmarshalling/inspecting 
is done in a different layer than the crypto algorithms. So if we can 
support ECC encryption without adding any new xml elements, then we 
don't have to touch the xml marshalling/unmarshalling/inspecting code at 
all,  just give the  CipherData and the URI to the crypto layer and ask 
it do decrypt it.  

I like this idea of putting ephemeral key in the CipherData itself.

I am not saying that we should not support ECC with KeyEncapsulation or 
KeyAgreement, all I saying is that we should support a simpler (and 
probably only as secure as RSA v1.5) encryption with ECC.

Or if we could put KeyEncapsulation parameters as part of the URI itself


Magnus Nyström wrote:
> 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 
> 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 
> 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 Friday, 29 May 2009 00:32:33 UTC