Re: ACTION-829: Provide additional proposal text regarding xml encryption changes for pkcs1.5

Magnus

You raise a good point.

Something is odd here, because the text in PKCS1 indicates that RSAES-OAEP-ENCRYPT takes three args: the key, the message and a label. It also has two options, the hash function and the mask generation function. These options by definition are conveyed in OAEPparams, which has defaults of sha1 for the hash function and MGF1 with SHA1 for the mask generation function, but these are values that can be changed explicitly.

It looks like XML Encryption 1.1 text and example (not schema) says that the hash is defined using the XML Algorithm Attribute of the child EncryptionMethod element but does not allow in *XML* to define the MGF function, thus fixing it to a specific value. Yet at the same time the element OAEPParams is supported.

This seems to open the way for a possible ambiguity and inconsistency in the selection of hash algorithm, as well as not being clear on MGF.

The text is also correspondingly misleading by indicating that the MGF is fixed, which it should not be.

I propose we simply rely on OAEPParams  to select the hash and mgf. No need to change the XML schema for this, only the text and example

The current text is:

[[
The RSAES-OAEP-ENCRYPT algorithm, as specified in RFC 3447 [PKCS1], takes three parameters. The two user specified parameters are a MANDATORY message digest function and an optional encoding octet string OAEPparams. The message digest function is indicated by the Algorithm attribute of a childds:DigestMethod element and the mask generation function, the third parameter, is always MGF1 with SHA1 (mgf1SHA1Identifier). Both the message digest and mask generation functions are used in the EME-OAEP-ENCODE operation aspart of RSAES-OAEP-ENCRYPT. The encoding octet string is the base64 decoding of the content of an optional OAEPparams child element . If no OAEPparams child is provided, a null string is used.
]]

Proposed change:

[[
The RSAES-OAEP-ENCRYPT algorithm, as specified in RFC 3447 [PKCS1], takes two options to define the hash function and mask generation function, indicated in the OAEPParams value. By default,  the Hash is SHA1 and the mask generation function is MGF1 with SHA1 (mgf1SHA1Identifier).  If no OAEPparams child is provided, a null string is used.
]]

remove DigestMethod from example.

what have implementers been doing here? Will this simplification work?

I also think we should adopt Scott's text regarding key lengths.

regards, Frederick

Frederick Hirsch
Nokia



On Sep 14, 2011, at 2:24 AM, ext Magnus Nystrom wrote:

> On OAEP's use of SHA-1, maybe someone who participated in XML Encryption 1.0 can clarify the following for me:
> - What is the OAEPparams element intended to carry? If it is a Base64-encoded DER-encoded ASN.1 value of type RSAES-OAEP-params from RFC 3447 then we should be fine since all parameters - including the MGF can be specified in it.
> - OTOH, if I am correct above, then why was the MGF fixed to use SHA-1? This seems inconsistent.
> 
> -- Magnus
> 
> 
>> -----Original Message-----
>> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org]
>> On Behalf Of Cantor, Scott
>> Sent: Tuesday, September 13, 2011 7:55 AM
>> To: public-xmlsec@w3.org
>> Subject: Re: ACTION-829: Provide additional proposal text regarding xml
>> encryption changes for pkcs1.5
>> 
>> The WG preference was to leave the requirements more as is, so this is a
>> modified proposal to clean up the text.
>> 
>> Remove the last paragraph in the section 5.5 intro that starts "The RSA
>> v1.5 Key Transport algorithm given below..." It's misleading by implying you
>> have to use 1.5 with 3DES, and the reference for V2 to AESWRAP isn't correct
>> anyway. I think that text adds nothing.
>> 
>> Add a paragraph break leading to this text:
>> 
>> "Implementations must support this key transport algorithm for transporting
>> 192-bit TRIPLEDES keys. Support of this algorithm for transporting other keys is
>> optional. RSA-OAEP is recommended for the transport of AES keys, including
>> 192-bit keys.
>> 
>> Replace the last paragraph in section 5.5.2 with:
>> 
>> "The transported key size is 192 bits for TRIPLEDES and 128, 192, or 256 bits for
>> AES. Implementations MUST implement RSA-OAEP for the transport of all key
>> types and sizes that are mandatory to implement for symmetric encryption. They
>> MAY implement RSA-OAEP for the transport of other keys."
>> 
>> This question remains:
>> 
>>> Question: What, if anything, should be said about the DigestMethod(s)
>>> to require in conjunction with OAEP. Today, one typically finds that
>>> only
>>> SHA-1 works and is used. That seems like a problem if we reach a future
>>> state in which SHA-1 is totally broken and people want to turn it off
>>> entirely rather than pick and choose places where its use isn't
>>> suspect. I think even if we don't need SHA-256 here we ought to mandate
>>> it for future proofing.
>> 
>> -- Scott
>> 
>> 
> 
>

Received on Monday, 3 October 2011 18:23:53 UTC