rfc9919.original.xml   rfc9919.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
3) --> -ietf-lamps-rfc5019bis-12" number="9919" category="std" consensus="true" submiss
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ionType="IETF" updates="" obsoletes="5019" tocInclude="true" sortRefs="true" sym
-ietf-lamps-rfc5019bis-12" category="std" consensus="true" submissionType="IETF" Refs="true" version="3" xml:lang="en">
obsoletes="5019" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.23.0 -->
<front> <front>
<title abbrev="Lightweight OCSP Profile Update">Updates to Lightweight OCSP
Profile for High Volume Environments</title> <!--[rfced] Please note the title of the document has been updated as
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc5019bis-12"/> 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 Lightweight O
nline Certificate Status Protocol (OCSP) Profile for High Volume Environments</t
itle>
<seriesInfo name="RFC" value="9919"/>
<author fullname="伊藤 忠彦" asciiFullname="Tadahiko Ito"> <author fullname="伊藤 忠彦" asciiFullname="Tadahiko Ito">
<organization>SECOM CO., LTD.</organization> <organization>SECOM CO., LTD.</organization>
<address> <address>
<email>tadahiko.ito.public@gmail.com</email> <email>tadahiko.ito.public@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Clint Wilson"> <author fullname="Clint Wilson">
<organization>Apple, Inc.</organization> <organization>Apple, Inc.</organization>
<address> <address>
<email>clintw@apple.com</email> <email>clintw@apple.com</email>
skipping to change at line 39 skipping to change at line 71
<address> <address>
<email>corey.bonnell@digicert.com</email> <email>corey.bonnell@digicert.com</email>
</address> </address>
</author> </author>
<author fullname="Sean Turner"> <author fullname="Sean Turner">
<organization>sn3rd</organization> <organization>sn3rd</organization>
<address> <address>
<email>sean@sn3rd.com</email> <email>sean@sn3rd.com</email>
</address> </address>
</author> </author>
<date year="2024" month="September" day="13"/> <date year="2026" month="January"/>
<keyword>Internet-Draft</keyword>
<abstract> <area>SEC</area>
<?line 48?> <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>
<t>This specification defines a profile of the Online Certificate Status <t>This specification defines a profile of the Online Certificate Status
Protocol (OCSP) that addresses the scalability issues inherent when Protocol (OCSP) that addresses the scalability issues inherent when
using OCSP in large scale (high volume) Public Key Infrastructure using OCSP in large scale (high volume) Public Key Infrastructure
(PKI) environments and/or in PKI environments that require a (PKI) environments and/or in PKI environments that require a
lightweight solution to minimize communication bandwidth and client- lightweight solution to minimize communication bandwidth and client-
side processing.</t> side processing.</t>
<t>This specification obsoletes RFC 5019. The profile specified in RFC 501 9 <t>This specification obsoletes RFC 5019. The profile specified in RFC 501 9
has been updated to allow and recommend the use of SHA-256 over SHA-1.</t> has been updated to allow and recommend the use of SHA-256 over SHA-1.</t>
</abstract> </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> </front>
<middle> <middle>
<?line 62?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The Online Certificate Status Protocol <xref target="RFC6960"/> specifi es a mechanism <t>The Online Certificate Status Protocol <xref target="RFC6960"/> specifi es a mechanism
used to determine the status of digital certificates, in lieu of used to determine the status of digital certificates, in lieu of
using Certificate Revocation Lists (CRLs). Since its definition in using Certificate Revocation Lists (CRLs). Since its definition in
1999, it has been deployed in a variety of environments and has 1999, it has been deployed in a variety of environments and has
proven to be a useful certificate status checking mechanism. proven to be a useful certificate status checking mechanism.
(For brevity, the term "OCSP" is used herein to denote the (For brevity, the term "OCSP" is used herein to denote the
verification of certificate status; however, it should be noted verification of certificate status; however, it should be noted
that this protocol is employed solely to ascertain the that this protocol is employed solely to ascertain the
revocation status of a certificate.)</t> revocation status of a certificate.)</t>
<t>To date, numerous OCSP deployments have been implemented to provide tim ely <t>To date, numerous OCSP deployments have been implemented to provide tim ely
and secure certificate status information, crucial for high-value and secure certificate status information, crucial for high-value
electronic transactions and the handling of highly sensitive information, electronic transactions and the handling of highly sensitive information,
such as within the banking and financial sectors. such as within the banking and financial sectors.
Therefore, the requirement for an OCSP Therefore, the requirement for an OCSP
responder to respond in "real time" (i.e., generating a new OCSP responder to respond in "real time" (i.e., generating a new OCSP
response for each OCSP request) has been important. In addition, response for each OCSP request) has been important. In addition,
these deployments have operated in environments where bandwidth usage these deployments have operated in environments where bandwidth usage
is not an issue, and have run on client and server systems where is not an issue and have run on client and server systems where
processing power is not constrained.</t> processing power is not constrained.</t>
<t>As the use of PKI continues to grow and move into diverse <t>As the use of PKI continues to grow and move into diverse
environments, so does the need for a scalable and cost-effective environments, so does the need for a scalable and cost-effective
certificate status mechanism. Although OCSP as currently defined and certificate status mechanism. Although OCSP as currently defined and
deployed meets the need of small to medium-sized PKIs that operate on deployed meets the need of small to medium-sized PKIs that operate on
powerful systems on wired networks, there is a limit as to how these powerful systems on wired networks, there is a limit as to how these
OCSP deployments scale from both an efficiency and cost perspective. OCSP deployments scale from both an efficiency and cost perspective.
Mobile environments, where network bandwidth may be at a premium and Mobile environments, where network bandwidth may be at a premium and
client-side devices are constrained from a processing point of view, client-side devices are constrained from a processing point of view,
require the careful use of OCSP to minimize bandwidth usage and require the careful use of OCSP to minimize bandwidth usage and
client-side processing complexity. <xref target="OCSPMP"/></t> client-side processing complexity <xref target="OCSPMP"/>.</t>
<t>PKI continues to be deployed into environments where millions if not <t>PKI continues to be deployed into environments where millions if not
hundreds of millions of certificates have been issued. In many of hundreds of millions of certificates have been issued. In many of
these environments, an even larger number of users (also known as these environments, an even larger number of users (also known as
relying parties) have the need to ensure that the certificate they relying parties) have the need to ensure that the certificate they
are relying upon has not been revoked. As such, it is important that are relying upon has not been revoked. As such, it is important that
OCSP is used in such a way that ensures the load on OCSP responders OCSP is used in such a way that ensures the load on OCSP responders
and the network infrastructure required to host those responders are and the network infrastructure required to host those responders are
kept to a minimum.</t> kept to a minimum.</t>
<t>This document addresses the scalability issues inherent when using <t>This document addresses the scalability issues inherent when using
OCSP in highly scaled PKI environments by defining a message OCSP in highly scaled PKI environments by defining a message
profile and clarifying OCSP client and responder behavior that will profile and clarifying OCSP client and responder behavior that will
permit:</t> permit:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<li>
<t>OCSP response pre-production and distribution.</t> <t>OCSP response pre-production and distribution.</t>
</li> </li>
<li> <li>
<t>Reduced OCSP message size to lower bandwidth usage.</t> <t>Reduced OCSP message size to lower bandwidth usage.</t>
</li> </li>
<li> <li>
<t>Response message caching both in the network and on the client.</t> <t>Response message caching both in the network and on the client.</t>
</li> </li>
</ol> </ol>
<t>It is intended that the normative requirements defined in this <t>It is intended that the normative requirements defined in this
skipping to change at line 132 skipping to change at line 165
protocol. Thus, clients may need to use out-of-band mechanisms (e.g., protocol. Thus, clients may need to use out-of-band mechanisms (e.g.,
agreed upon arrangements between operators of OCSP responders and OCSP agreed upon arrangements between operators of OCSP responders and OCSP
clients) to determine whether a responder conforms to the profile clients) to determine whether a responder conforms to the profile
defined in this document. Regardless of the availability of such defined in this document. Regardless of the availability of such
out-of-band mechanisms, this profile ensures that interoperability will out-of-band mechanisms, this profile ensures that interoperability will
still occur between an OCSP client that fully conforms with <xref target="RFC696 0"/> still occur between an OCSP client that fully conforms with <xref target="RFC696 0"/>
and a responder that is operating in a mode as described in this and a responder that is operating in a mode as described in this
specification.</t> specification.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
<?line -18?> </t>
</section>
</section>
<section anchor="ocsp-message-profile"> <section anchor="ocsp-message-profile">
<name>OCSP Message Profile</name> <name>OCSP Message Profile</name>
<t>This section defines a subset of OCSPRequest and OCSPResponse <t>This section defines a subset of OCSPRequest and OCSPResponse
functionality as defined in <xref target="RFC6960"/>.</t> functionality as defined in <xref target="RFC6960"/>.</t>
<section anchor="req-profile"> <section anchor="req-profile">
<name>OCSP Request Profile</name> <name>OCSP Request Profile</name>
<section anchor="certid"> <section anchor="certid">
<name>OCSPRequest Structure</name> <name>OCSPRequest Structure</name>
<t>Provided for convenience here, a partial extract of the <t>A partial extract of the
ASN.1 structure corresponding to the OCSPRequest with the relevant ASN.1 structure corresponding to the OCSPRequest with the relevant
CertID as defined in <xref target="RFC6960"/>:</t> CertID as defined in <xref target="RFC6960"/> is provided here for convenience:<
<artwork><![CDATA[ /t>
<sourcecode type="asn.1"><![CDATA[
OCSPRequest ::= SEQUENCE { OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest, tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL } optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE { TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1, version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL, requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request, requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL } requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Request ::= SEQUENCE { Request ::= SEQUENCE {
reqCert CertID, reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE { CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier, hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of issuer's DN issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber } serialNumber CertificateSerialNumber }
]]></artwork> ]]></sourcecode>
<t>OCSPRequests that conform to the profile in this document <bcp14>MU ST</bcp14> <t>OCSPRequests that conform to the profile in this document <bcp14>MU ST</bcp14>
include only one Request in the OCSPRequest.RequestList structure.</t> include only one Request in the OCSPRequest.RequestList structure.</t>
<t>The CertID.issuerNameHash and CertID.issuerKeyHash fields contain h ashes <t>The CertID.issuerNameHash and CertID.issuerKeyHash fields contain h ashes
of the issuer's distinguished name (DN) and public key, respectively. of the issuer's distinguished name (DN) and public key, respectively.
OCSP clients that conform with this profile <bcp14>MUST</bcp14> use SHA-256 as d OCSP clients that conform with this profile <bcp14>MUST</bcp14> use SHA-256, as
efined defined
in <xref section="2.2" sectionFormat="of" target="RFC5754"/> as in <xref section="2.2" sectionFormat="of" target="RFC5754"/>, as
the hashing algorithm for the CertID.issuerNameHash and the the hashing algorithm for the CertID.issuerNameHash and the
CertID.issuerKeyHash values.</t> CertID.issuerKeyHash values.</t>
<t>Older OCSP clients which provide backward compatibility with <t>Older OCSP clients that provide backward compatibility with
<xref target="RFC5019"/> use SHA-1 as defined in <xref target="RFC3174"/> as the <xref target="RFC5019"/> use SHA-1, as defined in <xref target="RFC3174"/>, as t
hashing he hashing
algorithm for the CertID.issuerNameHash and the algorithm for the CertID.issuerNameHash and the
CertID.issuerKeyHash values. However, these OCSP clients <bcp14>MUST</bcp14> CertID.issuerKeyHash values. However, these OCSP clients <bcp14>MUST</bcp14>
transition from SHA-1 to SHA-256 as soon as practical.</t> transition from SHA-1 to SHA-256 as soon as practical.</t>
<t>Clients <bcp14>MUST NOT</bcp14> include the singleRequestExtensions structure.</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 str ucture. If a <t>Clients <bcp14>SHOULD NOT</bcp14> include the requestExtensions str ucture. If a
requestExtensions structure is included, this profile RECOMMENDS that requestExtensions structure is included, it is <bcp14>RECOMMENDED</bcp14> by thi
it contain only the nonce extension (id-pkix-ocsp-nonce). See s profile that
the 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 <xref target="fresh"/> for issues concerning the use of a nonce in high-volume
OCSP environments.</t> OCSP environments.</t>
</section> </section>
<section anchor="signed-ocsprequests"> <section anchor="signed-ocsprequests">
<name>Signed OCSPRequests</name> <name>Signed OCSPRequests</name>
<t>Clients <bcp14>SHOULD NOT</bcp14> send signed OCSPRequests. Respond ers <bcp14>MAY</bcp14> ignore <t>Clients <bcp14>SHOULD NOT</bcp14> send signed OCSPRequests. Respond ers <bcp14>MAY</bcp14> ignore
the signature on OCSPRequests.</t> the signature on OCSPRequests.</t>
<t>If the OCSPRequest is signed, the client <bcp14>SHALL</bcp14> speci fy its name in <t>If the OCSPRequest is signed, the client <bcp14>SHALL</bcp14> speci fy its name in
the OCSPRequest.requestorName field; otherwise, clients <bcp14>SHOULD NOT</bcp14 > the OCSPRequest.requestorName field; otherwise, clients <bcp14>SHOULD NOT</bcp14 >
include the requestorName field in the OCSPRequest. OCSP responders include the requestorName field in the OCSPRequest. OCSP responders
<bcp14>MUST</bcp14> handle unsigned OCSP requests that contain the <bcp14>MUST</bcp14> handle unsigned OCSP requests that contain the
requestorName field, as if the requestorName field were absent.</t> requestorName field, as if the requestorName field were absent.</t>
</section> </section>
</section> </section>
<section anchor="ocsp-response-profile"> <section anchor="ocsp-response-profile">
<name>OCSP Response Profile</name> <name>OCSP Response Profile</name>
<section anchor="ocspresponse-structure"> <section anchor="ocspresponse-structure">
<name>OCSPResponse Structure</name> <name>OCSPResponse Structure</name>
<t>Provided for convenience here, a partial extract of the <t>A partial extract of the
ASN.1 structure corresponding to the OCSPResponse with the relevant ASN.1 structure corresponding to the OCSPResponse with the relevant
CertID as defined in <xref target="RFC6960"/>:</t> CertID as defined in <xref target="RFC6960"/> is provided here for convenience:<
<artwork><![CDATA[ /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 { OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus, responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
ResponseBytes ::= SEQUENCE { ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER, responseType OBJECT IDENTIFIER,
response OCTET STRING } response OCTET STRING }
The value for response SHALL be the DER encoding of BasicOCSPResponse. The value for response SHALL be the DER encoding of
BasicOCSPResponse.
BasicOCSPResponse ::= SEQUENCE { BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData, tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier, signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING, signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
ResponseData ::= SEQUENCE { ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1, version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID, responderID ResponderID,
producedAt GeneralizedTime, producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse, responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL } responseExtensions [1] EXPLICIT Extensions OPTIONAL }
SingleResponse ::= SEQUENCE { SingleResponse ::= SEQUENCE {
certID CertID, certID CertID,
certStatus CertStatus, certStatus CertStatus,
thisUpdate GeneralizedTime, thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL } singleExtensions [1] EXPLICIT Extensions OPTIONAL }
]]></artwork> ]]></sourcecode>
<t>Responders <bcp14>MUST</bcp14> generate a BasicOCSPResponse as iden tified by the <t>Responders <bcp14>MUST</bcp14> generate a BasicOCSPResponse as iden tified by the
id-pkix-ocsp-basic OID. Clients <bcp14>MUST</bcp14> be able to parse and accept a 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</bcp 14> BasicOCSPResponse. OCSPResponses that conform to this profile <bcp14>SHOULD</bcp 14>
include only one SingleResponse in the include only one SingleResponse in the
ResponseData.responses structure, but <bcp14>MAY</bcp14> include ResponseData.responses structure but <bcp14>MAY</bcp14> include
additional SingleResponse elements if necessary to improve response additional SingleResponse elements if necessary to improve response
pre-generation performance or cache efficiency, and pre-generation performance or cache efficiency and
to ensure backward compatibility. For instance, to ensure backward compatibility. For instance,
to provide support to OCSP clients which do not yet support the to provide support to OCSP clients that do not yet support the
use of SHA-256 for CertID hash calculation, the OCSP responder use of SHA-256 for CertID hash calculation, the OCSP responder
<bcp14>MAY</bcp14> include two SingleResponses in a BasicOCSPResponse. <bcp14>MAY</bcp14> include two SingleResponses in a BasicOCSPResponse.
In that BasicOCSPResponse, the CertID of one of the SingleResponses In that BasicOCSPResponse, the CertID of one of the SingleResponses
uses SHA-1 for the hash calculation, and the CertID in the other uses SHA-1 for the hash calculation, and the CertID in the other
SingleResponse uses SHA-256. OCSP responders <bcp14>SHOULD NOT</bcp14> distribut e SingleResponse uses SHA-256. OCSP responders <bcp14>SHOULD NOT</bcp14> distribut e
OCSP responses that contain CertIDs that use SHA-1 if the OCSP OCSP responses that contain CertIDs that use SHA-1 if the OCSP
responder has no clients that require the use of SHA-1. responder has no clients that require the use of SHA-1.
Operators of OCSP responders may consider logging the hash Operators of OCSP responders may consider logging the hash
algorithm used by OCSP clients to inform their determination of algorithm used by OCSP clients to inform their determination of
when it is appropriate to obsolete the distribution of OCSP responses when it is appropriate to obsolete the distribution of OCSP responses
skipping to change at line 300 skipping to change at line 361
id-pkix-ocsp-nocheck extension, as defined in <xref target="RFC6960"/>, to indic ate id-pkix-ocsp-nocheck extension, as defined in <xref target="RFC6960"/>, to indic ate
to the client that it need not check the certificate's status. In to the client that it need not check the certificate's status. In
addition, it is <bcp14>RECOMMENDED</bcp14> that neither an OCSP authorityInfoAcc ess addition, it is <bcp14>RECOMMENDED</bcp14> that neither an OCSP authorityInfoAcc ess
(AIA) extension nor cRLDistributionPoints (CRLDP) extension be (AIA) extension nor cRLDistributionPoints (CRLDP) extension be
included in the OCSP responder's certificate. Accordingly, the included in the OCSP responder's certificate. Accordingly, the
responder's signing certificate <bcp14>SHOULD</bcp14> be relatively short-lived and responder's signing certificate <bcp14>SHOULD</bcp14> be relatively short-lived and
renewed regularly.</t> renewed regularly.</t>
<t>Clients <bcp14>MUST</bcp14> be able to identify OCSP responder cert ificates using <t>Clients <bcp14>MUST</bcp14> be able to identify OCSP responder cert ificates using
the byKey field and <bcp14>SHOULD</bcp14> be able to identify OCSP responder the byKey field and <bcp14>SHOULD</bcp14> be able to identify OCSP responder
certificates using the byName field of the certificates using the byName field of the
ResponseData.ResponderID <xref target="RFC6960"/> choices.</t> ResponseData.ResponderID <xref target="RFC6960"/> choices.</t>
<t>Older responders which provide backward compatibility with <xref ta
rget="RFC5019"/> <!--[rfced] May we update this sentence as follows to clarify that the
<bcp14>MAY</bcp14> use the byName field to represent the ResponderID protocol in [RFC5019] is backward compatible, rather than the RFC itself?
, but should
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 tar
get="RFC5019"/>
<bcp14>MAY</bcp14> use the byName field to represent the ResponderID
but should
transition to using the byKey field as soon as practical.</t> transition to using the byKey field as soon as practical.</t>
<t>Newer responders that conform to this profile <bcp14>MUST</bcp14> u se the byKey <t>Newer responders that conform to this profile <bcp14>MUST</bcp14> u se the byKey
field to represent the ResponderID to reduce the size of the response.</t> field to represent the ResponderID to reduce the size of the response.</t>
</section> </section>
<section anchor="ocspresponsestatus-values"> <section anchor="ocspresponsestatus-values">
<name>OCSPResponseStatus Values</name> <name>OCSPResponseStatus Values</name>
<t>As long as the OCSP infrastructure has authoritative records for a <t>As long as the OCSP infrastructure has authoritative records for a
particular certificate, an OCSPResponseStatus of "successful" will be particular certificate, an OCSPResponseStatus of "successful" will be
returned. When access to authoritative records for a particular returned. When access to authoritative records for a particular
certificate is not available, the responder <bcp14>MUST</bcp14> return an certificate is not available, the responder <bcp14>MUST</bcp14> return an
skipping to change at line 357 skipping to change at line 433
See <xref target="cache-recs"/> for additional information on caching.</t> See <xref target="cache-recs"/> for additional information on caching.</t>
</dd> </dd>
<dt>producedAt:</dt> <dt>producedAt:</dt>
<dd> <dd>
<t>The time at which the OCSP response was signed.</t> <t>The time at which the OCSP response was signed.</t>
</dd> </dd>
</dl> </dl>
<aside> <aside>
<t>Note: The values of thisUpdate, nextUpdate, and producedAt are <t>Note: The values of thisUpdate, nextUpdate, and producedAt are
set as described in <xref section="2.5" sectionFormat="of" target="RFC6960"/>, set as described in <xref section="2.5" sectionFormat="of" target="RFC6960"/>,
and in many cases the value of thisUpdate and producedAt are and in many cases, the value of thisUpdate and producedAt are
the same.</t> the same.</t>
</aside> </aside>
<t>For the purposes of this profile, ASN.1-encoded GeneralizedTime <t>For the purposes of this profile, ASN.1-encoded GeneralizedTime
values such as thisUpdate, nextUpdate, and producedAt <bcp14>MUST</bcp14> be values, such as thisUpdate, nextUpdate, and producedAt, <bcp14>MUST</bcp14> be
expressed Greenwich Mean Time (Zulu) and <bcp14>MUST</bcp14> include seconds (i. e., expressed Greenwich Mean Time (Zulu) and <bcp14>MUST</bcp14> include seconds (i. e.,
times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values <bcp14>MUST NOT</bcp14> include fractional seconds.</t> GeneralizedTime values <bcp14>MUST NOT</bcp14> include fractional seconds.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="client-behavior"> <section anchor="client-behavior">
<name>Client Behavior</name> <name>Client Behavior</name>
<section anchor="ocsp-responder-discovery"> <section anchor="ocsp-responder-discovery">
<name>OCSP Responder Discovery</name> <name>OCSP Responder Discovery</name>
skipping to change at line 391 skipping to change at line 467
configured timeout and number of retries.</t> configured timeout and number of retries.</t>
</section> </section>
<section anchor="sending-an-ocsp-request"> <section anchor="sending-an-ocsp-request">
<name>Sending an OCSP Request</name> <name>Sending an OCSP Request</name>
<t>To avoid needless network traffic, applications <bcp14>MUST</bcp14> v erify the <t>To avoid needless network traffic, applications <bcp14>MUST</bcp14> v erify the
signature of signed data before asking an OCSP client to check the signature of signed data before asking an OCSP client to check the
status of certificates used to verify the data. If the signature is status of certificates used to verify the data. If the signature is
invalid or the application is not able to verify it, an OCSP check invalid or the application is not able to verify it, an OCSP check
<bcp14>MUST NOT</bcp14> be requested.</t> <bcp14>MUST NOT</bcp14> be requested.</t>
<t>Similarly, an application <bcp14>MUST</bcp14> validate the signature on certificates <t>Similarly, an application <bcp14>MUST</bcp14> validate the signature on certificates
in a chain, before asking an OCSP client to check the status of the in a chain before asking an OCSP client to check the status of the
certificate. If the certificate signature is invalid or the certificate. If the certificate signature is invalid or the
application is not able to verify it, an OCSP check <bcp14>MUST NOT</bcp14> be 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 requested. Clients <bcp14>SHOULD NOT</bcp14> make a request to check the status of
expired certificates.</t> expired certificates.</t>
</section> </section>
</section> </section>
<section anchor="fresh"> <section anchor="fresh">
<name>Ensuring an OCSPResponse Is Fresh</name> <name>Ensuring an OCSPResponse Is Fresh</name>
<t>In order to ensure that a client does not accept an out-of-date <t>In order to ensure that a client does not accept an out-of-date
response that indicates a 'good' status when in fact there is a more response that indicates a "good" status when in fact there is a more
up-to-date response that specifies the status of 'revoked', a client up-to-date response that specifies the status of "revoked", a client
must ensure the responses they receive are fresh.</t> must ensure the responses they receive are fresh.</t>
<t>In general, two mechanisms are available to clients to ensure a <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 response is fresh. The first uses nonces, and the second is based on
time. In order for time-based mechanisms to work, both clients and time. In order for time-based mechanisms to work, both clients and
responders <bcp14>MUST</bcp14> have access to an accurate source of time.</t> responders <bcp14>MUST</bcp14> have access to an accurate source of time.</t>
<t>Because this profile specifies that clients <bcp14>SHOULD NOT</bcp14> i nclude a <t>Because this profile specifies that clients <bcp14>SHOULD NOT</bcp14> i nclude a
requestExtensions structure in OCSPRequests (see <xref target="req-profile"/>), requestExtensions structure in OCSPRequests (see <xref target="req-profile"/>),
clients <bcp14>MUST</bcp14> be able to determine OCSPResponse freshness based on an 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 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 request <bcp14>SHOULD NOT</bcp14> reject a corresponding OCSPResponse solely on the
basis of the nonexistent expected nonce, but <bcp14>MUST</bcp14> fall back to basis of the nonexistent expected nonce but <bcp14>MUST</bcp14> fall back to
validating the OCSPResponse based on time.</t> validating the OCSPResponse based on time.</t>
<t>Clients that do not include a nonce in the request <bcp14>MUST</bcp14> ignore any <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> nonce that may be present in the response.</t>
<t>Clients <bcp14>MUST</bcp14> check for the existence of the nextUpdate f ield and <bcp14>MUST</bcp14> <t>Clients <bcp14>MUST</bcp14> check for the existence of the nextUpdate f ield and <bcp14>MUST</bcp14>
ensure the current time, expressed in GMT time as described in ensure the current time, expressed in GMT time as described in
<xref target="times"/>, falls between the thisUpdate and nextUpdate times. If <xref target="times"/>, falls between the thisUpdate and nextUpdate times. If
the nextUpdate field is absent, the client <bcp14>MUST</bcp14> reject the respon se.</t> the nextUpdate field is absent, the client <bcp14>MUST</bcp14> reject the respon se.</t>
<t>If the nextUpdate field is present, the client <bcp14>MUST</bcp14> ensu re that it is <t>If the nextUpdate field is present, the client <bcp14>MUST</bcp14> ensu re that it is
not earlier than the current time. If the current time on the client 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 is later than the time specified in the nextUpdate field, the client
<bcp14>MUST</bcp14> reject the response as stale. Clients <bcp14>MAY</bcp14> all ow configuration <bcp14>MUST</bcp14> reject the response as stale. Clients <bcp14>MAY</bcp14> all ow configuration
of a small tolerance period for acceptance of responses after of a small tolerance period for acceptance of responses after
nextUpdate to handle minor clock differences relative to responders nextUpdate to handle minor clock differences relative to responders
and caches. This tolerance period should be chosen based on the and caches. This tolerance period should be chosen based on the
accuracy and precision of time synchronization technology available accuracy and precision of time synchronization technology available
to the calling application environment. For example, Internet peers to the calling application environment. For example, Internet peers
with low latency connections typically expect NTP time with low latency connections typically expect NTP time
synchronization to keep them accurate within parts of a second; synchronization to keep them accurate within parts of a second;
higher latency environments or where an NTP analogue is not available higher latency environments or where an NTP analogue is not available
may have to be more liberal in their tolerance may have to be more liberal in their tolerance
(e.g. allow one day difference).</t> (e.g., allow one day difference).</t>
<t>See the security considerations in <xref target="sec-cons"/> for additi onal details <t>See the security considerations in <xref target="sec-cons"/> for additi onal details
on replay and man-in-the-middle attacks.</t> on replay and man-in-the-middle attacks.</t>
</section> </section>
<section anchor="transport"> <section anchor="transport">
<name>Transport Profile</name> <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 <t>OCSP clients can send HTTP-based OCSP requests using either the GET
or POST method. or POST method.
The OCSP responder <bcp14>MUST</bcp14> support requests and responses over HTTP. 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 When sending requests that are less than or equal to 255 bytes in
total (after encoding) including the scheme and delimiters (http://), total (after encoding) including the scheme and delimiters (http://),
server name and base64-encoded OCSPRequest structure, clients <bcp14>MUST</bcp14 > server name and base64-encoded OCSPRequest structure, clients <bcp14>MUST</bcp14 >
use the GET method (to enable OCSP response caching). OCSP requests 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 larger than 255 bytes <bcp14>SHOULD</bcp14> be submitted using the POST method. In
all cases, clients <bcp14>MUST</bcp14> follow the descriptions in A.1 of <xref t arget="RFC6960"/> all cases, clients <bcp14>MUST</bcp14> follow the descriptions in <xref section= "A.1" target="RFC6960"/>
when constructing these messages.</t> when constructing these messages.</t>
<t>When constructing a GET message, OCSP clients <bcp14>MUST</bcp14> base6 4-encode the <t>When constructing a GET message, OCSP clients <bcp14>MUST</bcp14> base6 4-encode the
OCSPRequest structure according to <xref section="4" sectionFormat="of" target=" RFC4648"/>. Clients 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 <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 the base64 character repertoire in the base64-encoded string. Clients
<bcp14>MUST</bcp14> properly URL-encode the base64-encoded OCSPRequest according to <bcp14>MUST</bcp14> properly URL-encode the base64-encoded OCSPRequest according to
<xref target="RFC3986"/>. OCSP clients <bcp14>MUST</bcp14> append the base64-enc oded OCSPRequest <xref target="RFC3986"/>. OCSP clients <bcp14>MUST</bcp14> append the base64-enc oded OCSPRequest
to the URI specified in the AIA extension <xref target="RFC5280"/>. For example: </t> to the URI specified in the AIA extension <xref target="RFC5280"/>. For example: </t>
<artwork><![CDATA[ <artwork><![CDATA[
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL2dA http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL2dA
deGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%3D%3D deGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%3D%3D
]]></artwork> ]]></artwork>
<t>In response to properly formatted OCSPRequests that are cachable <t>In response to properly formatted OCSPRequests that are cachable
(i.e., responses that contain a nextUpdate value), the responder will (i.e., responses that contain a nextUpdate value), the responder will
include the binary value of the DER encoding of the OCSPResponse include the binary value of the DER encoding of the OCSPResponse
preceded by the following HTTP <xref target="RFC9110"/> and <xref target="RFC911 preceded by the following HTTP <xref target="RFC9110"/> <xref target="RFC9111"/>
1"/> header fields.</t> header fields.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Content-type: application/ocsp-response Content-type: application/ocsp-response
Content-length: < OCSP response length > Content-length: < OCSP response length >
Last-modified: < producedAt HTTP-date > Last-modified: < producedAt HTTP-date >
ETag: "< strong validator >" ETag: "< strong validator >"
Expires: < nextUpdate HTTP-date > Expires: < nextUpdate HTTP-date >
Cache-control: max-age=< n >, public, no-transform, must-revalidate Cache-control: max-age=< n >, public, no-transform, must-revalidate
Date: < current HTTP-date > Date: < current HTTP-date >
]]></artwork> ]]></artwork>
<t>See <xref target="http-proxies"/> for details on the use of these HTTP header fields.</t> <t>See <xref target="http-proxies"/> for details on the use of these HTTP header fields.</t>
</section> </section>
<section anchor="cache-recs"> <section anchor="cache-recs">
<name>Caching Recommendations</name> <name>Caching Recommendations</name>
<t>The ability to cache OCSP responses throughout the network is an <t>The ability to cache OCSP responses throughout the network is an
important factor in high volume OCSP deployments. This section important factor in high volume OCSP deployments. This section
discusses the recommended caching behavior of OCSP clients and HTTP discusses the recommended caching behavior of OCSP clients and HTTP
proxies and the steps that should be taken to minimize the number of proxies and the steps that should be taken to minimize the number of
times that OCSP clients "hit the wire". In addition, the concept of times that OCSP clients "hit the wire". In addition, the concept of
including OCSP responses in protocol exchanges (aka stapling or including OCSP responses in protocol exchanges (aka stapling or
piggybacking), such as has been defined in TLS, is also discussed.</t> piggybacking), such as has been defined in TLS, is also discussed.</t>
<section anchor="caching-at-the-client"> <section anchor="caching-at-the-client">
<name>Caching at the Client</name> <name>Caching at the Client</name>
<t>To minimize bandwidth usage, clients <bcp14>MUST</bcp14> locally cach e authoritative <t>To minimize bandwidth usage, clients <bcp14>MUST</bcp14> locally cach e authoritative
OCSP responses (i.e., a response with a signature that has been OCSP responses (i.e., a response with a signature that has been
successfully validated and that indicate an OCSPResponseStatus of successfully validated and that indicates an OCSPResponseStatus of
'successful').</t> "successful").</t>
<t>Most OCSP clients will send OCSPRequests at or near the nextUpdate <t>Most OCSP clients will send OCSPRequests at or near the nextUpdate
time (when a cached response expires). To avoid large spikes in time (when a cached response expires). To avoid large spikes in
responder load that might occur when many clients refresh cached responder load that might occur when many clients refresh cached
responses for a popular certificate, responders <bcp14>MAY</bcp14> indicate when the responses for a popular certificate, responders <bcp14>MAY</bcp14> indicate when the
client should fetch an updated OCSP response by using the cache- client should fetch an updated OCSP response by using the cache-
control:max-age directive. Clients <bcp14>SHOULD</bcp14> fetch the updated OCSP control:max-age directive. Clients <bcp14>SHOULD</bcp14> fetch the updated OCSP
Response on or after the max-age time. To ensure that clients response on or after the max-age time. To ensure that clients
receive an updated OCSP response, OCSP responders <bcp14>MUST</bcp14> refresh th e receive an updated OCSP response, OCSP responders <bcp14>MUST</bcp14> refresh th e
OCSP response before the max-age time.</t> OCSP response before the max-age time.</t>
</section> </section>
<section anchor="http-proxies"> <section anchor="http-proxies">
<name>HTTP Proxies</name> <name>HTTP Proxies</name>
<t>The responder <bcp14>SHOULD</bcp14> set the HTTP header fields of the OCSP response in <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 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 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> of these HTTP header fields and the proper format of any date and time values.</ t>
<table anchor="http-headers"> <table anchor="http-headers">
skipping to change at line 530 skipping to change at line 630
<tr> <tr>
<td align="left">Last-Modified</td> <td align="left">Last-Modified</td>
<td align="left">This value specifies the date and time at which t he OCSP responder last modified the response. This date and time will be the sam e as the thisUpdate timestamp in the request itself.</td> <td align="left">This value specifies the date and time at which t he OCSP responder last modified the response. This date and time will be the sam e as the thisUpdate timestamp in the request itself.</td>
</tr> </tr>
<tr> <tr>
<td align="left">Expires</td> <td align="left">Expires</td>
<td align="left">Specifies how long the response is considered fre sh. This date and time will be the same as the nextUpdate timestamp in the OCSP response itself.</td> <td align="left">Specifies how long the response is considered fre sh. This date and time will be the same as the nextUpdate timestamp in the OCSP response itself.</td>
</tr> </tr>
<tr> <tr>
<td align="left">ETag</td> <td align="left">ETag</td>
<td align="left">A string that identifies a particular version of the associated data. This profile RECOMMENDS that the ETag value be the ASCII HE X representation of the SHA-256 hash of the OCSPResponse structure.</td> <td align="left">A string that identifies a particular version of the associated data. It is <bcp14>RECOMMENDED</bcp14> by this profile that the E Tag value be the ASCII HEX representation of the SHA-256 hash of the OCSPRespons e structure.</td>
</tr> </tr>
<tr> <tr>
<td align="left">Cache-Control</td> <td align="left">Cache-Control</td>
<td align="left">Contains a number of caching directives. <br/> * <td align="left"><t>Contains a number of caching directives.</t>
max-age = &lt; n &gt; -where n is a time value later than thisUpdate but earlier <ul spacing="normal">
than nextUpdate. <br/> * public -makes normally uncachable response cachable by <li>max-age = &lt; n &gt; - where n is a time value later than thisUpdate but ea
both shared and nonshared caches. <br/> * no-transform -specifies that a proxy rlier than nextUpdate.</li>
cache cannot change the type, length, or encoding of the object content. <br/> * <li>public - makes normally uncachable response cachable by both shared and nons
must-revalidate -prevents caches from intentionally returning stale responses.< hared caches.</li>
/td> <li>no-transform - specifies that a proxy cache cannot change the type, length,
or encoding of the object content.</li>
<li>must-revalidate - prevents caches from intentionally returning stale respons
es.</li>
</ul></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>OCSP responders <bcp14>MUST NOT</bcp14> include a "Pragma: no-cache", "Cache- <t>OCSP responders <bcp14>MUST NOT</bcp14> include the "Pragma: no-cache ", "Cache-
Control: no-cache", or "Cache-Control: no-store" HTTP header fields in Control: no-cache", or "Cache-Control: no-store" HTTP header fields in
authoritative OCSP responses.</t> authoritative OCSP responses.</t>
<t>OCSP responders <bcp14>SHOULD</bcp14> include one or more of these HT <t>OCSP responders <bcp14>SHOULD</bcp14> include one or more of these HT
TP header fields in non- TP header fields in non-authoritative OCSP responses.</t>
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 <t>For example, assume that an OCSP response has the following timestamp
values:</t> values:</t>
<artwork><![CDATA[ <artwork><![CDATA[
thisUpdate = March 19, 2023 01:00:00 GMT thisUpdate = March 19, 2023 01:00:00 GMT
nextUpdate = March 21, 2023 01:00:00 GMT nextUpdate = March 21, 2023 01:00:00 GMT
productedAt = March 19, 2023 01:00:00 GMT productedAt = March 19, 2023 01:00:00 GMT
]]></artwork> ]]></artwork>
<t>and that an OCSP client requests the response on March 20, 2023 01:00 :00 <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> GMT. In this scenario, the HTTP response may look like this:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Content-Type: application/ocsp-response Content-Type: application/ocsp-response
Content-Length: 1000 Content-Length: 1000
Date: Mon, 20 Mar 2023 01:00:00 GMT Date: Mon, 20 Mar 2023 01:00:00 GMT
Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT
ETag: "97df3588b5a3f24babc3851b372f0ba7 ETag: "97df3588b5a3f24babc3851b372f0ba7
1a9dcdded43b14b9d06961bfc1707d9d" 1a9dcdded43b14b9d06961bfc1707d9d"
Expires: Tue, 21 Mar 2023 01:00:00 GMT Expires: Tue, 21 Mar 2023 01:00:00 GMT
Cache-Control: max-age=86000,public,no-transform,must-revalidate Cache-Control: max-age=86000,public,no-transform,must-revalidate
<...> <...>
skipping to change at line 563 skipping to change at line 682
Content-Type: application/ocsp-response Content-Type: application/ocsp-response
Content-Length: 1000 Content-Length: 1000
Date: Mon, 20 Mar 2023 01:00:00 GMT Date: Mon, 20 Mar 2023 01:00:00 GMT
Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT
ETag: "97df3588b5a3f24babc3851b372f0ba7 ETag: "97df3588b5a3f24babc3851b372f0ba7
1a9dcdded43b14b9d06961bfc1707d9d" 1a9dcdded43b14b9d06961bfc1707d9d"
Expires: Tue, 21 Mar 2023 01:00:00 GMT Expires: Tue, 21 Mar 2023 01:00:00 GMT
Cache-Control: max-age=86000,public,no-transform,must-revalidate Cache-Control: max-age=86000,public,no-transform,must-revalidate
<...> <...>
]]></artwork> ]]></artwork>
<t>OCSP clients <bcp14>MUST NOT</bcp14> include a no-cache HTTP header f ield in OCSP request <t>OCSP clients <bcp14>MUST NOT</bcp14> include a no-cache HTTP header f ield in OCSP request
messages, unless the client encounters an expired response which may messages, unless the client encounters an expired response, which may
be a result of an intermediate proxy caching stale data. In this be a result of an intermediate proxy caching stale data. In this
situation, clients <bcp14>SHOULD</bcp14> resend the request specifying that prox ies situation, clients <bcp14>SHOULD</bcp14> resend the request specifying that prox ies
should be bypassed by including an appropriate HTTP header field in the should be bypassed by including an appropriate HTTP header field in the
request (i.e., Pragma: no-cache or Cache-Control: no-cache).</t> request (i.e., Pragma: no-cache or Cache-Control: no-cache).</t>
</section> </section>
<section anchor="caching-at-servers"> <section anchor="caching-at-servers">
<name>Caching at Servers</name> <name>Caching at Servers</name>
<t>In some scenarios, it is advantageous to include OCSP response <t>In some scenarios, it is advantageous to include OCSP response
information within the protocol being utilized between the client and information within the protocol being utilized between the client and
OCSP responder. OCSP responder.
Including OCSP responses in this manner has a few attractive effects.</t> Including OCSP responses in this manner has a few attractive effects.</t>
<t>First, it allows for the caching of OCSP responses on the <t>First, it allows for the caching of OCSP responses on the
OCSP responder, thus lowering the number of hits.</t> OCSP responder, thus lowering the number of hits.</t>
<t>Second, it enables certificate validation in the event the client is <t>Second, it enables certificate validation in the event the client is
not connected to a network and thus eliminates the need for clients not connected to a network and thus eliminates the need for clients
to establish a new HTTP session with the OCSP responder.</t> 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 <t>Third, it reduces the number of round trips the client needs to make
in order to complete a handshake.</t> in order to complete a handshake.</t>
<t>Fourth, it simplifies the client-side OCSP implementation by enabling <t>Fourth, it simplifies the client-side OCSP implementation by enabling
a situation where the client need only the ability to parse and a situation where the client need only the ability to parse and
recognize OCSP responses.</t> 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 <t>This functionality has been specified as an extension to the TLS
<xref target="I-D.ietf-tls-rfc8446bis"/> protocol in protocol <xref target="RFC9846"/> in
<xref section="4.4.2" sectionFormat="of" target="I-D.ietf-tls-rfc8446bis"/>, <xref section="4.4.2" sectionFormat="of" target="RFC9846"/>
but can be applied to any client-server protocol.</t> but can be applied to any client-server protocol.</t>
<t>This profile RECOMMENDS that both TLS clients and servers implement <t>It is <bcp14>RECOMMENDED</bcp14> by this profile that both TLS client s and servers implement
the certificate status request extension mechanism for TLS.</t> the certificate status request extension mechanism for TLS.</t>
<t>Further information regarding caching issues can be obtained <t>Further information regarding caching issues can be obtained
from <xref target="RFC3143"/>.</t> from <xref target="RFC3143"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec-cons"> <section anchor="sec-cons">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The following considerations apply in addition to the security <t>The following considerations apply in addition to the security
considerations addressed in <xref section="5" sectionFormat="of" target="RFC6960 "/>.</t> considerations addressed in <xref section="5" sectionFormat="of" target="RFC6960 "/>.</t>
<section anchor="replay-attacks"> <section anchor="replay-attacks">
<name>Replay Attacks</name> <name>Replay Attacks</name>
<t>Because the use of nonces in this profile is optional, there is a <t>Because the use of nonces in this profile is optional, there is a
possibility that an out of date OCSP response could be replayed, thus possibility that an out-of-date OCSP response could be replayed, thus
causing a client to accept a good response when in fact there is a causing a client to accept a good response when in fact there is a
more up-to-date response that specifies the status of revoked. In more up-to-date response that specifies the status of "revoked". In
order to mitigate this attack, clients <bcp14>MUST</bcp14> have access to an order to mitigate this attack, clients <bcp14>MUST</bcp14> have access to an
accurate source of time and ensure that the OCSP responses they accurate source of time and ensure that the OCSP responses they
receive are sufficiently fresh.</t> receive are sufficiently fresh.</t>
<t>Clients that do not have an accurate source of date and time are <t>Clients that do not have an accurate source of date and time are
vulnerable to service disruption. For example, a client with a vulnerable to service disruption. For example, a client with a
sufficiently fast clock may reject a fresh OCSP response. Similarly sufficiently fast clock may reject a fresh OCSP response. Similarly,
a client with a sufficiently slow clock may incorrectly accept a client with a sufficiently slow clock may incorrectly accept
expired valid responses for certificates that may in fact be revoked.</t> 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 <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 to know whether the responder supports nonces or does not support
nonces. If a client can determine that the responder supports nonces, 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. 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 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 NOT</bcp14> reject a corresponding OCSPResponse solely on the basis of the
nonexistent expected nonce, but <bcp14>MUST</bcp14> fall back to validating the nonexistent expected nonce but <bcp14>MUST</bcp14> fall back to validating the
OCSPResponse based on time.</t> OCSPResponse based on time.</t>
</section> </section>
<section anchor="man-in-the-middle-attacks"> <section anchor="man-in-the-middle-attacks">
<name>Man-in-the-Middle Attacks</name> <name>Man-in-the-Middle Attacks</name>
<t>To mitigate risk associated with this class of attack, the client <t>To mitigate risk associated with this class of attack, the client
<bcp14>MUST</bcp14> properly validate the signature on the response.</t> <bcp14>MUST</bcp14> properly validate the signature on the response.</t>
<t>The use of signed responses in OCSP serves to authenticate the <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 identity of the OCSP responder and to verify that it is authorized to
sign responses on the CA's behalf.</t> sign responses on the CA's behalf.</t>
<t>Clients <bcp14>MUST</bcp14> ensure that they are communicating with a n authorized <t>Clients <bcp14>MUST</bcp14> ensure that they are communicating with a n authorized
skipping to change at line 654 skipping to change at line 798
of-service attacks. As this profile specifies the use of unsigned of-service attacks. As this profile specifies the use of unsigned
OCSPRequests, access to the responder may be implicitly given to OCSPRequests, access to the responder may be implicitly given to
everyone who can send a request to a responder, and thus the ability everyone who can send a request to a responder, and thus the ability
to mount a denial-of-service attack via a flood of requests may be to mount a denial-of-service attack via a flood of requests may be
greater. For example, a responder could limit the rate of incoming greater. For example, a responder could limit the rate of incoming
requests from a particular IP address if questionable behavior is requests from a particular IP address if questionable behavior is
detected.</t> detected.</t>
</section> </section>
<section anchor="modification-of-http-header-fields"> <section anchor="modification-of-http-header-fields">
<name>Modification of HTTP Header Fields</name> <name>Modification of HTTP Header Fields</name>
<t>Values included in HTTP header fields, as described in <xref target=" <t>Values included in HTTP header fields, as described in Sections <xref
transport"/> target="transport" format="counter"/>
and <xref target="cache-recs"/>, and <xref target="cache-recs" format="counter"/>,
are not cryptographically protected; they may be manipulated by an are not cryptographically protected; they may be manipulated by an
attacker. Clients <bcp14>SHOULD</bcp14> use these values for caching guidance on ly attacker. Clients <bcp14>SHOULD</bcp14> use these values for caching guidance on ly
and ultimately <bcp14>SHOULD</bcp14> rely only on the values present in the sign ed and ultimately <bcp14>SHOULD</bcp14> rely only on the values present in the sign ed
OCSPResponse <xref section="4.2.2.1" sectionFormat="of" target="RFC6960"/>. OCSPResponse (<xref section="4.2.2.1" sectionFormat="of" target="RFC6960"/>).
Clients <bcp14>SHOULD NOT</bcp14> rely on cached responses beyond the Clients <bcp14>SHOULD NOT</bcp14> rely on cached responses beyond the
nextUpdate time.</t> nextUpdate time.</t>
</section> </section>
<section anchor="request-authentication-and-authorization"> <section anchor="request-authentication-and-authorization">
<name>Request Authentication and Authorization</name> <name>Request Authentication and Authorization</name>
<t>The suggested use of unsigned requests in this environment removes an <t>The suggested use of unsigned requests in this environment removes an
option that allows the responder to determine the authenticity of option that allows the responder to determine the authenticity of
incoming request. Thus, access to the responder may be implicitly incoming requests. Thus, access to the responder may be implicitly
given to everyone who can send a request to a responder. given to everyone who can send a request to a responder.
Environments where explicit authorization to access the OCSP Environments where explicit authorization to access the OCSP
responder is necessary can utilize other mechanisms to authenticate responder is necessary can utilize other mechanisms to authenticate
requestors or restrict or meter service.</t> requestors or restrict or meter service.</t>
</section> </section>
<section anchor="sha1-sec"> <section anchor="sha1-sec">
<name>Use of SHA-1 for the calculation of CertID field values</name> <name>Use of SHA-1 for the Calculation of CertID Field Values</name>
<t>Although the use of SHA-1 for the calculation of CertID field values is <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 not of concern from a cryptographic security standpoint, the continued
use of SHA-1 in an ecosystem requires that software that interoperates use of SHA-1 in an ecosystem requires that software that interoperates
with the ecosystem maintain support for SHA-1. This increases with the ecosystem maintain support for SHA-1. This increases
implementation complexity and potential attack surface for the software implementation complexity and potential attack surface for the software
in question. Thus, the continued use of SHA-1 in an ecosystem to in question. Thus, the continued use of SHA-1 in an ecosystem to
maintain interoperability with legacy software must be weighed against maintain interoperability with legacy software must be weighed against
the increased implementation complexity and potential attack surface.</t> the increased implementation complexity and potential attack surface.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC6960">
<front>
<title>X.509 Internet Public Key Infrastructure Online Certificate S
tatus 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 cu
rrent status of a digital certificate without requiring Certificate Revocation L
ists (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</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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 RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l 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</titl
e>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="January" year="2010"/>
<abstract>
<t>This document describes the conventions for using the Secure Ha
sh 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 (DS
A), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algori
thms. 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>
<reference anchor="RFC5019">
<front>
<title>The Lightweight Online Certificate Status Protocol (OCSP) Pro
file for High-Volume Environments</title>
<author fullname="A. Deacon" initials="A." surname="Deacon"/>
<author fullname="R. Hurst" initials="R." surname="Hurst"/>
<date month="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 commu
nication bandwidth and client-side processing. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5019"/>
<seriesInfo name="DOI" value="10.17487/RFC5019"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate 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 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [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 da
ta, use of padding in encoded data, use of non-alphabet characters in encoded da
ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA
CK]</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 ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; that task is performed by the individual 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="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition 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, 7
232, 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="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-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) Protocol Version 1.3</titl
e>
<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 S
ecurity
(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 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69
RFCs 5077, 5246, 6961, and 8446. This document also specifies new 60.xml"/>
requirements for TLS 1.2 implementations. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.57
54.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.50
19.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
80.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.46
48.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.39
86.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
10.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
11.xml"/>
<!-- [RFC9846]
draft-ietf-tls-rfc8446bis-14
companion doc RFC 9846 in AUTH48
-->
<reference anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>Independent</organization>
</author>
<date month='January' year='2026'/>
</front>
<seriesInfo name="RFC" value="9846"/>
<seriesInfo name="DOI" value="10.17487/RFC9846"/>
</reference>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-10"
/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="OCSPMP">
<!-- [rfced] We were unable to find a document directly matching the
title provided in the original reference. The URL provided goes to the
homepage for the Open Mobile Alliance. We did find the following URL,
which points to the OCSP Mobile Profile:
https://www.openmobilealliance.org/release/OCSP/V1_0-20040127-C/OMA-WAP-OCSP-V1_
0-20040127-C.pdf
May we update this 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 Version V1.0, 27 January 2004,
<https://www.openmobilealliance.org/release/OCSP/V1_0-20040127-C/OMA-WAP-OCSP
-V1_0-20040127-C.pdf>.
-->
<reference anchor="OCSPMP" target="https://www.openmobilealliance.org">
<front> <front>
<title>OCSP Mobile Profile V1.0</title> <title>OCSP Mobile Profile V1.0</title>
<author> <author>
<organization>Open Mobile Alliance</organization> <organization>Open Mobile Alliance</organization>
</author> </author>
<date/> <date/>
</front> </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 3
rd"/>
<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 to the Internet community. Th
is memo provides information for the 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 Wi
de Web (WWW) (caching) proxies and cache servers. The goal of the document is to
provide a discussion of the problems and proposed workarounds, and ultimately t
o improve conditions by illustrating problems. This memo provides information fo
r the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3143"/>
<seriesInfo name="DOI" value="10.17487/RFC3143"/>
</reference> </reference>
<reference anchor="RFC9500">
<!-- Note to PE: XML for possible update to [OCSPMP]
<reference anchor="OCSPMP" target="https://www.openmobilealliance.org/re
lease/OCSP/V1_0-20040127-C/OMA-WAP-OCSP-V1_0-20040127-C.pd">
<front> <front>
<title>Standard Public Key Cryptography (PKC) Test Keys</title> <title>Online Certificate Status Protocol Mobile Profile</title>
<author fullname="P. Gutmann" initials="P." surname="Gutmann"/> <author>
<author fullname="C. Bonnell" initials="C." surname="Bonnell"/> <organization>Open Mobile Alliance</organization>
<date month="December" year="2023"/> </author>
<abstract> <date day="27" month="January" year="2004"/>
<t>This document provides a set of standard Public Key Cryptograph
y (PKC) test keys that may be used wherever pre-generated keys and associated op
erations like digital signatures are required. Like the European Institute for C
omputer Antivirus Research (EICAR) virus test and the Generic Test for Unsolicit
ed Bulk Email (GTUBE) spam test files, these publicly known test keys can be det
ected and recognised by applications consuming them as being purely for testing
purposes without assigning any security properties to them.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9500"/> <refcontent>Candidate Version V1.0</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC9500"/>
</reference> </reference>
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.31
74.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.31
43.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
00.xml"/>
</references> </references>
</references> </references>
<?line 729?>
<section anchor="differences-from-rfc-5019"> <section anchor="differences-from-rfc-5019">
<name>Differences from RFC 5019</name> <name>Differences from RFC 5019</name>
<t>This document obsoletes <xref target="RFC5019"/>. <xref target="RFC5019 "/> defines a lightweight <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 profile for OCSP that makes the protocol more suitable for use in
high-volume environments. The lightweight profile specifies the high-volume environments. The lightweight profile specifies the
mandatory use of SHA-1 when calculating the values of several fields in mandatory use of SHA-1 when calculating the values of several fields in
OCSP requests and responses. In recent years, weaknesses have been OCSP requests and responses. In recent years, weaknesses have been
demonstrated with the SHA-1 algorithm. As a result, SHA-1 is demonstrated with the SHA-1 algorithm. As a result, SHA-1 is
increasingly falling out of use even for non-security relevant increasingly falling out of use even for non-security-relevant
use cases. This document obsoletes the lightweight profile as specified use cases. This document obsoletes the lightweight profile as specified
in RFC 5019 to instead recommend the use of SHA-256 where SHA-1 was in <xref target="RFC5019"/> to instead recommend the use of SHA-256 where SHA-1
previously required. An <xref target="RFC5019"/>-compliant OCSP client is still was
able previously required. An OCSP client compliant with <xref target="RFC5019"/> is s
till able
to use SHA-1, but the use of SHA-1 may become obsolete in the future.</t> to use SHA-1, but the use of SHA-1 may become obsolete in the future.</t>
<t>Substantive changes to RFC 5019:</t> <t>Substantive changes to RFC 5019:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><xref target="certid"/> requires new OCSP clients to use SHA-256 to <t><xref target="certid"/> requires new OCSP clients to use SHA-256 to
support migration for OCSP clients.</t> support migration for OCSP clients.</t>
</li> </li>
<li> <li>
<t><xref target="byKey"/> requires new OCSP responders to use the byKe y field, <t><xref target="byKey"/> requires new OCSP responders to use the byKe y field
and support migration from byName fields.</t> and support migration from byName fields.</t>
</li> </li>
<li> <li>
<t><xref target="transport"/> clarifies that OCSP clients <bcp14>MUST NOT</bcp14> include <t><xref target="transport"/> clarifies that OCSP clients <bcp14>MUST NOT</bcp14> include
whitespace or any other characters that are not part of whitespace or any other characters that are not part of
the base64 character repertoire in the base64-encoded string.</t> the base64 character repertoire in the base64-encoded string.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<section anchor="root-certification-authority-certificate"> <section anchor="root-certification-authority-certificate">
<name>Root Certification Authority Certificate</name> <name>Root Certification Authority Certificate</name>
<t>This is a self-signed certificate for the certification authority tha t <t>This is a self-signed certificate for the certification authority tha t
issued the end-entity certificate and OCSP delegated responder issued the end-entity certificate and OCSP-delegated responder
example certificates below.</t> example certificates below.</t>
<t>The key pair for the certification authority is the "testECCP521" <t>The key pair for the certification authority is the "testECCP521"
key from <xref section="2.3" sectionFormat="of" target="RFC9500"/>.</t> key from <xref section="2.3" sectionFormat="of" target="RFC9500"/>.</t>
<artwork><![CDATA[ <artwork><![CDATA[
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG
A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy
MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL
Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF
K4EEACMDgYYABAHQ/XJXqEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3 K4EEACMDgYYABAHQ/XJXqEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3
skipping to change at line 1095 skipping to change at line 1093
: CD EE F9 2F EE A2 B0 5F 24 EC 0A F2 03 A4 40 D3 : CD EE F9 2F EE A2 B0 5F 24 EC 0A F2 03 A4 40 D3
: 44 25 FC 75 41 5E EF 78 C6 79 B8 AD 92 E9 91 1E : 44 25 FC 75 41 5E EF 78 C6 79 B8 AD 92 E9 91 1E
: 35 61 94 12 4B A3 B9 F7 14 C2 6B 14 73 68 79 B9 : 35 61 94 12 4B A3 B9 F7 14 C2 6B 14 73 68 79 B9
: 4C 6F : 4C 6F
: } : }
: } : }
: } : }
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="end-entity-certificate"> <section anchor="end-entity-certificate">
<name>End-entity Certificate</name> <name>End-Entity Certificate</name>
<t>This is an end-entity certificate whose status is requested and <t>This is an end-entity certificate whose status is requested and
returned in the OCSP request and response examples below.</t> returned in the OCSP request and response examples below.</t>
<t>The key pair for the end-entity certificate is the "testECCP256" <t>The key pair for the end-entity certificate is the "testECCP256"
key from <xref section="2.3" sectionFormat="of" target="RFC9500"/>.</t> key from <xref section="2.3" sectionFormat="of" target="RFC9500"/>.</t>
<artwork><![CDATA[ <artwork><![CDATA[
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIB2zCCATygAwIBAgIEAarwDTAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEU MIIB2zCCATygAwIBAgIEAarwDTAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEU
MBIGA1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQw MBIGA1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQw
NDAyMTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjAcMRowGAYDVQQDDBF4bi0tMThqNGQu NDAyMTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjAcMRowGAYDVQQDDBF4bi0tMThqNGQu
ZXhhbXBsZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEIlSPiPt4L/teyjdERS ZXhhbXBsZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEIlSPiPt4L/teyjdERS
skipping to change at line 1222 skipping to change at line 1220
: 2B 4B B5 09 98 B6 B5 E9 2C 02 5F BE 41 3A 59 85 : 2B 4B B5 09 98 B6 B5 E9 2C 02 5F BE 41 3A 59 85
: 6A 09 49 78 F7 92 B1 F6 5E 8C F5 30 4B 2B 95 FA : 6A 09 49 78 F7 92 B1 F6 5E 8C F5 30 4B 2B 95 FA
: 57 7C : 57 7C
: } : }
: } : }
: } : }
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="ocsp-responder-certificate"> <section anchor="ocsp-responder-certificate">
<name>OCSP Responder Certificate</name> <name>OCSP Responder Certificate</name>
<t>This is a certificate for the OCSP delegated response that signed the <t>This is a certificate for the OCSP-delegated response that signed the
OCSP response example below.</t> OCSP response example below.</t>
<t>The key pair for the OCSP Responder certificate is the "testECCP384" <t>The key pair for the OCSP responder certificate is the "testECCP384"
key from <xref section="2.3" sectionFormat="of" target="RFC9500"/>.</t> key from <xref section="2.3" sectionFormat="of" target="RFC9500"/>.</t>
<artwork><![CDATA[ <artwork><![CDATA[
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIICSzCCAa6gAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG MIICSzCCAa6gAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG
A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy
MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA8MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA8MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL
Q2VydHMgJ3IgVXMxFzAVBgNVBAMMDk9DU1AgUmVzcG9uZGVyMHYwEAYHKoZIzj0C Q2VydHMgJ3IgVXMxFzAVBgNVBAMMDk9DU1AgUmVzcG9uZGVyMHYwEAYHKoZIzj0C
AQYFK4EEACIDYgAEWwkBuIUjKW65GdUP+hqcs3S8TUCVhigr/soRsdla27VHNK9X AQYFK4EEACIDYgAEWwkBuIUjKW65GdUP+hqcs3S8TUCVhigr/soRsdla27VHNK9X
C/grcijPImvPTCXdvP47GjrTlDDv92Ph1o0uFR2Rcgt3lbWNprNGOWE6j7m1qNpI C/grcijPImvPTCXdvP47GjrTlDDv92Ph1o0uFR2Rcgt3lbWNprNGOWE6j7m1qNpI
xnRxF/mRnoQk837Io4GHMIGEMB0GA1UdDgQWBBQK46D+ndQldpi163Lrygznvz31 xnRxF/mRnoQk837Io4GHMIGEMB0GA1UdDgQWBBQK46D+ndQldpi163Lrygznvz31
skipping to change at line 1666 skipping to change at line 1664
: } : }
: } : }
: } : }
: } : }
: } : }
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The authors of this version of the document wish to thank Alex Deacon <t>The authors of this version of the document wish to thank <contact
and Ryan Hurst for their work to produce the original version fullname="Alex Deacon"/> and <contact fullname="Ryan Hurst"/> for their
of the lightweight profile for the OCSP protocol.</t> work to produce the original version of the lightweight profile for the
<t>The authors of this version of the document wish to thank OCSP protocol.</t>
Paul Kyzivat, Russ Housley, Rob Stradling, Roman Danyliw, and <t>The authors of this version of the document wish to thank <contact
Wendy Brown for their reviews, feedback, and suggestions.</t> fullname="Paul Kyzivat"/>, <contact fullname="Russ Housley"/>, <contact
<t>The authors wish to thank Magnus Nystrom of RSA Security, Inc., fullname="Rob Stradling"/>, <contact fullname="Roman Danyliw"/>, and
Jagjeet Sondh of Vodafone Group R&amp;D, and David Engberg of CoreStreet, <contact fullname="Wendy Brown"/> for their reviews, feedback, and
Ltd. for their contributions to the original <xref target="RFC5019"/> specificat suggestions.</t>
ion. <t>The authors wish to thank <contact fullname="Magnus Nystrom"/> of RSA
Listed organizational affiliations reflect the author’s affiliation Security, Inc., <contact fullname="Jagjeet Sondh"/> of Vodafone Group
at the time of RFC5019 was published.</t> R&amp;D, and <contact fullname="David Engberg"/> of CoreStreet, Ltd. for
their contributions to the original <xref target="RFC5019"/>
specification. Listed organizational affiliations reflect the authors'
affiliations at the time RFC 5019 was published.</t>
</section> </section>
</back> </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> </rfc>
 End of changes. 85 change blocks. 
838 lines changed or deleted 403 lines changed or added

This html diff was produced by rfcdiff 1.48.