diff options
Diffstat (limited to 'doc/rfc/rfc5816.txt')
| -rw-r--r-- | doc/rfc/rfc5816.txt | 283 |
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] + |