- From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
- Date: Wed, 6 Mar 2002 15:34:54 -0500
- To: "'merlin'" <merlin@baltimore.ie>
- Cc: xml-encryption@w3.org, Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
- Message-ID: <05F679A54DF3D51188100008C791975607D340@ma07exm03.corp.isg.mot.com>
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
Attachments
- text/html attachment: xmlenc-mgf1sha1p.html
Received on Wednesday, 6 March 2002 15:35:58 UTC