RE: Proposed Section 12 for CMS draft

Next think you know Blake will want to take a vacation.

Comments:

1.  Section 12.2.1 - The DSA section is referering to our D-H draft.  I
expect it should be refering to a FIPS standard.

2.  Section 12.2.1 - Should include a statement to the effect that if the
parameters are omitted they are inherited from the signing certificate. (I
may be wrong on this statement.)

3.  Section 12.3 - Must include our varient of D-H --- see our D-H draft.
Don't reference X9.42 Static D-H.

4.  Section 12.3.1 - I don't like the inclusion of des in this OID.  I need
to be able to operation in a completely exportable manner and I want the RFC
to support this in an OPTIONAL mode.  Additionally this should refer(?) to
our D-H draft rathern than X9.42.

5.  Section 12.4 -- I though that I had talked Russ into providing something
which contained other than 3-DES key wrapping as an optional.

6.  Section 12.3.1 and section 12.4 -- It does not make sense that the Key
Agreement OID uses the word des, but the wrapping is actually done with
3-DES.

7.  Section 12.4 -- Need a statement on step 5 if the pad octects are
constant or random.  I assume that they are random bits.

8.  Section 12.4 -- Step 6.  "Encrypt the result with the Triple-DES keys.
..."

9.  Section 12.4 -- Unwrap - Step #2 does not make sense.  Suggest "Check
the parity of the resulting content encryption key.  If any is incorrect
then there is an error."  The encryption key may be RC2-40 and therefore not
have parity bits.

10.  Section 12.5.1 and Section 12.5.2 -- "CBCParameter ::= IV" -- missing
'='

11.  Section 12.6.2 - HMAC-SHA1 does not contain a paragraph describing the
parameters.  I don't remember there being any paraemters.


> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:phoffman(_at_)imc(_dot_)org]
> Sent: Monday, July 13, 1998 8:08 PM
> To: ietf-smime(_at_)imc(_dot_)org
> Subject: Proposed Section 12 for CMS draft
>
>
> Greetings again. Russ decided that summer was for vacations, 
> so he's gone 
> this week. Because we want to get everything ready for last call ASAP 
> (modulo stupid patent issues), he asked Blake and I to try to 
> clean up the 
> last big empty part of the CMS draft, which is section 12. 
> Below is my 
> suggested cut at it. Please read it over carefully and 
> comment, since there 
> are likely to be things that are wrong with it. If we can do 
> significant 
> bashing this week, Russ said he'd rev the draft as soon as he is back.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>
> 12  Supported Algorithms
>
> This section lists the algorithms that must be implemented.
> Additional algorithms that may be implemented are also included.
>
> 12.1  Digest Algorithms
>
> CMS implementations must include SHA-1. CMS implementations 
> may include MD5.
>
> Digest algorithm identifiers are used in the SignedData 
> digestAlgorithms
> field, the SignerInfo digestAlgorithm field, and the DigestedData
> digestAlgorithm field.
>
> Digest values are located in the DigestedData digest field. 
> In addition,
> digest values are located in the Message Digest authenticated 
> attribute.
>
> 12.1.1  SHA-1
>
> The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [FIPS 
> 180-1]. The
> algorithm identifier for SHA-1 is:
>
>     sha-1 OBJECT IDENTIFIER ::= {iso(1) 
> identified-organization(3) oiw(14)
>         secsig(3) algorithm(2) 26}
>
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate SHA-1 AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept SHA-1 AlgorithmIdentifiers with NULL
> parameters as well as absent parameters.  Note that current CMS
> implementations encode SHA-1 both with and without the NULL 
> attributes.
>
> 12.1.2  MD5
>
> The MD5 digest algorithm is defined in RFC 1321. The algorithm
> identifier for MD5 is:
>
>     md5 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) digestAlgorithm(2) 5}
>
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate MD5 AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept MD5 AlgorithmIdentifiers with 
> NULL parameters
> as well as absent parameters. Note that current CMS 
> implementations encode
> MD5 both with and without the NULL attributes.
>
> 12.2  Signature Algorithms
>
> CMS implementations must include DSA.  CMS implementations 
> may include RSA.
>
> Signature algorithm identifiers are used in the SignerInfo
> signatureAlgorithm field.
>
> 12.2.1  DSA
>
> The DSA signature algorithm is defined in RFC TBD (Diffie-Hellman Key
> Agreement Method, currently draft-ietf-smime-x942). The algorithm
> identifier for DSA is:
>
>     id-dsa OBJECT IDENTIFIER ::= {iso(1) member-body(2) 
> us(840) x9-57(10040)
>         x9cm(4) 1}
>
> The id-dsa algorithm syntax includes an optional sequence of 
> parameters.
> These parameters are commonly referred to as p, q, and g. If the DSA
> algorithm parameters are present, they are included using the 
> following
> ASN.1 structure:
>
>     Dss-Parms  ::=  SEQUENCE  {
>       p             INTEGER,
>       q             INTEGER,
>       g             INTEGER  }
>
> If the parameters are omitted, the parameters component must 
> be omitted
> entirely, so the AlgorithmIdentifier in this case is a 
> SEQUENCE of only one
> component, the OBJECT IDENTIFIER id-dsa.
>
> 12.2.2  RSA
>
> The RSA signature algorithm is defined in RFC 2313. The algorithm
> identifier for RSA is:
>
>     rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) pkcs(1) pkcs-1(1) 1}
>
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate RSA AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept RSA AlgorithmIdentifiers with 
> NULL parameters
> as well as absent parameters.  Note that current CMS 
> implementations encode
> RSA both with and without the NULL attributes.
>
> 12.3  Key Encryption Algorithms
>
> CMS implementations must include X9.42 Static Diffie-Hellman.  CMS
> implementations may include RSA.
>
> Key encryption algorithms are used in the KeyTransRecipientInfo
> keyEncryptionAlgorithm field, in the KeyAgreeRecipientInfo
> keyEncryptionAlgorithm field, and in the MailListRecipientInfo
> keyEncryptionAlgorithm field. These are all part of the RecipientInfo
> type, which is part of the EnvelopedData type.
>
> 12.3.1  X9.42 Static Diffie-Hellman with desCBC
>
> Diffie-Hellman key encryption is defined in X9.42 [X9.42]. 
> The algorithm
> identifier for static Diffie-Hellman is
>
>     id-smime-cms-x942-with-desCBC ::= { TBD }
>
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations 
> should accept
> static Diffie-Hellman AlgorithmIdentifiers with NULL 
> parameters as well as
> absent parameters. Implementations should generate static 
> Diffie-Hellman
> AlgorithmIdentifiers with the parameter field absent.
>
> 12.3.2  RSA
>
> The RSA encryption algorithm is defined in RFC 2313 [RFC 2313]. The
> algorithm identifier for RSA is:
>
>     rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) pkcs(1) pkcs-1(1) 1}
>
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate RSA AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept RSA AlgorithmIdentifiers with 
> NULL parameters
> as well as absent parameters.  Note that current CMS 
> implementations encode
> RSA both with and without the NULL attributes.
>
> 12.4  Triple-DES Key Wrap
>
> The block size of the key-encryption algorithm can be 
> determined from the CMS
> KeyEncryptionAlgorithmIdentifier protocol field.  Likewise, 
> the size of the
> content-encryption key can be determined from the CMS
> ContentEncryptionAlgorithmIdentifier protocol field.  
> Triple-DES may be an
> exception here; the same identifier is used for both 2-key 
> and 3-key Triple
> DES.  This is probably easily handled by always wrapping 
> three keys, even if
> the first and third keys match.
>
> The key checksum algorithm is:
>
> 1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
> 2.  Loop through the octets of the content-encryption key, most
>     significant octet to least significant octet.
>     2a.  Create a 16 bit integer, called temp, by concatenating 
>          8 zero bits and the key octet.
>     2b.  sum1 = sum1 + temp.
>     2c.  sum2 = sum2 + sum1.
> 3.  Use sum2 as the checksum value.
>
> The key wrap algorithm is:
>
> 1.  Adjust the parity bits on the Triple-DES keys.
> 2.  Compute a 16-bit key checksum value on the content-encryption
>     key as described above.
> 3.  Generate a 4-octet random salt value.
> 4.  Concatenate the salt, content-encryption key, and key 
>     checksum value.
> 5.  Generate the number of pad octets necessary to make the
>     result a multiple of 8 bytes (the Triple-DES algorithm block
>     size), then append them to the result.
> 6.  Encrypt the result with the key-encryption key.  Use an IV
>     with each octet equal to 'A5' hexadecimal.
>
> The key unwrap algorithm is:
>
> 1.  Decrypt the wrapped ciphertext using the key-encryption key.
>     Use an IV with each octet equal to 'A5' hexadecimal.
> 2.  Check the parity of the Triple-DES keys.  If any is 
>     incorrect then there is an error.
> 3.  Compute a 16-bit key checksum value on the content-encryption
>     key as described above.
> 4.  If computed key checksum value does not match the decrypted
>     key checksum value, then there is an error.
>
> 12.5  Content Encryption Algorithms
>
> CMS implementations must include Triple-DES in CBC mode.  CMS
> implementations may include DES in CBC mode and RC2 in CBC mode.
>
> Content encryption algorithms appear in the EncryptedContentInfo
> contentEncryptionAlgorithm field, which is part of the 
> EnvelopedData type
> and the EncryptedData type.
>
> 12.5.1  Triple-DES CBC
>
> The Triple-DES algorithm is described in [3DES]. The 
> algorithm identifier
> for Triple-DES is:
>
>     DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 
>         rsadsi(113549) encryptionAlgorithm(3) 7}
>
> The AlgorithmIdentifier parameter field is required and has 
> the structure:
>
>     CBCParameter :: IV
>     IV ::= OCTET STRING -- 8 octets.
>
> 12.5.2  DES CBC
>
> The DES algorithm in CBC mode is described in [DES]. The algorithm
> identifier for DES in CBC mode is:
>
>     DES-CBC OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
>         oiw(14) secsig(3) algorithm(2) 7}
>
> The AlgorithmIdentifier parameter field is required and has 
> the structure:
>
>     CBCParameter :: IV
>     IV ::= OCTET STRING -- 8 octets.
>
> 12.5.3  RC2 CBC
>
> The RC2 algorithm is described in RFC 2268. The algorithm 
> identifier for
> RC2 in CBC mode is:
>
>     RC2-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) encryptionAlgorithm(3) 2}
>
> For the effective-key-bits (key size) greater than 32 and less than
> 256, the RC2-CBC algorithm parameters are encoded as:
>
>     RC2-CBC parameter ::=  SEQUENCE {
>         rc2ParameterVersion  INTEGER,
>         iv                   OCTET STRING (8)}
>
> For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
> values are 160, 120, 58 respectively. It is very important to 
> note that
> these values are not simply the RC2 keylength. Also note that 
> the value 160
> must be encoded as two octets (00 A0), because encoding as 
> one octet (A0)
> is a negative number in ASN.1.
>
> 12.6  Message Authentication Code Algorithms
>
> No MAC algorithms are mandatory.  CMS implementations may include DES
> MAC and HMAC.
>
> MAC algorithms appear in the AuthenticatedData mac field.
>
> 12.6.1  DES MAC
>
> The DES MAC algorithm is described in FIPS Pub 113 [FIPS-113]. The
> algorithm identifier for DES MAC is:
>
>     DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
>         oiw(14) secsig(3) algorithm(2) 10 }
>
> The AlgorithmIdentifier parameter field is required. It is an 
> INTEGER, and
> carries the length in bits of the MAC, constrained to 
> multiples of eight
> from 16 to 64.
>
> 12.6.2  HMAC-SHA1
>
> The HMAC-SHA1 algorithm is described in RFC 2104. The 
> algorithm identifier for
> HMAC-SHA1 is:
>
>     HMAC-SHA1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
>         dod(6) internet(1) security(5) mechanisms(5) 8 1 2}
>
> {{{References added}}}
>
> 3DES  W. Tuchman. "Hellman Presents No Shortcut Solutions To 
> DES". IEEE
> Spectrum, v. 16, n. 7, pp40-41. July 1979.
>
> DES  American National Standards Institute. ANSI X3.106, 
> "American National
> Standard for Information Systems- Data Link Encryption". 1983.
>
> FIPS 113  National Institute of Standards and Technology. 
> FIPS Pub 113:
> Computer Data Authentication. May 1985.
>
> FIPS 180-1  National Institute of Standards and Technology. 
> FIPS Pub 180-1: 
> Secure Hash Standard.  April 1995.
>
> FIPS 186  National Institute of Standards and Technology. 
> FIPS Pub 186:
> Digital Signature Standard.  May 1994.
>
> RFC 1321  Rivest, R.  The MD5 Message Digest Algorithm.  April 1992.
>
> RFC 2104  Krawczyk, H.  HMAC: Keyed-Hashing for Message 
> Authentication.
> February 1997.
>
> RFC 2268  Rivest, R. A Description of the RC2 (r) Encryption 
> Algorithm.
> March 1998.
>
> X9.42  ANSI X9.42-199x.  Public Key Cryptography for The 
> Financial Services
> Industry: Agreement of Symmetric Algorithm Keys Using Diffie-Hellman
> (Working Draft).  December 1997.