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

Re: FW: Re: rsa/oaep

From: Tom Gindin <tgindin@us.ibm.com>
Date: Thu, 18 Apr 2002 07:45:42 -0400
To: "jiandong guo" <jguo@phaos.com>
Cc: <xml-encryption@w3.org>, <reagle@w3c.org>
Message-ID: <OF4581A52B.3E7811CF-ON85256B9F.003FD9DA@pok.ibm.com>

      I'm not an expert on XML syntax, but I don't think that requiring
that the MGF function be SHA-1 (as opposed to defaulting it) is reasonable.
The primary reason for this is that at some time in the next few years
SHA-256 (along with SHA-384 and SHA-512) will be standardized, and a few
years after that one of those will become widely used.  Eventually it will
be more common than SHA-1 because of its larger range size.  RIPEMD-160 is
a less important case.
      By comparison, requiring that the MGF function match the hash
function is far more reasonable.  It isn't necessary, but it seems to be
the most common practice.

            Tom Gindin

"jiandong guo" <jguo@phaos.com> on 04/18/2002 01:40:00 AM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    <xml-encryption@w3.org>, <reagle@w3c.org>
Subject:    Re: FW: Re: rsa/oaep

>       Looking at the way this is currently done, it would be more
> consistent to create a second optional element ("ds:MGFDigest") under
> RSA-OAEP with the note in the specification that if this method is
> it is considered as equal to ds:DigestMethod, and that if ds:DigestMethod
> is omitted it is considered as equal to "SHA-1".  Alternatively, we could
> put maxOccurs of ds:DigestMethod as 2, with the interpretation (explicit
> the spec) that if both are present the first is the hash algorithm and
> second the MGF, if one is present it's used for both, and if neither is
> present both are set to "SHA-1".  I can see no reason why ds:DigestMethod
> should not have a "maxOccurs" value.

It is conceptually wrong to put the ds:MGFDigest (or we should use
ds:MGF1Digest) in the same level with ds:DigestMehtod and OAEPParameters.
If we want  flexibility of the hash
function in MGF1, I think we should have a MaskGenerationFunction element
which has its own
URI attribute identifying the algorithm and parameters (in the case of
a hash function).
Only in this way we can be consistant with the RSA-OAEP ASN.1 syntax  as
specified in PKCS1 2.0.
But I guess this not what they originally desired. In this case I think the
best we can do is to fix the
Mask Generation Function.

Received on Thursday, 18 April 2002 07:47:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:03 UTC