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

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