ietf-smime
[Top] [All Lists]

Re: Proposed Section 12 for CMS draft

1998-07-14 10:03:15
Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org> writes:
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.
I believe this is wrong. Here's the relevant section from the
latest copy of the OIW OIDs that I have:
          7.1.6   SHA1

          This algorithm  is the NIST  Secure Hash  Algorithm [??].   It is
          based on  concepts  similar to  those used  in MD4  and MD5,  and
          outputs a 160-bit digest.

               sha1 ALGORITHM 
               PARAMETER NULL
               ::= {algorithm 26}

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.
I believe that that's wrong. Here's the relevant section from pkcs-1:
md2 OBJECT IDENTIFIER ::=
  { iso(1) member-body(2) US(840) rsadsi(113549)
      digestAlgorithm(2) 2 }
md4 OBJECT IDENTIFIER ::=
  { iso(1) member-body(2) US(840) rsadsi(113549)
      digestAlgorithm(2) 4 }
md5 OBJECT IDENTIFIER ::=
  { iso(1) member-body(2) US(840) rsadsi(113549)
      digestAlgorithm(2) 5 }

          For these object identifiers, the parameters field
          of the digestAlgorithm value should be NULL.


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
This doesn't seem right.
                              ^^^^^^^^^^^^^^^^^^^^^^

identifier for DSA is:

    id-dsa OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) x9-57(10040)
        x9cm(4) 1}
This is the wrong OID. It should be dsa-with-sha-1, no?


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.
id-dsa-with-sha-1 takes NULL parameters.

p,q,g, should be specified with the user's key, which will
have the OID id-dsa in the certificate.

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.
Again, they're wrong. PKCS-1 says:
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }

The rsaEncryption object identifier is intended to be used
in the algorithm field of a value of type
AlgorithmIdentifier. The parameters field of that type,
which has the algorithm-specific syntax ANY DEFINED BY
algorithm, would have ASN.1 type NULL for this algorithm.

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
Here's where the reference to my draft should go.

identifier for static Diffie-Hellman is

    id-smime-cms-x942-with-desCBC ::= { TBD }
This shouldn't be desCBC, since desCBC isn't being used. It's more like
id-smime-cms-x942-with-des3Wrap

I agree with Jim's previous comments. You should be able to
wrap DES in DES, RC2 in RC2, etc. These should be specified
in THIS document.

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.
We should choose NULL or omitted.

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.
See previous comments about PKCS-1.

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.
We need to come down on how long the RC2 keylength is. Stephen
Henson claims that it's commonly set to be the same as the 
effective length, but my experience is that it's set to a fixed
64 bits. Blake?

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
                "Put it in the top slot."

<Prev in Thread] Current Thread [Next in Thread>