- From: merlin <merlin@baltimore.ie>
- Date: Wed, 06 Mar 2002 21:15:46 +0000
- To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
- Cc: xml-encryption@w3.org
Hi, This looks good, although would it be too much to ask for it to be called #rsa-oaep-mgf1-sha1? The hyphen seems more in line with the rest of our algorithm URIs, and I really don't think that we need to specify anything about P here; it seems redundant, possibly confusing. I'd also like the digest method to be optional, defaulting to SHA-1; it would let the (common) default use of this algorithm to be encoded as concisely as our other algorithms. Merlin r/Donald.Eastlake@motorola.com/2002.03.06/15:34:54 >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 > > >--8<-- >***** 5. Algorithms ***** >This section discusses algorithms used with the XML Encryption specification. >Entries contain the identifier to be used as the value of the Algorithm >attribute of the EncryptionMethod element or other element representing the >role of the algorithm, a reference to the formal specification, definitions fo >r >the representation of keys and the results of cryptographic operations where >applicable, and general applicability comments. >**** 5.1 Algorithm Identifiers and Implementation Requirements **** >All algorithms listed below have implicit parameters depending on their role. >For example, the data to be encrypted or decrypted, keying material, and >direction of operation (encrypting or decrypting) for encryption algorithms. >Any explicit additional parameters to an algorithm appear as content elements >within the element. Such parameter child elements have descriptive element >names, which are frequently algorithm specific, and SHOULD be in the same >namespace as this XML Encryption specification, the XML Signature >specification, or in an algorithm specific namespace. An example of such an >explicit parameter could be a nonce (unique quantity) provided to a key >agreement algorithm. >This specification defines a set of algorithms, their URIs, and requirements >for implementation. Levels of requirement specified, such as "REQUIRED" or >"OPTIONAL", refere to implementation, not use. Furthermore, the mechanism is >extensible, and alternative algorithms may be used. >*** Table of Algorithms *** >The table below lists the categories of algorithms. Within each category, a >brief name, the level of implementation requirement, and an identifying URI ar >e >given for each algorithm. > Block Encryption > 1. REQUIRED TRIPLEDES > > http://www.w3.org/2001/04/xmlenc#tripledes-cbc > 2. REQUIRED AES-128 > > http://www.w3.org/2001/04/xmlenc#aes128-cbc > 3. REQUIRED AES-256 > > http://www.w3.org/2001/04/xmlenc#aes256-cbc > 4. OPTIONAL AES-192 > > http://www.w3.org/2001/04/xmlenc#aes192-cbc > Stream Encryption > 1. none> Syntax and recommendations are given below to support user > specified algorithms. > Key Transport > 1. REQUIRED RSA-v1.5 > > http://www.w3.org/2001/04/xmlenc#rsa-1_5 > 2. REQUIRED RSA-OAEP > > http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1sha1p > Key Agreement > 1. OPTIONAL Diffie-Hellman > > http://www.w3.org/2001/04/xmlenc#dh > Symmetric Key Wrap > 1. REQUIRED TRIPLEDES KeyWrap > > http://www.w3.org/2001/04/xmlenc#kw-tripledes > 2. REQUIRED AES-128 KeyWrap > > http://www.w3.org/2001/04/xmlenc#kw-aes128 > 3. REQUIRED AES-256 KeyWrap > > http://www.w3.org/2001/04/xmlenc#kw-aes256 > 4. OPTIONAL AES-192 KeyWrap > > http://www.w3.org/2001/04/xmlenc#kw-aes192 > Message Digest > 1. REQUIRED SHA1 > > http://www.w3.org/2000/09/xmldsig#sha1 > 2. RECOMMENDED SHA256 > > http://www.w3.org/2001/04/xmlenc#sha256 > 3. OPTIONAL SHA512 > > http://www.w3.org/2001/04/xmlenc#sha512 > 4. OPTIONAL RIPEMD-160 > > http://www.w3.org/2001/04/xmlenc#ripemd160 > Message Authentication > 1. RECOMMENDED XML Digital Signature > > http://www.w3.org/TR/2001/CR-xmldsig-core-20010419/ > Canonicalization > 1. OPTIONAL Canonical XML (omits comments) > > http://www.w3.org/TR/2001/REC-xml-c14n-20010315 > 2. OPTIONAL Canonical XML with Comments > > http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments > 3. OPTIONAL Exclusive XML Canonicalization (omits comments) > > http://www.w3.org/2001/10/xml-exc-c14n# > 4. OPTIONAL Exclusive XML Canonicalization with Comments > > http://www.w3.org/2001/10/xml-exc-c14n#WithComments > Encoding > 1. REQUIRED base64 > > http://www.w3.org/2000/09/xmldsig#base64 >*** 5.4.2 RSA-OAEP *** > Identifier: > http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1sha1p (REQUIRED) >The RSAES-OAEP-ENCRYPT, as specified in RFC 2437 [PKCS1], algorithm takes two >explicit parameters: a message digest function and an optional octet string >OAEPparams. The message digest function is indicated by the Algorithm attribut >e >of a child ds:DigestMethod element and and is used in the EME-OAEP-ENCODE >operation performed as part of RSAES-OAEP-ENCRYPT. The octet string is the >base64 decoding of the content of an optional OAEPparams child element and is >used, along with SHA1, in the mask generation function performed as part of >EME-OAEP-ENCODE. >Schema Definition: > ><element ref='ds:DigestMethod' minOccurs='0'/> ><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-mgf1sha1p"> > <ds:DigestMethod > Algorithm="http://www.w3.org/2000/09/xmldsig#sha256"/> > <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 (with SHA1) >specified in RFC 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.
Received on Wednesday, 6 March 2002 16:15:50 UTC