<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3.3) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-rfc5019bis-12" number="9919" category="std" consensus="true" submissionType="IETF" updates="" obsoletes="5019" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.23.0 -->version="3" xml:lang="en"> <front> <!--[rfced] Please note the title of the document has been updated as follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review. Original: Updates to Lightweight OCSP Profile for High Volume Environments Current: Updates to the Lightweight Online Certificate Status Protocol (OCSP) Profile for High Volume Environments Because this document will obsolete RFC 5019 (rather than update it), we suggest changing the title and abbreviated title as follows. Is this acceptable? Original: Updates to Lightweight OCSP Profile for High Volume Environments Perhaps (same title as RFC 5019): The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments Similarly, may the abbreviated title (which appears in the running header of the PDF) be updated as follows? Original: Lightweight OCSP Profile Update Perhaps: Lightweight OCSP Profile --> <title abbrev="Lightweight OCSP Profile Update">Updates to the LightweightOCSPOnline Certificate Status Protocol (OCSP) Profile for High Volume Environments</title> <seriesInfoname="Internet-Draft" value="draft-ietf-lamps-rfc5019bis-12"/>name="RFC" value="9919"/> <author fullname="伊藤 忠彦" asciiFullname="Tadahiko Ito"> <organization>SECOM CO., LTD.</organization> <address> <email>tadahiko.ito.public@gmail.com</email> </address> </author> <author fullname="Clint Wilson"> <organization>Apple, Inc.</organization> <address> <email>clintw@apple.com</email> </address> </author> <author fullname="Corey Bonnell"> <organization>DigiCert, Inc.</organization> <address> <email>corey.bonnell@digicert.com</email> </address> </author> <author fullname="Sean Turner"> <organization>sn3rd</organization> <address> <email>sean@sn3rd.com</email> </address> </author> <dateyear="2024" month="September" day="13"/> <keyword>Internet-Draft</keyword>year="2026" month="January"/> <area>SEC</area> <workgroup>lamps</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><?line 48?><t>This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing.</t> <t>This specification obsoletes RFC 5019. The profile specified in RFC 5019 has been updated to allow and recommend the use of SHA-256 over SHA-1.</t> </abstract><note removeInRFC="true"> <name>Discussion Venues</name> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/tadahik/RFC5019bis"/>.</t> </note></front> <middle><?line 62?><section anchor="introduction"> <name>Introduction</name> <t>The Online Certificate Status Protocol <xref target="RFC6960"/> specifies a mechanism used to determine the status of digital certificates, in lieu of using Certificate Revocation Lists (CRLs). Since its definition in 1999, it has been deployed in a variety of environments and has proven to be a useful certificate status checking mechanism. (For brevity, the term "OCSP" is used herein to denote the verification of certificate status; however, it should be noted that this protocol is employed solely to ascertain the revocation status of a certificate.)</t> <t>To date, numerous OCSP deployments have been implemented to provide timely and secure certificate status information, crucial for high-value electronic transactions and the handling of highly sensitive information, such as within the banking and financial sectors. Therefore, the requirement for an OCSP responder to respond in "real time" (i.e., generating a new OCSP response for each OCSP request) has been important. In addition, these deployments have operated in environments where bandwidth usage is not anissue,issue and have run on client and server systems where processing power is not constrained.</t> <t>As the use of PKI continues to grow and move into diverse environments, so does the need for a scalable and cost-effective certificate status mechanism. Although OCSP as currently defined and 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 OCSP deployments scale from both an efficiency and cost perspective. Mobile environments, where network bandwidth may be at a premium and client-side devices are constrained from a processing point of view, require the careful use of OCSP to minimize bandwidth usage and client-side processingcomplexity.complexity <xreftarget="OCSPMP"/></t>target="OCSPMP"/>.</t> <t>PKI continues to be deployed into environments where millions if not hundreds of millions of certificates have been issued. In many of these environments, an even larger number of users (also known as relying parties) have the need to ensure that the certificate they 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 and the network infrastructure required to host those responders are kept to a minimum.</t> <t>This document addresses the scalability issues inherent when using OCSP in highly scaled PKI environments by defining a message profile and clarifying OCSP client and responder behavior that will permit:</t> <ol spacing="normal"type="1"><li>type="1"> <li> <t>OCSP response pre-production and distribution.</t> </li> <li> <t>Reduced OCSP message size to lower bandwidth usage.</t> </li> <li> <t>Response message caching both in the network and on the client.</t> </li> </ol> <t>It is intended that the normative requirements defined in this profile will be adopted by OCSP clients and OCSP responders operating in very large-scale (high-volume) PKI environments or PKI environments that require a lightweight solution to minimize bandwidth and client-side processing power (or both), as described above.</t> <t>OCSP does not have the means to signal responder capabilities within the protocol. Thus, clients may need to use out-of-band mechanisms (e.g., agreed upon arrangements between operators of OCSP responders and OCSP clients) to determine whether a responder conforms to the profile defined in this document. Regardless of the availability of such out-of-band mechanisms, this profile ensures that interoperability will still occur between an OCSP client that fully conforms with <xref target="RFC6960"/> and a responder that is operating in a mode as described in this specification.</t> </section> <section anchor="conventions-and-definitions"><name>Conventions and Definitions</name> <t>The<name>Conventions</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <section anchor="ocsp-message-profile"> <name>OCSP Message Profile</name> <t>This section defines a subset of OCSPRequest and OCSPResponse functionality as defined in <xref target="RFC6960"/>.</t> <section anchor="req-profile"> <name>OCSP Request Profile</name> <section anchor="certid"> <name>OCSPRequest Structure</name><t>Provided for convenience here, a<t>A partial extract of the ASN.1 structure corresponding to the OCSPRequest with the relevant CertID as defined in <xreftarget="RFC6960"/>:</t> <artwork><![CDATA[target="RFC6960"/> is provided here for convenience:</t> <sourcecode type="asn.1"><![CDATA[ OCSPRequest ::= SEQUENCE { tbsRequest TBSRequest, optionalSignature [0] EXPLICIT Signature OPTIONAL } TBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, requestList SEQUENCE OF Request, requestExtensions [2] EXPLICIT Extensions OPTIONAL } Request ::= SEQUENCE { reqCert CertID, singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of issuer's DN issuerKeyHash OCTET STRING, -- Hash of issuer's public key serialNumber CertificateSerialNumber }]]></artwork>]]></sourcecode> <t>OCSPRequests that conform to the profile in this document <bcp14>MUST</bcp14> include only one Request in the OCSPRequest.RequestList structure.</t> <t>The CertID.issuerNameHash and CertID.issuerKeyHash fields contain hashes of the issuer's distinguished name (DN) and public key, respectively. OCSP clients that conform with this profile <bcp14>MUST</bcp14> useSHA-256SHA-256, as defined in <xref section="2.2" sectionFormat="of"target="RFC5754"/>target="RFC5754"/>, as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values.</t> <t>Older OCSP clientswhichthat provide backward compatibility with <xref target="RFC5019"/> useSHA-1SHA-1, as defined in <xreftarget="RFC3174"/>target="RFC3174"/>, as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values. However, these OCSP clients <bcp14>MUST</bcp14> transition from SHA-1 to SHA-256 as soon as practical.</t> <t>Clients <bcp14>MUST NOT</bcp14> include the singleRequestExtensions structure.</t> <!--[rfced] FYI, we changed "RECOMMENDS" to "is RECOMMENDED by" (2 instances), as "RECOMMENDED" is the defined keyword from BCP 14. This update allows using the <bcp14> element without warnings. We realize the original text matches RFC 5019. For example: Original: Clients SHOULD NOT include the requestExtensions structure. If a requestExtensions structure is included, this profile RECOMMENDS that it contain only the nonce extension (id-pkix-ocsp-nonce). Current: Clients SHOULD NOT include the requestExtensions structure. If a requestExtensions structure is included, it is RECOMMENDED by this profile that the structure contain only the nonce extension (id-pkix- ocsp-nonce). --> <t>Clients <bcp14>SHOULD NOT</bcp14> include the requestExtensions structure. If a requestExtensions structure is included, it is <bcp14>RECOMMENDED</bcp14> by this profileRECOMMENDSthatitthe structure contain only the nonce extension (id-pkix-ocsp-nonce). See <xref target="fresh"/> for issues concerning the use of a nonce in high-volume OCSP environments.</t> </section> <section anchor="signed-ocsprequests"> <name>Signed OCSPRequests</name> <t>Clients <bcp14>SHOULD NOT</bcp14> send signed OCSPRequests. Responders <bcp14>MAY</bcp14> ignore the signature on OCSPRequests.</t> <t>If the OCSPRequest is signed, the client <bcp14>SHALL</bcp14> specify its name in the OCSPRequest.requestorName field; otherwise, clients <bcp14>SHOULD NOT</bcp14> include the requestorName field in the OCSPRequest. OCSP responders <bcp14>MUST</bcp14> handle unsigned OCSP requests that contain the requestorName field, as if the requestorName field were absent.</t> </section> </section> <section anchor="ocsp-response-profile"> <name>OCSP Response Profile</name> <section anchor="ocspresponse-structure"> <name>OCSPResponse Structure</name><t>Provided for convenience here, a<t>A partial extract of the ASN.1 structure corresponding to the OCSPResponse with the relevant CertID as defined in <xreftarget="RFC6960"/>:</t> <artwork><![CDATA[target="RFC6960"/> is provided here for convenience:</t> <!--[rfced] Is this line within the sourcecode in Section 3.2.1 intended to be a comment within the sourcecode, or should it be taken out of the sourcecode? (Note: This line exceeded the 72-character limit so we included a line break within the sourcecode.) Original: The value for response SHALL be the DER encoding of BasicOCSPResponse. --> <sourcecode type="asn.1"><![CDATA[ OCSPResponse ::= SEQUENCE { responseStatus OCSPResponseStatus, responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } ResponseBytes ::= SEQUENCE { responseType OBJECT IDENTIFIER, response OCTET STRING } The value for response SHALL be the DER encoding of BasicOCSPResponse. BasicOCSPResponse ::= SEQUENCE { tbsResponseData ResponseData, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } ResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, responderID ResponderID, producedAt GeneralizedTime, responses SEQUENCE OF SingleResponse, responseExtensions [1] EXPLICIT Extensions OPTIONAL } SingleResponse ::= SEQUENCE { certID CertID, certStatus CertStatus, thisUpdate GeneralizedTime, nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, singleExtensions [1] EXPLICIT Extensions OPTIONAL }]]></artwork>]]></sourcecode> <t>Responders <bcp14>MUST</bcp14> generate a BasicOCSPResponse as identified by the id-pkix-ocsp-basic OID. Clients <bcp14>MUST</bcp14> be able to parse and accept a BasicOCSPResponse. OCSPResponses that conform to this profile <bcp14>SHOULD</bcp14> include only one SingleResponse in the ResponseData.responsesstructure,structure but <bcp14>MAY</bcp14> include additional SingleResponse elements if necessary to improve response pre-generation performance or cacheefficiency,efficiency and to ensure backward compatibility. For instance, to provide support to OCSP clientswhichthat do not yet support the use of SHA-256 for CertID hash calculation, the OCSP responder <bcp14>MAY</bcp14> include two SingleResponses in a BasicOCSPResponse. In that BasicOCSPResponse, the CertID of one of the SingleResponses uses SHA-1 for the hash calculation, and the CertID in the other SingleResponse uses SHA-256. OCSP responders <bcp14>SHOULD NOT</bcp14> distribute 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 OCSP responders may consider logging the hash algorithm used by OCSP clients to inform their determination of when it is appropriate to obsolete the distribution of OCSP responses that employ SHA-1 for CertID field hashes. See <xref target="sha1-sec"/> for more information on the security considerations for the continued use of SHA-1.</t> <t>The responder <bcp14>SHOULD NOT</bcp14> include responseExtensions. As specified in <xref target="RFC6960"/>, clients <bcp14>MUST</bcp14> ignore unrecognized non-critical responseExtensions in the response.</t> <t>In the case where a responder does not have the ability to respond to an OCSP request containing an option not supported by the responder, it <bcp14>SHOULD</bcp14> return the most complete response it can. For example, in the case where a responder only supports pre-produced responses and does not have the ability to respond to an OCSP request containing a nonce, it <bcp14>SHOULD</bcp14> return a response that does not include a nonce.</t> <t>Clients <bcp14>SHOULD</bcp14> attempt to process a response even if the response does not include a nonce. See <xref target="fresh"/> for details on validating responses that do not contain a nonce. See also <xref target="sec-cons"/> for relevant security considerations.</t> <t>Responders that do not have the ability to respond to OCSP requests that contain an unsupported option such as a nonce <bcp14>MAY</bcp14> forward the request to an OCSP responder capable of doing so.</t> <t>The responder <bcp14>MAY</bcp14> include the singleResponse.singleResponse extensions structure.</t> </section> <section anchor="byKey"> <name>Signed OCSPResponses</name> <t>Clients <bcp14>MUST</bcp14> validate the signature on the OCSPResponse.</t> <t>If the response is signed by a delegate of the issuing certification authority (CA), a valid responder certificate <bcp14>MUST</bcp14> be referenced in the BasicOCSPResponse.certs structure.</t> <t>It is <bcp14>RECOMMENDED</bcp14> that the OCSP responder's certificate contain the id-pkix-ocsp-nocheck extension, as defined in <xref target="RFC6960"/>, to indicate to the client that it need not check the certificate's status. In addition, it is <bcp14>RECOMMENDED</bcp14> that neither an OCSP authorityInfoAccess (AIA) extension nor cRLDistributionPoints (CRLDP) extension be included in the OCSP responder's certificate. Accordingly, the responder's signing certificate <bcp14>SHOULD</bcp14> be relatively short-lived and renewed regularly.</t> <t>Clients <bcp14>MUST</bcp14> be able to identify OCSP responder certificates using the byKey field and <bcp14>SHOULD</bcp14> be able to identify OCSP responder certificates using the byName field of the ResponseData.ResponderID <xref target="RFC6960"/> choices.</t><t>Older<!--[rfced] May we update this sentence as follows to clarify that the protocol in [RFC5019] is backward compatible, rather than the RFC itself? Original: Older responders which provide backward compatibility with [RFC5019] MAY use the byName field to represent the ResponderID, but should transition to using the byKey field as soon as practical. Perhaps: Older responders that provide backward compatibility with the protocol defined in [RFC5019] MAY use the byName field to represent the ResponderID but should transition to using the byKey field as soon as practical. --> <t>Older responders that provide backward compatibility with <xref target="RFC5019"/> <bcp14>MAY</bcp14> use the byName field to represent theResponderID,ResponderID but should transition to using the byKey field as soon as practical.</t> <t>Newer responders that conform to this profile <bcp14>MUST</bcp14> use the byKey field to represent the ResponderID to reduce the size of the response.</t> </section> <section anchor="ocspresponsestatus-values"> <name>OCSPResponseStatus Values</name> <t>As long as the OCSP infrastructure has authoritative records for a particular certificate, an OCSPResponseStatus of "successful" will be returned. When access to authoritative records for a particular certificate is not available, the responder <bcp14>MUST</bcp14> return an OCSPResponseStatus of "unauthorized". As such, this profile extends the <xref target="RFC6960"/> definition of "unauthorized" as follows:</t> <t>The response "unauthorized" is returned in cases where the client is not authorized to make this query to this responder or the responder is not capable of responding authoritatively.</t> <t>For example, OCSP responders that do not have access to authoritative records for a requested certificate, such as those that generate and distribute OCSP responses in advance and thus do not have the ability to properly respond with a signed "successful" yet "unknown" response, will respond with an OCSPResponseStatus of "unauthorized". Also, in order to ensure the database of revocation information does not grow unbounded over time, the responder <bcp14>MAY</bcp14> remove the status records of expired certificates. Requests from clients for certificates whose record has been removed will result in an OCSPResponseStatus of "unauthorized".</t> <t>Security considerations regarding the use of unsigned responses are discussed in <xref target="RFC6960"/>.</t> </section> <section anchor="times"> <name>thisUpdate, nextUpdate, and producedAt</name> <t>When pre-producing OCSPResponse messages, the responder <bcp14>MUST</bcp14> set the thisUpdate, nextUpdate, and producedAt times as follows:</t> <dl> <dt>thisUpdate:</dt> <dd> <t>The time at which the status being indicated is known to be correct.</t> </dd> <dt>nextUpdate:</dt> <dd> <t>The time at or before which newer information will be available about the status of the certificate. As described in <xref section="2.4" sectionFormat="of" target="RFC6960"/>, this field is optional. However, this field <bcp14>MUST</bcp14> be included in the profile specified in this document to help clients cache responses. See <xref target="cache-recs"/> for additional information on caching.</t> </dd> <dt>producedAt:</dt> <dd> <t>The time at which the OCSP response was signed.</t> </dd> </dl> <aside> <t>Note: The values of thisUpdate, nextUpdate, and producedAt are set as described in <xref section="2.5" sectionFormat="of" target="RFC6960"/>, and in manycasescases, the value of thisUpdate and producedAt are the same.</t> </aside> <t>For the purposes of this profile, ASN.1-encoded GeneralizedTimevaluesvalues, such as thisUpdate, nextUpdate, andproducedAtproducedAt, <bcp14>MUST</bcp14> be expressed Greenwich Mean Time (Zulu) and <bcp14>MUST</bcp14> include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values <bcp14>MUST NOT</bcp14> include fractional seconds.</t> </section> </section> </section> <section anchor="client-behavior"> <name>Client Behavior</name> <section anchor="ocsp-responder-discovery"> <name>OCSP Responder Discovery</name> <t>Clients <bcp14>MUST</bcp14> support the authorityInfoAccess extension as defined in <xref target="RFC5280"/> and <bcp14>MUST</bcp14> recognize the id-ad-ocsp access method. This enables CAs to inform clients how they can contact the OCSP service.</t> <t>In the case where a client is checking the status of a certificate that contains both an authorityInformationAccess (AIA) extension pointing to an OCSP responder and a cRLDistributionPoints extension pointing to a CRL, the client <bcp14>SHOULD</bcp14> attempt to contact the OCSP responder first. Clients <bcp14>MAY</bcp14> attempt to retrieve the CRL if no OCSPResponse is received from the responder after a locally configured timeout and number of retries.</t> </section> <section anchor="sending-an-ocsp-request"> <name>Sending an OCSP Request</name> <t>To avoid needless network traffic, applications <bcp14>MUST</bcp14> verify 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 invalid or the application is not able to verify it, an OCSP check <bcp14>MUST NOT</bcp14> be requested.</t> <t>Similarly, an application <bcp14>MUST</bcp14> validate the signature on certificates in achain,chain before asking an OCSP client to check the status of the certificate. If the certificate signature is invalid or the application is not able to verify it, an OCSP check <bcp14>MUST NOT</bcp14> be requested. Clients <bcp14>SHOULD NOT</bcp14> make a request to check the status of expired certificates.</t> </section> </section> <section anchor="fresh"> <name>Ensuring an OCSPResponse Is Fresh</name> <t>In order to ensure that a client does not accept an out-of-date response that indicates a'good'"good" status when in fact there is a more up-to-date response that specifies the status of'revoked',"revoked", a client must ensure the responses they receive are fresh.</t> <t>In general, two mechanisms are available to clients to ensure a 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 responders <bcp14>MUST</bcp14> have access to an accurate source of time.</t> <t>Because this profile specifies that clients <bcp14>SHOULD NOT</bcp14> include a requestExtensions structure in OCSPRequests (see <xref target="req-profile"/>), clients <bcp14>MUST</bcp14> be able to determine OCSPResponse freshness based on an accurate source of time. Clients that opt to include a nonce in the request <bcp14>SHOULD NOT</bcp14> reject a corresponding OCSPResponse solely on the basis of the nonexistent expectednonce,nonce but <bcp14>MUST</bcp14> fall back to validating the OCSPResponse based on time.</t> <t>Clients that do not include a nonce in the request <bcp14>MUST</bcp14> ignore any nonce that may be present in the response.</t> <t>Clients <bcp14>MUST</bcp14> check for the existence of the nextUpdate field and <bcp14>MUST</bcp14> ensure the current time, expressed in GMT time as described in <xref target="times"/>, falls between the thisUpdate and nextUpdate times. If the nextUpdate field is absent, the client <bcp14>MUST</bcp14> reject the response.</t> <t>If the nextUpdate field is present, the client <bcp14>MUST</bcp14> ensure that it is not earlier than the current time. If the current time on the client is later than the time specified in the nextUpdate field, the client <bcp14>MUST</bcp14> reject the response as stale. Clients <bcp14>MAY</bcp14> allow configuration of a small tolerance period for acceptance of responses after nextUpdate to handle minor clock differences relative to responders and caches. This tolerance period should be chosen based on the accuracy and precision of time synchronization technology available to the calling application environment. For example, Internet peers with low latency connections typically expect NTP time synchronization to keep them accurate within parts of a second; higher latency environments or where an NTP analogue is not available may have to be more liberal in their tolerance(e.g.(e.g., allow one day difference).</t> <t>See the security considerations in <xref target="sec-cons"/> for additional details on replay and man-in-the-middle attacks.</t> </section> <section anchor="transport"> <name>Transport Profile</name> <!--[rfced] We are having some trouble understanding how "server name and base64-encoded OCSPRequest structure" fits into the sentence below. Please review and let us know the sentence may be updated for clarity. Original: When sending requests that are less than or equal to 255 bytes in total (after encoding) including the scheme and delimiters (http://), server name and base64-encoded OCSPRequest structure, clients MUST use the GET method (to enable OCSP response caching). Perhaps: When sending requests that are less than or equal to 255 bytes in total (after encoding), including the scheme and delimiters (http://), server name, and base64-encoded OCSPRequest structure, clients MUST use the GET method (to enable OCSP response caching). --> <t>OCSP clients can send HTTP-based OCSP requests using either the GET or POST method. The OCSP responder <bcp14>MUST</bcp14> support requests and responses over HTTP. When sending requests that are less than or equal to 255 bytes in total (after encoding) including the scheme and delimiters (http://), server name and base64-encoded OCSPRequest structure, clients <bcp14>MUST</bcp14> use the GET method (to enable OCSP response caching). OCSP requests larger than 255 bytes <bcp14>SHOULD</bcp14> be submitted using the POST method. In all cases, clients <bcp14>MUST</bcp14> follow the descriptions inA.1 of<xref section="A.1" target="RFC6960"/> when constructing these messages.</t> <t>When constructing a GET message, OCSP clients <bcp14>MUST</bcp14> base64-encode the OCSPRequest structure according to <xref section="4" sectionFormat="of" target="RFC4648"/>. Clients <bcp14>MUST NOT</bcp14> include whitespace or any other characters that are not part of the base64 character repertoire in the base64-encoded string. Clients <bcp14>MUST</bcp14> properly URL-encode the base64-encoded OCSPRequest according to <xref target="RFC3986"/>. OCSP clients <bcp14>MUST</bcp14> append the base64-encoded OCSPRequest to the URI specified in the AIA extension <xref target="RFC5280"/>. For example:</t> <artwork><![CDATA[ http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL2dA deGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%3D%3D ]]></artwork> <t>In response to properly formatted OCSPRequests that are cachable (i.e., responses that contain a nextUpdate value), the responder will include the binary value of the DER encoding of the OCSPResponse preceded by the following HTTP <xref target="RFC9110"/>and<xref target="RFC9111"/> header fields.</t> <artwork><![CDATA[ Content-type: application/ocsp-response Content-length: < OCSP response length > Last-modified: < producedAt HTTP-date > ETag: "< strong validator >" Expires: < nextUpdate HTTP-date > Cache-control: max-age=< n >, public, no-transform, must-revalidate Date: < current HTTP-date > ]]></artwork> <t>See <xref target="http-proxies"/> for details on the use of these HTTP header fields.</t> </section> <section anchor="cache-recs"> <name>Caching Recommendations</name> <t>The ability to cache OCSP responses throughout the network is an important factor in high volume OCSP deployments. This section discusses the recommended caching behavior of OCSP clients and HTTP 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 including OCSP responses in protocol exchanges (aka stapling or piggybacking), such as has been defined in TLS, is also discussed.</t> <section anchor="caching-at-the-client"> <name>Caching at the Client</name> <t>To minimize bandwidth usage, clients <bcp14>MUST</bcp14> locally cache authoritative OCSP responses (i.e., a response with a signature that has been successfully validated and thatindicateindicates an OCSPResponseStatus of'successful').</t>"successful").</t> <t>Most OCSP clients will send OCSPRequests at or near the nextUpdate time (when a cached response expires). To avoid large spikes in responder load that might occur when many clients refresh cached responses for a popular certificate, responders <bcp14>MAY</bcp14> indicate when the client should fetch an updated OCSP response by using the cache- control:max-age directive. Clients <bcp14>SHOULD</bcp14> fetch the updated OCSPResponseresponse on or after the max-age time. To ensure that clients receive an updated OCSP response, OCSP responders <bcp14>MUST</bcp14> refresh the OCSP response before the max-age time.</t> </section> <section anchor="http-proxies"> <name>HTTP Proxies</name> <t>The responder <bcp14>SHOULD</bcp14> set the HTTP header fields of the OCSP response in such a way as to allow for the intelligent use of intermediate HTTP proxy servers. See <xref target="RFC9110"/> and <xref target="RFC9111"/> for the full definition of these HTTP header fields and the proper format of any date and time values.</t> <table anchor="http-headers"> <name>HTTP Header Fields</name> <thead> <tr> <th align="left">HTTP Header Field</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">Date</td> <td align="left">The date and time at which the OCSP responder generated the HTTP response.</td> </tr> <tr> <td align="left">Last-Modified</td> <td align="left">This value specifies the date and time at which the OCSP responder last modified the response. This date and time will be the same as the thisUpdate timestamp in the request itself.</td> </tr> <tr> <td align="left">Expires</td> <td align="left">Specifies how long the response is considered fresh. This date and time will be the same as the nextUpdate timestamp in the OCSP response itself.</td> </tr> <tr> <td align="left">ETag</td> <td align="left">A string that identifies a particular version of the associated data.ThisIt is <bcp14>RECOMMENDED</bcp14> by this profileRECOMMENDSthat the ETag value be the ASCII HEX representation of the SHA-256 hash of the OCSPResponse structure.</td> </tr> <tr> <td align="left">Cache-Control</td> <tdalign="left">Containsalign="left"><t>Contains a number of cachingdirectives. <br/> * max-agedirectives.</t> <ul spacing="normal"> <li>max-age = < n >-where- where n is a time value later than thisUpdate but earlier thannextUpdate. <br/> * public -makesnextUpdate.</li> <li>public - makes normally uncachable response cachable by both shared and nonsharedcaches. <br/> * no-transform -specifiescaches.</li> <li>no-transform - specifies that a proxy cache cannot change the type, length, or encoding of the objectcontent. <br/> * must-revalidate -preventscontent.</li> <li>must-revalidate - prevents caches from intentionally returning staleresponses.</td>responses.</li> </ul></td> </tr> </tbody> </table> <t>OCSP responders <bcp14>MUST NOT</bcp14> includeathe "Pragma: no-cache", "Cache- Control: no-cache", or "Cache-Control: no-store" HTTP header fields in authoritative OCSP responses.</t> <t>OCSP responders <bcp14>SHOULD</bcp14> include one or more of these HTTP header fields innon- authoritativenon-authoritative OCSP responses.</t> <!--[rfced] Should "productedAt" be "producedAt" (no 't')? Even though RFC 5019 contains one instance of "productedAt", it contains seven instances of "producedAt". We note that other RFCs also use "producedAt" (e.g., RFCs 9654, 6960, 5912). Original: productedAt = March 19, 2023 01:00:00 GMT Suggested: producedAt = March 19, 2023 01:00:00 GMT --> <t>For example, assume that an OCSP response has the following timestamp values:</t> <artwork><![CDATA[ thisUpdate = March 19, 2023 01:00:00 GMT nextUpdate = March 21, 2023 01:00:00 GMT productedAt = March 19, 2023 01:00:00 GMT ]]></artwork> <t>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 this:</t> <artwork><![CDATA[ Content-Type: application/ocsp-response Content-Length: 1000 Date: Mon, 20 Mar 2023 01:00:00 GMT Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT ETag: "97df3588b5a3f24babc3851b372f0ba7 1a9dcdded43b14b9d06961bfc1707d9d" Expires: Tue, 21 Mar 2023 01:00:00 GMT Cache-Control: max-age=86000,public,no-transform,must-revalidate <...> ]]></artwork> <t>OCSP clients <bcp14>MUST NOT</bcp14> include a no-cache HTTP header field in OCSP request messages, unless the client encounters an expiredresponseresponse, which may be a result of an intermediate proxy caching stale data. In this situation, clients <bcp14>SHOULD</bcp14> resend the request specifying that proxies should be bypassed by including an appropriate HTTP header field in the request (i.e., Pragma: no-cache or Cache-Control: no-cache).</t> </section> <section anchor="caching-at-servers"> <name>Caching at Servers</name> <t>In some scenarios, it is advantageous to include OCSP response information within the protocol being utilized between the client and OCSP responder. Including OCSP responses in this manner has a few attractive effects.</t> <t>First, it allows for the caching of OCSP responses on the OCSP responder, thus lowering the number of hits.</t> <t>Second, it enables certificate validation in the event the client is not connected to a network and thus eliminates the need for clients to establish a new HTTP session with the OCSP responder.</t> <t>Third, it reduces the number of round trips the client needs to make in order to complete a handshake.</t> <t>Fourth, it simplifies the client-side OCSP implementation by enabling a situation where the client need only the ability to parse and recognize OCSP responses.</t> <!--[rfced] May this sentence be updated as follows to avoid citing RFC 9846 twice? Original: This functionality has been specified as an extension to the TLS [I-D.ietf-tls-rfc8446bis] protocol in Section 4.4.2 of [I-D.ietf-tls-rfc8446bis], but can be applied to any client-server protocol. Current: This functionality has been specified as an extension to the TLS protocol [RFC9846] in Section 4.4.2 of [RFC9846] but can be applied to any client-server protocol. Option A: This functionality has been specified as an extension to the TLS protocol in Section 4.4.2 of [RFC9846] but can be applied to any client-server protocol. Option B: In Section 4.4.2 of [RFC9846], this functionality has been specified as an extension to the TLS protocol, but it can be applied to any client-server protocol. --> <t>This functionality has been specified as an extension to the TLS<xref target="I-D.ietf-tls-rfc8446bis"/>protocol <xref target="RFC9846"/> in <xref section="4.4.2" sectionFormat="of"target="I-D.ietf-tls-rfc8446bis"/>,target="RFC9846"/> but can be applied to any client-server protocol.</t><t>This<t>It is <bcp14>RECOMMENDED</bcp14> by this profileRECOMMENDSthat both TLS clients and servers implement the certificate status request extension mechanism for TLS.</t> <t>Further information regarding caching issues can be obtained from <xref target="RFC3143"/>.</t> </section> </section> <section anchor="sec-cons"> <name>Security Considerations</name> <t>The following considerations apply in addition to the security considerations addressed in <xref section="5" sectionFormat="of" target="RFC6960"/>.</t> <section anchor="replay-attacks"> <name>Replay Attacks</name> <t>Because the use of nonces in this profile is optional, there is a possibility that anout of dateout-of-date OCSP response could be replayed, thus causing a client to accept a good response when in fact there is a more up-to-date response that specifies the status ofrevoked."revoked". In order to mitigate this attack, clients <bcp14>MUST</bcp14> have access to an accurate source of time and ensure that the OCSP responses they receive are sufficiently fresh.</t> <t>Clients that do not have an accurate source of date and time are vulnerable to service disruption. For example, a client with a sufficiently fast clock may reject a fresh OCSP response.SimilarlySimilarly, a client with a sufficiently slow clock may incorrectly accept expired valid responses for certificates that may in fact be revoked.</t> <t>Future versions of the OCSP protocol may provide a way for the client to know whether the responder supports nonces or does not support nonces. If a client can determine that the responder supports nonces, it <bcp14>MUST</bcp14> reject a reply that does not contain an expected nonce. Otherwise, clients that opt to include a nonce in the request <bcp14>SHOULD NOT</bcp14> reject a corresponding OCSPResponse solely on the basis of the nonexistent expectednonce,nonce but <bcp14>MUST</bcp14> fall back to validating the OCSPResponse based on time.</t> </section> <section anchor="man-in-the-middle-attacks"> <name>Man-in-the-Middle Attacks</name> <t>To mitigate risk associated with this class of attack, the client <bcp14>MUST</bcp14> properly validate the signature on the response.</t> <t>The use of signed responses in OCSP serves to authenticate the identity of the OCSP responder and to verify that it is authorized to sign responses on the CA's behalf.</t> <t>Clients <bcp14>MUST</bcp14> ensure that they are communicating with an authorized responder by the rules described in <xref section="4.2.2.2" sectionFormat="of" target="RFC6960"/>.</t> </section> <section anchor="impersonation-attacks"> <name>Impersonation Attacks</name> <t>The use of signed responses in OCSP serves to authenticate the identity of OCSP responder.</t> <t>As detailed in <xref target="RFC6960"/>, clients must properly validate the signature of the OCSP response and the signature on the OCSP response signer certificate to ensure an authorized responder created it.</t> </section> <section anchor="denial-of-service-attacks"> <name>Denial-of-Service Attacks</name> <t>OCSP responders <bcp14>SHOULD</bcp14> take measures to prevent or mitigate denial- of-service attacks. As this profile specifies the use of unsigned OCSPRequests, access to the responder may be implicitly given to 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 greater. For example, a responder could limit the rate of incoming requests from a particular IP address if questionable behavior is detected.</t> </section> <section anchor="modification-of-http-header-fields"> <name>Modification of HTTP Header Fields</name> <t>Values included in HTTP header fields, as described in Sections <xreftarget="transport"/>target="transport" format="counter"/> and <xreftarget="cache-recs"/>,target="cache-recs" format="counter"/>, are not cryptographically protected; they may be manipulated by an attacker. Clients <bcp14>SHOULD</bcp14> use these values for caching guidance only and ultimately <bcp14>SHOULD</bcp14> rely only on the values present in the signed OCSPResponse<xref(<xref section="4.2.2.1" sectionFormat="of"target="RFC6960"/>.target="RFC6960"/>). Clients <bcp14>SHOULD NOT</bcp14> rely on cached responses beyond the nextUpdate time.</t> </section> <section anchor="request-authentication-and-authorization"> <name>Request Authentication and Authorization</name> <t>The suggested use of unsigned requests in this environment removes an option that allows the responder to determine the authenticity of incomingrequest.requests. Thus, access to the responder may be implicitly given to everyone who can send a request to a responder. Environments where explicit authorization to access the OCSP responder is necessary can utilize other mechanisms to authenticate requestors or restrict or meter service.</t> </section> <section anchor="sha1-sec"> <name>Use of SHA-1 for thecalculationCalculation of CertIDfield values</name>Field Values</name> <t>Although the use of SHA-1 for the calculation of CertID field values is not of concern from a cryptographic security standpoint, the continued use of SHA-1 in an ecosystem requires that software that interoperates with the ecosystem maintain support for SHA-1. This increases implementation complexity and potential attack surface for the software in question. Thus, the continued use of SHA-1 in an ecosystem to maintain interoperability with legacy software must be weighed against the increased implementation complexity and potential attack surface.</t> </section> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> </middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC6960"> <front> <title>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title> <author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="M. Myers" initials="M." surname="Myers"/> <author fullname="R. Ankney" initials="R." surname="Ankney"/> <author fullname="A. Malpani" initials="A." surname="Malpani"/> <author fullname="S. Galperin" initials="S." surname="Galperin"/> <author fullname="C. Adams" initials="C." surname="Adams"/> <date month="June" year="2013"/> <abstract> <t>This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.</t> </abstract> </front> <seriesInfo name="RFC" value="6960"/> <seriesInfo name="DOI" value="10.17487/RFC6960"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5754.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5019.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9111.xml"/> <!-- [RFC9846] draft-ietf-tls-rfc8446bis-14 companion doc RFC2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used9846 inprotocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC5754"> <front> <title>Using SHA2 Algorithms with Cryptographic Message Syntax</title> <author fullname="S. Turner" initials="S." surname="Turner"/> <date month="January" year="2010"/> <abstract> <t>This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5754"/> <seriesInfo name="DOI" value="10.17487/RFC5754"/> </reference>AUTH48 --> <referenceanchor="RFC5019">anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846"> <front> <title>TheLightweight Online Certificate StatusTransport Layer Security (TLS) Protocol(OCSP) Profile for High-Volume Environments</title> <author fullname="A. Deacon" initials="A." surname="Deacon"/>Version 1.3</title> <authorfullname="R. Hurst" initials="R." surname="Hurst"/>initials="E." surname="Rescorla" fullname="Eric Rescorla"> <organization>Independent</organization> </author> <datemonth="September" year="2007"/> <abstract> <t>This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing. [STANDARDS-TRACK]</t> </abstract>month='January' year='2026'/> </front> <seriesInfo name="RFC"value="5019"/>value="9846"/> <seriesInfo name="DOI"value="10.17487/RFC5019"/>value="10.17487/RFC9846"/> </reference><reference anchor="RFC5280"> <front> <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title> <author fullname="D. Cooper" initials="D." surname="Cooper"/> <author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="S. Farrell" initials="S." surname="Farrell"/> <author fullname="S. Boeyen" initials="S." surname="Boeyen"/> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="W. Polk" initials="W." surname="Polk"/> <date month="May" year="2008"/> <abstract> <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in</references> <references anchor="sec-informative-references"> <name>Informative References</name> <!-- [rfced] We were unable to find a document directly matching theInternet. An overview of this approach and model istitle providedas an introduction. The X.509 v3 certificate format is describedindetail, with additional information regardingtheformat and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified.original reference. TheX.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples areURL providedin the appendices. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5280"/> <seriesInfo name="DOI" value="10.17487/RFC5280"/> </reference> <reference anchor="RFC4648"> <front> <title>The Base16, Base32, and Base64 Data Encodings</title> <author fullname="S. Josefsson" initials="S." surname="Josefsson"/> <date month="October" year="2006"/> <abstract> <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4648"/> <seriesInfo name="DOI" value="10.17487/RFC4648"/> </reference> <reference anchor="RFC3986"> <front> <title>Uniform Resource Identifier (URI): Generic Syntax</title> <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/> <author fullname="R. Fielding" initials="R." surname="Fielding"/> <author fullname="L. Masinter" initials="L." surname="Masinter"/> <date month="January" year="2005"/> <abstract> <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementationgoes toparsethecommon components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammarhomepage forURIs; that task is performed bytheindividual specifications of each URI scheme. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="66"/> <seriesInfo name="RFC" value="3986"/> <seriesInfo name="DOI" value="10.17487/RFC3986"/> </reference> <reference anchor="RFC9110"> <front> <title>HTTP Semantics</title> <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/> <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/> <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/> <date month="June" year="2022"/> <abstract> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describesOpen Mobile Alliance. We did find theoverall architecture of HTTP, establishes common terminology, and defines aspects offollowing URL, which points to theprotocol that are shared by all versions. InOCSP Mobile Profile: https://www.openmobilealliance.org/release/OCSP/V1_0-20040127-C/OMA-WAP-OCSP-V1_0-20040127-C.pdf May we update thisdefinition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t> <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t> </abstract> </front> <seriesInfo name="STD" value="97"/> <seriesInfo name="RFC" value="9110"/> <seriesInfo name="DOI" value="10.17487/RFC9110"/> </reference> <reference anchor="RFC9111"> <front> <title>HTTP Caching</title> <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/> <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/> <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/> <date month="June" year="2022"/> <abstract> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t> <t>This document obsoletes RFC 7234.</t> </abstract> </front> <seriesInfo name="STD" value="98"/> <seriesInfo name="RFC" value="9111"/> <seriesInfo name="DOI" value="10.17487/RFC9111"/> </reference> <reference anchor="I-D.ietf-tls-rfc8446bis"> <front> <title>The Transport Layer Security (TLS)reference as follows? Original: [OCSPMP] Open Mobile Alliance, "OCSP Mobile Profile V1.0", www.openmobilealliance.org . Perhaps: [OCSPMP] Open Mobile Alliance, "Online Certificate Status Protocol Mobile Profile", Candidate Version1.3</title> <author fullname="Eric Rescorla" initials="E." surname="Rescorla"> <organization>Windy Hill Systems, LLC</organization> </author> <date day="3" month="March" year="2024"/> <abstract> <t> This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446. This document also specifies new requirements for TLS 1.2 implementations. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-10"/> </reference> </references> <references anchor="sec-informative-references"> <name>Informative References</name>V1.0, 27 January 2004, <https://www.openmobilealliance.org/release/OCSP/V1_0-20040127-C/OMA-WAP-OCSP-V1_0-20040127-C.pdf>. --> <referenceanchor="OCSPMP">anchor="OCSPMP" target="https://www.openmobilealliance.org"> <front> <title>OCSP Mobile Profile V1.0</title> <author> <organization>Open Mobile Alliance</organization> </author> <date/> </front><seriesInfo name="www.openmobilealliance.org" value=""/></reference><reference anchor="RFC3174"> <front> <title>US Secure Hash Algorithm 1 (SHA1)</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> <author fullname="P. Jones" initials="P." surname="Jones"/> <date month="September" year="2001"/> <abstract> <t>The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available<!-- Note tothe Internet community. This memo provides informationPE: XML forthe Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="3174"/> <seriesInfo name="DOI" value="10.17487/RFC3174"/> </reference> <reference anchor="RFC3143"> <front> <title>Known HTTP Proxy/Caching Problems</title> <author fullname="I. Cooper" initials="I." surname="Cooper"/> <author fullname="J. Dilley" initials="J." surname="Dilley"/> <date month="June" year="2001"/> <abstract> <t>This document catalogs a number of known problems with World Wide Web (WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimatelypossible update toimprove conditions by illustrating problems. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="3143"/> <seriesInfo name="DOI" value="10.17487/RFC3143"/> </reference>[OCSPMP] <referenceanchor="RFC9500">anchor="OCSPMP" target="https://www.openmobilealliance.org/release/OCSP/V1_0-20040127-C/OMA-WAP-OCSP-V1_0-20040127-C.pd"> <front><title>Standard Public Key Cryptography (PKC) Test Keys</title> <author fullname="P. Gutmann" initials="P." surname="Gutmann"/> <author fullname="C. Bonnell" initials="C." surname="Bonnell"/><title>Online Certificate Status Protocol Mobile Profile</title> <author> <organization>Open Mobile Alliance</organization> </author> <datemonth="December" year="2023"/> <abstract> <t>This document provides a set of standard Public Key Cryptography (PKC) test keys that may be used wherever pre-generated keys and associated operations like digital signatures are required. Like the European Institute for Computer Antivirus Research (EICAR) virus test and the Generic Test for Unsolicited Bulk Email (GTUBE) spam test files, these publicly known test keys can be detected and recognised by applications consuming them as being purely for testing purposes without assigning any security properties to them.</t> </abstract>day="27" month="January" year="2004"/> </front><seriesInfo name="RFC" value="9500"/> <seriesInfo name="DOI" value="10.17487/RFC9500"/><refcontent>Candidate Version V1.0</refcontent> </reference> --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3143.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9500.xml"/> </references> </references><?line 729?><section anchor="differences-from-rfc-5019"> <name>Differences from RFC 5019</name> <t>This document obsoletes <xref target="RFC5019"/>. <xref target="RFC5019"/> defines a lightweight profile for OCSP that makes the protocol more suitable for use in high-volume environments. The lightweight profile specifies the mandatory use of SHA-1 when calculating the values of several fields in OCSP requests and responses. In recent years, weaknesses have been demonstrated with the SHA-1 algorithm. As a result, SHA-1 is increasingly falling out of use even fornon-security relevantnon-security-relevant use cases. This document obsoletes the lightweight profile as specified inRFC 5019<xref target="RFC5019"/> to instead recommend the use of SHA-256 where SHA-1 was previously required. An<xref target="RFC5019"/>-compliantOCSP client compliant with <xref target="RFC5019"/> is still able to use SHA-1, but the use of SHA-1 may become obsolete in the future.</t> <t>Substantive changes to RFC 5019:</t> <ul spacing="normal"> <li> <t><xref target="certid"/> requires new OCSP clients to use SHA-256 to support migration for OCSP clients.</t> </li> <li> <t><xref target="byKey"/> requires new OCSP responders to use the byKeyfield,field and support migration from byName fields.</t> </li> <li> <t><xref target="transport"/> clarifies that OCSP clients <bcp14>MUST NOT</bcp14> include whitespace or any other characters that are not part of the base64 character repertoire in the base64-encoded string.</t> </li> </ul> </section> <section anchor="examples"> <name>Examples</name> <section anchor="root-certification-authority-certificate"> <name>Root Certification Authority Certificate</name> <t>This is a self-signed certificate for the certification authority that issued the end-entity certificate andOCSP delegatedOCSP-delegated responder example certificates below.</t> <t>The key pair for the certification authority is the "testECCP521" key from <xref section="2.3" sectionFormat="of" target="RFC9500"/>.</t> <artwork><![CDATA[ -----BEGIN CERTIFICATE----- MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF K4EEACMDgYYABAHQ/XJXqEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3 +i2iYNjrYtbS9dZJJ44yFzagYoy7swMItuYY2wD2KtIExkYDWbyBiriWG/Dw/A7F quikKBc85W8A3psVfB5cgsZPVi/K3vxKTCj200LPPvYW/ILTO3KFySHyvzb92KNC MEAwHQYDVR0OBBYEFI7CFAlgduqQOOk5rhttUsQXfZ++MA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgIEMAoGCCqGSM49BAMEA4GLADCBhwJBbr/1SJiHCgXG EJ7R+3er1LdWqrdZHgtCwyT7+wFBIJmVswEiom2LGh/oMuu5mD+u/+o1m07vmmZj /+ipGp8TIwkCQgCoZ4bHte6XkFm7hUXascLN7vkv7qKwXyTsCvIDpEDTRCX8dUFe 73jGebitkumRHjVhlBJLo7n3FMJrFHNoeblMbw== -----END CERTIFICATE----- ]]></artwork> <artwork><![CDATA[ 0 552: SEQUENCE { 4 394: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 1: INTEGER 1 16 10: SEQUENCE { 18 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4) : } 28 56: SEQUENCE { 30 11: SET { 32 9: SEQUENCE { 34 3: OBJECT IDENTIFIER countryName (2 5 4 6) 39 2: PrintableString 'XX' : } : } 43 20: SET { 45 18: SEQUENCE { 47 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 52 11: UTF8String 'Certs 'r Us' : } : } 65 19: SET { 67 17: SEQUENCE { 69 3: OBJECT IDENTIFIER commonName (2 5 4 3) 74 10: UTF8String 'Issuing CA' : } : } : } 86 30: SEQUENCE { 88 13: UTCTime 02/04/2024 12:37:47 GMT 103 13: UTCTime 02/04/2025 12:37:47 GMT : } 118 56: SEQUENCE { 120 11: SET { 122 9: SEQUENCE { 124 3: OBJECT IDENTIFIER countryName (2 5 4 6) 129 2: PrintableString 'XX' : } : } 133 20: SET { 135 18: SEQUENCE { 137 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 142 11: UTF8String 'Certs 'r Us' : } : } 155 19: SET { 157 17: SEQUENCE { 159 3: OBJECT IDENTIFIER commonName (2 5 4 3) 164 10: UTF8String 'Issuing CA' : } : } : } 176 155: SEQUENCE { 179 16: SEQUENCE { 181 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 190 5: OBJECT IDENTIFIER secp521r1 (1 3 132 0 35) : } 197 134: BIT STRING : 04 01 D0 FD 72 57 A8 4C 74 7F 56 25 75 C0 73 85 : DB EB F2 F5 2B EA 58 08 3D B8 2F DD 15 31 D8 AA : E3 CC 87 5F F0 2F F7 FA 2D A2 60 D8 EB 62 D6 D2 : F5 D6 49 27 8E 32 17 36 A0 62 8C BB B3 03 08 B6 : E6 18 DB 00 F6 2A D2 04 C6 46 03 59 BC 81 8A B8 : 96 1B F0 F0 FC 0E C5 AA E8 A4 28 17 3C E5 6F 00 : DE 9B 15 7C 1E 5C 82 C6 4F 56 2F CA DE FC 4A 4C : 28 F6 D3 42 CF 3E F6 16 FC 82 D3 3B 72 85 C9 21 : F2 BF 36 FD D8 : } 334 66: [3] { 336 64: SEQUENCE { 338 29: SEQUENCE { 340 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 345 22: OCTET STRING, encapsulates { 347 20: OCTET STRING : 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4 : 17 7D 9F BE : } : } 369 15: SEQUENCE { 371 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 376 1: BOOLEAN TRUE 379 5: OCTET STRING, encapsulates { 381 3: SEQUENCE { 383 1: BOOLEAN TRUE : } : } : } 386 14: SEQUENCE { 388 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 393 1: BOOLEAN TRUE 396 4: OCTET STRING, encapsulates { 398 2: BIT STRING 2 unused bits : '100000'B (bit 5) : } : } : } : } : } 402 10: SEQUENCE { 404 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4) : } 414 139: BIT STRING, encapsulates { 418 135: SEQUENCE { 421 65: INTEGER : 6E BF F5 48 98 87 0A 05 C6 10 9E D1 FB 77 AB D4 : B7 56 AA B7 59 1E 0B 42 C3 24 FB FB 01 41 20 99 : 95 B3 01 22 A2 6D 8B 1A 1F E8 32 EB B9 98 3F AE : FF EA 35 9B 4E EF 9A 66 63 FF E8 A9 1A 9F 13 23 : 09 488 66: INTEGER : 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 : 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 : 4C 6F : } : } : } ]]></artwork> </section> <section anchor="end-entity-certificate"><name>End-entity<name>End-Entity Certificate</name> <t>This is an end-entity certificate whose status is requested and returned in the OCSP request and response examples below.</t> <t>The key pair for the end-entity certificate is the "testECCP256" key from <xref section="2.3" sectionFormat="of" target="RFC9500"/>.</t> <artwork><![CDATA[ -----BEGIN CERTIFICATE----- MIIB2zCCATygAwIBAgIEAarwDTAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEU MBIGA1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQw NDAyMTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjAcMRowGAYDVQQDDBF4bi0tMThqNGQu ZXhhbXBsZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEIlSPiPt4L/teyjdERS xyoeVY+9b3O+XkjpMjLMRcWxbEzRDEy41bihcTnpSILImSVymTQl9BQZq36QpCpJ QnKjUDBOMB0GA1UdDgQWBBRbcKeYF/ef9jfS9+PcRGwhCde71DAfBgNVHSMEGDAW gBSOwhQJYHbqkDjpOa4bbVLEF32fvjAMBgNVHRMBAf8EAjAAMAoGCCqGSM49BAME A4GMADCBiAJCAIot8SYNFkScrcsY5T81HSmNzhP/0GC87N3WI849CN0qmNa0nMXW 8HnDKGR5nv/D9x+T8uLMBlpFUWmHQmXAJPN8AkIBW8A0XsiyPJyZfaZieODmtnoI obZP+eTLNWkGUFL6uCtLtQmYtrXpLAJfvkE6WYVqCUl495Kx9l6M9TBLK5X6V3w= -----END CERTIFICATE----- ]]></artwork> <artwork><![CDATA[ 0 475: SEQUENCE { 4 316: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 4: INTEGER 27979789 19 10: SEQUENCE { 21 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4) : } 31 56: SEQUENCE { 33 11: SET { 35 9: SEQUENCE { 37 3: OBJECT IDENTIFIER countryName (2 5 4 6) 42 2: PrintableString 'XX' : } : } 46 20: SET { 48 18: SEQUENCE { 50 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 55 11: UTF8String 'Certs 'r Us' : } : } 68 19: SET { 70 17: SEQUENCE { 72 3: OBJECT IDENTIFIER commonName (2 5 4 3) 77 10: UTF8String 'Issuing CA' : } : } : } 89 30: SEQUENCE { 91 13: UTCTime 02/04/2024 12:37:47 GMT 106 13: UTCTime 02/04/2025 12:37:47 GMT : } 121 28: SEQUENCE { 123 26: SET { 125 24: SEQUENCE { 127 3: OBJECT IDENTIFIER commonName (2 5 4 3) 132 17: UTF8String 'xn--18j4d.example' : } : } : } 151 89: SEQUENCE { 153 19: SEQUENCE { 155 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 164 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) : } 174 66: BIT STRING : 04 42 25 48 F8 8F B7 82 FF B5 EC A3 74 44 52 C7 : 2A 1E 55 8F BD 6F 73 BE 5E 48 E9 32 32 CC 45 C5 : B1 6C 4C D1 0C 4C B8 D5 B8 A1 71 39 E9 48 82 C8 : 99 25 72 99 34 25 F4 14 19 AB 7E 90 A4 2A 49 42 : 72 : } 242 80: [3] { 244 78: SEQUENCE { 246 29: SEQUENCE { 248 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 253 22: OCTET STRING, encapsulates { 255 20: OCTET STRING : 5B 70 A7 98 17 F7 9F F6 37 D2 F7 E3 DC 44 6C 21 : 09 D7 BB D4 : } : } 277 31: SEQUENCE { 279 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 284 24: OCTET STRING, encapsulates { 286 22: SEQUENCE { 288 20: [0] : 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4 : 17 7D 9F BE : } : } : } 310 12: SEQUENCE { 312 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 317 1: BOOLEAN TRUE 320 2: OCTET STRING, encapsulates { 322 0: SEQUENCE {} : } : } : } : } : } 324 10: SEQUENCE { 326 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4) : } 336 140: BIT STRING, encapsulates { 340 136: SEQUENCE { 343 66: INTEGER : 00 8A 2D F1 26 0D 16 44 9C AD CB 18 E5 3F 35 1D : 29 8D CE 13 FF D0 60 BC EC DD D6 23 CE 3D 08 DD : 2A 98 D6 B4 9C C5 D6 F0 79 C3 28 64 79 9E FF C3 : F7 1F 93 F2 E2 CC 06 5A 45 51 69 87 42 65 C0 24 : F3 7C 411 66: INTEGER : 01 5B C0 34 5E C8 B2 3C 9C 99 7D A6 62 78 E0 E6 : 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 : 6A 09 49 78 F7 92 B1 F6 5E 8C F5 30 4B 2B 95 FA : 57 7C : } : } : } ]]></artwork> </section> <section anchor="ocsp-responder-certificate"> <name>OCSP Responder Certificate</name> <t>This is a certificate for theOCSP delegatedOCSP-delegated response that signed the OCSP response example below.</t> <t>The key pair for the OCSPResponderresponder certificate is the "testECCP384" key from <xref section="2.3" sectionFormat="of" target="RFC9500"/>.</t> <artwork><![CDATA[ -----BEGIN CERTIFICATE----- MIICSzCCAa6gAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA8MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL Q2VydHMgJ3IgVXMxFzAVBgNVBAMMDk9DU1AgUmVzcG9uZGVyMHYwEAYHKoZIzj0C AQYFK4EEACIDYgAEWwkBuIUjKW65GdUP+hqcs3S8TUCVhigr/soRsdla27VHNK9X C/grcijPImvPTCXdvP47GjrTlDDv92Ph1o0uFR2Rcgt3lbWNprNGOWE6j7m1qNpI xnRxF/mRnoQk837Io4GHMIGEMB0GA1UdDgQWBBQK46D+ndQldpi163Lrygznvz31 8TAfBgNVHSMEGDAWgBSOwhQJYHbqkDjpOa4bbVLEF32fvjAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDCTAPBgkrBgEFBQcw AQUEAgUAMAoGCCqGSM49BAMEA4GKADCBhgJBFCqM1gpsZcd0Zd8RW8H/+L4OIbTa GtpT2QY0pd6JBw91lFqNCxj+F1k9XJrKSQAVVAa/b3JaZOsRrH6vihlO3MYCQUkL C0mmLubTRDH2v+6A1aycIVKIpR3G6+PuaD2Um3PSF7FElkoU4NYkbl1SH/8FzbDy /LCBhih25e7hAtyg/XsI -----END CERTIFICATE----- ]]></artwork> <artwork><![CDATA[ 0 587: SEQUENCE { 4 430: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 1: INTEGER 1 16 10: SEQUENCE { 18 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4) : } 28 56: SEQUENCE { 30 11: SET { 32 9: SEQUENCE { 34 3: OBJECT IDENTIFIER countryName (2 5 4 6) 39 2: PrintableString 'XX' : } : } 43 20: SET { 45 18: SEQUENCE { 47 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 52 11: UTF8String 'Certs 'r Us' : } : } 65 19: SET { 67 17: SEQUENCE { 69 3: OBJECT IDENTIFIER commonName (2 5 4 3) 74 10: UTF8String 'Issuing CA' : } : } : } 86 30: SEQUENCE { 88 13: UTCTime 02/04/2024 12:37:47 GMT 103 13: UTCTime 02/04/2025 12:37:47 GMT : } 118 60: SEQUENCE { 120 11: SET { 122 9: SEQUENCE { 124 3: OBJECT IDENTIFIER countryName (2 5 4 6) 129 2: PrintableString 'XX' : } : } 133 20: SET { 135 18: SEQUENCE { 137 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 142 11: UTF8String 'Certs 'r Us' : } : } 155 23: SET { 157 21: SEQUENCE { 159 3: OBJECT IDENTIFIER commonName (2 5 4 3) 164 14: UTF8String 'OCSP Responder' : } : } : } 180 118: SEQUENCE { 182 16: SEQUENCE { 184 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 193 5: OBJECT IDENTIFIER secp384r1 (1 3 132 0 34) : } 200 98: BIT STRING : 04 5B 09 01 B8 85 23 29 6E B9 19 D5 0F FA 1A 9C : B3 74 BC 4D 40 95 86 28 2B FE CA 11 B1 D9 5A DB : B5 47 34 AF 57 0B F8 2B 72 28 CF 22 6B CF 4C 25 : DD BC FE 3B 1A 3A D3 94 30 EF F7 63 E1 D6 8D 2E : 15 1D 91 72 0B 77 95 B5 8D A6 B3 46 39 61 3A 8F : B9 B5 A8 DA 48 C6 74 71 17 F9 91 9E 84 24 F3 7E : C8 : } 300 135: [3] { 303 132: SEQUENCE { 306 29: SEQUENCE { 308 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 313 22: OCTET STRING, encapsulates { 315 20: OCTET STRING : 0A E3 A0 FE 9D D4 25 76 98 B5 EB 72 EB CA 0C E7 : BF 3D F5 F1 : } : } 337 31: SEQUENCE { 339 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 344 24: OCTET STRING, encapsulates { 346 22: SEQUENCE { 348 20: [0] : 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4 : 17 7D 9F BE : } : } : } 370 12: SEQUENCE { 372 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 377 1: BOOLEAN TRUE 380 2: OCTET STRING, encapsulates { 382 0: SEQUENCE {} : } : } 384 14: SEQUENCE { 386 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 391 1: BOOLEAN TRUE 394 4: OCTET STRING, encapsulates { 396 2: BIT STRING 7 unused bits : '1'B (bit 0) : } : } 400 19: SEQUENCE { 402 3: OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 407 12: OCTET STRING, encapsulates { 409 10: SEQUENCE { 411 8: OBJECT IDENTIFIER ocspSigning (1 3 6 1 5 5 7 3 9) : } : } : } 421 15: SEQUENCE { 423 9: OBJECT IDENTIFIER ocspNoCheck (1 3 6 1 5 5 7 48 1 5) 434 2: OCTET STRING, encapsulates { 436 0: NULL : } : } : } : } : } 438 10: SEQUENCE { 440 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4) : } 450 138: BIT STRING, encapsulates { 454 134: SEQUENCE { 457 65: INTEGER : 14 2A 8C D6 0A 6C 65 C7 74 65 DF 11 5B C1 FF F8 : BE 0E 21 B4 DA 1A DA 53 D9 06 34 A5 DE 89 07 0F : 75 94 5A 8D 0B 18 FE 17 59 3D 5C 9A CA 49 00 15 : 54 06 BF 6F 72 5A 64 EB 11 AC 7E AF 8A 19 4E DC : C6 524 65: INTEGER : 49 0B 0B 49 A6 2E E6 D3 44 31 F6 BF EE 80 D5 AC : 9C 21 52 88 A5 1D C6 EB E3 EE 68 3D 94 9B 73 D2 : 17 B1 44 96 4A 14 E0 D6 24 6E 5D 52 1F FF 05 CD : B0 F2 FC B0 81 86 28 76 E5 EE E1 02 DC A0 FD 7B : 08 : } : } : } ]]></artwork> </section> <section anchor="ocsp-request"> <name>OCSP Request</name> <t>This is a base64-encoded OCSP request for the end-entity certificate above.</t> <artwork><![CDATA[ MGEwXzBdMFswWTANBglghkgBZQMEAgEFAAQgOplGd1aAc6cHv95QGGNF5M1hNNsI Xrqh0QQl8DtvCOoEIEdKbKMB8j3J9/cHhwThx/X8lucWdfbtiC56tlw/WEVDAgQB qvAN ]]></artwork> <artwork><![CDATA[ 0 97: SEQUENCE { 2 95: SEQUENCE { 4 93: SEQUENCE { 6 91: SEQUENCE { 8 89: SEQUENCE { 10 13: SEQUENCE { 12 9: OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1) 23 0: NULL : } 25 32: OCTET STRING : 3A 99 46 77 56 80 73 A7 07 BF DE 50 18 63 45 E4 : CD 61 34 DB 08 5E BA A1 D1 04 25 F0 3B 6F 08 EA 59 32: OCTET STRING : 47 4A 6C A3 01 F2 3D C9 F7 F7 07 87 04 E1 C7 F5 : FC 96 E7 16 75 F6 ED 88 2E 7A B6 5C 3F 58 45 43 93 4: INTEGER 27979789 : } : } : } : } : } ]]></artwork> </section> <section anchor="ocsp-response"> <name>OCSP Response</name> <t>This is a base64-encoded OCSP response for the end-entity certificate above.</t> <artwork><![CDATA[ MIIDnwoBAKCCA5gwggOUBgkrBgEFBQcwAQEEggOFMIIDgTCBsKIWBBQK46D+ndQl dpi163Lrygznvz318RgPMjAyNDA0MDIxMjM3NDdaMIGEMIGBMFkwDQYJYIZIAWUD BAIBBQAEIDqZRndWgHOnB7/eUBhjReTNYTTbCF66odEEJfA7bwjqBCBHSmyjAfI9 yff3B4cE4cf1/JbnFnX27YguerZcP1hFQwIEAarwDYAAGA8yMDI0MDQwMzEyMzc0 N1qgERgPMjAyNDA0MTAxMjM3NDdaMAoGCCqGSM49BAMDA2kAMGYCMQDRmVmiIb4D m9yEXiv2XtoeQi6ftpjLmlBqqRIi+3htfF/OyjdHnFuh38cQKYqqrWYCMQDKiPct Vu7SQs587d2ZBEHQH20j5AFiGGsbI1b3+C9ZK6NIzgD6DnWlDwpSfilEarOgggJT MIICTzCCAkswggGuoAMCAQICAQEwCgYIKoZIzj0EAwQwODELMAkGA1UEBhMCWFgx FDASBgNVBAoMC0NlcnRzICdyIFVzMRMwEQYDVQQDDApJc3N1aW5nIENBMB4XDTI0 MDQwMjEyMzc0N1oXDTI1MDQwMjEyMzc0N1owPDELMAkGA1UEBhMCWFgxFDASBgNV BAoMC0NlcnRzICdyIFVzMRcwFQYDVQQDDA5PQ1NQIFJlc3BvbmRlcjB2MBAGByqG SM49AgEGBSuBBAAiA2IABFsJAbiFIyluuRnVD/oanLN0vE1AlYYoK/7KEbHZWtu1 RzSvVwv4K3IozyJrz0wl3bz+Oxo605Qw7/dj4daNLhUdkXILd5W1jaazRjlhOo+5 tajaSMZ0cRf5kZ6EJPN+yKOBhzCBhDAdBgNVHQ4EFgQUCuOg/p3UJXaYtety68oM 57899fEwHwYDVR0jBBgwFoAUjsIUCWB26pA46TmuG21SxBd9n74wDAYDVR0TAQH/ BAIwADAOBgNVHQ8BAf8EBAMCB4AwEwYDVR0lBAwwCgYIKwYBBQUHAwkwDwYJKwYB BQUHMAEFBAIFADAKBggqhkjOPQQDBAOBigAwgYYCQRQqjNYKbGXHdGXfEVvB//i+ DiG02hraU9kGNKXeiQcPdZRajQsY/hdZPVyaykkAFVQGv29yWmTrEax+r4oZTtzG AkFJCwtJpi7m00Qx9r/ugNWsnCFSiKUdxuvj7mg9lJtz0hexRJZKFODWJG5dUh// Bc2w8vywgYYoduXu4QLcoP17CA== ]]></artwork> <artwork><![CDATA[ 0 927: SEQUENCE { 4 1: ENUMERATED 0 7 920: [0] { 11 916: SEQUENCE { 15 9: OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1) 26 901: OCTET STRING, encapsulates { 30 897: SEQUENCE { 34 176: SEQUENCE { 37 22: [2] { 39 20: OCTET STRING : 0A E3 A0 FE 9D D4 25 76 98 B5 EB 72 EB CA 0C E7 : BF 3D F5 F1 : } 61 15: GeneralizedTime 02/04/2024 12:37:47 GMT 78 132: SEQUENCE { 81 129: SEQUENCE { 84 89: SEQUENCE { 86 13: SEQUENCE { 88 9: OBJECT IDENTIFIER : sha-256 (2 16 840 1 101 3 4 2 1) 99 0: NULL : } 101 32: OCTET STRING : 3A 99 46 77 56 80 73 A7 07 BF DE 50 18 63 45 E4 : CD 61 34 DB 08 5E BA A1 D1 04 25 F0 3B 6F 08 EA 135 32: OCTET STRING : 47 4A 6C A3 01 F2 3D C9 F7 F7 07 87 04 E1 C7 F5 : FC 96 E7 16 75 F6 ED 88 2E 7A B6 5C 3F 58 45 43 169 4: INTEGER 27979789 : } 175 0: [0] 177 15: GeneralizedTime 03/04/2024 12:37:47 GMT 194 17: [0] { 196 15: GeneralizedTime 10/04/2024 12:37:47 GMT : } : } : } : } 213 10: SEQUENCE { 215 8: OBJECT IDENTIFIER : ecdsaWithSHA384 (1 2 840 10045 4 3 3) : } 225 105: BIT STRING, encapsulates { 228 102: SEQUENCE { 230 49: INTEGER : 00 D1 99 59 A2 21 BE 03 9B DC 84 5E 2B F6 5E DA : 1E 42 2E 9F B6 98 CB 9A 50 6A A9 12 22 FB 78 6D : 7C 5F CE CA 37 47 9C 5B A1 DF C7 10 29 8A AA AD : 66 281 49: INTEGER : 00 CA 88 F7 2D 56 EE D2 42 CE 7C ED DD 99 04 41 : D0 1F 6D 23 E4 01 62 18 6B 1B 23 56 F7 F8 2F 59 : 2B A3 48 CE 00 FA 0E 75 A5 0F 0A 52 7E 29 44 6A : B3 : } : } 332 595: [0] { 336 591: SEQUENCE { 340 587: SEQUENCE { 344 430: SEQUENCE { 348 3: [0] { 350 1: INTEGER 2 : } 353 1: INTEGER 1 356 10: SEQUENCE { 358 8: OBJECT IDENTIFIER : ecdsaWithSHA512 (1 2 840 10045 4 3 4) : } 368 56: SEQUENCE { 370 11: SET { 372 9: SEQUENCE { 374 3: OBJECT IDENTIFIER countryName (2 5 4 6) 379 2: PrintableString 'XX' : } : } 383 20: SET { 385 18: SEQUENCE { 387 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 392 11: UTF8String 'Certs 'r Us' : } : } 405 19: SET { 407 17: SEQUENCE { 409 3: OBJECT IDENTIFIER commonName (2 5 4 3) 414 10: UTF8String 'Issuing CA' : } : } : } 426 30: SEQUENCE { 428 13: UTCTime 02/04/2024 12:37:47 GMT 443 13: UTCTime 02/04/2025 12:37:47 GMT : } 458 60: SEQUENCE { 460 11: SET { 462 9: SEQUENCE { 464 3: OBJECT IDENTIFIER countryName (2 5 4 6) 469 2: PrintableString 'XX' : } : } 473 20: SET { 475 18: SEQUENCE { 477 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 482 11: UTF8String 'Certs 'r Us' : } : } 495 23: SET { 497 21: SEQUENCE { 499 3: OBJECT IDENTIFIER commonName (2 5 4 3) 504 14: UTF8String 'OCSP Responder' : } : } : } 520 118: SEQUENCE { 522 16: SEQUENCE { 524 7: OBJECT IDENTIFIER : ecPublicKey (1 2 840 10045 2 1) 533 5: OBJECT IDENTIFIER : secp384r1 (1 3 132 0 34) : } 540 98: BIT STRING : 04 5B 09 01 B8 85 23 29 6E B9 19 D5 0F FA 1A 9C : B3 74 BC 4D 40 95 86 28 2B FE CA 11 B1 D9 5A DB : B5 47 34 AF 57 0B F8 2B 72 28 CF 22 6B CF 4C 25 : DD BC FE 3B 1A 3A D3 94 30 EF F7 63 E1 D6 8D 2E : 15 1D 91 72 0B 77 95 B5 8D A6 B3 46 39 61 3A 8F : B9 B5 A8 DA 48 C6 74 71 17 F9 91 9E 84 24 F3 7E : C8 : } 640 135: [3] { 643 132: SEQUENCE { 646 29: SEQUENCE { 648 3: OBJECT IDENTIFIER : subjectKeyIdentifier (2 5 29 14) 653 22: OCTET STRING, encapsulates { 655 20: OCTET STRING : 0A E3 A0 FE 9D D4 25 76 98 B5 EB 72 EB CA 0C E7 : BF 3D F5 F1 : } : } 677 31: SEQUENCE { 679 3: OBJECT IDENTIFIER : authorityKeyIdentifier (2 5 29 35) 684 24: OCTET STRING, encapsulates { 686 22: SEQUENCE { 688 20: [0] : 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4 : 17 7D 9F BE : } : } : } 710 12: SEQUENCE { 712 3: OBJECT IDENTIFIER : basicConstraints (2 5 29 19) 717 1: BOOLEAN TRUE 720 2: OCTET STRING, encapsulates { 722 0: SEQUENCE {} : } : } 724 14: SEQUENCE { 726 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 731 1: BOOLEAN TRUE 734 4: OCTET STRING, encapsulates { 736 2: BIT STRING 7 unused bits : '1'B (bit 0) : } : } 740 19: SEQUENCE { 742 3: OBJECT IDENTIFIER : extKeyUsage (2 5 29 37) 747 12: OCTET STRING, encapsulates { 749 10: SEQUENCE { 751 8: OBJECT IDENTIFIER : ocspSigning (1 3 6 1 5 5 7 3 9) : } : } : } 761 15: SEQUENCE { 763 9: OBJECT IDENTIFIER : ocspNoCheck (1 3 6 1 5 5 7 48 1 5) 774 2: OCTET STRING, encapsulates { 776 0: NULL : } : } : } : } : } 778 10: SEQUENCE { 780 8: OBJECT IDENTIFIER : ecdsaWithSHA512 (1 2 840 10045 4 3 4) : } 790 138: BIT STRING, encapsulates { 794 134: SEQUENCE { 797 65: INTEGER : 14 2A 8C D6 0A 6C 65 C7 74 65 DF 11 5B C1 FF F8 : BE 0E 21 B4 DA 1A DA 53 D9 06 34 A5 DE 89 07 0F : 75 94 5A 8D 0B 18 FE 17 59 3D 5C 9A CA 49 00 15 : 54 06 BF 6F 72 5A 64 EB 11 AC 7E AF 8A 19 4E DC : C6 864 65: INTEGER : 49 0B 0B 49 A6 2E E6 D3 44 31 F6 BF EE 80 D5 AC : 9C 21 52 88 A5 1D C6 EB E3 EE 68 3D 94 9B 73 D2 : 17 B1 44 96 4A 14 E0 D6 24 6E 5D 52 1F FF 05 CD : B0 F2 FC B0 81 86 28 76 E5 EE E1 02 DC A0 FD 7B : 08 : } : } : } : } : } : } : } : } : } : } ]]></artwork> </section> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>The authors of this version of the document wish to thankAlex Deacon and Ryan Hurst<contact fullname="Alex Deacon"/> and <contact fullname="Ryan Hurst"/> for their work to produce the original version of the lightweight profile for the OCSP protocol.</t> <t>The authors of this version of the document wish to thankPaul Kyzivat, Russ Housley, Rob Stradling, Roman Danyliw, and Wendy Brown<contact fullname="Paul Kyzivat"/>, <contact fullname="Russ Housley"/>, <contact fullname="Rob Stradling"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Wendy Brown"/> for their reviews, feedback, and suggestions.</t> <t>The authors wish to thankMagnus Nystrom<contact fullname="Magnus Nystrom"/> of RSA Security, Inc.,Jagjeet Sondh<contact fullname="Jagjeet Sondh"/> of Vodafone Group R&D, andDavid Engberg<contact fullname="David Engberg"/> of CoreStreet, Ltd. for their contributions to the original <xref target="RFC5019"/> specification. Listed organizational affiliations reflect theauthor’s affiliationauthors' affiliations at the timeof RFC5019RFC 5019 was published.</t> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA+296XLjSpYm+B9P4RPXem5EhxaCO6PuzSpslCiJkihRW6TV D5AESUgkwQBAUdSt2za/5wXa+l//GJunmLExm0cZmzabx5hzjjsAx0ItEZGV 1W2FyswKgQ5fjh8/6+fuu7u7SuiGM+cL+3C1HNmhE7DQYyfuZBquHfxfdmZc nrNz3xu7M4eNPZ8dwmt27c1Wc4dZi0fX9xZzZxEGHxR7MPCdR6hq6/e8jQ/K EP534vmbLywIR4oy8oYLew6dGPn2ONx1nXC8O7Pny2DXHw9rJbU1cINdtawE q8HcDQLXW4SbJRTvWP22sljNB47/RcGavyhDbxE4i2AVfGGhv3IU6E5F+YXZ vmN/YZeWAf9ee/7DxPdWyy/sROueX7IbeOEuJuwAXyoPzgZKjKD2Rej4Cyfc NbFXijcIvJkDFPrCsEuKYq/CqQcNs12FwTNezWY0CvqLsS9f2P/7f/yv/99/ /t/Yf/u//ut/+z//d/HaDoau+4X17ZE9dR881gk9+sXzJ/bCfbZDGB319KzL jLO9HXbSN/eohDO33RkMS3y554be3nI1mLnDf5rgT3tDb57rDDNm7iJkN+4s 8BYFDWnL5czZgbEOU40M8av1P9n465Z6Pd/ZMN1bLJzZrKBi0524huOHBXXj l3sD/uU/jaDcEMoVt3Lp2AvWX8E0+AVtBIuKP5KrDqD4P9Fbqk5ZeP4cyj7C pCjuYpz8xYgvu+d8sqIlQLza9QbIqhHLXqt7pQ9UKp5vJnryhZ0tnUX0gTab ufZi6NDvxIxsbM8C/nfg+K4TYBe+sPV6vefBh3P6zhaf7UGFiqLs7u4yexCE vj0MFaU/dQMWLJ2hO3aHNGg2csbuApapzZaih96YhVOHnS1gzhyGNOelHXYZ 2uEqUGAooTf0ZuwjDvATlLZDZo9GvhMEuODh42Boz2zojhtuGKywFbx2F1PH h4XN1lNnoawCXCFEIHfBZrY/4R857OMUBcIjCYRP7JwYkh0Db3QWY9+GkayG 4cp3lI/nx51PzJEkBrMXo32QKFAh/Jb+ifroO99Wru8wW5lJEgWW4YpIAZJq 7i7cufvsAFPN56tFRKQB1Lx2R+EUm0Bmhjp3lcAdOUi1IYwbRrNXSN94mbOL tkErfY/1p05MbVHaGWG3oyLK1A7YwAFmWJGEG2HfYGa9NXXAd7B7DvwLab0K aM4uD7Xdcq3OvEfHpz9U6BBngLk7Gs0cBWQVyCDfGwEFoWvY3RemmcXT/Mcf /xN0rN6ql/78M+4vcszcGU5h+QRzmE7exxGM1J9jhcQFvCLoHK7K0J6xYdJM sEMz7zorKCD4Qe7FhfPoCRqeuAFM4Ufj4iT4tMcuXWBv5sIb4l2XirgLRW21 WlBnyGLijZzlzNtw0trs0YY1A/wI3clyDX6iwIw8OsQFA2ARJCvIDbnH0XiG U2dIAj4e/57ysQ2Mh+oKOH6HBo+E4CLgAywBRhTCFeAuOKEWXkhUUmC+JHYZ F7T4D2zqrR0oR8MLpt5qNsJOYhUjhVg7RM5bRjMG/3bmYuzIfrMNMVCAVdvY AWjWT+ibzJMtt773CVjEI9mzw0AtOqDPAr5mOWU5/ab2o8Pp7UKbDr7kzIAE xSUSunPogYJ0DpwhrN0iosbi1FvssCEschfYBe0DFAe7j/YMlK8zc4bAv7As QRnbi8AmPuYziCSHyRjNcGJgJPgZDBuVt4syOtUAaP4hrOWArV0gHNED1zhN KlYGbAUyFHsAHQ49P9jDteI7UIPDZ1eIEhws9RLUChIGqBosvcUIliAQQPyB 7PcBDIYZUeID++juOaCIJw5oIegPtskWzlquIOC2kWNDN4ng2J4ThJ8S5gZi ezCbi3APVjWKX5cPDXoHX+cmCDSET5IEOpNi/zUOTJJwq8CeOApwEHAXDovE 945YJVCRvwIuXQghyPik+ihzgk0QOnNRoZLIRbYE5vWZqBENKpg8EBEjkE9a IIswlNrwO5BkxQ1HMKu4xJt7NIO4cGAufdCC8hh2gMnZyBO6Z+HAKGlOhBoC KUti2wvCXWc8hhmFOpQCHkzWM2hfUM6riaA+0Bz4FrUXsBTXmCOsU4klzNxx Qql5GEwwB4FNOsUZuav5bgBqZYRDFMpITAjQUiECobCJSAj0XQN3jaCyEM3L gJgOpslFsTsDFRVin6ByEAyMZlzJrUuuTse+N2cDj1QXg9G7Q5i34SamCINu oExHmuwpwvZIE5dziOiKxClze0OiMiTjwZnDKIkoQj+SehyBRByissBVn0w9 75bNUlyChiUQ7tF11jtKpKuRpEP4Gskj2IRGKivrDPPmOiG1AooTZNQTSOk9 9ldus/2zouQYb+DIygNeFCyZuQumFoofd4ycrUxXCzCBRiRH49/S8jwlLHFd jWjxzu0FqiWxdNPEx1lDtUQmks+4d4LVAjF8UIpgEnrsYeGtQQYEQLXZhohp Q5tO8Im3F7MlDSRYEVlJaaRFMfwNYtpH6carWYEoIomDK5d6jVrjAbsNKxeF KGkk4MpYGlHNnBkjrQcSh8tbtgaOoZZ5L/iCmXn2CDleyDkhPwMlkuoR47kp +y+SwCO+CgJs2AscqQLkOfC+liHpPs4tq3lkpYGPuCLp/T7DlZGhokSGa6Rl cKmN8lbnQEgLLuPn0AzK1sj047YkWCXjTWwMS2I1USUDB6bRBYlGtFsDbylL NLNCcEPUPZlwATK7s7uMjTyqaQT2k+8OyMrdU8p7YFvBz9Bh+lJ0i6GAQlLN SFxn1tSeUsHPRBvRJ0PQT9h1ki9Cj0bThQ17/BUfFFC+w3kFDAQY1yhhwtiv kvVqEEtaqtkNYsIhBUjyjLwlqjQgs0Q8bg9kuEmIW5w7qA1UyIavqF3J6diN nY7sPALp4Z3ygkfBXvMolEIfIiueuKr8iLYkkPTTDkr5kRMMYfbA0rMHHgpp IepR3+G6jJf4HLxVkl6BO1mAtZEw0NBecqZGuz2xeZTIYESXZAXCJiIgSvZI YJDQXYW73nh3QKo4UpIgfJy9yd6OYk98LEvCwvbBMJuI+RsAK6DQ4LT3/CCW 3vIqFZMlJDbIrJQfAYsOVR9QWBqOR7YcjTVMfCklwy/xGkfOndg++EBBELm3 9iN4+NFKR3UNEkopHudObF2PuXKMZBcwAPKyT+MTVdHqDELkUG8IRkNMBGEh RiucvsbAxCYZDs4MeFuxs0UiUB44b1JiZu7ZzD3gIplT4hWT8kX30AM0vAWo k8RuNmMfKuAO4QO42hiwCtiH7tVl/8MO///s9Iz+fWH1rjoXlon/Bi/z5CT+ hyJKXB6eXZ2Yyb+SL42zbtc6NfnH8JalXikfutrdB25pfjg773fOTrWTD7nJ JFOCq2giPsg7lAGg/FLD143z//u/qlXhvJZVtQXOK/+jqTaq8AeK8x0hpmAW +J9cBS6Xjk1xBDThYPGg7xrQYgTnCzQtKgSg5n/8K1Lmn7+w3wbDpVr9i3iB A069jGiWekk0y7/JfcyJWPCqoJmYmqn3GUqn+6vdpf6O6C69/O0fKUKwqzb/ 8S8KshAPawkVIOJaUezDGWaiSsFqEDhhtPAvuBsTL/pIoyjj1YK+tGkR2SnZ L60IZGHRgaiqKLD2xy8gjHfFIv0Ty/2SavIythz++IWMnhEUOucuKvcXhrQ0 0Dx2aIZ30EBFQwpkqfNEITQhPRTt8nRPZYkxMvR8sUpxUQqxJLdOS5s7jjPn EewkBWMdHXP7UEG3/yd6FLkeHgn+nf7/JbCVdWpY7A+MCYaDQC6Uevr6pfht B4uC1iRSX6KeoP4z9tfSP1NR6/b8pGN0+iz5MeIJBgRLamIv9AVdNGQD+ck1 cC0KmVZbuzrps0eVOic8Xc8/tedO9K2a+faAfOcZFYm6J3+NEaMcFeI+nrWZ TA7xjfUUYrAABSO0WM60KP0q0yNL8mJ6QAs43fmJgYfzAXUETYCZc1HQHU6+ 1zojWOqVzoA9P9VmE88HlpyLkvHfnREqh7Hr+NQjMoFpJg7hK172zOhbwB79 i87pwQ7b3WX0EywMXvjXgJmnybfHzib59A3f8gwEaiGiiOPD6jvlTo9EMOGx XMo//xmtF3nBCDUtVGzGYMjrFhTfYCAOZ6uRw9WCt3BiUSMsXKn6vQuJ32Jx sMc1KZ+OvQwNUfSlfokoBESfgdZFPxRjdDhNTqAIcyWmD9rywCYrF34dMcxq sI/m6SeqNqHdDhkN3KufbfaUlHmcoogQTJJ9QyoMrb4oopyIKIVE1KUQ8uW9 Mk4dqtRao4YqFZQwj8MF5BbYMZeNyXl5iSQoVQvJQqG/AK3eGZpAqZGspy74 lVGccWAPH9Zg5pGTDxZPbJGFU4VrfoytQzejwak56fuPUKjCzQM7YNJYlJ85 FnYYhXO5x58aE7EghTd5ZJsiJby3wL3SnAQe2ts4bxgHBTcGaGRIlaB9wCJe Jt92i3iR+TaqIDExUlXkRWXyMeuMma28UIL7flTZKGNTx+bJJY8fuGG8DmgV cicRFbMTVcw+uqPd5YP7tOsNg+Uu/YrZAceByR4D+09hEnGuhBs/xAI+ueJS yNEW1QpfXriAfL3I7t4eNyhQKTojWQIEhTQLMDkT5AtHPjR5PmB7MSji+Y7C pydSuCIYEn8EjvM4Z1GgtUUN7Eg+NuM2JDf7N5QkIRHhLpSs5ErrWRI+/8A8 9LXWbuAkvmAyKqWAE+TPi+RjLqpDnEmBepiDhUSiqMZEPkmpilxbZIy7461d WWOEzgbTk+IOic0oAhix1ZpYieKX2Ez817ANRZs/bhyKilDhZy0P/pPI6bFY Dydf8Z925NL6BmOVKdMttj0uUmXStpD8S2R85G0hXqq/WaJ5d6YfWUafdUzr tN9pd6yLVEcKzAayQoFWJEtpbuLCnPkHnEFN6wJW8NAbiYSQbgfuUB438EXu nWQ4FVjXvIxphzYvJr8RBpxYwrJ9tc22CiTrO370TmweYRl0VAL599RUyAat nDotmhTqdX5cRZZ6upGtZrpY0rLBmRCFfqCCPBbpjLSs+StseEyL9N25k5r3 IFM2NdRLocd40dR3aRtefd1kTtdVQKBhxqZOPZLtjuUyiyxdTlpmqPo4dKmg bBFZFiBiMh9E7lTeKYq+TDtGXPnn6JOpophKkV0t6y4U4yKDieHP/EpC+Rwx PIVoUTamVPYAv2FnYCWxlN2CkV1M2mEK2fYDHii3h0MM5dv5NbuXkmZFBr9k aHBtljfxM3wgFI+8ePYS3oxl+w4brEKux3mFSpSHBbWQqdKZiagoposcDPja PqXl3TkhD2IeVjCCHyWHYeEtHZ8y16h6UBPZQ5BuSSaPQlhKktkptoL3WJuQ MUGI9ewoUno+WC0xd4NdKTCuRx4FmTdOmBQEymRAJyiGhc5Cgxk6ORuuZiKb H+m7RGYoEslYuPYytAp4WLNAYncWfHpzP+1IJjl2DOdUuE6ZurHrgTCoI1M+ 3+co+SRqFJYNmUdZmRHXB4TI2TuyURinYYR96edYliwe3qR4mbgqbmICSigD npxLu3Zy6lSaJxXcwJcC8Rj0xxSti/XOvMkkMpWROpL/Qzm9bMoF+VisuKnj +nEAP0K1KJQ847lCewmstwTPPaQ1HiGkqC05VZXpJM4dTx4StEWaQjFJ3PLj fjM5AmAxBVNb3Q2cofAF5mhsS0iQKENFuBR0FiMC2DxCHjFIlBweCYIqEcCq P5VSjkVeU14z8dypBPtSJMNuJ+UHCvcADGWEfE0WBCEAh2V3CJ1Fl08pUHyC V/140fBVg9m6wBG5azmpkE8kRbkMCcISeoq9SNnpEb9yzIyIKVI9Qk7EUj9p C7PFiiCS74AE5R2be1QdZubDpOPILUN7wSWX82TPCVkqJPOWsZA8F+0HUirU GUmrjVKiMGjl9UGzlwatkOtIGfD0mOxkDMSwMYUjphBeZ97ftsMQuDsU6ClU EnJlBASInR6hLbZWLlaA7ArDqrTdGeFLwHx2RzwhmpFDQuJH4ihVHaENYFU5 w11cKbxaJXJbti2jvZTpIDfyCvVTfqGSkpIwMeA+xpwm2C/CdUVuPeoZ6CHp Q8mTTM9sKkvKAbAjD2c48HIrPKW4pJiKWGvpPxWnOMiSiyRE9P/jl8Hm2Nn8 mQnkiLmKWpTCBFlXMgkVJKsoihPgarSBBWbOhHBHSWCRgDGx/4DQUI5Nxgn5 aGiYhuZ9kIkl+RuR1eY7Y0RKDLlUw9rzKpx7NDI1OChASlAluID0BP0apFqV IwSZUBAhNJNQ0c52R3qHa64RVakI51xO0cLipkw4LQmqNoOa+TUQ8DGE8sT2 X4SLyQ1r4bg8ny3YL6Z0B7SSNsQlr3zUOtonKdK1QLPv4sSUdOM5oqU4JtY8 l8sOnMi4TcVjtlERlNFw6PnoJM84cFWRSyLnpLkjMqH5fM9sHmHGvKgf7s7g Dw6MAzZw1iR1J2BT+RiDVrYZ+cJN2OTWowyc4rgbAmriEhHKHkV50p9XKlTy FXLk50YKHIkgTsryl1xamXeAHzwEt8WxacmYenNkmlfIA9NkFq8CJ98rEoug zgLOl07KyyYnhKOC5cAxYTeSMUpEK44dnzrr9BhedKTiLEFcu/J6V/mPqI+F KHuO5ZBkrmRjcsKtvqbgOWFGZx7q3yDh7gw2DK3iaGFFuKIhYRoIF6pQ5A6N /RST7USLMtMw9PADKBZcmuPV7EMEP1K4tkcw3A0atzaVINWyvWmWNJ1CoEZ4 W45KmcUo41jvILkj82KhbOnlaiGaBjvxg4TRS+NXUFaMeKZG5mYJTZ+rC4k9 9nADQvBFVokw/5mC0FBEF5Q/aKdFgMlEtMbw4vhDgkrZDw7vKihp7hvTX5J5 56fJEtUjaW4p1JqaBpJAKUsy6//k7JItE6qkJ1SYFDCEFCtFlghHJVLdSbgE kcOxM5jxccj3HT2Su8+90FWwzVwSbjx4dSCCI7uJpIodKf0U56IXD/NFcNEP sd23wzk6/f3WlZDmMUUDi5CsciAJR73HCFMHtw7YAzsQExPvN5AdsNgQJ6z3 ajHwVoQNpG0siJfPrQSQkb5DgPBkj0k8J7i542lJuFBZ2u+xOB9M+bTIyULr NaUV1gJEirUlWHve3iim02pGyeC3LkRFudziX/qES8vkpOK0iOSygNsKHDNc BUExJuYXKai4I8ULeSRDisH+8QsSNQATk4RW4iJFENQsyDMoFEWI6UE9+cZW qc20EEm+/KJ8oS1RWAjR5Fx3JpMLc8ChbtxKG6GM4YhnDgOjBMsQ8zxJD7J1 IqKStm+I2hek7GRGjEGlkQhGuOUqlPshVJVsPqE2SuHO5PR4Fb+QTU2UZiJV FsQonD1FSgfHBSIjKWvM5faNKTkQAwKindkyZnIeMYyZaU/hjiG93gXKCTeO SbHLTIhE4HyBwsmcbp+1NB55bUcOCHz+m02I17ntP4xgAn//MJh5w4cPf1FO PdzgGOd1BK3fxFu4NogfswhIeSpq6alQqBJXQO+5kgrjpFKq7cLmiCnAPNtT ftunIf2FKxeaoZW/9IJkCNGU7TDKDO5SUgp6mAnXK2LgieJ40+gFn4CruSQY O9Trg8ha42R0abcrzs/Hr6vZioNEeFxJuLDgsMOiDsSWJEUsU1gld/B0u6Z5 eNjtXl5+BReQgg+JIk82IkR1wEifHR9c5mweQgwsh0kY+7bA/EV1cIQq9750 AXrPZm9RBIEnNEQFsck4FVKEusixktyklEMYoUPKTbSDYiLFMTfuKI927RE5 mJFhMHeghRFip91AcRYoMwJmaHIwNFqCYpsOstqCO65DycPFDVTucFukTnij rrTxMC2TUpv2UlGSIN75k6KGWNmCKBlvU6GNOCJVnQ+ScEhysTe6pQ4GTmoG pJANdmVJIkW4x66POIJ4nkH9Sx+Crem7jrAFoB2+GSedFScTcuiQb0raP63P 7HFI+HKQRPZstsEt/2N3sqKtJcC+qANw0AnD8zY5JIRdOsLYXKRgqbRz0n70 3BGFDwh5Hu2MAB8Nszc7GAifiYhLFOnBvaA8VSbFecaRMYf2VKTH7OBBbjeK WXhJlEJJWCTj+XJ7O2mMKiYATzrCBHztLnjkRwg3qcuxzyK8blGdG+4kncKu KPHCHziJtYxGkTt3KTZAH8g1vxL1kkejUIhyOAVu33k7adIaXUkFRDo5LZ+i CEtTRPkOijCJIkpCEVYAJCKfKHYytoxBKTR5UZZaaItLtIjXRCdgbQwMgz3I A8Qke/I2PG3uEwSMI81RLnYRbQzBaUp2roqNESPBbjb7deJ5o1+j/vJM0IKN xYKPtjVSbma13A09qi8TQ0/2naen71exI+3XnbijynwVhLIbIge4nU0kDEjP 0eC54OXu2WyHEpLSLhcsFhuFNANJzks0YieDRwOO6iRjhoQXzxBSQDpIMotc 5WF59JBwEwKpX9oQyOeBkk/wapcXkLoELaMk2eHiXdr2pEj+rEBapR1ZClOs yAsNvJU/5MYOtqsoujO0eURHihbIdEfFsh0f+Ar2L41pYx8DMkJlzP6fn3aU 4ZYYYbIhKMXGROoFDi4iIjpl24YYLzCxATfkmjqVNmFpzJk8UN+5B3sS2SyF 6Ep1SOy256F5BREOsdsA1TtPoDRxKcGChap4Mm8YwQhwyGPccYLhQsy4JTma XKA/Ga+YvNTQRLigeGixMJEzjGAG83QWr0Bs7Y3CePmUYsrs4iIpypWKQQ7j 0J6EXkmitgRzldao2F8tXP7EmoWmD7p94WWkDXww27gvC64V0i3ZcIYVZix4 qRP0Ecp5pbB3KIwIOJiyWYRFSByQTa9uGSatIqe4JlnAUqaAYiAOaEOX7/Na 5KiSaCbpZXqLJcbDZnYo10CFUoeMFPVV7qCybagUOA7tmZOxxuhckshq4vkj skqjHfAzEKvIDktQh57Ymk8axBZMIsU50BZT5LnyIrAoLH5Mg6C/yEbuWGSa gjgJIaUOo93D5OEG3EDP9yM5R2OIQZ+FtKRQrZMMERvlYRqHbiAio5yim8Vw ikdR8LODWAjCeeHNvMlGCiBE6SQ8kwd1sGQpSNjiTII7OiYKuonjoGgcEhjn FTfuD/GgI3HwRbhZumS0CoHCTvvn1D8l1z+PPTjOEvszT1SA2AqKMWnhSXCt 9A8KgqERBiIaze6GFb7Jghq0wYPzJqt8EFtBMcJjlhSoQQ3PZrB6fQoxMA4V iSdGof2kgp8QwDOCz5Op/kRxNCdSnoXxNPL609lpOawh8t+KhyG95czmszu3 F7vuYhfq3eUn5aCDASKYm1B9zKiQV5nsNAujd38q6a0V6N4R9vuw3z8XejsN buYpGZEExKEcWH0F9xefwaITHiU/mCftd6X827i2ZJ84BRwwZoot7/HgXiB8 kzSyGu0Z8kdIRiDrfVvZdFJFuVZjAwLvYvrWwwN7PnLvKALSfhI6JXZCYYHN uYAdOXQuBR1KMA3D5Zf9fdDn4mwQAqFjKSRJvRrHQGRAu4SqS+2FiJJMQChB IPaRTC+yDdLBJhGo+rSXproiTk+gESejTDKHdBJcGBK+JxqbPCOU2qW9oIET ZDA6PKTJ3SjSTsuYF7U9FZeVvKWXrF9+Egbu0OdtSdHWPRGYTRWxxeCpyE5+ v0iarCS/CimLK9/zIxx6Eh+rRvt4qvVq888/Y/mu5GI26ylMcbC0ORaRzq0g TgbTFKM5cR4FmQxlAYoWcbSF6GRSFNcgOCye68emSYY9MMKwmGS6Eyc8ri5O pBG/xFrysEWwp9Jq1nGkeVri7l9ho2+vMpLtVxedvHbVOpoUauIJXootpUR9 guFnjIkVg+GlPfE7Hjm337W89aWpH3St3rp3rx3rk8m36YN70FqXDL3X6zWC Zf2gf7w8KY80rGfkHNg35XrDW/d63zoL6/KmZ5bmB46u+ZeTx/9Qbus3vU7v 5OgJ/jlpPbWb3uby7tmbNUvdwXLyHyom/CfG+3YWkhMmZZp4BCnM7G1JJh5X Icl/cdLRFqCjLZshFCT8lM010G56GW8zcBcIm5XitHmkf9ZWRkDt0BkleDS+ YrE0CkuxK7ylqlH0L36hwoupY/MwFO7O25PnzPDwIItwlx8eKWl3msbdGKEl FZ05i0k4/cJ+y8gt/p79Bcue2EG4O4fRIEthUSnaS2qF6EVFrb49+cI+/IYL BVPiwmEAHvsLnTFoUVwgwEokUmcqMSgPgJPie7MvoA2fdkHK/A6fsL/siD2F O7CYd0nr4dzvMPSwYYBRiAarMemIwt9i61RuJWIonnhAXken78l1gjwwTUqE cclIc5SdhV+o2ziFF9FheMIE+OMXKbHBc9USuIznQnLwWx/PeoqyPfGBM6hf leRkGwxY8OMFpSMKc+ehCXNT7ISPs3aB4GzRWWeUHJ4Sne4SwV3lY0xw8Iqg VRI6CJ2lWEuJERvaD076DMNUmF7E9umjVCsfQKJTUTxx6kP6MDFuvqJbuCQp nij/fM46PnzOecI4BagyMB4ebPQYlvxQNl9ZupPJBr1b1NFJjlw6sC/GaPVP LndoBhBxGKc+ecw1mnqBEuPagSKu246EyqhsEeoV3JDO7mdGJkSYhMKU8us8 Jkg0jcagJPn22SaOYY7E3EmBsa0pduXXpIpf0ejtIjw2Dc3HXCXZmSkBzPOc Czy7Iu3k0eSzj2R72HzUid0oEuZ4tGIcsxYHci7dB24MJhKZTmviMQI664Yf ckI181ya6KLvUGxGNCZhTAUMxlvm4Tdy8IpwloJSVDvFabkHLZh+7IRDSm5E h2SmZSoI+8SY4zJBiaScEHLAWL44+iwbfOWVkzCSao9xYSipvCh3gKWiGrmn 3k+HUAVRlDjyuKXPeVCK8MU5LSO7ThojD3jnOkDLhATnuZAdf/ySErtbkOsi rV8gc2XFKoFLF4p0tBc/ko77b1E0CM9oAfd3gvMmxDod24Kn4kXKiATcRpwj GEP3szo5UclR3bjGJNiS8oLKiGUnN2KECUM+LzBtHCUKk3wl0PBfeEWHvKI2 BXX+hZmJkc/+RfmXL7u7u/x/oDwqQSjS5ykVqc5tCXKsOMIFjRLSx9ElbIFb BF1hEVD1IBi5CZQOi7+9zRlUySIjIx3Q4tWnq4rAEVHeOwLfSUE20i8hWK7Z MKMbBs5szEciDBIYw2XcccyNEqAvFWtyg9i3p7SdCKm/uWfZeJ/cswwPy/0D gwo6pwnPQ0jsaBtbkMLvxXsnoxOlgsAbujSPPJ3Wf2GHO31BrfF5FCPQLo1O hx1atwmGMj4XFn+P9ltNxbEZubCwtB0fx8NtO4NLPRiYEeWFbSmfGRkisTCE JfjbwP8L+4+xUPmdkTnIdsVZkDxjk6yWdNQx5gkMa6dimsmsxE2IQyt2MdMV 8JPgUHOuFpEXkfbu6Q2Idsp8BOBKCt26gBL8ryjqJ+qXDVe2m0ln0AmUT5Eh MLQXHOaN5gvnbzDtd4R1vkOxkoyf4Q0oTDrk9n1Ct7R9zEDuIn4iAuMIFBod hMdDU4TfQ9gk7TvAIKsE2IGp/OML4wKcS7WAnzH++4ecgAo+RDGprBZJ5WrY h3PfnsztL0gf6hOeycXZRTEiX0D6Dcb+IcVN9Cvuunc+FMlbN9lEwMOzabtq L99JoYKSrZkUYqCY4UuC3V3QjqjXWkvFWGGpounOWWCRkQdTIUESLzEWIAKj k/LcJXb/nXVtH+St2tph5VK5wkrql1IJ/oMpjMw+3qhsWd1SVpzhSG7fyxVH 3lVsYmYS31L4T1pMmGbnPShlKlWgUvIDKBEYDB1wuV1vJ6+dKE0087wHNnMF dPdLkYPcf7uDfCIcZLUE/Yi9yi76IuUSdriYWCkN+YVdrqC82tpeXjjOrcZo XKk1m4OaXRmXqwN7MKw0a+qg0iiPSwO7ocTbrVW7NRqOwG2rVgZqddAaleqt ujoYD9VGqTFqjdLudh9PTC6r29vPrKTI527WYdg7wuVOedwFDvdve3t7f0md eZR2ctLrPVrK+SUUpWYjPlES4OdqIQLFcfIK5d9qEfKDG2OobeIbkb0BbKEM xMY8hMqSlZU2+xKxmwg8AUKJji50w1V0HHjaNCe9OErZGOLAk1hlCzNXSdzj wWZpB2LnauLGctxJvBu1kDZyNlh4g1nZiYIqLxzpp085l/WSm7kUXgs8zCWJ FRZEm4YI/h3CFOB561KKOiWnlDR4NT7HPPbDOWp2FbqExEvlRpNTZjNSGHdY b3fxSR6Al7cQG49t8JLWmCwhIN8j7UoHbUjiFoEPNB5yB6SdtIIQub29UeIt 3SGUOquAn0kb+XKJ5TJ1qbFLSlpRaxEMT0bvRGl0Qp7zFPVjtDklBtcpYs/j guflCbcmH2VL3aAUx4JfazOVThqP/DtMSwAvw/LFk6DoUHdiqcChW2aSg16y VMfTE30+Ar4/JsiM1EdYPAOjdJlajtiDINo7ocgo/Hg7rU0JVLCNHhxSgys/ 5Kc2B3hcf+I7yCfS8j010Wn+4g6MDScuHYbF4tWZ29shDkCPTm2SYm/xYQ5K gqzM6WkymtOnQcbhoSTQbgvxE8XYRTS+f3KJ4f3OrrlHl/6EM7ryp1mt1gcu xhqTGxIQPRCnP/aq4iizrV/uKGjLYnpvIEBwgknikMeuSHXFZ+qKsWxzAMiA hQ6nwn3CBU5or+SgaDxMFAmkhAQxPIg4EirG2cbJzuDcky0H0VKMDsjig/MG IR3RrpCJGh2JVq3wjQYs3slgpDOvf/wSp115bCExnzI5WqTehu9yGcU71eSk rpL9QJzQnQF1pyHdXMxe8KyuxvO3MqQpDipzHFYszuKjABNAvnzYvrL0YOlG PCyMKwwU4yZhO7t5B4Yq1A1PL/PDuVaBgr3gibwEjBih6Bii42QVWgiPU8gQ fjc8Lj6vvbNQYtkwB7JPOLISqyZiZSKkOdzYNlAVsW32UPlcfN3ZKDLqLliJ 40vwPoUIgleEYOLdKAStZWIdvqM8rmYYSBGIMQGqxtixv6KZzQAt4rngAV0l 3SmMj3CwCRq5MfSLB+JS48MbaQSQVcnUmR5oQDiZuE7Q6nzjCvzEeSHGccqb raOYaQrCG4O0IkYhluNTjcue4tIiPpEO3cUSEL+O9qfy8F2sonk8PeT3CsQn cKczc/EhC2I9edJBEuI3DigL+MGAEWFQysi3BNnhyxXv4FmAMiLJprW1idjE ia8ViY4FSGPr9pSzMHem3ev4P5bG/ynfhf9jMv5PeTf+j6Xxf2lQexb/B8Kv m+BYuhzHEsvBvrTofTd4kINVyQmgw5nND0iPREIWFBZngF8+kUDCxvUTwZvb 1Bb5HaT04n2WGBGJbqNQeOiNn9BeEMW0F2kgewSmS28sJSh9ztBkhvZrQMm3 2TgLaMzIs424viS+EgwmJNolmbQkJUmic09WaIpu2ZMEJseeOEE1o8Q6c7yT xRNn5yRz+PNImTM/aRcbpmALDkiILwVAVPUrHKAUZgnivGXR0RVJMRpVelu0 BLGWSS2xwNB3+J5Acc6j6Sxce4ag9EuhAGICbgk4YeIU704Qp/ojzoH7Bxh9 ihbNiFcL49uNFEsEEmNawLZCpnObOlOHE+9IKjYtBQUAl0z0oYsqYuLy28kU 3Cq48ehqBC8BnKX2CEhH4uwk3otkjqNwn6MjTyeCRBRLj4w9ujZqvBmaJ2RK iDAS75syIcr7Oa0qzQ1ZQ/y6IhqeOHcENd+cnzwjb8pNBdc755Hdh1t6qBga ZxT9jRLmLp75H5IgFRKQIkDJVWr56Kii8GMEUvsq81HFnYLNhAnoj1/MkN5B uaNEkKehv1mG3sS3l1MBzkSdS738By5NxOSCJ+1iFlSclIQ2FhEeaZrJRgob Nog3043FSXAoiiYrWIkEpV2Ia9ZWM9AKUO9sk8RMSCslqknUk0F4p3hULMus yFIzIqtg14poLZtpRnG78cQByZkETWS/cx7WEukVXWKjidVvJ3cXBqvJhG+9 z++cFowVmfkSgFXs5iZwhzg2iBv2PFCRXoe5Ow1jucpFqRLxctRkdJXKmxe2 Ei1s9r6FvadY+TupwK6gamNZGaN/o/5McxvsELUbn0eIzYqQkUD2pbedyGol OZeXzD+oMfTdIZebSDNpXyNM7ZV0Ep0UDYrP3MMfUwe5CQ4FxzI6ww30VHQt myRZ312jCPZg5oufCR2Jn9TKTTDGeGbiiHY0xoAYfhickuqBsD6HHr/FjYlj +CKgjjcO13YM+Y+vjcEtbHFYKPl4DsYsGbQR5BfHxw+d43lF4DuQv3gmXiZO k9xwxqHrHuWY7Fkk1UHNjRG+GREs6hhGjyIxGzFxarTsxdGCYor7XHApDoLY nQni6WNCkD0BS4EuTcKYzgQzkzziEY1ulI1CvXF0FKroaKdaJkyRvfxLHJ9I JcVtknv8zlS0wbESU9pqQGwS39GaqSq56FU+a34v9Zd0L4p0X1R8rxVOCRkp wr17ECZE4rN55Dy7IelBLL7iIAzp7PL0seUERZDvpio0UmDqFoQb3KQnmYOV oxUlwq/JBv0AJRZe0xmn/NJY9xQ6nSL7GARY4Gmito8XCzr2w4LfvRbfiwca fU7QZ9k3iY/rjw6hJKMryi/sRCyJm0GJb+g0K/KlKNTMwzWr6AQ9pBumDOMF Hh+7vQr43usIxFcwueEWetpB+kiGiE24iwlLxH7l3l4uwAXd6TpaB4ycVUCZ YX7VHYx6keKnXVoOLoIT5YQfZu3oBqpoF0p8iij3NHPCkyulISYj4tM4hUUw Xolj2i5XAxSEFOePAH5QdTTOL7Bs0CTiN+v8mUi/6GZTedukfLsE+mdCxs3d iTjzNl4J4qM9Xjs/Ha+ocsmsF/WT/52cerXD75/Nt0T3Y0pnbUVtSeaeuKUv Rg28mGtT/i4Qedrsy23wgFtSHlRtyIf6RRYUxm6l8wK4GCM8B+JgdoUFJXth sW5NVZecEcivbKD7LLkaW4x2hbMpVxNfyxedQSj5cYpwINJhroEDJtleci/Z 0nb9V3vj8kX6IcStqIZxXiurHxT8WgS0k0NBKrgCML7dqpW4942p1F18dOug c8oM6wIPpTe0vkVvlW6nYxybhqHdfZto646uTeC//QiWf3923uuZuqlVu71g bfTuzOte78BaH93dmNZVV+8cKJp6ZRmT9UmvfL0ZHXYnR5XO5Pq2+2Q9axf6 5PRa17pd42H2PKxcLwfz4aRXstaH0+Fp9763PjW1jdLtd55Pn3uVG3p5RS/j d/fbW44aVt7T8uRrsLa0u8Nj72vn+b5kaL27tnJctSzN6JqTuztN1w57+7dH t9+sp9JYvZuNhvrzdPToNx+v/Pps0jkfTB4rF1dP5WP//rkzGjeN/Yry2S27 d6f3/l04uGyNvh4dVaub9rM9ufM2jWDd7YSru7vy2iwfhx3r6eHOvBlsdNd3 bw72zfW+1mgrsPgfjvVhs3bT1CrL4Hqs14aT4Ov5tbt/XHl8Ou4b9+VS6eT8 /PHuZr9z0j+rHLc3l4ebx+dBq3x8aihdS1sfIpEuSme6fme1Ow2jrc0mo9W3 3tnZQ82fhuFV0Lsdf/38uas1kXgja23p++teu6t1dUUbN9dAAKzgXOsd7uta zwResLqad2AY3w4uu9UWENTSqgcnmmno0/WRPvD31csj99CY3B4o1lHj4nPF 8dWT0c03f/T1cBIa602/8Xnd1jtH82ugu+vNyycH032vu1rV5ubn1f5nT52X Go/z+dd7Zf+zuzxYNvud9YPRmxje1+rgMHTqtw/teWN6dWsHw5PTxuPDY+Pb 8fp20w+Mx465tMz+hXHbHF21HaVRuT9wBm74sJpfHN5fT2f60YnXWFTa3SO/ fXjqOYNZd7D+/Xe+HqxTM78aCHiA/1NitVr5S/rk/CqrtKpfWOb6hya8qHyJ T7CHV2oJ4RVfBM6ic9q3DqwLVo6gF9EPf0LJSlIyKqfC6zq8LfHXclsqttWM vs/dMwG26yiwb8CaAE1UU8vso8rKrFktIfakWsP+s+qngm6Uod5aPd9eBQai xgO5tPr0sgz/bkUvMx9UE2Js6yShLXyunj6WGXarDp2qtKB0Wf703EfjG/T9 JUcu/np7+2u282IA2ZfwqgqkLZcyfQciABGL+15tvN53z5/Y0QZUeQBqCUZQ K8vUwueq325GnTfolNhfffAa3zGKOna4lRlFHXqqNopHUW+9ZQbm83T/K9D9 RjVhunz3O+JQXUN7R+/Tr+BFExi7UsDYTWBANe71Vd+gU5ZK5f1Sdb9cKgOB y18qjS8wRYg2UkuVF4vX0sVz3VDVYn5XywX8rpa387ta/m5+V8s/l9/VSgG/ q5Xt/K5WfpDf1erP53e1VsDvam07v6u17+V3tf6353e1UWcwpDyjNaDXaj0Z ZvJLU4UX0liLhPw5oenQD8gI+DJTYWAtVD+1l6oAN3EJNqSvYgUVWEplVmKV Wk410BhaDShQjV4lt/nkC5eqrKQys8TaJmsAoRtMa7KqgZKl0YYFx2BlNmrM KLFGhTVr+QpMnVk6a5dZG8YC/9ZYrclKTVYxmd5k5TYzTaAnq0AjTaZp+Qqs CjMM1mywWpu1S/hFu8HaGiubTCuzegm/gxbqZWbWmZnTyAwbhl+qLVZusKaF uk5tsEqdaSX8qGkwXWd6hYEAgm7p9YIe1FFLw0BKQAYYsQbNIGEMqLWO3wHD 6tBFlTU1GFS+ghZUoGPn8T8GK1nMqMFYmQUjrqKmxg4ZzKqxeptxRGmGiBZr 6UimhsFUi9WgsTI1z6egDSyNZaDuqgazk68A2oCem2ArwHdtVrHwTzBJ2lQT vK/oOL1NmEmgk1pAxDLT20g14AMzN8Q/lQqaCXXB/n+toM1UgdKsXi1YEZUK COtysfytVJHVX1n9wYoA7bBcktuquBwAEayCPVRBq6CcEsXpSz3BMbWXAaU1 Amq1IYva/BdFAgMfYCgDGApWSQt5EYQDcDisVhih1UIDSLNw7usmmhJGdVs1 wAANk7XaTLeKixQIJyI72gZqrZiSDfV1StLtRgYPZfGz2iMqtoCKMBzJ6sVH Pzs7sbRT1r+4suB3lNS1t1O5metRusfNSra9XJtbCFhIn+1kQ6NFrRaTrSlZ /9vIBo76FV0sHZMLJG2llet+mlwtJGf17eRqYU/K6RElwhpUw2rBr7lxw2Ab YX5FjHqp9KvOPkIxVqQQXiBU7mWRBSi/+FOplsqREpaoWi2hWSXMlp/i5UBL sOzUCokR6UK6LBWrILvBaMop7GoZmLEeM69w1fIjrlso+UCJVJsMJgQUUUlj pRqKX3AKWxYzVdYG6QmaUWdmwQrXGyikQdzjP1oov0s6yeEKA1sTPoX/gI6t qrh3oNUqUB810k/we5lUnsmaoAw0prZRg4A+A/Wnt7BzlTbImwLh3UapBIYj KJGqxaw2a2kgrFm9Qj+BFmphfSB+wHktVwqsgJZSxWVRr79KLtCRYCGAOwNL zGgwvcYsUF4NlImoJnXUMTCjJpBDBdGZr8Aw8Yt2C9Ua/AMGrJdQ9wOtLANp D6oIdC4oTmAPs6Cz1SoaJaDZwC4BotZowI0mThjIKzA6NJC0ZRTPLRVmI18B EKqushZ6KKyqM62C1AWjA9gNZH1dx3+AtVNvUn0FEwb2Ub396kKR/vyTByl+ waMQ46BkcfhzsS1uyc8EF5hKN8bexjddJKfdS5iW5J57aZ81j8++HNbc0ols VLNcq78U1XxnUFMvPxvwYhMFNS3N9tfmGwObihxf/J7AppIKYhYHNofdC299 oFHLpqm3qwO3FHb702+nB72V8vV2Oh3c6sHXvv61q3cP9A2PwWkTK47HaWvr UCt1NN3qzC7P3fOwerIfOpv7kXVxqTxtPOf67nNrUDn7fPtwv+zen3QvhjdP A+v5wrQ2VXXgTof9xfKyc9KZX15v5v3erKX3vn6r1HtLY3mk9BbH91emftbV SxQuNCe9G12/GIDncdfed8at+/Fl6/P58OJgPTVGTkM1tTHS5fCyax2Y2o0y 0S/P1tPe0d3h4NuDeb88s6uDwfWJ1a6Ux4/3WpcKX3R1bdy0tHtNy4YaFa16 0MVYo6sdGVrHC5uXd6fth8uhPwzuav2meng5P32enu+XDoxm47Ry02lWW8Zp 6dv81C4turc3SvNwYR4fXNQWj/tm6+lzv7k66eqzZfvqZn7Ym99qR+enTe2h o980tdJt4G7OjzZfx/ZX1zkz5+HC6yje4Ov5Z6d/cnrzcHDVPqmvjPAk7M3v Qv92eaIdjR8frPrN3fU342pWbdWOn1qzerfV10+Oa7f168r6jaHGaqOWDzVy //Dnhhqr6VBjudGC/2uCVFJbxRFH1Ht/i4gjuHDFEcdKUcQR7POtEcc3RDG2 RBwxfvFTI471oohjc3vEsfYG7+XliGPtbxBxbBZEHBul7RHHRvktM1AYcWz8 K0QcW8URR1Dn74o41n8s4ojrqNwsiDhi1K6eprZaRn+02OFQy2/i96J4F8bt 5TlMU/tpsburNu+ro+isrh8Je9VgtM1WfrS1Spq3pF9wif9Y2KsuOQ3FVSx9 mDSwMh7VbA0VprJGcfirUZVN2VfCXyBSymT8t8H4b6MR3yyj2YyWrYHGIdQG Jie69418BWWNAjY1+tTE+A5YjrqFVmmVhwjK+B/DQKPYKIifgZVcN9CiBDej RP8AC9askR0LA1QxxgDVQGUYEioKPrUoRlfGf1S4aVxFCxbUAzgsDQstc4xC aRgiqxYY5I0C1VNGQdssyeGeMhABzOwCTiiTFC0W9uXqG7ztV8M9ZeTCd4R7 8HDF7wr31HSUm1oDnS21gU4BOE3tOqoss4x/WhVmGsgPMGlFcTT+lFrMbKAz VOQvcgoXvAayo3itqMWUbLwhbB7jD4ppifHicrOaFlWv0RJjKeVMlELuFzqO WVqTsfP3jqm9O2qElplaLqR+RX2Dynw52KaiGngheoSZLPaOkCYluUrb5uV9 Q8+9fD0OVClXC+JAlTLGwH5uHAgDzWq19EocCAPLaiVvn1Ywq/y2wEaTsg5t 6FOdlUyMn8NCbxkYUDB0zBFYNQzBgG2rmgWqoMWa6DOg2Q76wywhc+sGahHT xBQFGA7wa8XEPIRZVIGGYgcK6tSqQXmNdgmjEBhLajJQl/DvloXVGwWREYxh tFmrgiEUi5QO2EA1DVUPqPd6C4NbINjrlM8pFyysNmg7Q6mq6tsopqK8hKpA 7YC+M5pML2OeA/oOugjWplbHDEwD6FZiVkHiRa+zhobUAE2nU7ajDcquisTG GE2Lul9CKdAuTryUdQzggKYuUXgM6kCtDQoRRl7GoBJo4iqoUA1jU0XZq7qG n4JihE6isC+jPgZ5D8NpGhgUrJSwBWinBXq1IHtVayDFMq/fFgrK3Ca0BQ1X hIArhK/Fe3A5ci7MndIWYdtejPtkOvVS7KfSrP7E2I9xibEfu/5vE9DWfDeg rf2sXUctmw8t80rVJlfz6+fhQWv19eB60z28S4HaFES1cVBbx7ybaNbN+kFf da7uj2/qtYPR1fnn6bdhULls9q+M66k78fcD7yIYzexy4/rw9Lh1qxj7E3/o 3p935o/nfeN29HhebRzc+/2ZaT62yudT1Sut2hfli+EkrMwGN6dL//Tg7Maq 3zfm6rfTZUd5Wlw8tffnFwuv99CsNDpe9eCw2zmw0sGk3nG1bn5ejHqz0dJV 65UTfzN5Xjw+V1Sl2U9Hk94bTFK6WpW3xFFuFvDC4cTU+rzSK8s0iSd8fWK1 9d7QNPrauT55iP5eAxGvLKBzLiwF9R4TAm5ypLeNb111sgy+Dkelr6PmxU3z cP/zSfWsM+jbykG47Jd7d6XlqH6kr1vqrP3t1Hi6/9xWH1q3R/7xZU+7vtbs /UHlyP56Flz4h/VHdzo7q3TvjN7Vw4lilObzk9Wgf2Eelh8/1zXV3gw718ed 5UXloP75fGWb5at55fyy3Whbswfvqnp69zCYqZeH+83288DcKPsn0E13Wq45 jakWbib7t0Hnjei3ZiMXkqpWshr639Fv/45++3f023+H6Ld6vhv/jn77N4F+ K1cyo0D0W7nYjf9R9Ft1W/fTltuPhAKbIH7VgsBns7wVAYdc9YMIOFQsryLg wObMIODy6oECKeDNgUfwxhAgeDHgBYA7ozcxfQ1+GvA64gLQc8dgXKmNHgim 0AuwVzqFCMHRq5qYsgZHAYQGKChwGtoWIrfAnQKvwmyhK2bqBRXUUJSDJtLa 6E+UdAxFlgmwBdUYbcQF1HX8R9Vg5SIMnonNQ2MVwg2Au2NWML8N2tAiOF29 wiwVvUlwUMsF0RIVPVqMr0OTJcI6ICahhsXBh4MBVuuo7urkSjVzqW+GlILi WhPz/lWeiq9i8BJjaJSHB6cVmATxEECtgh7kI5vg95dKCbJDYM5KNPEFPFgp bQ9CVko/IwhZUd8XhKyo3xmELGkYZtRKOKMtk5kU1G3UycOtIRikQZAQ4KyS wayCoLSYkzbGGsCHbW+JU24Lg1W2ByErlZ8ThKxU3xeErFRfDkJWqv/DBCEb LwQh35K3ewXx90oQsvnOIGTzJwYhK82Mgkuh9uqvD30Lak99ecgtVF7vQe3V syRKofYab0PtRYC90vsAe1VUbGqxmCNk3ms0cp5QxKXJVGl8go8bab57hQzV Uitrfac7o6ZgCNs7hIfwXroTOnKaFHudqdAtkHjw79YW6rx3VREYcAuOtooJ Xdle3tbLU8+gKyYzvQTRoyLuskq+5DsoiPjp7No5vTo5+ZsjOBGenUdwEjD7 JyM4a6jBqc6XEJy1arJdQe4RmtFvQHCqlN1sGmjggO6sGxThbqAJAv8w22iA YaBaxbh5uyCMrFuI2QcW0atowIAJBf9bq6DJBlYFGmY1hN834U8wzwrMn0YN zS0w78BgKlGmAFS3SnBQUME1A/GYBiVg0aQpsOCAAtASaGxMIJexJjD2QcdD zzUDk7hgGjY1tEarFjMLjFCjrtTQt3sDubAXOmFUW2jdlS3cAIFbBxDAhMFv nYCZoAnA8tUK2mph6hPVIjjBGlmOYO9BZ8Foge/qtPcDyNHSMRdetGMDKAMG MeZW6rihAebPKlGCpIpWd41UrtrG2UIcbkGmRC/RjhMD/4HbMsjeRhVOaFQw dUESmgaZUCZrFJjcpQJzM/Xi5Zh9dLl6HKUvuKItRl++DKlU7IH36IgYeffA Wt8+66NuO1jf9LVTfTKbTB8m+tde19ImVlvTepOz5exgpNrasD48fGzVegcH p+1aV52engYd5db/Ni31erOmGT4aZ57VsUbHg+Ou3ryvHLX2h4fTdX/6tH/b nK2GN6PxIHSNWj2crfdvrGtTm/R05dujdirHFFkrG1MsI2A5Izsw0shalXyY BMQkWP8F5jpFIZtbgnKUh03psdSvmfAGPgXm/NSmgx1Ax6l1LqigXpTcVe5x MhL77xG/iPGpbJXvxZ+Bv9RqofvUIJR4k/ZRaQ0UJLDMQKighGyigwZC1Npi ZhomuV5V2qPUxOSUrmHODCEjHPFRQtcPNxeB9aopKHfe3VNwQaskPDXCosP6 gmVsEDC6Tf1FZHwVFxeI1naBDMMHliSsaauBNAehCMLEMlFMgJBpaJifA1lY aeMWMdQZFYW1JIgjf/JAx3xD36X2pD8Lk3CB8/qKji78fseS7nTMxdrTtWPD 0GqT9WRydiWnLLSeZcG7Npab9A09OO6kkixKNsvSvJicd++1zamplbpm56l7 362cmiObMjWdA73bflibvbuju87XjnZzZSq61oEKNatjfvt6sRjdTA7PFnpj 37nSp/cXTv/0rt8fGO163RtZ1tFYawzW9990Qz+8nG/utXGnpWzG44peHVrV 4VjdPxos2ovbcuNusnL8r8NzddrurQVS+07TDrTmBnoFPeutu8/Wpvs8LCmn 6reJJXe7ryXdTmdqTK38oHUP7oxuz7yYX8/dzqBqKvPWxrp1H8u3oef03Po4 XN6fzGf6t28XHfdzZRqO2/tnm/vR4aK9mlaaw97x3bdv/g1VcuyeD0PletW4 7AW1ZmNU/qpbh73Dcum+prXdg4Ng0FEHlc9G6+tx/bTzPDHr5uJmZq6Xl2N3 Ztn+2WQyOepThrKPGcqHAKbwYOVpXUPrdeC/1tqY3HVEGs/S1r31mWmddLUH yg3q065x0548KW1Tu+T5QK9rlE5nw8XFc8cYbTrt6+fuRXdt9QSoXFseDSun qn1TW3SsU72rV2/NfqekEEXvOUVPVQ9fqpl36/OClqOGleKWh+t23HLtvKee 9jrto9mwoj8O5hez4b1e7uoaIdmVCMquX650XdNcrdzR9HZwpA3cdmczW60u FtfmvmcvTk5Lj5aqze7uvOP9xrE1OPx6E65U5eL58vF6/Vg9rnS8582R/1xa zyqD589nT169VOutG/uj++rIPj2ZXo0ebjsno9qNem/bzxf3s+mZ97mmhPa9 fdn9WhpejGsPX+vW0fnp583xmT59NvSpqY0oT9irWu1J78pYnU32l5Wro1v7 LnTCTb3pdZUaCJTW2FofrunUjHtdn6zbnnZ1H3SujBu9XF9q1Xp/vjooq5dP +qi1aFTXpkZl+3jCBi6mtWZqZ7ylJqUugW0NvaqtLV7pTNfWnCfWd7Dwrg61 NazI9d0R/q3gi64Ga1/rtDUzk+KGet2Jtp7c3Rm9i963+9O748HB7eHo4HZs XT/q+/vuZ8V0D0rlqW9ftR4OTo9vHbc3PB99vbDve8Hd/nT09fx6Y28eHrT2 de/gsdza3Mz7vmU/ffar3td++HygaA/tI2MdHi3dxrxU6j21/P3V5PQmWBjt S/f4avS0erxvzCet2VH4XJo6TxdHX4/bZ+bN0UFtdDXdBxoMy+vm4wa76Y1W t6tq72TonasNQ/v9d9l2aJXz+UjhiVunV13rQuuDdsDtsIi8IE0c5SNVsBoK 0ntqClVe7KXpGP8o9NFI6ddZqxQbJC/6Zxg+bba2ZK1AGauN+jYTBSNo2WjV X8s0NAyg5QNV/5bCgjyNl/GX8TmgG+LoHo8Xs10IplEr24N1aLKr5Va21VSJ ato6LCxTz1qJhaUw9FtQEz45BtpGkOh53ahsYXw0N7382W5cRs+fCtbGsrQT vX0Dj/wUc/P9Biel7b6/1z/F9Hy/8alS6rla1Ou3GKHRg4BzlEsFs47xZ5W2 TNTyP+aWU2VL8hgDlOldAHHtmHzDeGRR/fkW1NKWBfvS4Lb+uPWnraG5MmZQ 0jFDGUhM0j0TMXzzEpXjUxhILohPVbaGWsuYgS+laPhCvKqMJzqUXkBEIwql mpM5WwMy/CmVcHnB6gXnTStTNMrCjbAtHUMZTYJYYkqRwIlmARSRP6pFOxos ykmQcjB0DD/Bwq9rtBG4jPlE3NEMcqAgtsKfhoHwSYPyl6DNgFFaBgbRUAi0 cRmCj46AVw03Pmtbq6nXlTIeCvA91ICWm4TKLJsoyywLIfi4r9rC3sHSNk0k F27h2KrJzBIGkuomOvsWHXVSL5MA1DG5Ay+hYpQydFJJbesyL9MuYUxsWnRI iIbxQlj0GqWGQTHXyhikA4LgzoCtc6MXYHb5s3XJVCpl6FeKM/myR1B0raVu ZUKEQxMgjG0vEcPDXiiTy5xmulFLQcfSz1YgWXbwlVrhwRByHSoUquczDvke 11KQs/TzboX/Xfi03OjqElpte8cbpSw6RS7Xj/N/W4yZTGU5nE/6eSvqhx8B UqjZ+fNWDFD6eUGtRAXosJC8pRwNlejRzKCFsoWk9GEOO5R+3s0Z+LwENqq0 cmCj9PMe6FH6eQPxqqVaOk0oP5x4POFXYFZEhaS8Yi7pn37eCGDC8zy2LGD+ vAO+lx3wK0VeKYAJQgnol35SqcLmNp/jdRBgtVp5x8cvQwJz3a9JAMHt3a+/ KmKq9beKmGr9J4mYav3vJWKqjVdFTLXxVhFTbfxri5hq8+8qYlop5GP6EcRr ZXCQ2UIJ8Vo/R8TUSjmMZPp5J2IyO+hXirwqZmplCVuZfiRq1MoppOUL5TK4 y/TzHQz3GkyzVsnANH+4xbejOtMP0LKawnimn5cQn/z5YdynaOhH0Z+imh/F gPLnh5Gg/PlhPKgY1I+iQvlTtOtdfv5U6lUJKZp+OG60Xq3kQ5LRI62oenYr +wslt3pG/Pkucf8qCLWe3wmfafalkHa9aF/89u///pFo+XlV+hInZHfQpx95 AvP76dPPd03gG7Cv9fwG/EzDL05h0Xb87YMs3pyffv5NoGTTzxvm+o0M0chu 6k8/Eq0a+S3+6ee7GOJFOG4jfyZA+kkhVRv5EwIyHXyJcRpF5wVsI8ZPpH/5 RYtMpn85B/FNP28E/DYqOcBv+kkTtZKD/2ZafZGolQIwcKa1d0KD08/rQOH0 87Y5qZa2RwfSc1L9W6yJbRjkRjWHQc609uJcVAsQydtHVivEJ/+E0eHznaDm 9PMTF2FROjd5ZLLUc2Do9PN9Xuzr6OlGI4eezjT84tw3CrDU6ef17Ct/3kTQ V4q86ge+8DPMVqNZzMjyPDUltHb6eecM/XCIGzrcimHe6eeFJFqjVZXPqN82 zFYKAp5+Xkkh/TAsXIzhR8Hh/PlhiDh/fhgozh+jrjTr1e8m7Q9DyPnzw0By /vwwnJw/Pwwq508eWp5+Xln8W398f7q94PXPAs4ybfiw8NYzZzShGx6VP74s VvOB4zuj3z+M7VngfPiTnzDDHSJx/bwb4C3pgbgVFRG08d2GazeY8ntq7cUD 02bOEzMde+gt6Ma8i429YIcrP4HTuz5be/4DvynbG62G/K498L0m7sKeRe1E V4EXXZaYOvMmut1y7we6rZzbqxk73jy7j3a4wy5WQcAO8fJEZwN/eQN2CU7A CG+DxD/nMCTTXmxm7pqux1ZunMVow3TfWy+kUeIFjM462GFjxxnhfaD8Lm1x 67C4K1TucpqSXXsCNic73YAD4s3pYJ5LjV2KSyd3WGcx3NtRjuzJveOE7NJb jKZY6Nob2WO8BfjA91ZLdvE/m7xZ0350R8xaTGCuJ3S1redjXB4+3lFOwtGe 1HO8s9V3ByvqZHQHcTxBdLu7uJBU3FnJL9HbU05cOtdajn3j3apjmDWX36AK VBnPnGEYX4bs+f/P//JfArmMYvNf8VpncR4R3YS5tgO2xCBnMMULu/9/McU7 nC3wAAA=[rfced] Please review the "type" attribute of each sourcecode element in the XML file to ensure correctness. If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave the "type" attribute not set. In addition, review each artwork element. Specifically, should any artwork element be tagged as sourcecode or another element? --> <!--[rfced] Should instances of "OCSP protocol" be updated to simply "OCSP" to avoid redundancy (if expanded, "OCSP protocol" would read "Online Certificate Status Protocol protocol")? Please review and let us know if any updates are needed. Original: Future versions of the OCSP protocol may provide a way for the client to know whether the responder supports nonces or does not support nonces. ... The authors of this version of the document wish to thank Alex Deacon and Ryan Hurst for their work to produce the original version of the lightweight profile for the OCSP protocol. --> <!--[rfced] Abbreviations a) Both the expansion and the acronym for the following term are used throughout the document. Would you like to update to using the expansion upon first usage and the acronym for the rest of the document? certification authority (CA) b) We note that "AIA" has been expanded two different ways in the document. Please review and let us know which version should be used for consistency. authorityInfoAccess (AIA) vs. authorityInformationAccess (AIA) --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether "man-in-the-middle" should be updated. --> </rfc>