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: Magnus Nystrom <mnystrom@microsoft.com>
Date: Tue, 4 Oct 2011 02:48:06 +0000
To: "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>, "cantor.2@osu.edu" <cantor.2@osu.edu>
CC: "public-xmlsec@w3.org" <public-xmlsec@w3.org>
Message-ID: <D744D68428430B4F9C81DE8A4D5950681217D028@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
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 02:48:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 October 2011 02:48:35 GMT