doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc5816.txt b/doc/rfc/rfc5816.txt
new file mode 100644
index 0000000..8bb5fa6
--- /dev/null
+++ b/doc/rfc/rfc5816.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      S. Santesson
+Request for Comments: 5816                                  3xA Security
+Updates: 3161                                                    N. Pope
+Category: Standards Track                                         Thales
+ISSN: 2070-1721                                               March 2010
+
+
+                    ESSCertIDv2 Update for RFC 3161
+
+Abstract
+
+   This document updates RFC 3161.  It allows the use of ESSCertIDv2, as
+   defined in RFC 5035, to specify the hash of a signer certificate when
+   the hash is calculated with a function other than the Secure Hash
+   Algorithm (SHA-1).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5816.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+
+
+
+Santesson & Pope             Standards Track                    [Page 1]
+
+RFC 5816             ESSCertIDv2 Update for RFC 3161          March 2010
+
+
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................2
+   2. Updates to RFC 3161 .............................................3
+      2.1. Changes to Section 2.4.1, Request Format ...................3
+      2.2. Changes to Section 2.4.2, Response Format ..................3
+           2.2.1. Signature of Time-Stamp Token .......................3
+           2.2.2. Verifying the Time-Stamp Token ......................4
+   3. Security Considerations .........................................4
+   4. References ......................................................5
+      4.1. Normative References .......................................5
+      4.2. Informative References .....................................5
+
+1.  Introduction
+
+   The time-stamping protocol defined in RFC 3161 [RFC3161] requires
+   that the Cryptographic Message Syntax (CMS) SignedData [RFC5652],
+   used to apply a digital signature on the time-stamp token, include a
+   signed attribute that identifies the signer's certificate.
+
+   This identifier only allows SHA-1 [SHA1] to be used as the hash
+   algorithm to generate the identifier value.
+
+   The mechanism used in [RFC3161] employed ESSCertID from RFC 2634
+   [ESS].  RFC 5035 [ESSV2] updated ESSCertID with ESSCertIDv2 to allow
+   the use of any hash algorithm.
+
+   The changes to RFC 3161 [RFC3161] defined in this document allow
+   ESSCertIDv2 to be used to include an identifier of the signing
+   certificate as defined in RFC 5035 [ESSV2].
+
+1.1.  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 [RFC2119].
+
+
+
+
+
+Santesson & Pope             Standards Track                    [Page 2]
+
+RFC 5816             ESSCertIDv2 Update for RFC 3161          March 2010
+
+
+2.  Updates to RFC 3161
+
+2.1.  Changes to Section 2.4.1, Request Format
+
+   Last paragraph on Page 5.
+
+   Old:
+
+      If the certReq field is present and set to true, the TSA's public
+      key certificate that is referenced by the ESSCertID identifier
+      inside a SigningCertificate attribute in the response MUST be
+      provided by the TSA in the certificates field from the SignedData
+      structure in that response.  That field may also contain other
+      certificates.
+
+   New:
+
+      If the certReq field is present and set to true, the TSA's public
+      key certificate that is referenced by the ESSCertID [ESS] field
+      inside a SigningCertificate attribute or by the ESSCertIDv2
+      [ESSV2] field inside a SigningCertificateV2 attribute in the
+      response MUST be provided by the TSA in the certificates field
+      from the SignedData structure in that response.  That field may
+      also contain other certificates.
+
+2.2.  Changes to Section 2.4.2, Response Format
+
+2.2.1.  Signature of Time-Stamp Token
+
+   Fifth paragraph on Page 8, just before the definition of TSTInfo.
+
+   Old:
+
+      The time-stamp token MUST NOT contain any signatures other than
+      the signature of the TSA.  The certificate identifier (ESSCertID)
+      of the TSA certificate MUST be included as a signerInfo attribute
+      inside a SigningCertificate attribute.
+
+   New:
+
+      The time-stamp token MUST NOT contain any signatures other than
+      the signature of the TSA.  The certificate identifier (either
+      ESSCertID [ESS] or ESSCertIDv2 [ESSV2]) of the TSA certificate
+      MUST be included as a signerInfo attribute inside a
+      SigningCertificate attribute.
+
+
+
+
+
+
+Santesson & Pope             Standards Track                    [Page 3]
+
+RFC 5816             ESSCertIDv2 Update for RFC 3161          March 2010
+
+
+      Note: As mentioned in RFC 5035 [ESSV2], the SigningCertificateV2
+            attribute MUST be used if any algorithm other than SHA-1 is
+            used and SHOULD NOT be used for SHA-1.
+
+      Note: For backwards compatibility, in line with RFC 5035, both
+            ESSCertID and ESSCertIDv2 MAY be present.  Systems MAY
+            ignore ESSCertIDv2 if RFC 5035 has not been implemented.
+
+2.2.2.  Verifying the Time-Stamp Token
+
+   Third paragraph on Page 11.
+
+   Old:
+
+      The purpose of the tsa field is to give a hint in identifying the
+      name of the TSA.  If present, it MUST correspond to one of the
+      subject names included in the certificate that is to be used to
+      verify the token.  However, the actual identification of the
+      entity that signed the response will always occur through the use
+      of the certificate identifier (ESSCertID Attribute) inside a
+      SigningCertificate attribute which is part of the signerInfo (See
+      Section 5 of [ESS]).
+
+   New:
+
+      The purpose of the tsa field is to give a hint in identifying the
+      name of the TSA.  If present, it MUST correspond to one of the
+      subject names included in the certificate that is to be used to
+      verify the token.  However, the actual identification of the
+      entity that signed the response will always occur through the use
+      of the certificate identifier (ESSCertID inside a
+      SigningCertificate attribute or ESSCertIDv2 inside a
+      SigningCertificateV2 attribute) that is part of the signerInfo
+      (see Section 5 of [ESS] and Section 3 of [ESSV2]).
+
+3.  Security Considerations
+
+   This document incorporates the security considerations of RFC 5035
+   [ESSV2] with further explanations in this section.
+
+   ESSCertID provides a means based on the SHA-1 hash algorithm for
+   identifying the certificate used to verify the signature on a time
+   stamp.  The use of ESSCertIDv2 aims to enable implementers to comply
+   with policies that require phasing out all uses of the SHA-1
+   algorithm.
+
+
+
+
+
+
+Santesson & Pope             Standards Track                    [Page 4]
+
+RFC 5816             ESSCertIDv2 Update for RFC 3161          March 2010
+
+
+   The update provided by this document is motivated by reasons of
+   interoperability and migration to other hash algorithms rather than
+   mitigating new security issues.
+
+4.  References
+
+4.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [ESS]       Hoffman, P., Ed., "Enhanced Security Services for
+               S/MIME", RFC 2634, June 1999.
+
+   [ESSV2]     Schaad, J., "Enhanced Security Services (ESS) Update:
+               Adding CertID Algorithm Agility", RFC 5035, August 2007.
+
+   [RFC3161]   Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
+               "Internet X.509 Public Key Infrastructure Time-Stamp
+               Protocol (TSP)", RFC 3161, August 2001.
+
+   [RFC5652]   Housley, R., "Cryptographic Message Syntax (CMS)",
+               RFC 5652, September 2009.
+
+4.2.  Informative References
+
+   [SHA1]      Secure Hash Standard. FIPS Pub 180-1. National Institute
+               of Standards and Technology. 17 April 1995.
+
+Authors' Addresses
+
+   Stefan Santesson
+   3xA Security AB
+   Sweden
+
+   EMail: sts@aaa-sec.com
+
+
+   Nick Pope
+   Thales Information Systems Security
+   Long Crendon, Aylesbury
+   United Kingdom
+
+   EMail: nick.pope@thales-esecurity.com
+
+
+
+
+
+
+
+Santesson & Pope             Standards Track                    [Page 5]
+