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.