| 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 " "> | <!ENTITY nbsp " "> | |||
| <!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
| <!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
| <!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
| ]> | ]> | |||
| <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> | ||||
| <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3. | <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 OCSPProfile Update">Updates to LightweightOCSP | <title abbrev="Lightweight OCSPProfile">The LightweightOnline Certificate | |||
| Profile forHigh Volume Environments</title> | Status Protocol (OCSP) Profile forHigh-Volume Environments</title> | |||
| <seriesInfoname="Internet-Draft" value="draft-ietf-lamps-rfc5019bis-12"/> | <seriesInfoname="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 39 ¶ | |||
| <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> | |||
| <dateyear="2024" month="September" day="13"/> | <dateyear="2026" month="February"/> | |||
| <keyword>Internet-Draft</keyword> | ||||
| <abstract> | ||||
| <?line 48?> | ||||
| <area>SEC</area> | ||||
| <workgroup>lamps</workgroup> | ||||
| <keyword>Revocation</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 5019 | <t>This specification obsoletes RFC 5019. The profile specified in RFC 5019 | |||
| has been updated to allow and recommend the use of SHA-256 over SHA-1.</t> | 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/>.</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/> specifies a mechanism | <t>The Online Certificate Status Protocol <xref/> specifies 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 timely | <t>To date, numerous OCSP deployments have been implemented to provide timely | |||
| 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/></t> | client-side processing complexity <xref/>.</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 130 ¶ | |||
| 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/> | still occur between an OCSP client that fully conforms with <xref/> | |||
| 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 bei | RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
| nterpreted as | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | |||
| described inBCP 14 <xref/> <xref/> when, and | beinterpreted as | |||
| only when, they | described inBCP 14 <xref/> <xref/> | |||
| appear in all capitals, as shownhere.</t> | when, and only when, they appear in all capitals, as shownhere. | |||
| <?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/>.</t> | functionality as defined in <xref/>.</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 <xreftarget="RFC6960"/>:</t> | CertID as defined in <xreftarget="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>MUST</bcp14> | <t>OCSPRequests that conform to the profile in this document <bcp14>MUST</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 hashes | <t>The CertID.issuerNameHash and CertID.issuerKeyHash fields contain hashes | |||
| 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> useSHA-256 asd | OCSP clients that conform with this profile <bcp14>MUST</bcp14> useSHA-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 clientswhich provide backward compatibility with | <t>Older OCSP clientsthat provide backward compatibility with | |||
| <xref/> useSHA-1 as defined in <xreftarget="RFC3174"/> asthe | <xref/> useSHA-1, as defined in <xreftarget="RFC3174"/>, ast | |||
| 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> | |||
| <t>Clients <bcp14>SHOULD NOT</bcp14> include the requestExtensions structure. If a | <t>Clients <bcp14>SHOULD NOT</bcp14> include the requestExtensions structure. If a | |||
| requestExtensions structure is included,this profileRECOMMENDS 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/> for issues concerning the use of a nonce in high-volume | <xref/> 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. Responders <bcp14>MAY</bcp14> ignore | <t>Clients <bcp14>SHOULD NOT</bcp14> send signed OCSPRequests. Responders <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> specify its name in | <t>If the OCSPRequest is signed, the client <bcp14>SHALL</bcp14> specify its name in | |||
| the OCSPRequest.requestorName field; otherwise, clients <bcp14>SHOULD NOT</bcp14> | 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 <xreftarget="RFC6960"/>:</t> | CertID as defined in <xreftarget="RFC6960"/> is provided here for convenience:< | |||
| <artwork><![CDATA[ | /t> | |||
| <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 } | |||
| ]]></sourcecode> | ||||
| The value for response SHALL be the DER encoding ofBasicOCSPResponse. | <t>The value for response SHALL be the DER encoding of | |||
| BasicOCSPResponse.</t> | ||||
| <sourcecode type="asn.1"><![CDATA[ | ||||
| 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 identified by the | <t>Responders <bcp14>MUST</bcp14> generate a BasicOCSPResponse as identified by the | |||
| id-pkix-ocsp-basic OID. Clients <bcp14>MUST</bcp14> be able to parse and accepta | id&nbhy;pkix&nbhy;ocsp&nbhy;basic OID. Clients <bcp14>MUST</bcp14> be able to parse and accepta | |||
| BasicOCSPResponse. OCSPResponses that conform to this profile <bcp14>SHOULD</bcp14> | BasicOCSPResponse. OCSPResponses that conform to this profile <bcp14>SHOULD</bcp14> | |||
| 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 clientswhich do not yet support the | to provide support to OCSP clientsthat 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 twoSingleResponses in a BasicOCSPResponse. | <bcp14>MAY</bcp14> include twoSingleResponse elements in a BasicOCSPResponse. | |||
| In that BasicOCSPResponse, the CertID of one of theSingleResponses | In that BasicOCSPResponse, the CertID of one of theSingleResponse structures | |||
| 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> distribute | SingleResponse uses SHA-256. OCSP responders <bcp14>SHOULD NOT</bcp14> distribute | |||
| OCSP responses that contain CertIDs that use SHA-1 if the OCSP | OCSP responses that contain CertIDs that use SHA-1 if the OCSP | |||
| responder has no clients that require the use of SHA-1. | 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 | |||
| that employ SHA-1 for CertID field hashes. See <xref/> for more | that employ SHA-1 for CertID field hashes. See <xref/> for more | |||
| information on the security considerations for the continued use of | information on the security considerations for the continued use of | |||
| SHA-1.</t> | SHA-1.</t> | |||
| skipping to change at line 280 ¶ | skipping to change at line 282 ¶ | |||
| case where a responder only supports pre-produced responses and does | case where a responder only supports pre-produced responses and does | |||
| not have the ability to respond to an OCSP request containing a | not have the ability to respond to an OCSP request containing a | |||
| nonce, it <bcp14>SHOULD</bcp14> return a response that does not include a nonce.</t> | nonce, it <bcp14>SHOULD</bcp14> return a response that does not include a nonce.</t> | |||
| <t>Clients <bcp14>SHOULD</bcp14> attempt to process a response even if the response | <t>Clients <bcp14>SHOULD</bcp14> attempt to process a response even if the response | |||
| does not include a nonce. See <xref/> for details on validating | does not include a nonce. See <xref/> for details on validating | |||
| responses that do not contain a nonce. See also <xref/> for | responses that do not contain a nonce. See also <xref/> for | |||
| relevant security considerations.</t> | relevant security considerations.</t> | |||
| <t>Responders that do not have the ability to respond to OCSP requests | <t>Responders that do not have the ability to respond to OCSP requests | |||
| that contain an unsupported option such as a nonce <bcp14>MAY</bcp14> forward the | that contain an unsupported option such as a nonce <bcp14>MAY</bcp14> forward the | |||
| request to an OCSP responder capable of doing so.</t> | request to an OCSP responder capable of doing so.</t> | |||
| <t>The responder <bcp14>MAY</bcp14> include thesingleResponse.singleResponse | <t>The responder <bcp14>MAY</bcp14> include theSingleResponse.singleExtensions | |||
| extensions structure.</t> | extensions structure.</t> | |||
| </section> | </section> | |||
| <section anchor="byKey"> | <section anchor="byKey"> | |||
| <name>Signed OCSPResponses</name> | <name>Signed OCSPResponses</name> | |||
| <t>Clients <bcp14>MUST</bcp14> validate the signature on the OCSPResponse.</t> | <t>Clients <bcp14>MUST</bcp14> validate the signature on the OCSPResponse.</t> | |||
| <t>If the response is signed by a delegate of the issuing certification | <t>If the response is signed by a delegate of the issuing certification | |||
| authority (CA), a valid responder certificate <bcp14>MUST</bcp14> be referenced in | authority (CA), a valid responder certificate <bcp14>MUST</bcp14> be referenced in | |||
| the BasicOCSPResponse.certs structure.</t> | the BasicOCSPResponse.certs structure.</t> | |||
| <t>It is <bcp14>RECOMMENDED</bcp14> that the OCSP responder's certificate contain the | <t>It is <bcp14>RECOMMENDED</bcp14> that the OCSP responder's certificate contain the | |||
| id-pkix-ocsp-nocheck extension, as defined in <xref/>, to indicate | id-pkix-ocsp-nocheck extension, as defined in <xref/>, to indicate | |||
| 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 OCSPauthorityInfoAcc | addition, it is <bcp14>RECOMMENDED</bcp14> that neither an OCSPAuthority Inform | |||
| ess | ation Access | |||
| (AIA) extension norcRLDistributionPoints (CRLDP) extension be | (AIA) extension norCRL Distribution Points (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 certificates using | <t>Clients <bcp14>MUST</bcp14> be able to identify OCSP responder certificates using | |||
| the byKey field and <bcp14>SHOULD</bcp14> be able to identify OCSP responder | 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/> choices.</t> | ResponseData.ResponderID <xref/> choices.</t> | |||
| <t>Older responderswhich provide backward compatibility with <xrefta | <t>Older respondersthat provide backward compatibility withthe proto | |||
| rget="RFC5019"/> | col defined in <xreftarget="RFC5019"/> | |||
| <bcp14>MAY</bcp14> use the byName field to represent the ResponderID | <bcp14>MAY</bcp14> use the byName field to represent the ResponderID | |||
| , but should | 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> use the byKey | <t>Newer responders that conform to this profile <bcp14>MUST</bcp14> use the byKey | |||
| field to represent the ResponderID to reduce the size of the response.</t> | 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 | |||
| OCSPResponseStatus of"unauthorized". As such, this profile extends | OCSPResponseStatus of"unauthorized".</t> | |||
| the <xref/> definition of "unauthorized" as follows:</t> | ||||
| <t>The response "unauthorized" is returned in cases where the client | ||||
| is not authorized to make this query to this responder or the responder | ||||
| is not capable of responding authoritatively.</t> | ||||
| <t>For example, OCSP responders that do not have access to authoritative | <t>For example, OCSP responders that do not have access to authoritative | |||
| records for a requested certificate, such as those that generate and | records for a requested certificate, such as those that generate and | |||
| distribute OCSP responses in advance and thus do not have the ability | distribute OCSP responses in advance and thus do not have the ability | |||
| to properly respond with a signed "successful" yet "unknown" | to properly respond with a signed "successful" yet "unknown" | |||
| response, will respond with an OCSPResponseStatus of "unauthorized". | response, will respond with an OCSPResponseStatus of "unauthorized". | |||
| Also, in order to ensure the database of revocation information does | Also, in order to ensure the database of revocation information does | |||
| not grow unbounded over time, the responder <bcp14>MAY</bcp14> remove the status | not grow unbounded over time, the responder <bcp14>MAY</bcp14> remove the status | |||
| records of expired certificates. Requests from clients for | records of expired certificates. Requests from clients for | |||
| certificates whose record has been removed will result in an | certificates whose record has been removed will result in an | |||
| OCSPResponseStatus of "unauthorized".</t> | OCSPResponseStatus of "unauthorized".</t> | |||
| skipping to change at line 357 ¶ | skipping to change at line 355 ¶ | |||
| See <xref/> for additional information on caching.</t> | See <xref/> 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"/>, | set as described in <xref section="2.5" sectionFormat="of"/>, | |||
| 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> | |||
| <t>Clients <bcp14>MUST</bcp14> support theauthorityInfoAccess extension as defined in | <t>Clients <bcp14>MUST</bcp14> support theAIA extension as defined in | |||
| <xref/> and <bcp14>MUST</bcp14> recognize the id-ad-ocsp access method. This | <xref/> and <bcp14>MUST</bcp14> recognize the id-ad-ocsp access method. This | |||
| enables CAs to inform clients how they can contact the OCSP service.</t> | enables CAs to inform clients how they can contact the OCSP service.</t> | |||
| <t>In the case where a client is checking the status of a certificate | <t>In the case where a client is checking the status of a certificate | |||
| that contains both anauthorityInformationAccess (AIA) extension | that contains both anAIA extension | |||
| pointing to an OCSP responder and acRLDistributionPoints extension | pointing to an OCSP responder and aCRLDP extension | |||
| pointing to a CRL, the client <bcp14>SHOULD</bcp14> attempt to contact the OCSP | pointing to a CRL, the client <bcp14>SHOULD</bcp14> attempt to contact the OCSP | |||
| responder first. Clients <bcp14>MAY</bcp14> attempt to retrieve the CRL if no | responder first. Clients <bcp14>MAY</bcp14> attempt to retrieve the CRL if no | |||
| OCSPResponse is received from the responder after a locally | OCSPResponse is received from the responder after a locally | |||
| 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> verify the | <t>To avoid needless network traffic, applications <bcp14>MUST</bcp14> verify the | |||
| signature of signed data before asking an OCSP client to check the | signature of signed data before asking an OCSP client to check the | |||
| status of certificates used to verify the data. If the signature is | status of certificates used to verify the data. If the signature is | |||
| invalid or the application is not able to verify it, an OCSP check | invalid or the application is not able to verify it, an OCSP check | |||
| <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> include a | <t>Because this profile specifies that clients <bcp14>SHOULD NOT</bcp14> include a | |||
| requestExtensions structure in OCSPRequests (see <xref/>), | requestExtensions structure in OCSPRequests (see <xref/>), | |||
| 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 field and <bcp14>MUST</bcp14> | <t>Clients <bcp14>MUST</bcp14> check for the existence of the nextUpdate field and <bcp14>MUST</bcp14> | |||
| ensure the current time, expressed in GMT time as described in | ensure the current time, expressed in GMT time as described in | |||
| <xref/>, falls between the thisUpdate and nextUpdate times. If | <xref/>, falls between the thisUpdate and nextUpdate times. If | |||
| the nextUpdate field is absent, the client <bcp14>MUST</bcp14> reject the response.</t> | the nextUpdate field is absent, the client <bcp14>MUST</bcp14> reject the response.</t> | |||
| <t>If the nextUpdate field is present, the client <bcp14>MUST</bcp14> ensure that it is | <t>If the nextUpdate field is present, the client <bcp14>MUST</bcp14> ensure that it is | |||
| not earlier than the current time. If the current time on the client | 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> allow configuration | <bcp14>MUST</bcp14> reject the response as stale. Clients <bcp14>MAY</bcp14> allow configuration | |||
| of a small tolerance period for acceptance of responses after | of a small tolerance period for acceptance of responses after | |||
| nextUpdate to handle minor clock differences relative to responders | nextUpdate to handle minor clock differences relative to responders | |||
| and caches. This tolerance period should be chosen based on the | and caches. This tolerance period should be chosen based on the | |||
| accuracy and precision of time synchronization technology available | accuracy and precision of time synchronization technology available | |||
| to the calling application environment. For example, Internet peers | to the calling application environment. For example, Internet peers | |||
| with low latency connections typically expect NTP time | with low latency connections typically expect NTP time | |||
| synchronization to keep them accurate within parts of a second; | synchronization to keep them accurate within parts of a second; | |||
| higher latency environments or where an NTP analogue is not available | higher latency environments or where an NTP analogue is not available | |||
| may have to be more liberal in their tolerance | 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/> for additional details | <t>See the security considerations in <xref/> for additional details | |||
| on replay andman-in-the-middle attacks.</t> | on replay andon-path attacks.</t> | |||
| </section> | </section> | |||
| <section anchor="transport"> | <section anchor="transport"> | |||
| <name>Transport Profile</name> | <name>Transport Profile</name> | |||
| <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 (afterencoding) including the scheme and delimiters (http://), | total (afterencoding), including the scheme and delimiters (http://), | |||
| servername and base64-encoded OCSPRequest structure, clients<bcp14>MUST</bcp14 | servername, and base64-encoded OCSPRequest structure, clients<bcp14>MUST</bcp1 | |||
| > | 4> | |||
| 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 inA.1 of <xref target="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> base64-encode the | <t>When constructing a GET message, OCSP clients <bcp14>MUST</bcp14> base64-encode the | |||
| OCSPRequest structure according to <xref section="4" sectionFormat="of"/>. Clients | OCSPRequest structure according to <xref section="4" sectionFormat="of"/>. 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/>. OCSP clients <bcp14>MUST</bcp14> append the base64-encoded OCSPRequest | <xref/>. OCSP clients <bcp14>MUST</bcp14> append the base64-encoded OCSPRequest | |||
| to the URI specified in the AIA extension <xref/>. For example:</t> | to the URI specified in the AIA extension <xref/>. 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/>and <xreftarget="RFC911 | preceded by the following HTTP <xref/> <xreftarget="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/> for details on the use of these HTTP header fields.</t> | <t>See <xref/> 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 cache authoritative | <t>To minimize bandwidth usage, clients <bcp14>MUST</bcp14> locally cache authoritative | |||
| OCSP responses (i.e., a response with a signature that has been | OCSP responses (i.e., a response with a signature that has been | |||
| successfully validated and thatindicate an OCSPResponseStatus of | successfully validated and thatindicates 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 the | receive an updated OCSP response, OCSP responders <bcp14>MUST</bcp14> refresh the | |||
| 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/> and <xref/> for the full definition | proxy servers. See <xref/> and <xref/> 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 532 ¶ | |||
| <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 the OCSP responder last modified the response. This date and time will be the same as the thisUpdate timestamp in the request itself.</td> | <td align="left">This value specifies the date and time at which the OCSP responder last modified the response. This date and time will be the same as the thisUpdate timestamp in the request itself.</td> | |||
| </tr> | </tr> | |||
| <tr> | <tr> | |||
| <td align="left">Expires</td> | <td align="left">Expires</td> | |||
| <td align="left">Specifies how long the response is considered fresh. This date and time will be the same as the nextUpdate timestamp in the OCSP response itself.</td> | <td align="left">Specifies how long the response is considered fresh. This date and time will be the same as the nextUpdate timestamp in the OCSP response itself.</td> | |||
| </tr> | </tr> | |||
| <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 HEX 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 ETag value be the ASCII HEX representation of the SHA-256 hash of the OCSPResponse structure.</td> | |||
| </tr> | </tr> | |||
| <tr> | <tr> | |||
| <td align="left">Cache-Control</td> | <td align="left">Cache-Control</td> | |||
| <tdalign="left">Contains a number of cachingdirectives. <br/> * | <tdalign="left"><t>Contains a number of cachingdirectives.</t> | |||
| max-age = < n >-where n is a time value later than thisUpdate butearlier | <ul spacing="normal"> | |||
| thannextUpdate. <br/> * public -makes normally uncachable response cachable by | <li>max-age = < n >- where n is a time value later than thisUpdate butea | |||
| both shared andnonshared caches. <br/> * no-transform -specifies that a proxy | rlier thannextUpdate.</li> | |||
| cache cannot change the type, length, or encoding of the objectcontent. <br/> * | <li>public - makes normally uncachable response cachable by both shared andnons | |||
| must-revalidate -prevents caches from intentionally returning staleresponses.< | hared caches.</li> | |||
| /td> | <li>no-transform - specifies that a proxy cache cannot change the type, length, | |||
| or encoding of the objectcontent.</li> | ||||
| <li>must-revalidate - prevents caches from intentionally returning stalerespons | ||||
| es.</li> | ||||
| </ul></td> | ||||
| </tr> | </tr> | |||
| </tbody> | </tbody> | |||
| </table> | </table> | |||
| <t>OCSP responders <bcp14>MUST NOT</bcp14> includea "Pragma: no-cache", "Cache- | <t>OCSP responders <bcp14>MUST NOT</bcp14> includethe "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 innon- | TP header fields innon-authoritative OCSP responses.</t> | |||
| authoritative OCSP responses.</t> | ||||
| <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 | producedAt = 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 572 ¶ | |||
| 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 field in OCSP request | <t>OCSP clients <bcp14>MUST NOT</bcp14> include a no-cache HTTP header field 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 proxies | situation, clients <bcp14>SHOULD</bcp14> resend the request specifying that proxies | |||
| 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> | |||
| <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/> protocol in | protocol 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 clients 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/>.</t> | from <xref/>.</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"/>.</t> | considerations addressed in <xref section="5" sectionFormat="of"/>.</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 ofdate 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 ofrevoked. 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 ofthe OCSPprotocol may provide a way for the client | <t>Future versions of OCSP 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>On-Path 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 an authorized | <t>Clients <bcp14>MUST</bcp14> ensure that they are communicating with an authorized | |||
| responder by the rules described in <xref section="4.2.2.2" sectionFormat="of" target="RFC6960"/>.</t> | responder by the rules described in <xref section="4.2.2.2" sectionFormat="of" target="RFC6960"/>.</t> | |||
| </section> | </section> | |||
| <section anchor="impersonation-attacks"> | <section anchor="impersonation-attacks"> | |||
| <name>Impersonation Attacks</name> | <name>Impersonation Attacks</name> | |||
| skipping to change at line 654 ¶ | skipping to change at line 664 ¶ | |||
| 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 <xreftarget=" | <t>Values included in HTTP header fields, as described inSections <xref | |||
| transport"/> | target="transport" format="counter"/> | |||
| and <xreftarget="cache-recs"/>, | and <xreftarget="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 only | attacker. Clients <bcp14>SHOULD</bcp14> use these values for caching guidance only | |||
| and ultimately <bcp14>SHOULD</bcp14> rely only on the values present in the signed | and ultimately <bcp14>SHOULD</bcp14> rely only on the values present in the signed | |||
| OCSPResponse<xref section="4.2.2.1" sectionFormat="of"/>. | OCSPResponse(<xref section="4.2.2.1" sectionFormat="of"/>). | |||
| 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 thecalculation of CertID field values</name> | <name>Use of SHA-1 for theCalculation 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"> | ||||
| <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> | |||
| <referenceanchor="OCSPMP"> | ||||
| <referenceanchor="OCSPMP"> | ||||
| <front> | <front> | |||
| <title>OCSP Mobile Profile V1.0</title> | <title>Online Certificate Status Protocol Mobile Profile</title> | |||
| <author> | <author> | |||
| <organization>Open Mobile Alliance</organization> | <organization>Open Mobile Alliance</organization> | |||
| </author> | </author> | |||
| <date/> | <dateday="27" month="January" year="2004"/> | |||
| </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"/> | ||||
| <datemonth="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 anchor="RFC9500"> | ||||
| <front> | ||||
| <title>Standard Public Key Cryptography (PKC) Test Keys</title> | ||||
| <author fullname="P. Gutmann" initials="P." surname="Gutmann"/> | ||||
| <author fullname="C. Bonnell" initials="C." surname="Bonnell"/> | ||||
| <date month="December" year="2023"/> | ||||
| <abstract> | ||||
| <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/>. <xref/> defines a lightweight | <t>This document obsoletes <xref/>. <xref/> 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-securityrelevant | 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 | |||
| inRFC 5019 to instead recommend the use of SHA-256 where SHA-1 was | in<xref/> to instead recommend the use of SHA-256 where SHA-1 | |||
| previously required. An<xref/>-compliant OCSP client isstill | was | |||
| able | previously required. An OCSP clientcompliant with <xref/> iss | |||
| 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/> requires new OCSP clients to use SHA-256 to | <t><xref/> 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/> requires new OCSP responders to use the byKey field, | <t><xref/> requires new OCSP responders to use the byKey field | |||
| and support migration from byName fields.</t> | and support migration from byName fields.</t> | |||
| </li> | </li> | |||
| <li> | <li> | |||
| <t><xref/> clarifies that OCSP clients <bcp14>MUST NOT</bcp14> include | <t><xref/> 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>RootCertification Authority Certificate</name> | <name>RootCA Certificate</name> | |||
| <t>This is a self-signed certificate for thecertification authority tha | <t>This is a self-signed certificate for theCA that | |||
| t | issued the end-entity certificate andOCSP-delegated responder | |||
| issued the end-entity certificate andOCSP delegated responder | ||||
| example certificates below.</t> | example certificates below.</t> | |||
| <t>The key pair for thecertification authority is the "testECCP521" | <t>The key pair for theCA is the "testECCP521" | |||
| key from <xref section="2.3" sectionFormat="of"/>.</t> | key from <xref section="2.3" sectionFormat="of"/>.</t> | |||
| <artwork><![CDATA[ | <artwork><![CDATA[ | |||
| -----BEGIN CERTIFICATE----- | -----BEGIN CERTIFICATE----- | |||
| MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG | MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG | |||
| A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy | A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy | |||
| MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL | MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL | |||
| Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF | Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF | |||
| K4EEACMDgYYABAHQ/XJXqEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3 | K4EEACMDgYYABAHQ/XJXqEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3 | |||
| +i2iYNjrYtbS9dZJJ44yFzagYoy7swMItuYY2wD2KtIExkYDWbyBiriWG/Dw/A7F | +i2iYNjrYtbS9dZJJ44yFzagYoy7swMItuYY2wD2KtIExkYDWbyBiriWG/Dw/A7F | |||
| quikKBc85W8A3psVfB5cgsZPVi/K3vxKTCj200LPPvYW/ILTO3KFySHyvzb92KNC | quikKBc85W8A3psVfB5cgsZPVi/K3vxKTCj200LPPvYW/ILTO3KFySHyvzb92KNC | |||
| skipping to change at line 1095 ¶ | skipping to change at line 931 ¶ | |||
| : 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"/>.</t> | key from <xref section="2.3" sectionFormat="of"/>.</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 1058 ¶ | |||
| : 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 OCSPdelegated 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 OCSPResponder certificate is the "testECCP384" | <t>The key pair for the OCSPresponder certificate is the "testECCP384" | |||
| key from <xref section="2.3" sectionFormat="of"/>.</t> | key from <xref section="2.3" sectionFormat="of"/>.</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 1502 ¶ | |||
| : } | : } | |||
| : } | : } | |||
| : } | : } | |||
| : } | : } | |||
| : } | : } | |||
| ]]></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 thankAlex Deacon | <t>The authors of this version of the document wish to thank<contact | |||
| andRyan Hurst for their work to produce the original version | fullname="Alex Deacon"/> and<contact fullname="Ryan Hurst"/> for their | |||
| of the lightweight profile forthe OCSP protocol.</t> | work to produce the original version of the lightweight profile for | |||
| <t>The authors of this version of the document wish to thank | OCSP.</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 thankMagnus Nystrom of RSA Security, Inc., | fullname="Rob Stradling"/>, <contact fullname="Roman Danyliw"/>, and | |||
| Jagjeet Sondh of Vodafone Group R&D, andDavid Engberg of CoreStreet, | <contact fullname="Wendy Brown"/> for their reviews, feedback, and | |||
| Ltd. for their contributions to the original <xref/>specificat | suggestions.</t> | |||
| ion. | <t>The authors wish to thank<contact fullname="Magnus Nystrom"/> of RSA | |||
| Listed organizational affiliations reflect theauthor’s affiliation | Security, Inc.,<contact fullname="Jagjeet Sondh"/> of Vodafone Group | |||
| at the timeof RFC5019 was published.</t> | R&D, and<contact fullname="David Engberg"/> of CoreStreet, Ltd. for | |||
| their contributions to the original <xref/> | ||||
| specification. Listed organizational affiliations reflect theauthors' | ||||
| affiliations at the timeRFC 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= | ||||
| </rfc> | </rfc> | |||
| End of changes. 95 change blocks. | ||||
| 872 lines changed or deleted | 223 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||