INTERNET-DRAFT D.Pinkas Intended Status: Proposed Standard Bull SAS Updates: 2560bis (if approved) August 31, 2012 Expires: March 1, 2013 CertInfo single response extension Update to OCSP < draft-pinkas-2560bis-certinfo-00.txt > Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 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. Denis Pinkas Expires March 1, 2013 [Page 1] INTERNET DRAFT CertInfo single response extension August 31, 2012 Abstract OCSP [RFC2560] has been designed to allow an OCSP server to use any kind of trustable information to answer to a client varying from CRLs to an access to a database of issued certificates. In its original version, OCSP does not allow taking full advantage of an access to a database of issued certificates. When a database of issued certificates is used by an OCSP server, this document explains how the OCSP server shall respond and how OCSP clients shall react. The proposal is intended to update 2560bis. It defines a new single extension in a single response, called certInfo. The extension is non critical. The meaning of "good", "revoked" and "unknown" are unchanged. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. CertInfo single extension . . . . . . . . . . . . . . . . . . . 3 3. Text to be placed in the Security Considerations section . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 9. ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document is intended to be incorporated in 2560bis, a draft document being currently discussed in the PKIX WG to replace RFC 2560 [RFC2560]. 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]. Denis Pinkas Expires March 1, 2013 [Page 2] INTERNET DRAFT CertInfo single response extension August 31, 2012 2. certInfo single extension This single extension may be used in singleExtensions within a SingleResponse. It either contains: - an indication that the serial number of the target certificate is not present in the database, or - a hash value of the target certificate computed using the value of the certificate that is present in the database. This extension may only be used when an OCSP server has access to a database maintained by a CA which contains, for every issued certificate, the following up-to-date information: - its serial number, - its revocation status, and - the value of the certificate. The use of this single extension is RECOMMENDED, when the server is able to support it. The following only applies when this single extension is supported by the OCSP server. When the serial number of the target certificate is present in the database, then the OCSP server SHALL indicate the revocation status of the target certificate accordingly to the revocation status indicated in the database and the extension SHALL contain a hash value of the target certificate computed using the value of the certificate that is present in the database. The critical flag SHALL NOT be set. When the serial number of the certificate is not present in the database, then the OCSP server SHALL indicate that the revocation status of the target certificate is "unknown" and the extension SHALL contain an indication that the serial number of the target certificate is not present in the database. The critical flag SHALL NOT be set. The identifier for this extension is id-pkix-ocsp-certInfo, while the value is CertInfo. id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-certInfo OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 } CertInfo ::= CHOICE { certSerialNumberUnknown [0] BOOLEAN DEFAULT TRUE, certHashValue [1] CertHashValue } Denis Pinkas Expires March 1, 2013 [Page 3] INTERNET DRAFT CertInfo single response extension August 31, 2012 CertHashValue ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OCTET STRING } certSerialNumberUnknown is a Boolean which indicates that the serial number of the target certificate is not present in the list of the certificates issued by the CA to which the OCSP responder has access. In that case, certStatus SHALL be set to "unknown". certHashValue contains a hash value of the target certificate computed using the same hash function that was used by the OCSP client in the CertID field from the OCSP request. If this extension is not understood by the OCSP client, then it SHALL be ignored. If this extension is understood by the OCSP client, the OCSP client should make sure that there is no mistake with the serial number value. It should also make sure that it holds a certificate which includes that serial number and for which a certification path has been verified valid up to a trusted root (except the revocation status of the target certificate). The processing of this extension by an OCSP client is as follows: If the certSerialNumberUnknown Boolean is returned in the single extension, then the CertStatus is necessarily "unknown". The OCSP client SHOULD use this information to alert the OCSP server using out of bands means. If a hash of the certificate is returned in the single extension, the OCSP client SHALL compare its value with a hash computed locally on the target certificate it holds. If the hashes match, then the revocation status of the target certificate, as indicated by the OCSP server, is valid. If the hashes do not match, then the OCSP client SHOULD use this information to alert the OCSP server using out of bands means. Denis Pinkas Expires March 1, 2013 [Page 4] INTERNET DRAFT CertInfo single response extension August 31, 2012 3. Text to be placed in the Security Considerations section X.X. Certificate not regularly issued The advantages and the limitations provided through the use of the single extension "CertInfo" are indicated below: When certSerialNumberUnknown is returned, this extension indicates: - either that the target certificate has indeed not been issued and thus is a forged certificate, - or that the target certificate which was indeed regularly issued has been removed from the database by an attacker (denial of service attack) or by accident. When certHashValue is returned and the hashes do not match, this extension allows detecting an abnormal situation : there exists two certificates with the same serial number: one regularly issued by the CA and another one which has either been forged or obtained irregularly. When certHashValue is returned and the hashes match, then everything looks fine, but this case does not allow detecting an abnormal situation if the RA software has been corrupted or if the database to which the OCSP server has access has been maliciously corrupted. When an OCSP server receives an alert from an OCSP client, it should use the information provided by the OCSP client to investigate the case. If the target certificate is unknown to the OCSP server, but has been regularly issued, it is necessary to discriminate between a denial of service attack or an accident and to correct the problem so that the situation does not persist. If the target certificate has not been regularly issued, its serial number should be immediately added by the CA to the list of revoked certificates. Then after, the OCSP server should continue to investigate the case: - either the extend of the damage can be evaluated by the CA and only those certificates which have been fraudulently issued shall be revoked by the CA, or - the extend of damage cannot be evaluated and in that case the CA should ask to its superior CA to revoke its CA certificate. Denis Pinkas Expires March 1, 2013 [Page 5] INTERNET DRAFT CertInfo single response extension August 31, 2012 It is up to the CA and to the OCSP server to cooperate together in order to attempt to recover from these situations. OCSP servers and CAs should include in their recovery plans, the above situations. 4. Security Considerations The text covering the security considerations is provided in section 3. 5. IANA Considerations This document has no actions for IANA. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010. 6.2. Informative References [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, C., "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. 7. Acknowledgements Several of the ideas present in this document came from discussions on the PKIW WG list and with Romain Santini. 8. Author's Address Denis Pinkas Bull SAS BP 78 78340 Les Clayes sous bois France EMail: denis.pinkas@bull.net Denis Pinkas Expires March 1, 2013 [Page 6] INTERNET DRAFT CertInfo single response extension August 31, 2012 9. ASN.1 Module CERTINFO-2012 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-cert-info-2012-93(79) } DEFINITIONS EXPLICIT TAGS ::= BEGIN EXPORTS ALL; -- export all items from this module IMPORTS Extensions, AlgorithmIdentifier FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } id-pkix-ocsp FROM OCSP-2009 -- From [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) } ; certInfo EXTENSION ::= { SYNTAX CertInfo, IDENTIFIED BY id-pkix-ocsp-certInfo } id-pkix-ocsp-certInfo OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 } CertInfo ::= CHOICE { certSerialNumberUnknown [0] BOOLEAN DEFAULT TRUE, certHashValue [1] CertHashValue } CertHashValue ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OCTET STRING } END Denis Pinkas Expires March 1, 2013 [Page 7]