Re: ACTION-319: Split DH Key agreement between new & legacy KDFs

Brian, all,

I had a look at this change and would like to make some minor (editorial) 
suggestions.

Section 5.6.2:

- Replace:

"Use of Diffie-Hellman with "new" KDFs is described in Section 5.6.1.1."

with:

"Use of Diffie-Hellman with explicit KDFs is described in Section 
5.6.2.1."

(Note: I have already made the reference correction above; this is about 
replacing "new" with "explicit")

- Replace:

"However, if implemented, such implementations MUST support the Legacy Key 
Derviation Function and SHOULD support new Key Derivation Functions."

with:

"However, if implemented, such implementations MUST support the Legacy Key 
Derivation Function and SHOULD support use of explicit Key Derivation 
Functions."

Section 5.6.2.1:

- Replace title with:

Diffie-Hellman Key Agreement with explicit Key Derivation Functions

- I agree with you on the example, maybe we could use the ECDH with
   derived keys example in 5.6.4 as a basis?

-- Magnus

On Mon, 6 Jul 2009, Brian LaMacchia wrote:

> Folks,
>
> I've committed revision 1.30 of xmlenc-core-11\Overview.htm, which 
> includes text to resolve ACTION-319 for Diffie-Hellman.  Specifically, 
> Section 5.6.2, Diffie-Hellman Key Agreement, now has two subsections:
>
> 5.6.2.1. Diffie-Hellman Key Agreement with new Key Derivation Functions
> 5.6.2.2. Diffie-Hellman Key Agreement with Legacy Key Derivation Function
>
> 5.6.2.2 has the "legacy KDF" that was defined for DH in XMLENC 1.0, and 5.6.2.1 is for use with the new standard elements for Key Derivation that Magnus introduced.  I made 5.6.2.1 say that it is RECOMMENDED that implementations use a new KDF in the standard format if doing DH, but if you implement DH you're REQUIRED to support the legacy format since it was defined in 1.0.  Also, the best/only way I could come up with to distinguish between legacy and new for DH is to key off the absence or presence of the KA-Nonce element (absence == new, presence == legacy).
>
> I also put a placeholder in Section 5.6.2.1 for an example, since it 
> seemed like a good idea to have one there.