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:42:01 UTC