1 files changed, 283 insertions, 0 deletions
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]
+