W3C home > Mailing lists > Public > public-xmlsec@w3.org > October 2011

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

From: <Frederick.Hirsch@nokia.com>
Date: Tue, 4 Oct 2011 18:10:52 +0000
To: <mnystrom@microsoft.com>
CC: <Frederick.Hirsch@nokia.com>, <pratik.datta@oracle.com>, <cantor.2@osu.edu>, <public-xmlsec@w3.org>
Message-ID: <0D945C61-311D-42DB-BEA4-8E7EE1F543DB@nokia.com>
Adding an XML child element for MGF  would be most straightforward and consistent, mirroring what we do for the digest function. 

How about I write that up as a proposal?

Now what exactly do we have the OAEPparams element for? Is it ignored, Pratik?

I think it would eliminate a *lot* of confusion if it were not there and we had appropriate XML elements. Scott indicated that the XML digest algorithm *is* used.

Should we remove the OAEPparams XML element?

regards, Frederick

Frederick Hirsch
Nokia



On Oct 4, 2011, at 1:57 PM, ext Magnus Nystrom wrote:

> I see. Well in that case we really don't have an option today for the MGF. Adding a new attribute?
> 
> -- Magnus
> 
> 
>> -----Original Message-----
>> From: Pratik Datta [mailto:pratik.datta@oracle.com]
>> Sent: Tuesday, October 04, 2011 10:41 AM
>> To: Magnus Nystrom; Frederick.Hirsch@nokia.com; cantor.2@osu.edu
>> Cc: public-xmlsec@w3.org
>> Subject: RE: ACTION-829: Provide additional proposal text regarding xml
>> encryption changes for pkcs1.5
>> 
>> I looked through our implementation, and there OAEPParams is a different.  It is
>> not the value of the PKCS 2.1 "RSAES-OAEP-params", instead it is the value of
>> "EncodingParameters" for PSource.
>> 
>> 
>> 
>> PKCS 2.1 has this field for "EncodingParameters"
>> 
>> 
>> PSourceAlgorithm ::= AlgorithmIdentifier { {PKCS1PSourceAlgorithms} }
>> PKCS1PSourceAlgorithms ALGORITHM-IDENTIFIER ::= { { OID id-pSpecified
>> PARAMETERS EncodingParameters }, ... -- Allows for future expansion -- } id-
>> pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } EncodingParameters ::= OCTET
>> STRING(SIZE(0..MAX))
>> 
>> 
>> 
>> We have also done an interop in which OAEPParams should be used this way
>> 
>> See http://lists.w3.org/Archives/Public/xml-encryption/2002Mar/0008.html
>> there is a zip file attached to this email.  Open up the zip file and see "encsig-
>> hmac-sha256-rsa-oaep-mgf1p.xml", and locate this
>> 
>> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-
>> oaep-mgf1p">
>>        <DigestMethod xmlns="http://www.w3.org/2000/09/xmldsig#"
>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>>        <OAEPparams>
>>          MTIzNDU2Nzg=
>>        </OAEPparams>
>>      </EncryptionMethod>
>> 
>> Notice that OAEPParams is of size 8 bytes, which can clearly not be the "RSAES-
>> OAEP-params" structure of PKCS 2.1, as that would have been  much larger.
>> 
>> Pratik
>> 
>> -----Original Message-----
>> From: Magnus Nystrom [mailto:mnystrom@microsoft.com]
>> Sent: Monday, October 03, 2011 7:48 PM
>> To: Frederick.Hirsch@nokia.com; cantor.2@osu.edu
>> Cc: public-xmlsec@w3.org
>> Subject: RE: ACTION-829: Provide additional proposal text regarding xml
>> encryption changes for pkcs1.5
>> 
>> Thanks for doing some specification archeology, Frederick!
>> 
>> To me, since the OAEPparams element does exist, it should be the vehicle to
>> specify non-standard digest or MGF algorithms. It should also be made clear that
>> it shall be a base64 encoding of the RSAES-OAEP-params ASN.1 type defined in
>> PKCS #1 v2.1.
>> If both the DigestMethod attribute and the OAEPparams element are present,
>> then for the digest algorithm used, the DigestMethod attribute should take
>> precedence (if there's a mismatch). The latter would be the price to pay for
>> backwards-compatibility although I wonder what existing code does with the
>> OAEPparams element since it really is underspecified as it stands (what is an
>> "encoding octet string"?).
>> 
>> -- Magnus
>> 
>> 
>>> -----Original Message-----
>>> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
>>> Sent: Monday, October 03, 2011 3:09 PM
>>> To: cantor.2@osu.edu
>>> Cc: Frederick.Hirsch@nokia.com; Magnus Nystrom; public-xmlsec@w3.org
>>> Subject: Re: ACTION-829: Provide additional proposal text regarding
>>> xml encryption changes for pkcs1.5
>>> 
>>> Thanks Scott, comments inline.
>>> regards, Frederick
>>> 
>>> Frederick Hirsch
>>> Nokia
>>> 
>>> 
>>> 
>>> On Oct 3, 2011, at 5:56 PM, ext Cantor, Scott wrote:
>>> 
>>>> On 10/3/11 2:23 PM, "Frederick.Hirsch@nokia.com"
>>>> <Frederick.Hirsch@nokia.com> wrote:
>>>>> 
>>>>> 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.
>>>> 
>>>> I think that's accurate, but I think that the in actual
>>>> implementation, the OAEPParams string doesn't actually get used to
>>>> drive hash algorithm selection, since the spec is telling you that
>>>> DigestMethod is what you use for that.
>>>> 
>>>> In practice, implementations I've tested against often do not
>>>> support anything but SHA1.
>>> 
>>> 
>>> An alternative is to (1) add XML to enable definition of MGF function
>>> and (2) add language to spec indicating that it is implementation
>>> dependent if both XML and OAEPParams are defined and disagree, (3)
>>> remove language that only allows SHA1, making it the default but
>>> allowing change of both hash and MGF
>>> 
>>>> 
>>>>> 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?
>>>> 
>>>> It wouldn't work in my implementation right this moment, which is
>>>> looking for DigestMethod. I'm assuming you're asking "would this
>>>> break
>>>> 1.0 implementations and constitute a change in 1.1".
>>> 
>>> Yes, I was looking for implementor feedback, so this is helpful
>>> 
>>>> 
>>>> -- Scott
>>>> 
>>> 
>> 
>> 
> 
Received on Tuesday, 4 October 2011 18:11:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 October 2011 18:11:55 GMT