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

So we could have originally picked a more meaningful name like "label"?

regards, Frederick

Frederick Hirsch
Nokia



On Oct 4, 2011, at 2:40 PM, ext Pratik Datta wrote:

> We can't remove the OAEPparams element because we use it. It corresponds to the "EncodingParameters" element as defined in PKCS 2.1 , also called "label L"  (see page 42 of ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf ) .  The value of Label L can be specified, or it can be an empty string. <OAEPparams> is the mechanism to specify this value.
> 
> 
> Pratik
> 
> -----Original Message-----
> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
> Sent: Tuesday, October 04, 2011 11:11 AM
> To: mnystrom@microsoft.com
> Cc: Frederick.Hirsch@nokia.com; Pratik Datta; cantor.2@osu.edu; public-xmlsec@w3.org
> Subject: 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:51:34 UTC