RE: In XML encryption 1.1, the PBKDF2-params/KeyLength is superfluous

Maybe we can put in a warning that the specified length must match the 
implied length, otherwise it is an error condition.

Here is a my proposed text  for section 5.4.2

Original:
The PBKDF2-params element and its child elements have the same names and meaning as the corresponding components of the PBKDF2-params ASN.1 type in [PKCS5]. 


Proposed:
The PBKDF2-params element and its child elements have the same names and meaning as the corresponding components of the PBKDF2-params ASN.1 type in [PKCS5]. Note, in case of ConcatKDF and the Diffie Helman legacy KDF, the keylength is implied parameter and needs to be inferred from the context, but in case PBKDF2 the KeyLength child element has to be specified, as it has been made a mandatory parameter to be consistent with PKCS5. For PBKDF2, the inferred key length must match the specified key length, otherwise it is an error condition.

This is for my ACTION-851

Pratik


-----Original Message-----
From: Pratik Datta 
Sent: Monday, October 17, 2011 1:08 PM
To: Magnus Nystrom; XMLSec WG Public List (public-xmlsec@w3.org)
Subject: RE: In XML encryption 1.1, the PBKDF2-params/KeyLength is superfluous

Even the original Diffie Helman of XML encryption 1.0, which we now call "legacy KDF"  does not have keydatalen.

So I think we should not have KeyLength anywhere.  

Another thing to compare with is wsc:DerivedKeyToken  http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.html#_Toc162064057
Here the /wsc:DerivedKeyToken/wsc:Length  is optional

Pratik

-----Original Message-----
From: Magnus Nystrom [mailto:mnystrom@microsoft.com]
Sent: Monday, October 17, 2011 10:03 AM
To: Pratik Datta; XMLSec WG Public List (public-xmlsec@w3.org)
Subject: RE: In XML encryption 1.1, the PBKDF2-params/KeyLength is superfluous

True. Perhaps we should instead add the KeyDatalen to ConcatKDF (at least as an optional?)?

I am a little wary at doing any changes to the schema at this late point though given that what we have apparently works - but I can see the inconsistency. I'd rather not change the PBKDF2 schema though since we currently have alignment with the schema for PKCS #5 - the same elements & attributes.

-- Magnus


> -----Original Message-----
> From: Pratik Datta [mailto:pratik.datta@oracle.com]
> Sent: Monday, October 17, 2011 9:25 AM
> To: Magnus Nystrom; XMLSec WG Public List (public-xmlsec@w3.org)
> Subject: RE: In XML encryption 1.1, the PBKDF2-params/KeyLength is 
> superfluous
> 
> Even for ConcatKDF, "keydatalen" is a required input to the algorithm.
> But we don't have that as a parameter for ConcatKDF. It needs to be inferred.
> 
> Pratik
> 
> -----Original Message-----
> From: Magnus Nystrom [mailto:mnystrom@microsoft.com]
> Sent: Monday, October 17, 2011 8:57 AM
> To: XMLSec WG Public List (public-xmlsec@w3.org)
> Subject: RE: In XML encryption 1.1, the PBKDF2-params/KeyLength is 
> superfluous
> 
> Pratik wrote:
> 
> > Can we remove the  KeyLength parameter in  PBKDF2 ?
> > In the other two key derivation functions - ConcatKDF and 
> > LegacyKeyDerivation, the length of the key to be derived is not 
> > specified ,
> rather it needs to be inferred from the context.  We should have 
> PBKDF2  also behave similarly.
> 
> I don't see how one could do this as the KeyLength is an integral part 
> of the
> PBKDF2 algorithm. For example, it is used to determine how many blocks 
> of hash output that is required. I'd recommend not trying to change 
> this at this point.
> 
> -- Magnus
> 
>

Received on Tuesday, 29 November 2011 17:41:18 UTC