RE: Key Transport with ECC keys in XML Encryption 1.1

We have been focusing on specific algorithms, this will serve to help assure consistency and interoperability.  I see that there is a need for further work to enable easier use of still other algorithms. It would be best if we do not have to revise the standard as much when yet another, stronger, algorithm presents itself. How can we enable this standard be better able to support arbitrary algorithms in consistent ways?  I know these statements are at odds with one another, "arbitrary" yet "consistent" but this way we are enabling a better path to still other (unknown) algorithms. How can we specify a consistent structure, can we simply reference other standards that would specify the structure? Does IETF have this?


Gerald Edgar, CISSP
Enterprise Architecture & Information Security

Cell: 425-503-3912

-----Original Message-----
From: Magnus Nyström [mailto:magnus@rsa.com] 
Sent: Friday, May 29, 2009 2:37 AM
To: Pratik Datta
Cc: XMLSec WG Public List
Subject: Re: Key Transport with ECC keys in XML Encryption 1.1

Well, I guess you could just put the recipient's public key in the <ds:KeyInfo> of the <EncryptedKey> and then have the ephemeral public key of the sender prepended to the wrapped key in the <CipherData> as suggested. But you would still need to specify the key derivation algorithm - unless, as you suggest, you include that in the URI, perhaps along with an indication of the key length. But it looks like a hack to me...

-- Magnus

On Thu, 28 May 2009, Pratik Datta wrote:

> 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 14:32:34 UTC