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.
>> 
>
>
>