INTERNET-DRAFT D.Pinkas Intended Status: Proposed Standard Bull SAS Updates: 2560bis (if approved) September 25, 2012 Expires: March 24, 2013 OCSP LocationCheck certificate extension Update to OCSP < draft-pinkas-2560bis-ocsp-locationcheck-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. Abstract RFC 2560 [RFC2560] allows CAs to designate one or more OCSP Responders for being responsible to provide the revocation status of the certificates they issue under a given CA key. Denis Pinkas March 24, 2013 [Page 1] INTERNET DRAFT OCSP LocationCheck extension September 25, 2012 This document introduces a new feature that allows allows CAs to split the workload between different sets of OCSP Responders in a way that is analogous to the way CRLs can be split between different sets of CRL issuers (using the cRLDistributionPoints extension). This new feature allows a CA to designate one or more OCSP Responders for being responsible to provide the revocation status for a subset of the certificates they issue under a given CA key. This document defines a critical extension that may only be placed in an OCSP certificate and the way it shall be processed by OCSP clients. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Text to be placed in section 4.5 (Extensions) . . . . . . . . . 3 3. Text to be placed in the Security Considerations section . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 9. ASN.1 modules . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. ASN.1 module which conforms to the 1988 syntax of ASN.1 . . 6 9.2. ASN.1 module which conforms to the 2002 syntax of ASN.1 . . 6 1. Introduction CAs may indicate in the certificates they issue the location of one or more Authorized OCSP Responders. In such a case, they include in these certificates an AIA extension with an accessMethod which contains the id-ad-ocsp OID as well as the location of the OCSP Responder(s) in the accessLocation field. Each OCSP Responder is able to demonstrate that it is an Authorized OCSP Responder because: - it got an OCSP certificate which includes both the ocspSigning OID in the extended key usage extension and the digitalSignature bit in the key usage extension; and - the key that was used to sign the OCSP certificate is the same as the key that was used to sign the target certificate. In RFC 2560 [RFC2560], OCSP clients have now way to make sure which OCSP Responder is behind a given URI. OCSP Responses can be interchanged, since all OCSP Responders are equally trusted. Denis Pinkas March 24, 2013 [Page 2] INTERNET DRAFT OCSP LocationCheck extension September 25, 2012 When using CRLs, CAs designating CRL issuers have a way to split the CRLs so that a given CRL issuer is only responsible for a subset of the issued certificates: they use the cRLDistributionPoints extension. In RFC 2560 [RFC2560], there is no similar functionality. Every OCSP Responder that has been initially designated by the CA must continue to be responsible to indicate the revocation status for every certificate issued by the CA under the key that was used to sign their OCSP certificate. The consequence is that every OCSP Responder must provide the revocation status of all certificates issued under a given CA key (even when millions of certificates are issued). Since it is not possible to add new fields in the AIA extension (when it contains an accessMethod which itself contains the id-ad-ocsp extension), in order to allow a client to make sure that an OCSP Response comes from the right URI, a new extension is defined. It may only be included in an OCSP certificate. The OCSP LocationCheck extension allows an OCSP client to verify that an OCSP Response comes from an URI that is indicated in the accessLocation field from target certificate to be verified (which is part of the AIA extension when the accessMethod contains the id-ad-ocsp OID). 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]. 2. Text to be placed in section 4.5 (Extensions) 4.5.X OCSP LocationCheck extension This single extension MAY only be placed in an OCSP certificate. The identifier for this extension is id-pkix-ocsp-locationcheck, while the value is LocationCheck. id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-locationcheck OBJECT IDENTIFIER ::= { id-pkix-ocsp X } LocationCheck ::= GeneralName This extension SHALL be set critical. Denis Pinkas March 24, 2013 [Page 3] INTERNET DRAFT OCSP LocationCheck extension September 25, 2012 This extension is not relevant to path processing, i.e. it SHALL be ignored when building a certification path up to a trusted root. When this extension is encountered by an OCSP client in an OCSP certificate and if it cannot be understood by an OCSP client, then the OCSP certificate SHALL be considered as invalid. When this extension is encountered by an OCSP client in an OCSP certificate and if it is recognized by an OCSP client, the OCSP client SHALL compare the URI included in the accessLocation field of the target certificate (which is part of the AIA extension when the accessMethod contains the id-ad-ocsp OID) with the content of the LocationCheck. The comparison SHALL be done using the dualStringMatch matching rule, as defined in X.520 [X.520] in section 14.8.2. If they match, then the OCSP client may proceed with further checks. If they don't match, then the OCSP client SHALL consider the OCSP certificate as invalid and SHALL consider the whole OCSP Response as invalid. 3. Text to be placed in the Security Considerations section 5.X. OCSP LocationCheck extension In RFC 2560 [RFC2560], OCSP clients have no way to make sure which OCSP Responder is behind a given URI. OCSP Responses can be interchanged, since all OCSP Responders are equally trusted. When an OCSP Responder is only responsible for a subset, OCSP Responders are no more equally trusted. OCSP clients need to make sure that the OCSP Responder was indeed authorized for a given certificate. The OCSP LocationCheck extension allows an OCSP client to verify that an OCSP Response comes from an URI that is indicated in the accessLocation field from target certificate to be verified (which is part of the AIA extension when the accessMethod contains the id-ad-ocsp OID). 4. Security Considerations The text covering the security considerations is provided in Section 3. 5. IANA Considerations This document has no actions for IANA. Denis Pinkas March 24, 2013 [Page 4] INTERNET DRAFT OCSP LocationCheck extension September 25, 2012 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 2497. [X.520] Information technology - Open Systems Interconnection The Directory: Selected attribute types. TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (ITU-T). (Edition from 11/2008). 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 TBD. 8. Author's Address Denis Pinkas Bull SAS BP 78 78340 Les Clayes sous bois France EMail: denis.pinkas@bull.net Denis Pinkas March 24, 2013 [Page 5] INTERNET DRAFT OCSP LocationCheck extension September 25, 2012 9. ASN.1 Modules Section 9.1 includes an ASN.1 module that conforms to the 1998 version of ASN.1. Section 9.2 includes an ASN.1 module that conforms to the 2002 version of ASN.1. 9.1. ASN.1 module which conforms to the 1988 syntax of ASN.1 CERTLOCATIONCHECK-1988 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-cert-location-check-88(XX) } BEGIN EXPORTS ALL ; id-pkix-ocsp-locationcheck OBJECT IDENTIFIER ::= { id-pkix-ocsp X } LocationCheck ::= GeneralName END 9.2. ASN.1 module which conforms to the 2002 syntax of ASN.1 CERTLOCATIONCHECK-2002 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-cert-location-check-02(XX) } BEGIN EXPORTS ALL ; id-pkix-ocsp-locationcheck OBJECT IDENTIFIER ::= { id-pkix-ocsp X } locationCheck EXTENSION ::= { SYNTAX LocationCheck IDENTIFIED BY id-pkix-ocsp-locationcheck } LocationCheck ::= GeneralName END Denis Pinkas March 24, 2013 [Page 6]