Subject: Proposed updates to CMS

From: Russ Housley <[email-masked]>
Date: Wed, 05 Apr 2006 17:15:36 -0400

Here are the proposed changes to CMS in support of hash function migration.

Please review and comment.

Russ

= = = = = = = = =

Updates to Section 5: Signed-data Content Type

    Replace the next to the last paragraph in section 5 as follows.

    OLD:

|  A recipient independently computes the message digest.  This message
|  digest and the signer's public key are used to verify the signature
|  value.  The signer's public key is referenced either by an issuer
|  distinguished name along with an issuer-specific serial number or by
|  a subject key identifier that uniquely identifies the certificate
|  containing the public key.  The signer's certificate can be included
|  in the SignedData certificates field.

    NEW:

|  A recipient independently computes the message digest.  This message
|  digest and the signer's public key are used to verify the signature
|  value.  The signer's public key is referenced either by an issuer
|  distinguished name along with an issuer-specific serial number or by
|  a subject key identifier that uniquely identifies the certificate
|  containing the public key.  The signer's certificate can be included
|  in the SignedData certificates field.
|
|  When more than one signature is present, the successful validation
|  of any one of these signatures ought to be treated as a successful
|  validation of the signed-data content type.  The primary reason
|  is that signers may include seperate signatures for different
|  communities of recipients.  For example, the signed-data content
|  type might include signatures generated with the RSA signature
|  algorithm and with the ECDSA signature algorithm.  This allows
|  recipients able to verify one algorithm or the other.

Updates to Section 5.1: SignedData Type

    Replace the next to the last paragraph in section 5.1 as follows.

    OLD:

|     signerInfos is a collection of per-signer information.  There MAY
|     be any number of elements in the collection, including zero.  The
|     details of the SignerInfo type are discussed in section 5.3.
|     Since each signer can employ a digital signature technique and
|     future specifications could update the syntax, all implementations
|     MUST gracefully handle unimplemented versions of SignerInfo.
|     Further, since all implementations will not support every possible
|     signature algorithm, all implementations MUST gracefully handle
|     unimplemented signature algorithms when they are encountered.

    NEW:

|     signerInfos is a collection of per-signer information.  There MAY
|     be any number of elements in the collection, including zero.  When
|     the collection represents more than one signature, the successful
|     validation of any one of these collection members ought to be
|     treated as a successful validation of the signed-data content
|     type.  The details of the SignerInfo type are discussed in
|     section 5.3.  Since each signer can employ a digital signature
|     technique and future specifications could update the syntax, all
|     implementations MUST gracefully handle unimplemented versions of
|     SignerInfo.  Further, since all implementations will not support
|     every possible signature algorithm, all implementations MUST
|     gracefully handle unimplemented signature algorithms when they
|     are encountered.