RE: Key Transport with ECC keys in XML Encryption 1.1

In reading this, this was the result of a "settlement agreement" (as stated in filing 112, May 26, 2009), I am not a lawyer, but a settlement may mean that the case is unchanged, just that they felt they could do better negotiating than in court.


Gerald Edgar, CISSP
Enterprise Architecture & Information Security



-----Original Message-----
From: Martin, Cynthia E. [mailto:cemartin@mitre.org] 
Sent: Thursday, May 28, 2009 5:32 PM
To: XMLSec WG Public List
Cc: Martin, Cynthia E.
Subject: RE: Key Transport with ECC keys in XML Encryption 1.1

Colleagues,

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

http://dockets.justia.com/docket/court-txedce/case_no-2:2007cv00216/case_id-103383/

This may have an impact on the decision next week.

Regards, Cynthia

-----Original Message-----
From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] 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

Pratik


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 
> 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 Friday, 29 May 2009 13:45:03 UTC