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 21:15:46 +0000
To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
Cc: xml-encryption@w3.org
Message-Id: <20020306211546.17CB643BE1@yog-sothoth.ie.baltimore.com>

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 GMT

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