draft-ietf-smime-cms-mult-sign-00.txt   draft-ietf-smime-cms-mult-sign-01.txt 
S/MIME Working Group R. Housley (Vigil Security) S/MIME Working Group R. Housley (Vigil Security)
Expires October 2006 Expires January 2007
Cryptographic Message Syntax (CMS) Cryptographic Message Syntax (CMS)
Multiple Signer Clarification Multiple Signer Clarification
<draft-ietf-smime-cms-mult-sign-00.txt> <draft-ietf-smime-cms-mult-sign-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 16 skipping to change at page 3, line 16
| A recipient independently computes the message digest. This message | A recipient independently computes the message digest. This message
| digest and the signer's public key are used to verify the signature | 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 | value. The signer's public key is referenced either by an issuer
| distinguished name along with an issuer-specific serial number or by | distinguished name along with an issuer-specific serial number or by
| a subject key identifier that uniquely identifies the certificate | a subject key identifier that uniquely identifies the certificate
| containing the public key. The signer's certificate can be included | containing the public key. The signer's certificate can be included
| in the SignedData certificates field. | in the SignedData certificates field.
| |
| When more than one signature is present, the successful validation | When more than one signature is present, the successful validation
| of any one of these signatures ought to be treated as a successful | of one of signature associated with each signer is usually treated
| validation of the signed-data content type. The primary reason | as a successful validation of the signed-data content type. However,
| is that signers may include separate signatures for different | there are some application environments where other rules are needed.
| communities of recipients. For example, the signed-data content | An application that employs a rule other than one valid signature for
| type might include signatures generated with the RSA signature | each signer must specify those rules. Also, where simple matching of
| algorithm and with the ECDSA signature algorithm. This allows | the signer identifier is not sufficient to determine whether the
| recipients to verify one algorithm or the other. | signatures were generated by the same signer, then the application
| specification must describe how to determine which signatures were
| generated by the same signer. Support of different communities of
| recipients is the primary reason that signers choose to include more
| than one signature. 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 to
| verify one algorithm or the other.
4. Update to RFC 3852, Section 5.1: SignedData Type 4. Update to RFC 3852, Section 5.1: SignedData Type
RFC 3852, section 5.1, the next to the last paragraph says: RFC 3852, section 5.1, the next to the last paragraph says:
| signerInfos is a collection of per-signer information. There MAY | signerInfos is a collection of per-signer information. There MAY
| be any number of elements in the collection, including zero. The | be any number of elements in the collection, including zero. The
| details of the SignerInfo type are discussed in section 5.3. | details of the SignerInfo type are discussed in section 5.3.
| Since each signer can employ a digital signature technique and | Since each signer can employ a digital signature technique and
| future specifications could update the syntax, all implementations | future specifications could update the syntax, all implementations
| MUST gracefully handle unimplemented versions of SignerInfo. | MUST gracefully handle unimplemented versions of SignerInfo.
| Further, since all implementations will not support every possible | Further, since all implementations will not support every possible
| signature algorithm, all implementations MUST gracefully handle | signature algorithm, all implementations MUST gracefully handle
| unimplemented signature algorithms when they are encountered. | unimplemented signature algorithms when they are encountered.
This block of text is replaced with: This block of text is replaced with:
| signerInfos is a collection of per-signer information. There MAY | signerInfos is a collection of per-signer information. There MAY
| be any number of elements in the collection, including zero. When | be any number of elements in the collection, including zero. When
| the collection represents more than one signature, the successful | the collection represents more than one signature, the successful
| validation of any one of these collection members ought to be | validation of one of signature from each signer ought to be
| treated as a successful validation of the signed-data content | treated as a successful validation of the signed-data content
| type. The details of the SignerInfo type are discussed in | type. However, there are some application environments where
| section 5.3. Since each signer can employ a digital signature
| technique and future specifications could update the syntax, all | other rules are needed. The details of the SignerInfo type are
| implementations MUST gracefully handle unimplemented versions of | discussed in section 5.3. Since each signer can employ a
| SignerInfo. Further, since all implementations will not support | different digital signature technique and future specifications
| every possible signature algorithm, all implementations MUST | could update the syntax, all implementations MUST gracefully
| gracefully handle unimplemented signature algorithms when they | handle unimplemented versions of SignerInfo. Further, since all
| are encountered. | implementations will not support every possible signature
| algorithm, all implementations MUST gracefully handle
| unimplemented signature algorithms when they are encountered.
6. Security Considerations 6. Security Considerations
The replacement text will reduce the likelihood of interoperability The replacement text will reduce the likelihood of interoperability
errors during the transition from MD5 and SHA-1 to stronger one-way errors during the transition from MD5 and SHA-1 to stronger one-way
hash functions. hash functions, or to better signature algorithms.
7. Normative References 7. Normative References
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", [CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004. RFC 3852, July 2004.
[STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8. IANA Considerations 8. IANA Considerations
 End of changes. 6 change blocks. 
19 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/