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

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 UTC