W3C home > Mailing lists > Public > xml-encryption@w3.org > April 2002

Re: FW: Re: rsa/oaep

From: Tom Gindin <tgindin@us.ibm.com>
Date: Fri, 26 Apr 2002 07:42:29 -0400
To: reagle@w3.org
Cc: Donald Eastlake 3rd <dee3@torque.pothole.com>, xml-encryption@w3.org
Message-ID: <OF35A3165C.58675C70-ON85256BA7.003EFD6C@pok.ibm.com>

      Joseph:

      I wish to document my view that treating the default MGF as
MGF1(SHA-1) rather than MGF1(DigestMethod) is a mistake, although I appear
to have been outvoted.  The currently posted draft does not make clear
which interpretation is to be used ("using the mask generator function MGF1
specified in RFC 2437"), and the apparent reason for the defaulting in
PKCS#1 is that it is easiest to default values to a literal constant in
ASN.1.  There is no syntax defined in the draft by which the MGF1's digest
method can be specified, unlike in PKCS#1.  While Don is correct that there
are no reasons why the DigestMethod and the MGF1's digest method must
match, the reasons for increasing the range size of one apply almost
equally strongly to the other, and increases in the range size of a digest
method are IMO the principal reason for the use of an algorithm other than
SHA-1 in this context.
      Current implementations which use SHA-1 for both the DigestMethod and
the MGF's digest method would be unaffected by either interpretation.
Nobody has stated AFAIK that they have implemented anything other than
SHA-1 for either digest method.

            Tom Gindin



Joseph Reagle <reagle@w3.org>@w3.org on 04/25/2002 04:16:26 PM

Please respond to reagle@w3.org

Sent by:    xml-encryption-request@w3.org


To:    Donald Eastlake 3rd <dee3@torque.pothole.com>, xml-encryption@w3.org
cc:
Subject:    Re: FW: Re: rsa/oaep


On Thursday 25 April 2002 00:40, Donald Eastlake 3rd wrote:
> Seems to me that we should stick with the current implemented URI for
> the currently implemented algorithm with the current parameters.

This sounds like the best bet to me. What we have does work, and it might
not be the best format for future parameters but that bridge can be crossed

when encountered. (A new identifier/namespace and all the parameters
desired can be proposed.) So I'm going to stick with the text I have now in

[1] and consider the issue closed unless someone wants to document their
dissent.

[1]
http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview.html#sec-RSA-OAEP

 $Revision: 1.184 $ on $Date: 2002/04/17 13:17:07 $ GMT
Received on Friday, 26 April 2002 07:43:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:21 GMT