- From: <Frederick.Hirsch@nokia.com>
- Date: Mon, 3 Oct 2011 22:08:35 +0000
- To: <cantor.2@osu.edu>
- CC: <Frederick.Hirsch@nokia.com>, <mnystrom@microsoft.com>, <public-xmlsec@w3.org>
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 Monday, 3 October 2011 22:09:19 UTC