Re: FW: Re: rsa/oaep

From:  "Tom Gindin" <tgindin@us.ibm.com>
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>
Date:  Thu, 7 Mar 2002 07:50:37 -0500

>      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

That could be done but would be very messy and subject to length
limitations.  We have contemplated things like a Java transform where
an entire Java program was a parameter. In character based systems, to
assume you can process infinitely long lines without a line break is a
bad assumption and its demonstrably false in the case of
URIs. Furthermore, the parameters would no longer be locatable or
manipulable with XML level operations....

Donald

>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 09:19:35 UTC