Re: ACTION-317: Move derived keys into XML Enc v1.1.

Frederick,

Thanks for reviewing so quickly. My responses below.

On Fri, 19 Jun 2009, Frederick Hirsch wrote:

> Magnus
>
> I have a couple of questions.
>
> Questions related to 5.4:
>
> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-Alg-KeyDerivation
>
> (1) Regarding section 5.4.1 in XML Encryption, why does the schema not 
> also define SuppPrivInfo to correspond to that item in Section 5.8.1 of 
> NIST 800-56A, it seems this may also need to be optionally conveyed?

This is an oversight, the schema should allow for this.

> (2) Do we need to specify which alternative algorithm in Section 5.8.1 of 
> NIST 800-56A is used, the difference being how OtherInfo is encoded? Perhaps 
> we need a sentence on which encoding is to be used?

Not sure. Brian and Kelvin had suggested that the value "00" be 
interpreted for 3DES and AES-128. I copied that text. Looking at this 
again, it may make sense to add a sentence stating that in this case, the 
complete KDF output is to be interpreted as the key.

> (3) I must be misinterpreting section 5.8 of NIST 800-56A since it seems to 
> read that you can only use a KDF once on a secret, yet I thought the secret 
> could be retained and used with the KDF more than once to generate a variety 
> of keys.
>
> "Each call to the KDF requires a freshly computed shared secret, and this 
> shared secret shall be zeroized immediately following its use. "

For compliance with NIST 800-56A, when using a key derivation function 
_with a key agreement scheme_, the input should be different each time. 
But this just means that either you use at least one ephemeral key pair or 
you make sure to use fresh nonce.

Once you have established the shared keying material, an application can 
derive other keys from it by use of a fresh nonce, for example.

> (4) Maybe it is better to include the Algorithm attribute with URI value in 
> the PRF element, rather than relying on a default value from the schema?
> Perhaps mandate this?

This is in the context of PBKDF2. Yes, including it might be better, 
especially given that PKCS #5 v2.0 Amd.1 defaults to HMAC-SHA1. I'd be 
open to this change (profiling of PKCS #5 v2.0 Amd.1.).

> (5) I notice that the references related to PKCS#5 point to the generic RSA 
> PKCS page rather than the specific PKCS documents. When I tried to access 
> those documents I could not retrieve from the RSA site, had to find mirrors 
> on the internet...

They are available, I have checked in an update with more precise 
references.

> questions on 3.5.2 The DerivedKey Element
>
> (6) What does it mean if there is more than one KeyDerivationMethod? Should 
> there be a maxOccurs of 1?

Maybe I'm confused, but isn't that the default in the schema? ("when an 
element ... is declared without a maxOccurs attribute, the element may not 
occur more than once" (from the Schema Primer).

> (7) In the text " If no MasterKeyName is provided" the formatting of "no" 
> seems wrong. (nit)

There's no special formatting of it in the source.

> (8) Does having Recipient make sense for DerivedKey, given that the Derived 
> Key is used in the same document? Does it make sense?

I am certainly willing to discuss it. I did not originally have this 
attribute, but added it in the May version of Derived Keys after comparing 
with the xenc:EncryptedKey element. It seemed to me that it could make 
sense when an element has been encrypted for several recipients in that it 
could assist a particular recipient in quickly finding the correct 
DerivedKey element (there's no guarantee the MasterKeyName is unique among 
recipients).

> Thanks for updating the XML Encryption 1.1 specification with this material, 
> it seems to be appropriate in this document.

Well thanks for reviewing, Frederick. I wanted to make sure to get this 
ready for review before my vacation (which has now started) so that we 
don't loose time. Intend to dial in tomorrow.

-- Magnus

> On Jun 17, 2009, at 6:49 PM, ext Magnus Nyström wrote:
>
>> This is in response to ACTION-317 that I got during last week's call.
>> 
>> I have now checked in a version of XML Encryption version 1.1 that
>> includes key derivation. In particular, I have:
>> 
>> - Created a new subsection 3.5.2
>> - Created a new subsection 5.4 (and up-ed the numbering of remaining
>>  subsections in Section 5)
>> - Modified section 5.1
>> - Modified section 5.6 - but there remains some work here, especially for
>>  "ordinary" DH - but this is Brian's and Kelvin's ACTION-319.
>> 
>> The above also includes several new examples.
>> 
>> I also added PKCS #5 v2.0 and PKCS #5 v2.0 Amd.1 to the references and
>> updated the reference to PKCS #1 to v2.1 from v2.0.
>> 
>> The schema file has been updated too (it validates) but I have not created
>> a redline version. I have also not changed the explain.html file as I
>> wanted to give the group a chance to review this work before doing so.
>> 
>> -- Magnus
>> 
>
>