- From: Magnus Nystrom <mnystrom@microsoft.com>
- Date: Tue, 4 Oct 2011 17:57:18 +0000
- To: Pratik Datta <pratik.datta@oracle.com>, "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>
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 17:57:51 UTC