RE: FW: Re: rsa/oaep

I don't have any objection to changing to hyphenated form. But if the
algorithms are going to be explicitly represented in the URI, then the
algorithm provided for in OAEP to calculate the encoding parameters and
which is usually an algorithm which simply uses the constant parameter
provided should be represented. So I've attached it changed to
rsa-oaep-mgf1-sha1-p in the attached.

Donald

-----Original Message-----
From: merlin [mailto:merlin@baltimore.ie]
Sent: Wednesday, March 06, 2002 4:16 PM
To: Eastlake III Donald-LDE008
Cc: xml-encryption@w3.org
Subject: Re: FW: Re: rsa/oaep 



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.