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

RE: FW: Re: rsa/oaep

From: Tom Gindin <tgindin@us.ibm.com>
Date: Thu, 7 Mar 2002 07:50:37 -0500
To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
Cc: "'merlin'" <merlin@baltimore.ie>, xml-encryption@w3.org
Message-ID: <OFDA8263BC.89275525-ON85256B75.00466680@pok.ibm.com>

      This may be a naive question, but why aren't parameters included at
the end of a URI using the standard "?" convention with keyword-value pairs
following the question mark?

            Tom Gindin


Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>@w3.org on
03/06/2002 03:34:54 PM

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


To:    "'merlin'" <merlin@baltimore.ie>
cc:    xml-encryption@w3.org, Eastlake III Donald-LDE008
       <Donald.Eastlake@motorola.com>
Subject:    RE: FW: Re: rsa/oaep



There was some argument during the initial specification of this how
orthogonal the different algorithms needed to be. XMLDSIG generally
combined
everything into the URI. Some advocated splitting everything out into
algorithmic parameters. Looking back at the record, I believe the decision
at the time was to fix the mask generation function, presumably including
its digest method, into the URI but permit specifying an encode digest
function...  (Actually, if you look at the original, the parameters P were
produced are the output of a algorithm which could be specified but
defaulted to an algorithm that just used a supplied constant.) Attached is
another try at the text :-)

I don't remember exactly why the "p" is there but I think it alludes to the
optional OAEP encoding parameters which are represented by P in RFC 2437.

See http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0016.html

Thanks,
Donald

-----Original Message-----
From: merlin [mailto:merlin@baltimore.ie]
Sent: Wednesday, March 06, 2002 12:02 PM
To: Eastlake III Donald-LDE008
Cc: xml-encryption@w3.org
Subject: Re: FW: Re: rsa/oaep

Hi Donald,

This still doesn't address the fact that EME-OAEP-ENCODE and MGF1
each use a message digest algorithm. RFC 2437 specifies these message
digest algorithm independently. Are we collapsing them into one? If
RFC 2437 specifies them independently, I'm not sure why we would choose
to do things differently. I'd also question making the digest method
mandatory. If the default in RFC 2437 is SHA-1, then would that not be
a sensible default for us, too?

Also, it doesn't address where the "p" of "mgf1p" comes from?

If we wanted to be completely general, I'd encode things as follows:

<EncryptionMethod Algorithm="&enc;rsa-oaep">
  <DigestMethod Algorithm="..." /> <!-- optional, default SHA-1 -->
  <OAEPMaskGenerator Algorithm="..."> <!-- optional, default MGF1/SHA-1 -->
    <DigestMethod Algorithm="..." />
  </OAEPMaskGenerator>
  <OAEPParams /> <!-- optional, default empty octet string -->
</EncryptionMethod>

This would mirror RFC 2437, which is what we are referencing.

An alternative, closer to what we have would be:

<EncryptionMethod Algorithm="&enc;rsa-oaep-sha1-mgf1-sha1">
  <OAEPParams /> <!-- optional, default empty octet string -->
</EncryptionMethod>

Our present encoding takes some of the parameters (the mask generator)
and places them in the URI, leaves some as parameters and merges some,
which I think complicates matters.

Merlin

r/Donald.Eastlake@motorola.com/2002.03.06/11:37:28
>My intent was to use the hash function from the DigestMethod element.
>Seems to me the way to clarify this is to make it mandatory. See
>attached suggested change.
>
>Thanks,
>Donald
>
>Subject: Re: rsa/oaep
>Date: Mon, 04 Mar 2002 11:20:12 -0500
>From: Jiandong Guo <jguo@phaos.com>
>To: Takeshi Imamura <IMAMU@jp.ibm.com>
>Cc: merlin <merlin@baltimore.ie>, xml-encryption@w3.org
>
>Takeshi Imamura wrote:
>> I interpret "mgf1p" as MGF1 with the hash function specified by the
>> DigestMethod element.
>
>This is not that obvious from the context of the document. My first
> impression is that the default (MGF1
>with SHA1) would be used. Should we make this more clear in case it will
> cause confusion when we
>interop with each other?
>
>Jiandong Guo
>Phaos Technology
>
>
>--8<--
>*** 5.4.2 RSA-OAEP ***
>  Identifier:
>      http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p (REQUIRED)
>THE RSAES-OAEP-ENCRYPT, as specified in RFC 2437 [PKCS1], algorithm takes
two
>explicit parameters: a mandatory message digest function and an optional
octet
>string OAEPparams. The message digest function is indicated by the
Algorithm
>attribute of a child ds:DigestMethod element and the octet string is the
base6
>4
>decoding of the content of an optional OAEPparams child element.
>Schema Definition:
>
><element ref='ds:DigestMethod'/>
><element name='OAEPparams' minOccurs='0'
>         type='base64Binary'/>
>An example of an RSA-OAEP element is:
>  <EncryptionMethod
>     Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
>     <ds:DigestMethod
>        Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>     <OAEPparams> 9lWu3Q== </OAEPparams>
>  <EncryptionMethod>
>The CipherValue for an RSA-OAEP encrypted key is the base64 [MIME]
encoding
of
>the octet string computed as per RFC 2437 [PKCS1, section 7.1.1:
Encryption
>operation]. As described in the EME-OAEP-ENCODE function RFC 2437 [PKCS1,
>section 9.1.1.1], the value input to the key transport function is
calculated
>using the message digest function and string specified in the DigestMethod
and
>OAEPparams elements and using the mask generator function MGF1 specified
in
RF
>C
>2437. The desired output length for EME-OAEP-ENCODE is one byte shorter
than
>the RSA modulus.
>The transported key size is 192 bits for TRIPLEDES and 128, 192, or 256
bits
>for AES. Implementations MUST implement RSA-OAEP for the transport of 128
and
>256 bit keys. They MAY implement RSA-OAEP for the transport of other keys.


----------------------------------------------------------------------------

-
Baltimore Technologies plc will not be liable for direct,  special,
indirect
or consequential  damages  arising  from  alteration of  the contents of
this
message by a third party or as a result of any virus being passed on.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com
Received on Thursday, 7 March 2002 07:51:24 GMT

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