RE: DH Key agreement in XMLEnc

Hi, jim,
thanks for your comments.

> On the contrary it is enough.  The recipient's key is specified in the
> KeyInfo structure which is part of the EncryptedKey element (just like it is
> for RSA or any other algorithm).  This syntax is for the additional
> non-standard parameters for DH and comes as the children of the
> EncryptionMethod element.
> 
> PartyAInfo is a base64 encoded blob (that's what CryptoBinary means) that
> can contain a string of bytes randomly generated by the originator so that
> the key agreement does not always end-up with the same key everytime in the
> static-static case.  This is a standard field straight out of X9.42

Check Section 7.5.1 and Section 8 of X9.42 Working Draft dated 
September 1999. I do not see anything there about what you are talking
about.

> I am looking at the CMS version of the X9.42 specification.  We explicitly
> put in both the algorithm and the key size (and made it fixed for RC2) in
> the key derivation function.  Note that for RC2 this is necessary becase the
> actual key size and the effective key size may not be the same.  Only the
> effective key size needs to be specified in the RC2 algorithm parameters
> since the actual key size is the size of the data that comes out of the key
> wrap (or key derivation) code.

For an algorithm specification, the effective key size is the default.
The reason we do not include the key size in the DH element is we do not
want to put additional burden on the complexity of schema definition
and implementation validation.

> It might not be necessary to have a new name space, but it does not hurt to
> show what would happen if it did occur.

I cannot see any reason for doing this. I assume that the original goal of
W3C namespace is to have one namespace for one standard (or definition).
I cannot see any advantage of having two namespaces for one standard.

> Creating a new EncryptedKey element for every algorithm is asking for
> trouble.  This means that the code needs to recognize, parse and treat as

We are not creating EncryptedKey element for each algorithm.

> equivant every different structure defined for every algorithm that comes
> along.  I don't want to define a new EncryptedKey structure for EC, for
> AES-KeyWrap, for RSAv1.5, for RSAv2.0, for RSAv9.9.  This is what the
> EncryptionMethod URI is for, it allows for an ANY structure to be placed as
> a child of that element that contains all necessary information for dealing
> with the new algorithm that is not part of the standard structure (the
> identification of the recipient key).
> 
> Not keeping everything uniform is what is going to cause complexity.


Thanks!
Yongge

Received on Friday, 16 March 2001 09:50:03 UTC