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

Re: FW: Re: rsa/oaep

From: merlin <merlin@baltimore.ie>
Date: Wed, 06 Mar 2002 17:01:45 +0000
To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
Cc: "'xml-encryption@w3.org'" <xml-encryption@w3.org>
Message-Id: <20020306170145.ADC2143BE1@yog-sothoth.ie.baltimore.com>

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="..." />
  <OAEPParams /> <!-- optional, default empty octet string -->

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 -->

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.


>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.
>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
>*** 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
>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], 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
>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.
Received on Wednesday, 6 March 2002 12:01:49 UTC

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