rfc9919.original   rfc9919.txt 
Network Working Group 伊藤 忠彦 (T. Ito) Internet Engineering Task Force (IETF) 伊藤 忠彦 (T. Ito)
Internet-Draft SECOM CO., LTD. Request for Comments: 9919 SECOM CO., LTD.
Obsoletes: 5019 (if approved) C. Wilson Obsoletes: 5019 C. Wilson
Intended status: Standards Track Apple, Inc. Category: Standards Track Apple, Inc.
Expires: 17 March 2025 C. Bonnell ISSN: 2070-1721 C. Bonnell
DigiCert, Inc. DigiCert, Inc.
S. Turner S. Turner
sn3rd sn3rd
13 September 2024 January 2026
Updates to Lightweight OCSP Profile for High Volume Environments Updates to the Lightweight Online Certificate Status Protocol (OCSP)
draft-ietf-lamps-rfc5019bis-12 Profile for High Volume Environments
Abstract Abstract
This specification defines a profile of the Online Certificate Status This specification defines a profile of the Online Certificate Status
Protocol (OCSP) that addresses the scalability issues inherent when Protocol (OCSP) that addresses the scalability issues inherent when
using OCSP in large scale (high volume) Public Key Infrastructure using OCSP in large scale (high volume) Public Key Infrastructure
(PKI) environments and/or in PKI environments that require a (PKI) environments and/or in PKI environments that require a
lightweight solution to minimize communication bandwidth and client- lightweight solution to minimize communication bandwidth and client-
side processing. side processing.
This specification obsoletes RFC 5019. The profile specified in RFC This specification obsoletes RFC 5019. The profile specified in RFC
5019 has been updated to allow and recommend the use of SHA-256 over 5019 has been updated to allow and recommend the use of SHA-256 over
SHA-1. SHA-1.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/tadahik/RFC5019bis.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9919.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 17 March 2025.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2. Conventions
3. OCSP Message Profile . . . . . . . . . . . . . . . . . . . . 4 3. OCSP Message Profile
3.1. OCSP Request Profile . . . . . . . . . . . . . . . . . . 5 3.1. OCSP Request Profile
3.1.1. OCSPRequest Structure . . . . . . . . . . . . . . . . 5 3.1.1. OCSPRequest Structure
3.1.2. Signed OCSPRequests . . . . . . . . . . . . . . . . . 6 3.1.2. Signed OCSPRequests
3.2. OCSP Response Profile . . . . . . . . . . . . . . . . . . 6 3.2. OCSP Response Profile
3.2.1. OCSPResponse Structure . . . . . . . . . . . . . . . 6 3.2.1. OCSPResponse Structure
3.2.2. Signed OCSPResponses . . . . . . . . . . . . . . . . 8 3.2.2. Signed OCSPResponses
3.2.3. OCSPResponseStatus Values . . . . . . . . . . . . . . 9 3.2.3. OCSPResponseStatus Values
3.2.4. thisUpdate, nextUpdate, and producedAt . . . . . . . 10 3.2.4. thisUpdate, nextUpdate, and producedAt
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 4. Client Behavior
4.1. OCSP Responder Discovery . . . . . . . . . . . . . . . . 10 4.1. OCSP Responder Discovery
4.2. Sending an OCSP Request . . . . . . . . . . . . . . . . . 11 4.2. Sending an OCSP Request
5. Ensuring an OCSPResponse Is Fresh . . . . . . . . . . . . . . 11 5. Ensuring an OCSPResponse Is Fresh
6. Transport Profile . . . . . . . . . . . . . . . . . . . . . . 12 6. Transport Profile
7. Caching Recommendations . . . . . . . . . . . . . . . . . . . 13 7. Caching Recommendations
7.1. Caching at the Client . . . . . . . . . . . . . . . . . . 13 7.1. Caching at the Client
7.2. HTTP Proxies . . . . . . . . . . . . . . . . . . . . . . 14 7.2. HTTP Proxies
7.3. Caching at Servers . . . . . . . . . . . . . . . . . . . 15 7.3. Caching at Servers
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations
8.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 16 8.1. Replay Attacks
8.2. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 17 8.2. Man-in-the-Middle Attacks
8.3. Impersonation Attacks . . . . . . . . . . . . . . . . . . 17 8.3. Impersonation Attacks
8.4. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 17 8.4. Denial-of-Service Attacks
8.5. Modification of HTTP Header Fields . . . . . . . . . . . 17 8.5. Modification of HTTP Header Fields
8.6. Request Authentication and Authorization . . . . . . . . 18 8.6. Request Authentication and Authorization
8.7. Use of SHA-1 for the calculation of CertID field 8.7. Use of SHA-1 for the Calculation of CertID Field Values
values . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Differences from RFC 5019
Appendix A. Differences from RFC 5019 . . . . . . . . . . . . . 20 Appendix B. Examples
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 20 B.1. Root Certification Authority Certificate
B.1. Root Certification Authority Certificate . . . . . . . . 20 B.2. End-Entity Certificate
B.2. End-entity Certificate . . . . . . . . . . . . . . . . . 23 B.3. OCSP Responder Certificate
B.3. OCSP Responder Certificate . . . . . . . . . . . . . . . 26 B.4. OCSP Request
B.4. OCSP Request . . . . . . . . . . . . . . . . . . . . . . 29 B.5. OCSP Response
B.5. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 30 Acknowledgments
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The Online Certificate Status Protocol [RFC6960] specifies a The Online Certificate Status Protocol [RFC6960] specifies a
mechanism used to determine the status of digital certificates, in mechanism used to determine the status of digital certificates, in
lieu of using Certificate Revocation Lists (CRLs). Since its lieu of using Certificate Revocation Lists (CRLs). Since its
definition in 1999, it has been deployed in a variety of environments definition in 1999, it has been deployed in a variety of environments
and has proven to be a useful certificate status checking mechanism. and has proven to be a useful certificate status checking mechanism.
(For brevity, the term "OCSP" is used herein to denote the (For brevity, the term "OCSP" is used herein to denote the
verification of certificate status; however, it should be noted that verification of certificate status; however, it should be noted that
this protocol is employed solely to ascertain the revocation status this protocol is employed solely to ascertain the revocation status
of a certificate.) of a certificate.)
To date, numerous OCSP deployments have been implemented to provide To date, numerous OCSP deployments have been implemented to provide
timely and secure certificate status information, crucial for high- timely and secure certificate status information, crucial for high-
value electronic transactions and the handling of highly sensitive value electronic transactions and the handling of highly sensitive
information, such as within the banking and financial sectors. information, such as within the banking and financial sectors.
Therefore, the requirement for an OCSP responder to respond in "real Therefore, the requirement for an OCSP responder to respond in "real
time" (i.e., generating a new OCSP response for each OCSP request) time" (i.e., generating a new OCSP response for each OCSP request)
has been important. In addition, these deployments have operated in has been important. In addition, these deployments have operated in
environments where bandwidth usage is not an issue, and have run on environments where bandwidth usage is not an issue and have run on
client and server systems where processing power is not constrained. client and server systems where processing power is not constrained.
As the use of PKI continues to grow and move into diverse As the use of PKI continues to grow and move into diverse
environments, so does the need for a scalable and cost-effective environments, so does the need for a scalable and cost-effective
certificate status mechanism. Although OCSP as currently defined and certificate status mechanism. Although OCSP as currently defined and
deployed meets the need of small to medium-sized PKIs that operate on deployed meets the need of small to medium-sized PKIs that operate on
powerful systems on wired networks, there is a limit as to how these powerful systems on wired networks, there is a limit as to how these
OCSP deployments scale from both an efficiency and cost perspective. OCSP deployments scale from both an efficiency and cost perspective.
Mobile environments, where network bandwidth may be at a premium and Mobile environments, where network bandwidth may be at a premium and
client-side devices are constrained from a processing point of view, client-side devices are constrained from a processing point of view,
require the careful use of OCSP to minimize bandwidth usage and require the careful use of OCSP to minimize bandwidth usage and
client-side processing complexity. [OCSPMP] client-side processing complexity [OCSPMP].
PKI continues to be deployed into environments where millions if not PKI continues to be deployed into environments where millions if not
hundreds of millions of certificates have been issued. In many of hundreds of millions of certificates have been issued. In many of
these environments, an even larger number of users (also known as these environments, an even larger number of users (also known as
relying parties) have the need to ensure that the certificate they relying parties) have the need to ensure that the certificate they
are relying upon has not been revoked. As such, it is important that are relying upon has not been revoked. As such, it is important that
OCSP is used in such a way that ensures the load on OCSP responders OCSP is used in such a way that ensures the load on OCSP responders
and the network infrastructure required to host those responders are and the network infrastructure required to host those responders are
kept to a minimum. kept to a minimum.
This document addresses the scalability issues inherent when using This document addresses the scalability issues inherent when using
skipping to change at page 4, line 40 skipping to change at line 170
OCSP does not have the means to signal responder capabilities within OCSP does not have the means to signal responder capabilities within
the protocol. Thus, clients may need to use out-of-band mechanisms the protocol. Thus, clients may need to use out-of-band mechanisms
(e.g., agreed upon arrangements between operators of OCSP responders (e.g., agreed upon arrangements between operators of OCSP responders
and OCSP clients) to determine whether a responder conforms to the and OCSP clients) to determine whether a responder conforms to the
profile defined in this document. Regardless of the availability of profile defined in this document. Regardless of the availability of
such out-of-band mechanisms, this profile ensures that such out-of-band mechanisms, this profile ensures that
interoperability will still occur between an OCSP client that fully interoperability will still occur between an OCSP client that fully
conforms with [RFC6960] and a responder that is operating in a mode conforms with [RFC6960] and a responder that is operating in a mode
as described in this specification. as described in this specification.
2. Conventions and Definitions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. OCSP Message Profile 3. OCSP Message Profile
This section defines a subset of OCSPRequest and OCSPResponse This section defines a subset of OCSPRequest and OCSPResponse
functionality as defined in [RFC6960]. functionality as defined in [RFC6960].
3.1. OCSP Request Profile 3.1. OCSP Request Profile
3.1.1. OCSPRequest Structure 3.1.1. OCSPRequest Structure
Provided for convenience here, a partial extract of the ASN.1 A partial extract of the ASN.1 structure corresponding to the
structure corresponding to the OCSPRequest with the relevant CertID OCSPRequest with the relevant CertID as defined in [RFC6960] is
as defined in [RFC6960]: provided here for convenience:
OCSPRequest ::= SEQUENCE { OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest, tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL } optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE { TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1, version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL, requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request, requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL } requestExtensions [2] EXPLICIT Extensions OPTIONAL }
skipping to change at page 5, line 39 skipping to change at line 217
issuerNameHash OCTET STRING, -- Hash of issuer's DN issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber } serialNumber CertificateSerialNumber }
OCSPRequests that conform to the profile in this document MUST OCSPRequests that conform to the profile in this document MUST
include only one Request in the OCSPRequest.RequestList structure. include only one Request in the OCSPRequest.RequestList structure.
The CertID.issuerNameHash and CertID.issuerKeyHash fields contain The CertID.issuerNameHash and CertID.issuerKeyHash fields contain
hashes of the issuer's distinguished name (DN) and public key, hashes of the issuer's distinguished name (DN) and public key,
respectively. OCSP clients that conform with this profile MUST use respectively. OCSP clients that conform with this profile MUST use
SHA-256 as defined in Section 2.2 of [RFC5754] as the hashing SHA-256, as defined in Section 2.2 of [RFC5754], as the hashing
algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash
values. values.
Older OCSP clients which provide backward compatibility with Older OCSP clients that provide backward compatibility with [RFC5019]
[RFC5019] use SHA-1 as defined in [RFC3174] as the hashing algorithm use SHA-1, as defined in [RFC3174], as the hashing algorithm for the
for the CertID.issuerNameHash and the CertID.issuerKeyHash values. CertID.issuerNameHash and the CertID.issuerKeyHash values. However,
However, these OCSP clients MUST transition from SHA-1 to SHA-256 as these OCSP clients MUST transition from SHA-1 to SHA-256 as soon as
soon as practical. practical.
Clients MUST NOT include the singleRequestExtensions structure. Clients MUST NOT include the singleRequestExtensions structure.
Clients SHOULD NOT include the requestExtensions structure. If a Clients SHOULD NOT include the requestExtensions structure. If a
requestExtensions structure is included, this profile RECOMMENDS that requestExtensions structure is included, it is RECOMMENDED by this
it contain only the nonce extension (id-pkix-ocsp-nonce). See profile that the structure contain only the nonce extension (id-pkix-
Section 5 for issues concerning the use of a nonce in high-volume ocsp-nonce). See Section 5 for issues concerning the use of a nonce
OCSP environments. in high-volume OCSP environments.
3.1.2. Signed OCSPRequests 3.1.2. Signed OCSPRequests
Clients SHOULD NOT send signed OCSPRequests. Responders MAY ignore Clients SHOULD NOT send signed OCSPRequests. Responders MAY ignore
the signature on OCSPRequests. the signature on OCSPRequests.
If the OCSPRequest is signed, the client SHALL specify its name in If the OCSPRequest is signed, the client SHALL specify its name in
the OCSPRequest.requestorName field; otherwise, clients SHOULD NOT the OCSPRequest.requestorName field; otherwise, clients SHOULD NOT
include the requestorName field in the OCSPRequest. OCSP responders include the requestorName field in the OCSPRequest. OCSP responders
MUST handle unsigned OCSP requests that contain the requestorName MUST handle unsigned OCSP requests that contain the requestorName
field, as if the requestorName field were absent. field, as if the requestorName field were absent.
3.2. OCSP Response Profile 3.2. OCSP Response Profile
3.2.1. OCSPResponse Structure 3.2.1. OCSPResponse Structure
Provided for convenience here, a partial extract of the ASN.1 A partial extract of the ASN.1 structure corresponding to the
structure corresponding to the OCSPResponse with the relevant CertID OCSPResponse with the relevant CertID as defined in [RFC6960] is
as defined in [RFC6960]: provided here for convenience:
OCSPResponse ::= SEQUENCE { OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus, responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
ResponseBytes ::= SEQUENCE { ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER, responseType OBJECT IDENTIFIER,
response OCTET STRING } response OCTET STRING }
The value for response SHALL be the DER encoding of BasicOCSPResponse. The value for response SHALL be the DER encoding of
BasicOCSPResponse.
BasicOCSPResponse ::= SEQUENCE { BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData, tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier, signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING, signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
ResponseData ::= SEQUENCE { ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1, version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID, responderID ResponderID,
producedAt GeneralizedTime, producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse, responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL } responseExtensions [1] EXPLICIT Extensions OPTIONAL }
SingleResponse ::= SEQUENCE { SingleResponse ::= SEQUENCE {
certID CertID, certID CertID,
certStatus CertStatus, certStatus CertStatus,
thisUpdate GeneralizedTime, thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL } singleExtensions [1] EXPLICIT Extensions OPTIONAL }
Responders MUST generate a BasicOCSPResponse as identified by the id- Responders MUST generate a BasicOCSPResponse as identified by the id-
pkix-ocsp-basic OID. Clients MUST be able to parse and accept a pkix-ocsp-basic OID. Clients MUST be able to parse and accept a
BasicOCSPResponse. OCSPResponses that conform to this profile SHOULD BasicOCSPResponse. OCSPResponses that conform to this profile SHOULD
include only one SingleResponse in the ResponseData.responses include only one SingleResponse in the ResponseData.responses
structure, but MAY include additional SingleResponse elements if structure but MAY include additional SingleResponse elements if
necessary to improve response pre-generation performance or cache necessary to improve response pre-generation performance or cache
efficiency, and to ensure backward compatibility. For instance, to efficiency and to ensure backward compatibility. For instance, to
provide support to OCSP clients which do not yet support the use of provide support to OCSP clients that do not yet support the use of
SHA-256 for CertID hash calculation, the OCSP responder MAY include SHA-256 for CertID hash calculation, the OCSP responder MAY include
two SingleResponses in a BasicOCSPResponse. In that two SingleResponses in a BasicOCSPResponse. In that
BasicOCSPResponse, the CertID of one of the SingleResponses uses BasicOCSPResponse, the CertID of one of the SingleResponses uses
SHA-1 for the hash calculation, and the CertID in the other SHA-1 for the hash calculation, and the CertID in the other
SingleResponse uses SHA-256. OCSP responders SHOULD NOT distribute SingleResponse uses SHA-256. OCSP responders SHOULD NOT distribute
OCSP responses that contain CertIDs that use SHA-1 if the OCSP OCSP responses that contain CertIDs that use SHA-1 if the OCSP
responder has no clients that require the use of SHA-1. Operators of responder has no clients that require the use of SHA-1. Operators of
OCSP responders may consider logging the hash algorithm used by OCSP OCSP responders may consider logging the hash algorithm used by OCSP
clients to inform their determination of when it is appropriate to clients to inform their determination of when it is appropriate to
obsolete the distribution of OCSP responses that employ SHA-1 for obsolete the distribution of OCSP responses that employ SHA-1 for
skipping to change at page 9, line 23 skipping to change at line 351
(AIA) extension nor cRLDistributionPoints (CRLDP) extension be (AIA) extension nor cRLDistributionPoints (CRLDP) extension be
included in the OCSP responder's certificate. Accordingly, the included in the OCSP responder's certificate. Accordingly, the
responder's signing certificate SHOULD be relatively short-lived and responder's signing certificate SHOULD be relatively short-lived and
renewed regularly. renewed regularly.
Clients MUST be able to identify OCSP responder certificates using Clients MUST be able to identify OCSP responder certificates using
the byKey field and SHOULD be able to identify OCSP responder the byKey field and SHOULD be able to identify OCSP responder
certificates using the byName field of the ResponseData.ResponderID certificates using the byName field of the ResponseData.ResponderID
[RFC6960] choices. [RFC6960] choices.
Older responders which provide backward compatibility with [RFC5019] Older responders that provide backward compatibility with [RFC5019]
MAY use the byName field to represent the ResponderID, but should MAY use the byName field to represent the ResponderID but should
transition to using the byKey field as soon as practical. transition to using the byKey field as soon as practical.
Newer responders that conform to this profile MUST use the byKey Newer responders that conform to this profile MUST use the byKey
field to represent the ResponderID to reduce the size of the field to represent the ResponderID to reduce the size of the
response. response.
3.2.3. OCSPResponseStatus Values 3.2.3. OCSPResponseStatus Values
As long as the OCSP infrastructure has authoritative records for a As long as the OCSP infrastructure has authoritative records for a
particular certificate, an OCSPResponseStatus of "successful" will be particular certificate, an OCSPResponseStatus of "successful" will be
skipping to change at page 10, line 37 skipping to change at line 404
nextUpdate: The time at or before which newer information will be nextUpdate: The time at or before which newer information will be
available about the status of the certificate. As described in available about the status of the certificate. As described in
Section 2.4 of [RFC6960], this field is optional. However, this Section 2.4 of [RFC6960], this field is optional. However, this
field MUST be included in the profile specified in this document field MUST be included in the profile specified in this document
to help clients cache responses. See Section 7 for additional to help clients cache responses. See Section 7 for additional
information on caching. information on caching.
producedAt: The time at which the OCSP response was signed. producedAt: The time at which the OCSP response was signed.
| Note: The values of thisUpdate, nextUpdate, and producedAt are | Note: The values of thisUpdate, nextUpdate, and producedAt are
| set as described in Section 2.5 of [RFC6960], and in many cases | set as described in Section 2.5 of [RFC6960], and in many
| the value of thisUpdate and producedAt are the same. | cases, the value of thisUpdate and producedAt are the same.
For the purposes of this profile, ASN.1-encoded GeneralizedTime For the purposes of this profile, ASN.1-encoded GeneralizedTime
values such as thisUpdate, nextUpdate, and producedAt MUST be values, such as thisUpdate, nextUpdate, and producedAt, MUST be
expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds. GeneralizedTime values MUST NOT include fractional seconds.
4. Client Behavior 4. Client Behavior
4.1. OCSP Responder Discovery 4.1. OCSP Responder Discovery
Clients MUST support the authorityInfoAccess extension as defined in Clients MUST support the authorityInfoAccess extension as defined in
[RFC5280] and MUST recognize the id-ad-ocsp access method. This [RFC5280] and MUST recognize the id-ad-ocsp access method. This
skipping to change at page 11, line 22 skipping to change at line 438
4.2. Sending an OCSP Request 4.2. Sending an OCSP Request
To avoid needless network traffic, applications MUST verify the To avoid needless network traffic, applications MUST verify the
signature of signed data before asking an OCSP client to check the signature of signed data before asking an OCSP client to check the
status of certificates used to verify the data. If the signature is status of certificates used to verify the data. If the signature is
invalid or the application is not able to verify it, an OCSP check invalid or the application is not able to verify it, an OCSP check
MUST NOT be requested. MUST NOT be requested.
Similarly, an application MUST validate the signature on certificates Similarly, an application MUST validate the signature on certificates
in a chain, before asking an OCSP client to check the status of the in a chain before asking an OCSP client to check the status of the
certificate. If the certificate signature is invalid or the certificate. If the certificate signature is invalid or the
application is not able to verify it, an OCSP check MUST NOT be application is not able to verify it, an OCSP check MUST NOT be
requested. Clients SHOULD NOT make a request to check the status of requested. Clients SHOULD NOT make a request to check the status of
expired certificates. expired certificates.
5. Ensuring an OCSPResponse Is Fresh 5. Ensuring an OCSPResponse Is Fresh
In order to ensure that a client does not accept an out-of-date In order to ensure that a client does not accept an out-of-date
response that indicates a 'good' status when in fact there is a more response that indicates a "good" status when in fact there is a more
up-to-date response that specifies the status of 'revoked', a client up-to-date response that specifies the status of "revoked", a client
must ensure the responses they receive are fresh. must ensure the responses they receive are fresh.
In general, two mechanisms are available to clients to ensure a In general, two mechanisms are available to clients to ensure a
response is fresh. The first uses nonces, and the second is based on response is fresh. The first uses nonces, and the second is based on
time. In order for time-based mechanisms to work, both clients and time. In order for time-based mechanisms to work, both clients and
responders MUST have access to an accurate source of time. responders MUST have access to an accurate source of time.
Because this profile specifies that clients SHOULD NOT include a Because this profile specifies that clients SHOULD NOT include a
requestExtensions structure in OCSPRequests (see Section 3.1), requestExtensions structure in OCSPRequests (see Section 3.1),
clients MUST be able to determine OCSPResponse freshness based on an clients MUST be able to determine OCSPResponse freshness based on an
accurate source of time. Clients that opt to include a nonce in the accurate source of time. Clients that opt to include a nonce in the
request SHOULD NOT reject a corresponding OCSPResponse solely on the request SHOULD NOT reject a corresponding OCSPResponse solely on the
basis of the nonexistent expected nonce, but MUST fall back to basis of the nonexistent expected nonce but MUST fall back to
validating the OCSPResponse based on time. validating the OCSPResponse based on time.
Clients that do not include a nonce in the request MUST ignore any Clients that do not include a nonce in the request MUST ignore any
nonce that may be present in the response. nonce that may be present in the response.
Clients MUST check for the existence of the nextUpdate field and MUST Clients MUST check for the existence of the nextUpdate field and MUST
ensure the current time, expressed in GMT time as described in ensure the current time, expressed in GMT time as described in
Section 3.2.4, falls between the thisUpdate and nextUpdate times. If Section 3.2.4, falls between the thisUpdate and nextUpdate times. If
the nextUpdate field is absent, the client MUST reject the response. the nextUpdate field is absent, the client MUST reject the response.
skipping to change at page 12, line 22 skipping to change at line 484
is later than the time specified in the nextUpdate field, the client is later than the time specified in the nextUpdate field, the client
MUST reject the response as stale. Clients MAY allow configuration MUST reject the response as stale. Clients MAY allow configuration
of a small tolerance period for acceptance of responses after of a small tolerance period for acceptance of responses after
nextUpdate to handle minor clock differences relative to responders nextUpdate to handle minor clock differences relative to responders
and caches. This tolerance period should be chosen based on the and caches. This tolerance period should be chosen based on the
accuracy and precision of time synchronization technology available accuracy and precision of time synchronization technology available
to the calling application environment. For example, Internet peers to the calling application environment. For example, Internet peers
with low latency connections typically expect NTP time with low latency connections typically expect NTP time
synchronization to keep them accurate within parts of a second; synchronization to keep them accurate within parts of a second;
higher latency environments or where an NTP analogue is not available higher latency environments or where an NTP analogue is not available
may have to be more liberal in their tolerance (e.g. allow one day may have to be more liberal in their tolerance (e.g., allow one day
difference). difference).
See the security considerations in Section 8 for additional details See the security considerations in Section 8 for additional details
on replay and man-in-the-middle attacks. on replay and man-in-the-middle attacks.
6. Transport Profile 6. Transport Profile
OCSP clients can send HTTP-based OCSP requests using either the GET OCSP clients can send HTTP-based OCSP requests using either the GET
or POST method. The OCSP responder MUST support requests and or POST method. The OCSP responder MUST support requests and
responses over HTTP. When sending requests that are less than or responses over HTTP. When sending requests that are less than or
equal to 255 bytes in total (after encoding) including the scheme and equal to 255 bytes in total (after encoding) including the scheme and
delimiters (http://), server name and base64-encoded OCSPRequest delimiters (http://), server name and base64-encoded OCSPRequest
structure, clients MUST use the GET method (to enable OCSP response structure, clients MUST use the GET method (to enable OCSP response
caching). OCSP requests larger than 255 bytes SHOULD be submitted caching). OCSP requests larger than 255 bytes SHOULD be submitted
using the POST method. In all cases, clients MUST follow the using the POST method. In all cases, clients MUST follow the
descriptions in A.1 of [RFC6960] when constructing these messages. descriptions in Appendix A.1 of [RFC6960] when constructing these
messages.
When constructing a GET message, OCSP clients MUST base64-encode the When constructing a GET message, OCSP clients MUST base64-encode the
OCSPRequest structure according to Section 4 of [RFC4648]. Clients OCSPRequest structure according to Section 4 of [RFC4648]. Clients
MUST NOT include whitespace or any other characters that are not part MUST NOT include whitespace or any other characters that are not part
of the base64 character repertoire in the base64-encoded string. of the base64 character repertoire in the base64-encoded string.
Clients MUST properly URL-encode the base64-encoded OCSPRequest Clients MUST properly URL-encode the base64-encoded OCSPRequest
according to [RFC3986]. OCSP clients MUST append the base64-encoded according to [RFC3986]. OCSP clients MUST append the base64-encoded
OCSPRequest to the URI specified in the AIA extension [RFC5280]. For OCSPRequest to the URI specified in the AIA extension [RFC5280]. For
example: example:
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL2dA http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL2dA
deGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%3D%3D deGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%3D%3D
In response to properly formatted OCSPRequests that are cachable In response to properly formatted OCSPRequests that are cachable
(i.e., responses that contain a nextUpdate value), the responder will (i.e., responses that contain a nextUpdate value), the responder will
include the binary value of the DER encoding of the OCSPResponse include the binary value of the DER encoding of the OCSPResponse
preceded by the following HTTP [RFC9110] and [RFC9111] header fields. preceded by the following HTTP [RFC9110] [RFC9111] header fields.
Content-type: application/ocsp-response Content-type: application/ocsp-response
Content-length: < OCSP response length > Content-length: < OCSP response length >
Last-modified: < producedAt HTTP-date > Last-modified: < producedAt HTTP-date >
ETag: "< strong validator >" ETag: "< strong validator >"
Expires: < nextUpdate HTTP-date > Expires: < nextUpdate HTTP-date >
Cache-control: max-age=< n >, public, no-transform, must-revalidate Cache-control: max-age=< n >, public, no-transform, must-revalidate
Date: < current HTTP-date > Date: < current HTTP-date >
See Section 7.2 for details on the use of these HTTP header fields. See Section 7.2 for details on the use of these HTTP header fields.
7. Caching Recommendations 7. Caching Recommendations
The ability to cache OCSP responses throughout the network is an The ability to cache OCSP responses throughout the network is an
important factor in high volume OCSP deployments. This section important factor in high volume OCSP deployments. This section
discusses the recommended caching behavior of OCSP clients and HTTP discusses the recommended caching behavior of OCSP clients and HTTP
proxies and the steps that should be taken to minimize the number of proxies and the steps that should be taken to minimize the number of
times that OCSP clients "hit the wire". In addition, the concept of times that OCSP clients "hit the wire". In addition, the concept of
including OCSP responses in protocol exchanges (aka stapling or including OCSP responses in protocol exchanges (aka stapling or
piggybacking), such as has been defined in TLS, is also discussed. piggybacking), such as has been defined in TLS, is also discussed.
7.1. Caching at the Client 7.1. Caching at the Client
To minimize bandwidth usage, clients MUST locally cache authoritative To minimize bandwidth usage, clients MUST locally cache authoritative
OCSP responses (i.e., a response with a signature that has been OCSP responses (i.e., a response with a signature that has been
successfully validated and that indicate an OCSPResponseStatus of successfully validated and that indicates an OCSPResponseStatus of
'successful'). "successful").
Most OCSP clients will send OCSPRequests at or near the nextUpdate Most OCSP clients will send OCSPRequests at or near the nextUpdate
time (when a cached response expires). To avoid large spikes in time (when a cached response expires). To avoid large spikes in
responder load that might occur when many clients refresh cached responder load that might occur when many clients refresh cached
responses for a popular certificate, responders MAY indicate when the responses for a popular certificate, responders MAY indicate when the
client should fetch an updated OCSP response by using the cache- client should fetch an updated OCSP response by using the cache-
control:max-age directive. Clients SHOULD fetch the updated OCSP control:max-age directive. Clients SHOULD fetch the updated OCSP
Response on or after the max-age time. To ensure that clients response on or after the max-age time. To ensure that clients
receive an updated OCSP response, OCSP responders MUST refresh the receive an updated OCSP response, OCSP responders MUST refresh the
OCSP response before the max-age time. OCSP response before the max-age time.
7.2. HTTP Proxies 7.2. HTTP Proxies
The responder SHOULD set the HTTP header fields of the OCSP response The responder SHOULD set the HTTP header fields of the OCSP response
in such a way as to allow for the intelligent use of intermediate in such a way as to allow for the intelligent use of intermediate
HTTP proxy servers. See [RFC9110] and [RFC9111] for the full HTTP proxy servers. See [RFC9110] and [RFC9111] for the full
definition of these HTTP header fields and the proper format of any definition of these HTTP header fields and the proper format of any
date and time values. date and time values.
+===============+==================================================+ +===============+===================================================+
| HTTP Header | Description | | HTTP Header | Description |
| Field | | | Field | |
+===============+==================================================+ +===============+===================================================+
| Date | The date and time at which the OCSP responder | | Date | The date and time at which the OCSP responder |
| | generated the HTTP response. | | | generated the HTTP response. |
+---------------+--------------------------------------------------+ +---------------+---------------------------------------------------+
| Last-Modified | This value specifies the date and time at which | | Last-Modified | This value specifies the date and time at which |
| | the OCSP responder last modified the response. | | | the OCSP responder last modified the response. |
| | This date and time will be the same as the | | | This date and time will be the same as the |
| | thisUpdate timestamp in the request itself. | | | thisUpdate timestamp in the request itself. |
+---------------+--------------------------------------------------+ +---------------+---------------------------------------------------+
| Expires | Specifies how long the response is considered | | Expires | Specifies how long the response is considered |
| | fresh. This date and time will be the same as | | | fresh. This date and time will be the same as |
| | the nextUpdate timestamp in the OCSP response | | | the nextUpdate timestamp in the OCSP response |
| | itself. | | | itself. |
+---------------+--------------------------------------------------+ +---------------+---------------------------------------------------+
| ETag | A string that identifies a particular version of | | ETag | A string that identifies a particular version of |
| | the associated data. This profile RECOMMENDS | | | the associated data. It is RECOMMENDED by this |
| | that the ETag value be the ASCII HEX | | | profile that the ETag value be the ASCII HEX |
| | representation of the SHA-256 hash of the | | | representation of the SHA-256 hash of the |
| | OCSPResponse structure. | | | OCSPResponse structure. |
+---------------+--------------------------------------------------+ +---------------+---------------------------------------------------+
| Cache-Control | Contains a number of caching directives. | | Cache-Control | Contains a number of caching directives. |
| | * max-age = < n > -where n is a time value later | | | |
| | than thisUpdate but earlier than nextUpdate. | | | * max-age = < n > - where n is a time value |
| | * public -makes normally uncachable response | | | later than thisUpdate but earlier than |
| | cachable by both shared and nonshared caches. | | | nextUpdate. |
| | * no-transform -specifies that a proxy cache | | | |
| | cannot change the type, length, or encoding of | | | * public - makes normally uncachable response |
| | the object content. | | | cachable by both shared and nonshared caches. |
| | * must-revalidate -prevents caches from | | | |
| | intentionally returning stale responses. | | | * no-transform - specifies that a proxy cache |
+---------------+--------------------------------------------------+ | | cannot change the type, length, or encoding |
| | of the object content. |
| | |
| | * must-revalidate - prevents caches from |
| | intentionally returning stale responses. |
+---------------+---------------------------------------------------+
Table 1: HTTP Header Fields Table 1: HTTP Header Fields
OCSP responders MUST NOT include a "Pragma: no-cache", "Cache- OCSP responders MUST NOT include the "Pragma: no-cache", "Cache-
Control: no-cache", or "Cache-Control: no-store" HTTP header fields Control: no-cache", or "Cache-Control: no-store" HTTP header fields
in authoritative OCSP responses. in authoritative OCSP responses.
OCSP responders SHOULD include one or more of these HTTP header OCSP responders SHOULD include one or more of these HTTP header
fields in non- authoritative OCSP responses. fields in non-authoritative OCSP responses.
For example, assume that an OCSP response has the following timestamp For example, assume that an OCSP response has the following timestamp
values: values:
thisUpdate = March 19, 2023 01:00:00 GMT thisUpdate = March 19, 2023 01:00:00 GMT
nextUpdate = March 21, 2023 01:00:00 GMT nextUpdate = March 21, 2023 01:00:00 GMT
productedAt = March 19, 2023 01:00:00 GMT productedAt = March 19, 2023 01:00:00 GMT
and that an OCSP client requests the response on March 20, 2023 and that an OCSP client requests the response on March 20, 2023
01:00:00 GMT. In this scenario, the HTTP response may look like 01:00:00 GMT. In this scenario, the HTTP response may look like
skipping to change at page 15, line 30 skipping to change at line 636
Content-Length: 1000 Content-Length: 1000
Date: Mon, 20 Mar 2023 01:00:00 GMT Date: Mon, 20 Mar 2023 01:00:00 GMT
Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT
ETag: "97df3588b5a3f24babc3851b372f0ba7 ETag: "97df3588b5a3f24babc3851b372f0ba7
1a9dcdded43b14b9d06961bfc1707d9d" 1a9dcdded43b14b9d06961bfc1707d9d"
Expires: Tue, 21 Mar 2023 01:00:00 GMT Expires: Tue, 21 Mar 2023 01:00:00 GMT
Cache-Control: max-age=86000,public,no-transform,must-revalidate Cache-Control: max-age=86000,public,no-transform,must-revalidate
<...> <...>
OCSP clients MUST NOT include a no-cache HTTP header field in OCSP OCSP clients MUST NOT include a no-cache HTTP header field in OCSP
request messages, unless the client encounters an expired response request messages, unless the client encounters an expired response,
which may be a result of an intermediate proxy caching stale data. which may be a result of an intermediate proxy caching stale data.
In this situation, clients SHOULD resend the request specifying that In this situation, clients SHOULD resend the request specifying that
proxies should be bypassed by including an appropriate HTTP header proxies should be bypassed by including an appropriate HTTP header
field in the request (i.e., Pragma: no-cache or Cache-Control: no- field in the request (i.e., Pragma: no-cache or Cache-Control: no-
cache). cache).
7.3. Caching at Servers 7.3. Caching at Servers
In some scenarios, it is advantageous to include OCSP response In some scenarios, it is advantageous to include OCSP response
information within the protocol being utilized between the client and information within the protocol being utilized between the client and
skipping to change at page 16, line 10 skipping to change at line 665
to establish a new HTTP session with the OCSP responder. to establish a new HTTP session with the OCSP responder.
Third, it reduces the number of round trips the client needs to make Third, it reduces the number of round trips the client needs to make
in order to complete a handshake. in order to complete a handshake.
Fourth, it simplifies the client-side OCSP implementation by enabling Fourth, it simplifies the client-side OCSP implementation by enabling
a situation where the client need only the ability to parse and a situation where the client need only the ability to parse and
recognize OCSP responses. recognize OCSP responses.
This functionality has been specified as an extension to the TLS This functionality has been specified as an extension to the TLS
[I-D.ietf-tls-rfc8446bis] protocol in Section 4.4.2 of protocol [RFC9846] in Section 4.4.2 of [RFC9846] but can be applied
[I-D.ietf-tls-rfc8446bis], but can be applied to any client-server to any client-server protocol.
protocol.
This profile RECOMMENDS that both TLS clients and servers implement It is RECOMMENDED by this profile that both TLS clients and servers
the certificate status request extension mechanism for TLS. implement the certificate status request extension mechanism for TLS.
Further information regarding caching issues can be obtained from Further information regarding caching issues can be obtained from
[RFC3143]. [RFC3143].
8. Security Considerations 8. Security Considerations
The following considerations apply in addition to the security The following considerations apply in addition to the security
considerations addressed in Section 5 of [RFC6960]. considerations addressed in Section 5 of [RFC6960].
8.1. Replay Attacks 8.1. Replay Attacks
Because the use of nonces in this profile is optional, there is a Because the use of nonces in this profile is optional, there is a
possibility that an out of date OCSP response could be replayed, thus possibility that an out-of-date OCSP response could be replayed, thus
causing a client to accept a good response when in fact there is a causing a client to accept a good response when in fact there is a
more up-to-date response that specifies the status of revoked. In more up-to-date response that specifies the status of "revoked". In
order to mitigate this attack, clients MUST have access to an order to mitigate this attack, clients MUST have access to an
accurate source of time and ensure that the OCSP responses they accurate source of time and ensure that the OCSP responses they
receive are sufficiently fresh. receive are sufficiently fresh.
Clients that do not have an accurate source of date and time are Clients that do not have an accurate source of date and time are
vulnerable to service disruption. For example, a client with a vulnerable to service disruption. For example, a client with a
sufficiently fast clock may reject a fresh OCSP response. Similarly sufficiently fast clock may reject a fresh OCSP response. Similarly,
a client with a sufficiently slow clock may incorrectly accept a client with a sufficiently slow clock may incorrectly accept
expired valid responses for certificates that may in fact be revoked. expired valid responses for certificates that may in fact be revoked.
Future versions of the OCSP protocol may provide a way for the client Future versions of the OCSP protocol may provide a way for the client
to know whether the responder supports nonces or does not support to know whether the responder supports nonces or does not support
nonces. If a client can determine that the responder supports nonces. If a client can determine that the responder supports
nonces, it MUST reject a reply that does not contain an expected nonces, it MUST reject a reply that does not contain an expected
nonce. Otherwise, clients that opt to include a nonce in the request nonce. Otherwise, clients that opt to include a nonce in the request
SHOULD NOT reject a corresponding OCSPResponse solely on the basis of SHOULD NOT reject a corresponding OCSPResponse solely on the basis of
the nonexistent expected nonce, but MUST fall back to validating the the nonexistent expected nonce but MUST fall back to validating the
OCSPResponse based on time. OCSPResponse based on time.
8.2. Man-in-the-Middle Attacks 8.2. Man-in-the-Middle Attacks
To mitigate risk associated with this class of attack, the client To mitigate risk associated with this class of attack, the client
MUST properly validate the signature on the response. MUST properly validate the signature on the response.
The use of signed responses in OCSP serves to authenticate the The use of signed responses in OCSP serves to authenticate the
identity of the OCSP responder and to verify that it is authorized to identity of the OCSP responder and to verify that it is authorized to
sign responses on the CA's behalf. sign responses on the CA's behalf.
skipping to change at page 17, line 39 skipping to change at line 738
of-service attacks. As this profile specifies the use of unsigned of-service attacks. As this profile specifies the use of unsigned
OCSPRequests, access to the responder may be implicitly given to OCSPRequests, access to the responder may be implicitly given to
everyone who can send a request to a responder, and thus the ability everyone who can send a request to a responder, and thus the ability
to mount a denial-of-service attack via a flood of requests may be to mount a denial-of-service attack via a flood of requests may be
greater. For example, a responder could limit the rate of incoming greater. For example, a responder could limit the rate of incoming
requests from a particular IP address if questionable behavior is requests from a particular IP address if questionable behavior is
detected. detected.
8.5. Modification of HTTP Header Fields 8.5. Modification of HTTP Header Fields
Values included in HTTP header fields, as described in Section 6 and Values included in HTTP header fields, as described in Sections 6 and
Section 7, are not cryptographically protected; they may be 7, are not cryptographically protected; they may be manipulated by an
manipulated by an attacker. Clients SHOULD use these values for attacker. Clients SHOULD use these values for caching guidance only
caching guidance only and ultimately SHOULD rely only on the values and ultimately SHOULD rely only on the values present in the signed
present in the signed OCSPResponse Section 4.2.2.1 of [RFC6960]. OCSPResponse (Section 4.2.2.1 of [RFC6960]). Clients SHOULD NOT rely
Clients SHOULD NOT rely on cached responses beyond the nextUpdate on cached responses beyond the nextUpdate time.
time.
8.6. Request Authentication and Authorization 8.6. Request Authentication and Authorization
The suggested use of unsigned requests in this environment removes an The suggested use of unsigned requests in this environment removes an
option that allows the responder to determine the authenticity of option that allows the responder to determine the authenticity of
incoming request. Thus, access to the responder may be implicitly incoming requests. Thus, access to the responder may be implicitly
given to everyone who can send a request to a responder. given to everyone who can send a request to a responder.
Environments where explicit authorization to access the OCSP Environments where explicit authorization to access the OCSP
responder is necessary can utilize other mechanisms to authenticate responder is necessary can utilize other mechanisms to authenticate
requestors or restrict or meter service. requestors or restrict or meter service.
8.7. Use of SHA-1 for the calculation of CertID field values 8.7. Use of SHA-1 for the Calculation of CertID Field Values
Although the use of SHA-1 for the calculation of CertID field values Although the use of SHA-1 for the calculation of CertID field values
is not of concern from a cryptographic security standpoint, the is not of concern from a cryptographic security standpoint, the
continued use of SHA-1 in an ecosystem requires that software that continued use of SHA-1 in an ecosystem requires that software that
interoperates with the ecosystem maintain support for SHA-1. This interoperates with the ecosystem maintain support for SHA-1. This
increases implementation complexity and potential attack surface for increases implementation complexity and potential attack surface for
the software in question. Thus, the continued use of SHA-1 in an the software in question. Thus, the continued use of SHA-1 in an
ecosystem to maintain interoperability with legacy software must be ecosystem to maintain interoperability with legacy software must be
weighed against the increased implementation complexity and potential weighed against the increased implementation complexity and potential
attack surface. attack surface.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-tls-rfc8446bis]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-10, 3 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-10>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online
Certificate Status Protocol (OCSP) Profile for High-Volume Certificate Status Protocol (OCSP) Profile for High-Volume
Environments", RFC 5019, DOI 10.17487/RFC5019, September Environments", RFC 5019, DOI 10.17487/RFC5019, September
2007, <https://www.rfc-editor.org/rfc/rfc5019>. 2007, <https://www.rfc-editor.org/info/rfc5019>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <https://www.rfc-editor.org/rfc/rfc5754>. 2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/rfc/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111, Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022, DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>. <https://www.rfc-editor.org/info/rfc9111>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, January
2026, <https://www.rfc-editor.org/info/rfc9846>.
10.2. Informative References 10.2. Informative References
[OCSPMP] Open Mobile Alliance, "OCSP Mobile Profile V1.0", [OCSPMP] Open Mobile Alliance, "OCSP Mobile Profile V1.0",
www.openmobilealliance.org . <https://www.openmobilealliance.org>.
[RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching [RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching
Problems", RFC 3143, DOI 10.17487/RFC3143, June 2001, Problems", RFC 3143, DOI 10.17487/RFC3143, June 2001,
<https://www.rfc-editor.org/rfc/rfc3143>. <https://www.rfc-editor.org/info/rfc3143>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<https://www.rfc-editor.org/rfc/rfc3174>. <https://www.rfc-editor.org/info/rfc3174>.
[RFC9500] Gutmann, P. and C. Bonnell, "Standard Public Key [RFC9500] Gutmann, P. and C. Bonnell, "Standard Public Key
Cryptography (PKC) Test Keys", RFC 9500, Cryptography (PKC) Test Keys", RFC 9500,
DOI 10.17487/RFC9500, December 2023, DOI 10.17487/RFC9500, December 2023,
<https://www.rfc-editor.org/rfc/rfc9500>. <https://www.rfc-editor.org/info/rfc9500>.
Appendix A. Differences from RFC 5019 Appendix A. Differences from RFC 5019
This document obsoletes [RFC5019]. [RFC5019] defines a lightweight This document obsoletes [RFC5019]. [RFC5019] defines a lightweight
profile for OCSP that makes the protocol more suitable for use in profile for OCSP that makes the protocol more suitable for use in
high-volume environments. The lightweight profile specifies the high-volume environments. The lightweight profile specifies the
mandatory use of SHA-1 when calculating the values of several fields mandatory use of SHA-1 when calculating the values of several fields
in OCSP requests and responses. In recent years, weaknesses have in OCSP requests and responses. In recent years, weaknesses have
been demonstrated with the SHA-1 algorithm. As a result, SHA-1 is been demonstrated with the SHA-1 algorithm. As a result, SHA-1 is
increasingly falling out of use even for non-security relevant use increasingly falling out of use even for non-security-relevant use
cases. This document obsoletes the lightweight profile as specified cases. This document obsoletes the lightweight profile as specified
in RFC 5019 to instead recommend the use of SHA-256 where SHA-1 was in [RFC5019] to instead recommend the use of SHA-256 where SHA-1 was
previously required. An [RFC5019]-compliant OCSP client is still previously required. An OCSP client compliant with [RFC5019] is
able to use SHA-1, but the use of SHA-1 may become obsolete in the still able to use SHA-1, but the use of SHA-1 may become obsolete in
future. the future.
Substantive changes to RFC 5019: Substantive changes to RFC 5019:
* Section 3.1.1 requires new OCSP clients to use SHA-256 to support * Section 3.1.1 requires new OCSP clients to use SHA-256 to support
migration for OCSP clients. migration for OCSP clients.
* Section 3.2.2 requires new OCSP responders to use the byKey field, * Section 3.2.2 requires new OCSP responders to use the byKey field
and support migration from byName fields. and support migration from byName fields.
* Section 6 clarifies that OCSP clients MUST NOT include whitespace * Section 6 clarifies that OCSP clients MUST NOT include whitespace
or any other characters that are not part of the base64 character or any other characters that are not part of the base64 character
repertoire in the base64-encoded string. repertoire in the base64-encoded string.
Appendix B. Examples Appendix B. Examples
B.1. Root Certification Authority Certificate B.1. Root Certification Authority Certificate
This is a self-signed certificate for the certification authority This is a self-signed certificate for the certification authority
that issued the end-entity certificate and OCSP delegated responder that issued the end-entity certificate and OCSP-delegated responder
example certificates below. example certificates below.
The key pair for the certification authority is the "testECCP521" key The key pair for the certification authority is the "testECCP521" key
from Section 2.3 of [RFC9500]. from Section 2.3 of [RFC9500].
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG
A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy
MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL
Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF
skipping to change at page 23, line 43 skipping to change at line 1019
488 66: INTEGER 488 66: INTEGER
: 00 A8 67 86 C7 B5 EE 97 90 59 BB 85 45 DA B1 C2 : 00 A8 67 86 C7 B5 EE 97 90 59 BB 85 45 DA B1 C2
: CD EE F9 2F EE A2 B0 5F 24 EC 0A F2 03 A4 40 D3 : CD EE F9 2F EE A2 B0 5F 24 EC 0A F2 03 A4 40 D3
: 44 25 FC 75 41 5E EF 78 C6 79 B8 AD 92 E9 91 1E : 44 25 FC 75 41 5E EF 78 C6 79 B8 AD 92 E9 91 1E
: 35 61 94 12 4B A3 B9 F7 14 C2 6B 14 73 68 79 B9 : 35 61 94 12 4B A3 B9 F7 14 C2 6B 14 73 68 79 B9
: 4C 6F : 4C 6F
: } : }
: } : }
: } : }
B.2. End-entity Certificate B.2. End-Entity Certificate
This is an end-entity certificate whose status is requested and This is an end-entity certificate whose status is requested and
returned in the OCSP request and response examples below. returned in the OCSP request and response examples below.
The key pair for the end-entity certificate is the "testECCP256" key The key pair for the end-entity certificate is the "testECCP256" key
from Section 2.3 of [RFC9500]. from Section 2.3 of [RFC9500].
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIB2zCCATygAwIBAgIEAarwDTAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEU MIIB2zCCATygAwIBAgIEAarwDTAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEU
MBIGA1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQw MBIGA1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQw
skipping to change at page 26, line 28 skipping to change at line 1146
: B6 7A 08 A1 B6 4F F9 E4 CB 35 69 06 50 52 FA B8 : B6 7A 08 A1 B6 4F F9 E4 CB 35 69 06 50 52 FA B8
: 2B 4B B5 09 98 B6 B5 E9 2C 02 5F BE 41 3A 59 85 : 2B 4B B5 09 98 B6 B5 E9 2C 02 5F BE 41 3A 59 85
: 6A 09 49 78 F7 92 B1 F6 5E 8C F5 30 4B 2B 95 FA : 6A 09 49 78 F7 92 B1 F6 5E 8C F5 30 4B 2B 95 FA
: 57 7C : 57 7C
: } : }
: } : }
: } : }
B.3. OCSP Responder Certificate B.3. OCSP Responder Certificate
This is a certificate for the OCSP delegated response that signed the This is a certificate for the OCSP-delegated response that signed the
OCSP response example below. OCSP response example below.
The key pair for the OCSP Responder certificate is the "testECCP384" The key pair for the OCSP responder certificate is the "testECCP384"
key from Section 2.3 of [RFC9500]. key from Section 2.3 of [RFC9500].
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIICSzCCAa6gAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG MIICSzCCAa6gAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG
A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy
MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA8MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA8MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL
Q2VydHMgJ3IgVXMxFzAVBgNVBAMMDk9DU1AgUmVzcG9uZGVyMHYwEAYHKoZIzj0C Q2VydHMgJ3IgVXMxFzAVBgNVBAMMDk9DU1AgUmVzcG9uZGVyMHYwEAYHKoZIzj0C
AQYFK4EEACIDYgAEWwkBuIUjKW65GdUP+hqcs3S8TUCVhigr/soRsdla27VHNK9X AQYFK4EEACIDYgAEWwkBuIUjKW65GdUP+hqcs3S8TUCVhigr/soRsdla27VHNK9X
C/grcijPImvPTCXdvP47GjrTlDDv92Ph1o0uFR2Rcgt3lbWNprNGOWE6j7m1qNpI C/grcijPImvPTCXdvP47GjrTlDDv92Ph1o0uFR2Rcgt3lbWNprNGOWE6j7m1qNpI
xnRxF/mRnoQk837Io4GHMIGEMB0GA1UdDgQWBBQK46D+ndQldpi163Lrygznvz31 xnRxF/mRnoQk837Io4GHMIGEMB0GA1UdDgQWBBQK46D+ndQldpi163Lrygznvz31
skipping to change at page 36, line 18 skipping to change at line 1595
and Ryan Hurst for their work to produce the original version of the and Ryan Hurst for their work to produce the original version of the
lightweight profile for the OCSP protocol. lightweight profile for the OCSP protocol.
The authors of this version of the document wish to thank Paul The authors of this version of the document wish to thank Paul
Kyzivat, Russ Housley, Rob Stradling, Roman Danyliw, and Wendy Brown Kyzivat, Russ Housley, Rob Stradling, Roman Danyliw, and Wendy Brown
for their reviews, feedback, and suggestions. for their reviews, feedback, and suggestions.
The authors wish to thank Magnus Nystrom of RSA Security, Inc., The authors wish to thank Magnus Nystrom of RSA Security, Inc.,
Jagjeet Sondh of Vodafone Group R&D, and David Engberg of CoreStreet, Jagjeet Sondh of Vodafone Group R&D, and David Engberg of CoreStreet,
Ltd. for their contributions to the original [RFC5019] specification. Ltd. for their contributions to the original [RFC5019] specification.
Listed organizational affiliations reflect the author’s affiliation Listed organizational affiliations reflect the authors' affiliations
at the time of RFC5019 was published. at the time RFC 5019 was published.
Authors' Addresses Authors' Addresses
Tadahiko Ito Tadahiko Ito
SECOM CO., LTD. SECOM CO., LTD.
Email: tadahiko.ito.public@gmail.com Email: tadahiko.ito.public@gmail.com
Additional contact information: Additional contact information:
伊藤 忠彦 伊藤 忠彦
 End of changes. 76 change blocks. 
235 lines changed or deleted 229 lines changed or added

This html diff was produced by rfcdiff 1.48.