From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4853.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc4853.txt (limited to 'doc/rfc/rfc4853.txt') diff --git a/doc/rfc/rfc4853.txt b/doc/rfc/rfc4853.txt new file mode 100644 index 0000000..55b41f9 --- /dev/null +++ b/doc/rfc/rfc4853.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group R. Housley +Request for Comments: 4853 Vigil Security +Updates: 3852 April 2007 +Category: Standards Track + + + Cryptographic Message Syntax (CMS) + Multiple Signer Clarification + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document updates the Cryptographic Message Syntax (CMS), which + is published in RFC 3852. This document clarifies the proper + handling of the SignedData protected content type when more than one + digital signature is present. + + + + + + + + + + + + + + + + + + + + + + + + +Housley Standards Track [Page 1] + +RFC 4853 CMS Multiple Signer Clarification April 2007 + + +1. Introduction + + This document updates the Cryptographic Message Syntax [CMS]. The + CMS SignedData protected content type allows multiple digital + signatures, but the specification is unclear about the appropriate + processing by a recipient of such a signed content. This document + provides replacement text for a few paragraphs, making it clear that + the protected content is validly signed by a given signer, if any of + the digital signatures from that signer are valid. + + This property is especially important in two cases. First, when the + recipients do not all implement the same digital signature algorithm, + a signer can sign the content with several different digital + signature algorithms so that each of the recipients can find an + acceptable signature. For example, if some recipients support RSA + and some recipients support ECDSA, then the signer can generate two + signatures, one with RSA and one with ECDSA, so that each recipient + will be able to validate one of the signatures. Second, when a + community is transitioning one-way hash functions or digital + signature algorithms, a signer can sign the content with the older + and the newer signature algorithms so that each recipient can find an + acceptable signature, regardless of their state in the transition. + For example, consider a transition from RSA with SHA-1 to RSA with + SHA-256. The signer can generate two signatures, one with SHA-1 and + one with SHA-256, so that each recipient will be able to validate at + least one of the RSA signatures. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [STDWORDS]. + +3. Update to RFC 3852, Section 5: Signed-data Content Type + + RFC 3852, section 5, the next to the last paragraph says: + +| 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. + + + + + + + +Housley Standards Track [Page 2] + +RFC 4853 CMS Multiple Signer Clarification April 2007 + + + This block of text is replaced with: + +| 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 one signature associated with a given signer is usually treated +| as a successful signature by that signer. However, there are some +| application environments where other rules are needed. An +| application that employs a rule other than one valid signature for +| each signer must specify those rules. Also, where simple matching of +| the signer identifier is not sufficient to determine whether the +| signatures were generated by the same signer, 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 the signature associated with one algorithm or the other. + +4. Update to RFC 3852, Section 5.1: SignedData Type + + RFC 3852, section 5.1, the next to the last paragraph says: + +| 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. + + This block of text is replaced with: + +| 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 one of signature from a given signer ought to be +| treated as a successful signature by that signer. However, +| there are some application environments where other rules are + + + +Housley Standards Track [Page 3] + +RFC 4853 CMS Multiple Signer Clarification April 2007 + + +| needed. The details of the SignerInfo type are discussed in +| section 5.3. Since each signer can employ a different 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. + +6. Security Considerations + + The replacement text will reduce the likelihood of interoperability + errors during the transition from MD5 and SHA-1 to stronger one-way + hash functions, or to better signature algorithms. + +7. Normative References + + [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC + 3852, July 2004. + + [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +Author's Address + + Russell Housley + Vigil Security, LLC + 918 Spring Knoll Drive + Herndon, VA 20170 + USA + + EMail: housley@vigilsec.com + + + + + + + + + + + + + + + + + + + +Housley Standards Track [Page 4] + +RFC 4853 CMS Multiple Signer Clarification April 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Housley Standards Track [Page 5] + -- cgit v1.2.3