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 02:48:34 UTC