rfc9162xml2.original.xml   rfc9162.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.11 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc sortrefs="yes"?> -ietf-trans-rfc6962-bis-42" number="9162" obsoletes="6962" updates="" submission
<?rfc symrefs="yes"?> Type="IETF" category="exp" consensus="true" xml:lang="en" tocInclude="true" sort
Refs="true" symRefs="true" version="3">
<rfc ipr="trust200902" docName="draft-ietf-trans-rfc6962-bis-42" category="exp"
obsoletes="6962">
<!-- xml2rfc v2v3 conversion 3.9.1 -->
<front> <front>
<title>Certificate Transparency Version 2.0</title> <title>Certificate Transparency Version 2.0</title>
<seriesInfo name="RFC" value="9162"/>
<author initials="B." surname="Laurie" fullname="Ben Laurie"> <author initials="B." surname="Laurie" fullname="Ben Laurie">
<organization abbrev="Google">Google UK Ltd.</organization> <organization abbrev="Google">Google UK Ltd.</organization>
<address> <address>
<email>benl@google.com</email> <email>benl@google.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Langley" fullname="Adam Langley">
<organization abbrev="Google">Google Inc.</organization>
<address>
<email>agl@google.com</email>
</address>
</author>
<author initials="E." surname="Kasper" fullname="Emilia Kasper">
<organization abbrev="Google">Google Switzerland GmbH</organization>
<address>
<email>ekasper@google.com</email>
</address>
</author>
<author initials="E." surname="Messeri" fullname="Eran Messeri"> <author initials="E." surname="Messeri" fullname="Eran Messeri">
<organization abbrev="Google">Google UK Ltd.</organization> <organization abbrev="Google">Google UK Ltd.</organization>
<address> <address>
<email>eranm@google.com</email> <email>eranm@google.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Stradling" fullname="Rob Stradling"> <author initials="R." surname="Stradling" fullname="Rob Stradling">
<organization abbrev="Sectigo">Sectigo Ltd.</organization> <organization abbrev="Sectigo">Sectigo Ltd.</organization>
<address> <address>
<email>rob@sectigo.com</email> <email>rob@sectigo.com</email>
</address> </address>
</author> </author>
<date year="2021" month="November"/>
<date year="2021" month="August" day="31"/>
<area>Security</area> <area>Security</area>
<workgroup>TRANS (Public Notary Transparency)</workgroup> <workgroup>TRANS (Public Notary Transparency)</workgroup>
<keyword>certificates</keyword>
<keyword>pkix</keyword>
<keyword>tls</keyword>
<keyword>website</keyword>
<keyword>webpki</keyword>
<keyword>browsers</keyword>
<abstract> <abstract>
<t>This document describes version 2.0 of the Certificate Transparency (CT
<t>This document describes version 2.0 of the Certificate Transparency (CT) )
protocol for publicly logging the existence of Transport Layer Security (TLS) protocol for publicly logging the existence of Transport Layer Security (TLS)
server certificates as they are issued or observed, in a manner that allows server certificates as they are issued or observed, in a manner that allows
anyone to audit certification authority (CA) activity and notice the issuance of anyone to audit certification authority (CA) activity and notice the issuance of
suspect certificates as well as to audit the certificate logs themselves. The suspect certificates as well as to audit the certificate logs themselves. The
intent is that eventually clients would refuse to honor certificates that do not intent is that eventually clients would refuse to honor certificates that do not
appear in a log, effectively forcing CAs to add all issued certificates to the appear in a log, effectively forcing CAs to add all issued certificates to the
logs.</t> logs.</t>
<t>This document obsoletes RFC 6962. It also specifies a new TLS extensio
<t>This document obsoletes RFC 6962. It also specifies a new TLS extension that n that is
is
used to send various CT log artifacts.</t> used to send various CT log artifacts.</t>
<t>Logs are network services that implement the protocol operations for su
<t>Logs are network services that implement the protocol operations for submissi bmissions
ons
and queries that are defined in this document.</t> and queries that are defined in this document.</t>
<t>[RFC Editor: please update 'RFCXXXX' to refer to this document,
once its RFC number is known, through the document. Also, the OID
assigned below must also appear in the appendix as indicated. ]</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>Certificate Transparency aims to mitigate the problem of misissued cert
<t>Certificate Transparency aims to mitigate the problem of misissued certificat ificates
es
by providing append-only logs of issued certificates. The logs do not themselves by providing append-only logs of issued certificates. The logs do not themselves
prevent misissuance, but they ensure that interested parties (particularly those prevent misissuance, but they ensure that interested parties (particularly those
named in certificates) can detect such misissuance. Note that this is a general named in certificates) can detect such misissuance. Note that this is a general
mechanism that could be used for transparently logging any form of binary data, mechanism that could be used for transparently logging any form of binary data,
subject to some kind of inclusion criteria. In this document, we only describe subject to some kind of inclusion criteria. In this document, we only describe
its use for public TLS server certificates (i.e., where the inclusion criteria its use for public TLS server certificates (i.e., where the inclusion criteria
is a valid certificate issued by a public certification authority (CA)). is a valid certificate issued by a public certification authority (CA)).
A typical definition of "public" can be found in <xref target="CABBR"></xref>.</ A typical definition of "public" can be found in <xref target="CABBR" format="de
t> fault"/>.</t>
<t>Each log contains certificate chains, which can be submitted by anyone.
<t>Each log contains certificate chains, which can be submitted by anyone. It is It is
expected that public CAs will contribute all their newly issued certificates to expected that public CAs will contribute all their newly issued certificates to
one or more logs; however, certificate holders can also contribute their own one or more logs; however, certificate holders can also contribute their own
certificate chains, as can third parties. In order to avoid logs being rendered certificate chains, as can third parties. In order to avoid logs being rendered
useless by the submission of large numbers of spurious certificates, it is useless by the submission of large numbers of spurious certificates, it is
required that each chain ends with a trust anchor that is accepted by the log. required that each chain ends with a trust anchor that is accepted by the log.
A log may also limit the length of the chain it is willing to accept; A log may also limit the length of the chain it is willing to accept;
such chains must also end with an acceptable trust anchor. such chains must also end with an acceptable trust anchor.
When a chain is accepted by a log, a signed timestamp is returned, which can When a chain is accepted by a log, a signed timestamp is returned, which can
later be used to provide evidence to TLS clients that the chain has been later be used to provide evidence to TLS clients that the chain has been
submitted. TLS clients can thus require that all certificates they accept as submitted. TLS clients can thus require that all certificates they accept as
valid are accompanied by signed timestamps.</t> valid are accompanied by signed timestamps.</t>
<t>Those who are concerned about misissuance can monitor the logs, asking
<t>Those who are concerned about misissuance can monitor the logs, asking them them
regularly for all new entries, and can thus check whether domains for which they regularly for all new entries, and can thus check whether domains for which they
are responsible have had certificates issued that they did not expect. What are responsible have had certificates issued that they did not expect. What
they do with this information, particularly when they find that a misissuance they do with this information, particularly when they find that a misissuance
has happened, is beyond the scope of this document. However, broadly speaking, has happened, is beyond the scope of this document. However, broadly speaking,
they can invoke existing business mechanisms for dealing with misissued they can invoke existing business mechanisms for dealing with misissued
certificates, such as working with the CA to get the certificate revoked, or certificates, such as working with the CA to get the certificate revoked or
with maintainers of trust anchor lists to get the CA removed. Of course, anyone with maintainers of trust anchor lists to get the CA removed. Of course, anyone
who wants can monitor the logs and, if they believe a certificate is incorrectly who wants can monitor the logs and, if they believe a certificate is incorrectly
issued, take action as they see fit.</t> issued, take action as they see fit.</t>
<t>Similarly, those who have seen signed timestamps from a particular log
<t>Similarly, those who have seen signed timestamps from a particular log can la can later
ter
demand a proof of inclusion from that log. If the log is unable to provide this demand a proof of inclusion from that log. If the log is unable to provide this
(or, indeed, if the corresponding certificate is absent from monitors' copies of (or, indeed, if the corresponding certificate is absent from monitors' copies of
that log), that is evidence of the incorrect operation of the log. The checking that log), that is evidence of the incorrect operation of the log. The checking
operation is asynchronous to allow clients to proceed without delay, despite operation is asynchronous to allow clients to proceed without delay, despite
possible issues such as network connectivity and the vagaries of firewalls.</t> possible issues, such as network connectivity and the vagaries of firewalls.</t>
<t>The append-only property of each log is achieved using Merkle Trees, wh
<t>The append-only property of each log is achieved using Merkle Trees, which ca ich can
n
be used to efficiently prove that any particular instance of the log is a be used to efficiently prove that any particular instance of the log is a
superset of any particular previous instance and to efficiently detect various superset of any particular previous instance and to efficiently detect various
misbehaviors of the log (e.g., issuing a signed timestamp for a certificate that misbehaviors of the log (e.g., issuing a signed timestamp for a certificate that
is not subsequently logged).</t> is not subsequently logged).</t>
<t>The log auditing mechanisms described in this document can
<t>It is necessary to treat each log as a trusted third party, because the log be circumvented by a misbehaving log that shows different, inconsistent
auditing mechanisms described in this document can be circumvented by a views of itself to different clients. Therefore, it is necessary to treat each l
misbehaving log that shows different, inconsistent views of itself to different og
clients. While mechanisms are being developed to address these as a trusted third party. While mechanisms are being developed to address these
shortcomings and thereby avoid the need to blindly trust logs, shortcomings and thereby avoid the need to blindly trust logs,
such mechanisms are outside the scope of this document.</t> such mechanisms are outside the scope of this document.</t>
<section anchor="requirements-language" numbered="true" toc="default">
<section anchor="requirements-language" title="Requirements Language"> <name>Requirements Language</name>
<t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> < NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
xref target="RFC8174"/> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
</section> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<section anchor="data_structures" title="Data Structures"> when, and only when, they appear in all capitals, as shown here.
</t>
<t>Data structures are defined and encoded according to the conventions laid out </section>
in Section 3 of <xref target="RFC8446"></xref>.</t> <section anchor="data_structures" numbered="true" toc="default">
<name>Data Structures</name>
<t>This document uses object identifiers (OIDs) to identify Log IDs (see <t>Data structures are defined and encoded according to the conventions
<xref target="log_id"/>), the precertificate CMS <spanx style="verb">eContentTyp laid out
e</spanx> (see <xref target="precertificates"/>), in <xref target="RFC8446" sectionFormat="of" section="3"/>.</t>
and X.509v3 extensions in certificates (see <xref target="cert_transinfo_extensi <t>This document uses object identifiers (OIDs) to identify Log IDs (see
on"/>) and <xref target="log_id" format="default"/>), the precertificate Cryptograph
OCSP responses (see <xref target="ocsp_transinfo_extension"/>). The OIDs are def ic Message
ined in an Syntax (CMS) <tt>eContentType</tt> (see <xref target="precertificates"
arc that was selected due to its short encoding.</t> format="default"/>), X.509v3 extensions in certificates (see <xref
target="cert_transinfo_extension" format="default"/>), and
</section> Online Certificate Status Protocol (OCSP) responses (see <xref
<section anchor="major-differences-from-ct-10" title="Major Differences from CT target="ocsp_transinfo_extension" format="default"/>). The OIDs are defin
1.0"> ed in an
arc that was selected due to its short encoding.</t>
<t>This document revises and obsoletes the CT 1.0 <xref target="RFC6962"></xref> </section>
protocol, drawing on <section anchor="major-differences-from-ct-10" numbered="true" toc="defaul
insights gained from CT 1.0 deployments and on feedback from the community. The t">
major changes are:</t> <name>Major Differences from CT 1.0</name>
<t>This document revises and obsoletes the CT 1.0 protocol <xref target=
<t><list style="symbols"> "RFC6962"
<t>Hash and signature algorithm agility: permitted algorithms are now specifie format="default"/>, drawing on
d insights gained from CT 1.0 deployments and on feedback from the communit
in IANA registries.</t> y. The
<t>Precertificate format: precertificates are now CMS objects rather than X.50 major changes are:</t>
9 <ul spacing="normal">
certificates, which avoids violating the certificate serial number uniqueness <li>Hash and signature algorithm agility: Permitted algorithms are now
requirement in Section 4.1.2.2 of <xref target="RFC5280"></xref>.</t> specified
<t>Removed precertificate signing certificates and the precertificate poison in IANA registries.</li>
extension: the change of precertificate format means that these are no longer <li>Precertificate format: Precertificates are now CMS objects rather
needed.</t> than X.509
<t>Logs IDs: each log is now identified by an OID rather than by the hash of i certificates, which avoids violating the certificate serial number uniq
ts ueness
public key. OID allocations are managed by an IANA registry.</t> requirement in <xref target="RFC5280" sectionFormat="of" section="4.1.2
<t><spanx style="verb">TransItem</spanx> structure: this new data structure is .2"/>.</li>
used to encapsulate most <li>Removal of precertificate signing certificates and the precertific
types of CT data. A <spanx style="verb">TransItemList</spanx>, consisting of one ate poison
or more <spanx style="verb">TransItem</spanx> extension: The change of precertificate format means that these are no
structures, can be used anywhere that <spanx style="verb">SignedCertificateTimes longer
tampList</spanx> was needed.</li>
used in <xref target="RFC6962"></xref>.</t> <li>Logs IDs: Each log is now identified by an OID rather than by the
<t>Merkle tree leaves: the <spanx style="verb">MerkleTreeLeaf</spanx> structur hash of its
e has been replaced by the public key. OID allocations are available from an IANA registry.</li>
<spanx style="verb">TransItem</spanx> structure, which eases extensibility and s <li><tt>TransItem</tt> structure: This new data structure is used to e
implifies the leaf ncapsulate
structure by removing one layer of abstraction.</t> most types of CT data. A <tt>TransItemList</tt>, consisting of one or m
<t>Unified leaf format: the structure for both certificate and precertificate ore
entries now includes only the TBSCertificate (whereas certificate entries in <tt>TransItem</tt> structures, can be used anywhere that
<xref target="RFC6962"></xref> included the entire certificate).</t> <tt>SignedCertificateTimestampList</tt> was
<t>Log Artifact Extensions: these are now typed and managed by an IANA registr used in <xref target="RFC6962" format="default"/>.</li>
y, <li>Merkle Tree leaves: The <tt>MerkleTreeLeaf</tt> structure has been
and they can now appear not only in SCTs but also in STHs.</t> replaced by
<t>API outputs: complete <spanx style="verb">TransItem</spanx> structures are the <tt>TransItem</tt> structure, which eases extensibility and simplif
returned, rather than the ies the leaf
constituent parts of each structure.</t> structure by removing one layer of abstraction.</li>
<t>get-all-by-hash: new client API for obtaining an inclusion proof and the <li>Unified leaf format: The structure for both certificate and precer
corresponding consistency proof at the same time.</t> tificate
<t>submit-entry: new client API, replacing add-chain and add-pre-chain.</t> entries now includes only the TBSCertificate (whereas certificate entri
<t>Presenting SCTs with proofs: TLS servers may present SCTs together with the es in
corresponding inclusion proofs using any of the mechanisms that <xref target="RF <xref target="RFC6962" format="default"/> included the entire certifica
C6962"></xref> te).</li>
defined for presenting SCTs only. (Presenting SCTs only is still supported).</t> <li>Log artifact extensions: These are now typed and managed by an IAN
<t>CT TLS extension: the <spanx style="verb">signed_certificate_timestamp</spa A registry,
nx> TLS extension has been and they can now appear not only in Signed Certificate Timestamps (SCTs
replaced by the <spanx style="verb">transparency_info</spanx> TLS extension.</t> ) but also
<t>Verification algorithms: added detailed algorithms for verifying inclusion in Signed Tree Heads (STHs).</li>
proofs, for verifying consistency between two STHs, and for verifying a root <li>API outputs: Complete <tt>TransItem</tt> structures are returned r
hash given a complete list of the relevant leaf input entries.</t> ather than
<t>Extensive clarifications and editorial work.</t> the constituent parts of each structure.</li>
</list></t> <li><tt>get-all-by-hash</tt>: This is a new client API for obtaining a
n inclusion proof and
</section> the corresponding consistency proof at the same time.</li>
</section> <li><tt>submit-entry</tt>: This is a new client API, replacing <tt>add
<section anchor="cryptographic-components" title="Cryptographic Components"> -chain</tt> and
<tt>add-pre-chain</tt>.</li>
<section anchor="mht" title="Merkle Hash Trees"> <li>Presenting SCTs with proofs: TLS servers may present SCTs together
with the
<t>A full description of Merkle Hash Tree is beyond the scope of this corresponding inclusion proofs, using any of the mechanisms that <xref
document. Briefly, it is a binary tree where each non-leaf node is a target="RFC6962" format="default"/>
hash of its children. For CT, the number of children is at most two. defined for presenting SCTs only. (Presenting SCTs only is still suppor
Additional information can be found in the Introduction and Reference ted).</li>
section of <xref target="RFC8391"/>.</t> <li>CT TLS extension: The <tt>signed_certificate_timestamp</tt> TLS ex
tension has
<section anchor="mht_definition" title="Definition of the Merkle Tree"> been replaced by the <tt>transparency_info</tt> TLS extension.</li>
<li>Verification algorithms: Detailed algorithms for verifying inclusi
<t>The log uses a binary Merkle Hash Tree for efficient auditing. The hash on
algorithm used is one of the log's parameters (see <xref target="log_parameters" proofs, for verifying consistency between two STHs, and for verifying a
/>). root
This document establishes a registry of acceptable hash algorithms (see hash given a complete list of the relevant leaf input entries have been
<xref target="hash_algorithms"/>). Throughout this document, the hash algorithm added.</li>
in use is <li>Extensive clarifications and editorial work.</li>
referred to as HASH and the size of its output in bytes as HASH_SIZE. The input </ul>
to the Merkle Tree Hash is a list of data entries; these entries will be </section>
hashed to form the leaves of the Merkle Hash Tree. The output is a single </section>
HASH_SIZE Merkle Tree Hash. Given an ordered list of n inputs, D_n = <section anchor="cryptographic-components" numbered="true" toc="default">
{d[0], d[1], …, d[n-1]}, the Merkle Tree Hash (MTH) is thus defined as <name>Cryptographic Components</name>
follows:</t> <section anchor="mht" numbered="true" toc="default">
<name>Merkle Trees</name>
<t>The hash of an empty list is the hash of an empty string:</t> <t>A full description of the Merkle Tree is beyond the scope of this
document. Briefly, it is a binary tree where each non-leaf node is a
<figure><artwork><![CDATA[ hash of its children. For CT, the number of children is at most two.
Additional information can be found in the Introduction and Reference
sections of <xref target="RFC8391" format="default"/>.</t>
<section anchor="mht_definition" numbered="true" toc="default">
<name>Definition of the Merkle Tree</name>
<t>The log uses a binary Merkle Tree for efficient auditing. The hash
algorithm used is one of the log's parameters (see <xref target="log_pa
rameters"
format="default"/>). This document establishes a registry of acceptable
hash
algorithms (see <xref target="hash_algorithms" format="default"/>). Thr
oughout this
document, the hash algorithm in use is referred to as HASH and the size
of its
output in bytes is referred to as HASH_SIZE. The input
to the Merkle Tree Hash is a list of data entries; these entries will b
e
hashed to form the leaves of the Merkle Tree. The output is a single
HASH_SIZE Merkle Tree Hash. Given an ordered list of n inputs, D_n =
{d[0], d[1], ..., d[n-1]}, the Merkle Tree Hash (MTH) is thus defined a
s
follows:</t>
<t>The hash of an empty list is the hash of an empty string:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
MTH({}) = HASH(). MTH({}) = HASH().
]]></artwork></figure> ]]></artwork>
<t>The hash of a list with one entry (also known as a leaf hash) is:</
<t>The hash of a list with one entry (also known as a leaf hash) is:</t> t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
MTH({d[0]}) = HASH(0x00 || d[0]). MTH({d[0]}) = HASH(0x00 || d[0]).
]]></artwork></figure> ]]></artwork>
<t>For n &gt; 1, let k be the largest power of two smaller than n
<t>For n &gt; 1, let k be the largest power of two smaller than n (i.e., k &lt; n &lt;= 2k).
(i.e., k &lt; n &lt;= 2k). The Merkle Tree Hash of an n-element list D_n is then defined recursive
The Merkle Tree Hash of an n-element list D_n is then defined recursively as</t> ly as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
MTH(D_n) = HASH(0x01 || MTH(D[0:k]) || MTH(D[k:n])), MTH(D_n) = HASH(0x01 || MTH(D[0:k]) || MTH(D[k:n])),
]]></artwork></figure> ]]></artwork>
<t>where:</t>
<t>where:</t> <ul spacing="normal">
<li>|| denotes concatenation</li>
<t><list style="symbols"> <li>: denotes concatenation of lists</li>
<t>|| denotes concatenation</t> <li>D[k1:k2] = D'_(k2-k1) denotes the list {d'[0] = d[k1], d'[1] = d
<t>: denotes concatenation of lists</t> [k1+1],
<t>D[k1:k2] = D'_(k2-k1) denotes the list {d'[0] = d[k1], d'[1] = d[k1+1], ..., d'[k2-k1-1] = d[k2-1]} of length (k2 - k1).</li>
…, d'[k2-k1-1] = d[k2-1]} of length (k2 - k1).</t> </ul>
</list></t> <t>Note that the hash calculations for leaves and nodes differ; this d
omain
<t>Note that the hash calculations for leaves and nodes differ; this domain
separation is required to give second preimage resistance.</t> separation is required to give second preimage resistance.</t>
<t>Note that we do not require the length of the input list to be a po
<t>Note that we do not require the length of the input list to be a power of two wer of two.
.
The resulting Merkle Tree may thus not be balanced; however, its shape is The resulting Merkle Tree may thus not be balanced; however, its shape is
uniquely determined by the number of leaves. (Note: This Merkle Tree is uniquely determined by the number of leaves. (Note: This Merkle Tree is
essentially the same as the history tree <xref target="CrosbyWallach"></xref> pr essentially the same as the history tree proposed by <xref target="CrosbyWallach
oposal, except our " format="default"/>, except our
definition handles non-full trees differently).</t> definition handles non-full trees differently.)</t>
</section>
</section> <section anchor="verify_hash" numbered="true" toc="default">
<section anchor="verify_hash" title="Verifying a Tree Head Given Entries"> <name>Verifying a Tree Head Given Entries</name>
<t>When a client has a complete list of <tt>entries</tt> from <tt>0</t
<t>When a client has a complete list of <spanx style="verb">entries</spanx> from t> up to
<spanx style="verb">0</spanx> up to <tt>tree_size - 1</tt> and wishes to verify this list against a tree head <tt>ro
<spanx style="verb">tree_size - 1</spanx> and wishes to verify this list against ot_hash</tt>
a tree head <spanx style="verb">root_hash</spanx> returned by the log for the same <tt>tree_size</tt>, the following algorithm may
returned by the log for the same <spanx style="verb">tree_size</spanx>, the foll be
owing algorithm may be
used:</t> used:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>Set <tt>stack</tt> to an empty stack.</li>
<t>Set <spanx style="verb">stack</spanx> to an empty stack.</t> <li>
<t>For each <spanx style="verb">i</spanx> from <spanx style="verb">0</spanx> u <t>For each <tt>i</tt> from <tt>0</tt> up to <tt>tree_size - 1</tt
p to <spanx style="verb">tree_size - 1</spanx>: <list style="numbers"> >:</t>
<t>Push <spanx style="verb">HASH(0x00 || entries[i])</spanx> to <spanx sty <ol spacing="normal" type="a">
le="verb">stack</spanx>.</t> <li>Push <tt>HASH(0x00 || entries[i])</tt> to <tt>stack</tt>.</li
<t>Set <spanx style="verb">merge_count</spanx> to the lowest value (<spanx >
style="verb">0</spanx> included) such that <spanx style="verb">LSB(i &gt;&gt; <li>Set <tt>merge_count</tt> to the lowest value (<tt>0</tt> inc
merge_count)</spanx> is not set, where <spanx style="verb">LSB</spanx> means the luded)
least significant bit. such that <tt>LSB(i &gt;&gt; merge_count)</tt> is not set, where
In other words, set <spanx style="verb">merge_count</spanx> to the number <tt>LSB</tt> means the least significant
of consecutive <spanx style="verb">1</spanx>s found starting at the least signif bit. In other words, set <tt>merge_count</tt> to the number
icant bit of <spanx style="verb">i</spanx>.</t> of consecutive <tt>1</tt>s found starting at the least significan
<t>Repeat <spanx style="verb">merge_count</spanx> times: <list style= t bit of
"numbers"> <tt>i</tt>.</li>
<t>Pop <spanx style="verb">right</spanx> from <spanx style="verb">stac <li>
k</spanx>.</t> <t>Repeat <tt>merge_count</tt> times:</t>
<t>Pop <spanx style="verb">left</spanx> from <spanx style="verb">stack <ol spacing="normal" type="i">
</spanx>.</t> <li>Pop <tt>right</tt> from <tt>stack</tt>.</li>
<t>Push <spanx style="verb">HASH(0x01 || left || right)</spanx> to <sp <li>Pop <tt>left</tt> from <tt>stack</tt>.</li>
anx style="verb">stack</spanx>.</t> <li>Push <tt>HASH(0x01 || left || right)</tt> to <tt>stack</
</list></t> tt>.</li>
</list></t> </ol>
<t>If there is more than one element in the <spanx style="verb">stack</spanx>, </li>
repeat the same merge </ol>
procedure (the sub-items of Step 2.3 above) until only a single element </li>
remains.</t> <li>If there is more than one element in the <tt>stack</tt>, repeat
<t>The remaining element in <spanx style="verb">stack</spanx> is the Merkle Tr the same merge
ee hash for the given procedure (the sub-items of Step 2(c) above) until only a single element
<spanx style="verb">tree_size</spanx> and should be compared by equality against remains.</li>
the supplied <li>The remaining element in <tt>stack</tt> is the Merkle Tree Hash
<spanx style="verb">root_hash</spanx>.</t> for the given
</list></t> <tt>tree_size</tt> and should be compared by equality against the supplied
<tt>root_hash</tt>.</li>
</section> </ol>
<section anchor="merkle_inclusion_proof" title="Merkle Inclusion Proofs"> </section>
<section anchor="merkle_inclusion_proof" numbered="true" toc="default">
<t>A Merkle inclusion proof for a leaf in a Merkle Hash Tree is the shortest lis <name>Merkle Inclusion Proofs</name>
t <t>A Merkle inclusion proof for a leaf in a Merkle Tree is the shortes
t list
of additional nodes in the Merkle Tree required to compute the Merkle Tree Hash of additional nodes in the Merkle Tree required to compute the Merkle Tree Hash
for that tree. Each node in the tree is either a leaf node or is computed from for that tree. Each node in the tree is either a leaf node or is computed from
the two nodes immediately below it (i.e., towards the leaves). At each step up the two nodes immediately below it (i.e., towards the leaves). At each step up
the tree (towards the root), a node from the inclusion proof is combined with the tree (towards the root), a node from the inclusion proof is combined with
the node computed so far. In other words, the inclusion proof consists of the the node computed so far. In other words, the inclusion proof consists of the
list of missing nodes required to compute the nodes leading from a leaf to the list of missing nodes required to compute the nodes leading from a leaf to the
root of the tree. If the root computed from the inclusion proof matches the true root of the tree. If the root computed from the inclusion proof matches the true
root, then the inclusion proof proves that the leaf exists in the tree.</t> root, then the inclusion proof proves that the leaf exists in the tree.</t>
<section anchor="generating-an-inclusion-proof" numbered="true" toc="d
<section anchor="generating-an-inclusion-proof" title="Generating an Inclusion P efault">
roof"> <name>Generating an Inclusion Proof</name>
<t>Given an ordered list of n inputs to the tree, D_n = {d[0], d[1],
<t>Given an ordered list of n inputs to the tree, D_n = {d[0], d[1], …, ...,
d[n-1]}, the Merkle inclusion proof PATH(m, D_n) for the (m+1)th input d[m], d[n-1]}, the Merkle inclusion proof PATH(m, D_n) for the (m+1)th input d[m],
0 &lt;= m &lt; n, is defined as follows:</t> 0 &lt;= m &lt; n, is defined as follows:</t>
<t>The proof for the single leaf in a tree with a one-element input
<t>The proof for the single leaf in a tree with a one-element input list D[1] = list D[1] =
{d[0]} is empty:</t> {d[0]} is empty:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
PATH(0, {d[0]}) = {} PATH(0, {d[0]}) = {}
]]></artwork></figure> ]]></artwork>
<t>For n &gt; 1, let k be the largest power of two smaller than n. T
<t>For n &gt; 1, let k be the largest power of two smaller than n. The proof for he proof for the
the (m+1)th element d[m] in a list of n &gt; m elements is then defined recursively
(m+1)th element d[m] in a list of n &gt; m elements is then defined recursively as:</t>
as</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
PATH(m, D_n) = PATH(m, D[0:k]) : MTH(D[k:n]) for m < k; and PATH(m, D_n) = PATH(m, D[0:k]) : MTH(D[k:n]) for m < k; and
PATH(m, D_n) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m >= k, PATH(m, D_n) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m >= k,
]]></artwork></figure> ]]></artwork>
<t>The : operator and D[k1:k2] are defined the same as in <xref targ
<t>The : operator and D[k1:k2] are defined the same as in <xref target="mht_defi et="mht_definition" format="default"/>.</t>
nition"/>.</t> </section>
<section anchor="verify_inclusion" numbered="true" toc="default">
</section> <name>Verifying an Inclusion Proof</name>
<section anchor="verify_inclusion" title="Verifying an Inclusion Proof"> <t>When a client has received an inclusion proof (e.g., in a <tt>Tra
nsItem</tt> of type
<t>When a client has received an inclusion proof (e.g., in a <spanx style="verb" <tt>inclusion_proof_v2</tt>) and wishes to verify inclusion of an input <tt>hash
>TransItem</spanx> of type </tt> for a
<spanx style="verb">inclusion_proof_v2</spanx>) and wishes to verify inclusion o given <tt>tree_size</tt> and <tt>root_hash</tt>, the following algorithm may be
f an input <spanx style="verb">hash</spanx> for a used to prove
given <spanx style="verb">tree_size</spanx> and <spanx style="verb">root_hash</s the <tt>hash</tt> was included in the <tt>root_hash</tt>:</t>
panx>, the following algorithm may be used to prove <ol spacing="normal" type="1">
the <spanx style="verb">hash</spanx> was included in the <spanx style="verb">roo <li>Compare <tt>leaf_index</tt> from the <tt>inclusion_proof_v2</tt
t_hash</spanx>:</t> > structure
against <tt>tree_size</tt>. If <tt>leaf_index</tt> is greater than
<t><list style="numbers"> or
<t>Compare <spanx style="verb">leaf_index</spanx> from the <spanx style="verb" equal to <tt>tree_size</tt>, then fail the proof verification.</li>
>inclusion_proof_v2</spanx> structure <li>Set <tt>fn</tt> to <tt>leaf_index</tt> and <tt>sn</tt> to <tt>
against <spanx style="verb">tree_size</spanx>. If <spanx style="verb">leaf_index tree_size -
</spanx> is greater than or 1</tt>.</li>
equal to <spanx style="verb">tree_size</spanx> then fail the proof verification. <li>Set <tt>r</tt> to <tt>hash</tt>.</li>
</t> <li>
<t>Set <spanx style="verb">fn</spanx> to <spanx style="verb">leaf_index</spanx <t>For each value <tt>p</tt> in the <tt>inclusion_path</tt> arra
> and <spanx style="verb">sn</spanx> to <spanx style="verb">tree_size - 1</spanx y:</t>
>.</t> <ol spacing="normal" type="a">
<t>Set <spanx style="verb">r</spanx> to <spanx style="verb">hash</spanx>.</t> <li>If <tt>sn</tt> is 0, then stop the iteration and fail the
<t>For each value <spanx style="verb">p</spanx> in the <spanx style="verb">inc proof verification.</li>
lusion_path</spanx> array: <vspace blankLines='1'/> <li>
If <spanx style="verb">sn</spanx> is 0, stop the iteration and fail the proof ve <t>If <tt>LSB(fn)</tt> is set, or if <tt>fn</tt> is equal to
rification. <vspace blankLines='1'/> <tt>sn</tt>, then:</t>
If <spanx style="verb">LSB(fn)</spanx> is set, or if <spanx style="verb">fn</spa <ol spacing="normal" type="i">
nx> is equal to <spanx style="verb">sn</spanx>, then: <list style="numbers"> <li>Set <tt>r</tt> to <tt>HASH(0x01 || p || r)</tt>.</li>
<t>Set <spanx style="verb">r</spanx> to <spanx style="verb">HASH(0x01 || p <li>If <tt>LSB(fn)</tt> is not set, then right-shift both
|| r)</spanx></t> <tt>fn</tt> and
<t>If <spanx style="verb">LSB(fn)</spanx> is not set, then right-shift bot <tt>sn</tt> equally until either <tt>LSB(fn)</tt> is set
h <spanx style="verb">fn</spanx> and <spanx style="verb">sn</spanx> equally or <tt>fn</tt> is <tt>0</tt>.</li>
until either <spanx style="verb">LSB(fn)</spanx> is set or <spanx style="verb">f </ol>
n</spanx> is <spanx style="verb">0</spanx>.</t> <t>Otherwise:</t>
</list> <ol spacing="normal" type="i">
Otherwise: <list style="numbers"> <li>Set <tt>r</tt> to <tt>HASH(0x01 || r || p)</tt>.</li>
<t>Set <spanx style="verb">r</spanx> to <spanx style="verb">HASH(0x01 || r </ol>
|| p)</spanx></t> </li>
</list> <li>Finally, right-shift both <tt>fn</tt> and <tt>sn</tt> one
Finally, right-shift both <spanx style="verb">fn</spanx> and <spanx style="verb" time.</li>
>sn</spanx> one time.</t> </ol>
<t>Compare <spanx style="verb">sn</spanx> to 0. Compare <spanx style="verb">r< </li>
/spanx> against the <spanx style="verb">root_hash</spanx>. If <spanx style="verb <li>Compare <tt>sn</tt> to 0. Compare <tt>r</tt> against the
">sn</spanx> is equal to <tt>root_hash</tt>. If <tt>sn</tt> is equal to
0, and <spanx style="verb">r</spanx> and the <spanx style="verb">root_hash</span 0 and <tt>r</tt> and the <tt>root_hash</tt> are equal, then the log
x> are equal, then the log has proven the has proven
inclusion of <spanx style="verb">hash</spanx>. Otherwise, fail the proof verific the inclusion of <tt>hash</tt>. Otherwise, fail the proof verificat
ation.</t> ion.</li>
</list></t> </ol>
</section>
</section> </section>
</section> <section anchor="consistency" numbered="true" toc="default">
<section anchor="consistency" title="Merkle Consistency Proofs"> <name>Merkle Consistency Proofs</name>
<t>Merkle consistency proofs prove the append-only property of the tre
<t>Merkle consistency proofs prove the append-only property of the tree. A Merkl e. A Merkle
e
consistency proof for a Merkle Tree Hash MTH(D_n) and a previously advertised consistency proof for a Merkle Tree Hash MTH(D_n) and a previously advertised
hash MTH(D[0:m]) of the first m leaves, m &lt;= n, is the list of nodes in the hash MTH(D[0:m]) of the first m leaves, m &lt;= n, is the list of nodes in the
Merkle Tree required to verify that the first m inputs D[0:m] are equal in both Merkle Tree required to verify that the first m inputs D[0:m] are equal in both
trees. Thus, a consistency proof must contain a set of intermediate nodes (i.e., trees. Thus, a consistency proof must contain a set of intermediate nodes (i.e.,
commitments to inputs) sufficient to verify MTH(D_n), such that (a subset of) commitments to inputs) sufficient to verify MTH(D_n), such that (a subset of)
the same nodes can be used to verify MTH(D[0:m]). We define an algorithm that the same nodes can be used to verify MTH(D[0:m]). We define an algorithm that
outputs the (unique) minimal consistency proof.</t> outputs the (unique) minimal consistency proof.</t>
<section anchor="generating-a-consistency-proof" numbered="true" toc="
<section anchor="generating-a-consistency-proof" title="Generating a Consistency default">
Proof"> <name>Generating a Consistency Proof</name>
<t>Given an ordered list of n inputs to the tree, D_n = {d[0], d[1],
<t>Given an ordered list of n inputs to the tree, D_n = {d[0], d[1], …, ...,
d[n-1]}, the Merkle consistency proof PROOF(m, D_n) for a previous Merkle Tree d[n-1]}, the Merkle consistency proof PROOF(m, D_n) for a previous Merkle Tree
Hash MTH(D[0:m]), 0 &lt; m &lt; n, is defined as:</t> Hash MTH(D[0:m]), 0 &lt; m &lt; n, is defined as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
PROOF(m, D_n) = SUBPROOF(m, D_n, true) PROOF(m, D_n) = SUBPROOF(m, D_n, true)
]]></artwork></figure> ]]></artwork>
<t>In SUBPROOF, the boolean value represents whether the subtree cre
<t>In SUBPROOF, the boolean value represents whether the subtree created from ated from
D[0:m] is a complete subtree of the Merkle Tree created from D_n, and, D[0:m] is a complete subtree of the Merkle Tree created from D_n and,
consequently, whether the subtree Merkle Tree Hash MTH(D[0:m]) is known. The consequently, whether the subtree Merkle Tree Hash MTH(D[0:m]) is kno
initial call to SUBPROOF sets this to be true, and SUBPROOF is then defined as wn. The
follows:</t> initial call to SUBPROOF sets this to be true, and SUBPROOF is then d
efined as
<t>The subproof for m = n is empty if m is the value for which PROOF was origina follows:</t>
lly <t>The subproof for m = n is empty if m is the value for which PROOF
requested (meaning that the subtree created from D[0:m] is a complete subtree was
of the Merkle Tree created from the original D_n for which PROOF was originally requested (meaning that the subtree created from D[0:m] is
requested, and the subtree Merkle Tree Hash MTH(D[0:m]) is known):</t> a complete
subtree of the Merkle Tree created from the original D_n for which PR
<figure><artwork><![CDATA[ OOF was
requested and the subtree Merkle Tree Hash MTH(D[0:m]) is known):</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SUBPROOF(m, D_m, true) = {} SUBPROOF(m, D_m, true) = {}
]]></artwork></figure> ]]></artwork>
<t>Otherwise, the subproof for m = n is the Merkle Tree Hash committ
<t>Otherwise, the subproof for m = n is the Merkle Tree Hash committing inputs ing inputs
D[0:m]:</t> D[0:m]:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
SUBPROOF(m, D_m, false) = {MTH(D_m)} SUBPROOF(m, D_m, false) = {MTH(D_m)}
]]></artwork></figure> ]]></artwork>
<t>For m &lt; n, let k be the largest power of two smaller than n. T
<t>For m &lt; n, let k be the largest power of two smaller than n. The subproof he subproof is
is then defined recursively, using the appropriate step below:</t>
then defined recursively, using the appropriate step below:</t> <t>If m &lt;= k, the right subtree entries D[k:n] only exist in the
current tree.
<t>If m &lt;= k, the right subtree entries D[k:n] only exist in the current tree We prove that the left subtree entries D[0:k] are consistent and add
. a
We prove that the left subtree entries D[0:k] are consistent and add a commitment to D[k:n]:</t>
commitment to D[k:n]:</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
SUBPROOF(m, D_n, b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n]) SUBPROOF(m, D_n, b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n])
]]></artwork></figure> ]]></artwork>
<t>If m &gt; k, the left subtree entries D[0:k] are identical in bo
<t>If m &gt; k, the left subtree entries D[0:k] are identical in both trees. We th trees. We
prove prove that the right subtree entries D[k:n] are consistent and add a
that the right subtree entries D[k:n] are consistent and add a commitment to commitment
D[0:k].</t> to D[0:k]:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
SUBPROOF(m, D_n, b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k]) SUBPROOF(m, D_n, b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k])
]]></artwork></figure> ]]></artwork>
<t>The number of nodes in the resulting proof is bounded above by ce
<t>The number of nodes in the resulting proof is bounded above by ceil(log2(n)) il(log2(n)) +
+
1.</t> 1.</t>
<t>The : operator and D[k1:k2] are defined the same as in <xref targ
<t>The : operator and D[k1:k2] are defined the same as in <xref target="mht_defi et="mht_definition" format="default"/>.</t>
nition"/>.</t> </section>
<section anchor="verify_consistency" numbered="true" toc="default">
</section> <name>Verifying Consistency between Two Tree Heads</name>
<section anchor="verify_consistency" title="Verifying Consistency between Two Tr <t>When a client has a tree head <tt>first_hash</tt> for tree size
ee Heads"> <tt>first</tt>, has a tree head
<tt>second_hash</tt> for tree size <tt>second</tt> where <tt>0 &lt; f
<t>When a client has a tree head <spanx style="verb">first_hash</spanx> for tree irst &lt;
size <spanx style="verb">first</spanx>, a tree head second</tt>, and has received a consistency proof between the two (e.
<spanx style="verb">second_hash</spanx> for tree size <spanx style="verb">second g., in a
</spanx> where <spanx style="verb">0 &lt; first &lt; second</spanx>, and has <tt>TransItem</tt> of type
received a consistency proof between the two (e.g., in a <spanx style="verb">Tra <tt>consistency_proof_v2</tt>), the following algorithm may be used t
nsItem</spanx> of type o verify the
<spanx style="verb">consistency_proof_v2</spanx>), the following algorithm may b consistency proof:</t>
e used to verify the <ol spacing="normal" type="1">
consistency proof:</t> <li>If <tt>consistency_path</tt> is an empty array, stop and fail t
he proof
<t><list style="numbers"> verification.</li>
<t>If <spanx style="verb">consistency_path</spanx> is an empty array, stop and <li>If <tt>first</tt> is an exact power of 2, then prepend <tt>fir
fail the proof st_hash</tt>
verification.</t> to the <tt>consistency_path</tt> array.</li>
<t>If <spanx style="verb">first</spanx> is an exact power of 2, then prepend < <li>Set <tt>fn</tt> to <tt>first - 1</tt> and <tt>sn</tt> to <tt>s
spanx style="verb">first_hash</spanx> to the econd -
<spanx style="verb">consistency_path</spanx> array.</t> 1</tt>.</li>
<t>Set <spanx style="verb">fn</spanx> to <spanx style="verb">first - 1</spanx> <li>If <tt>LSB(fn)</tt> is set, then right-shift both <tt>fn</tt>
and <spanx style="verb">sn</spanx> to <spanx style="verb">second - 1</spanx>.</ and
t> <tt>sn</tt> equally until <tt>LSB(fn)</tt> is not set.</li>
<t>If <spanx style="verb">LSB(fn)</spanx> is set, then right-shift both <spanx <li>Set both <tt>fr</tt> and <tt>sr</tt> to the first value in the
style="verb">fn</spanx> and <spanx style="verb">sn</spanx> equally until <tt>consistency_path</tt> array.</li>
<spanx style="verb">LSB(fn)</spanx> is not set.</t> <li>
<t>Set both <spanx style="verb">fr</spanx> and <spanx style="verb">sr</spanx> <t>For each subsequent value <tt>c</tt> in the <tt>consistency_p
to the first value in the <spanx style="verb">consistency_path</spanx> array.</t ath</tt> array:</t>
> <ol spacing="normal" type="a">
<t>For each subsequent value <spanx style="verb">c</spanx> in the <spanx style <li>If <tt>sn</tt> is 0, then stop the iteration and fail the
="verb">consistency_path</spanx> array: <vspace blankLines='1'/> proof verification.</li>
If <spanx style="verb">sn</spanx> is 0, stop the iteration and fail the proof ve <li>
rification. <vspace blankLines='1'/> <t>If <tt>LSB(fn)</tt> is set, or if <tt>fn</tt> is equal to
If <spanx style="verb">LSB(fn)</spanx> is set, or if <spanx style="verb">fn</spa <tt>sn</tt>, then:</t>
nx> is equal to <spanx style="verb">sn</spanx>, then: <list style="numbers"> <ol spacing="normal" type="i">
<t>Set <spanx style="verb">fr</spanx> to <spanx style="verb">HASH(0x01 || <li>Set <tt>fr</tt> to <tt>HASH(0x01 || c || fr)</tt>.</li
c || fr)</spanx><vspace /> >
Set <spanx style="verb">sr</spanx> to <spanx style="verb">HASH(0x01 || c || sr)< <li>Set <tt>sr</tt> to <tt>HASH(0x01 || c || sr)</tt>.</li
/spanx></t> >
<t>If <spanx style="verb">LSB(fn)</spanx> is not set, then right-shift bot <li>If <tt>LSB(fn)</tt> is not set, then right-shift both
h <spanx style="verb">fn</spanx> and <spanx style="verb">sn</spanx> equally <tt>fn</tt> and <tt>sn</tt>
until either <spanx style="verb">LSB(fn)</spanx> is set or <spanx style="verb">f equally until either <tt>LSB(fn)</tt> is set or <tt>fn</
n</spanx> is <spanx style="verb">0</spanx>.</t> tt> is <tt>0</tt>.</li>
</list> </ol>
Otherwise: <list style="numbers"> <t>Otherwise:</t>
<t>Set <spanx style="verb">sr</spanx> to <spanx style="verb">HASH(0x01 || <ol spacing="normal" type="i">
sr || c)</spanx></t> <li>Set <tt>sr</tt> to <tt>HASH(0x01 || sr || c)</tt>.</li
</list> >
Finally, right-shift both <spanx style="verb">fn</spanx> and <spanx style="verb" </ol>
>sn</spanx> one time.</t> </li>
<t>After completing iterating through the <spanx style="verb">consistency_path <li>Finally, right-shift both <tt>fn</tt> and <tt>sn</tt> one
</spanx> array as described time.</li>
above, verify that the <spanx style="verb">fr</spanx> calculated is equal to the </ol>
<spanx style="verb">first_hash</spanx> supplied, </li>
that the <spanx style="verb">sr</spanx> calculated is equal to the <spanx style= <li>After completing iterating through the <tt>consistency_path</t
"verb">second_hash</spanx> supplied and that <spanx style="verb">sn</spanx> t> array as
is 0.</t> described above, verify that the <tt>fr</tt> calculated is equal to
</list></t> the
<tt>first_hash</tt> supplied, that the <tt>sr</tt> calculated is eq
</section> ual to the
</section> <tt>second_hash</tt> supplied, and that <tt>sn</tt> is 0.</li>
<section anchor="example" title="Example"> </ol>
</section>
<t>The binary Merkle Tree with 7 leaves:</t> </section>
<section anchor="example" numbered="true" toc="default">
<figure><artwork><![CDATA[ <name>Example</name>
<t>The following is a binary Merkle Tree with 7 leaves:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
hash hash
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
k l k l
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
g h i j g h i j
/ \ / \ / \ | / \ / \ / \ |
a b c d e f d6 a b c d e f d6
| | | | | | | | | | | |
d0 d1 d2 d3 d4 d5 d0 d1 d2 d3 d4 d5
]]></artwork></figure> ]]></artwork>
<t>The inclusion proof for <tt>d0</tt> is [<tt>b</tt>, <tt>h</tt>, <tt
<t>The inclusion proof for d0 is [b, h, l].</t> >l</tt>].</t>
<t>The inclusion proof for <tt>d3</tt> is [<tt>c</tt>, <tt>g</tt>, <tt
<t>The inclusion proof for d3 is [c, g, l].</t> >l</tt>].</t>
<t>The inclusion proof for <tt>d4</tt> is [<tt>f</tt>, <tt>j</tt>, <tt
<t>The inclusion proof for d4 is [f, j, k].</t> >k</tt>].</t>
<t>The inclusion proof for <tt>d6</tt> is [<tt>i</tt>, <tt>k</tt>].</t
<t>The inclusion proof for d6 is [i, k].</t> >
<t>The same tree, built incrementally in four steps:</t>
<t>The same tree, built incrementally in four steps:</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
hash0 hash1=k hash0 hash1=k
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
g c g h g c g h
/ \ | / \ / \ / \ | / \ / \
a b d2 a b c d a b d2 a b c d
| | | | | | | | | | | |
d0 d1 d0 d1 d2 d3 d0 d1 d0 d1 d2 d3
skipping to change at line 526 skipping to change at line 489
/ \ / \ / \ / \
k i k l k i k l
/ \ / \ / \ / \ / \ / \ / \ / \
/ \ e f / \ / \ / \ e f / \ / \
/ \ | | / \ / \ / \ | | / \ / \
g h d4 d5 g h i j g h d4 d5 g h i j
/ \ / \ / \ / \ / \ | / \ / \ / \ / \ / \ |
a b c d a b c d e f d6 a b c d a b c d e f d6
| | | | | | | | | | | | | | | | | | | |
d0 d1 d2 d3 d0 d1 d2 d3 d4 d5 d0 d1 d2 d3 d0 d1 d2 d3 d4 d5
]]></artwork></figure> ]]></artwork>
<t>The consistency proof between <tt>hash0</tt> and <tt>hash</tt> is P
<t>The consistency proof between hash0 and hash is PROOF(3, D[7]) = [c, d, g, l] ROOF(3, D[7]) = [<tt>c</tt>, <tt>d</tt>, <tt>g</tt>, <tt>l</tt>].
. Non-leaf nodes <tt>c</tt>, <tt>g</tt> are used to verify <tt>hash0</tt>, and non
c, g are used to verify hash0, and d, l are additionally used to show hash is -leaf nodes <tt>d</tt>, <tt>l</tt> are additionally used to show <tt>hash</tt> i
consistent with hash0.</t> s
consistent with <tt>hash0</tt>.</t>
<t>The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l]. hash ca <t>The consistency proof between <tt>hash1</tt> and <tt>hash</tt> is P
n ROOF(4, D[7]) = [<tt>l</tt>]. <tt>hash</tt> can
be verified using hash1=k and l.</t> be verified using <tt>hash1</tt>=<tt>k</tt> and <tt>l</tt>.</t>
<t>The consistency proof between <tt>hash2</tt> and <tt>hash</tt> is P
<t>The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i, j, k]. ROOF(6, D[7]) = [<tt>i</tt>, <tt>j</tt>, <tt>k</tt>].
k, i are used to verify hash2, and j is additionally used to show hash is Non-leaf nodes <tt>k</tt>, <tt>i</tt> are used to verify <tt>hash2</tt>, and non
consistent with hash2.</t> -leaf node <tt>j</tt> is additionally used to show <tt>hash</tt> is
consistent with <tt>hash2</tt>.</t>
</section> </section>
</section> </section>
<section anchor="signatures" title="Signatures"> <section anchor="signatures" numbered="true" toc="default">
<name>Signatures</name>
<t>When signing data structures, a log MUST use one of <t>When signing data structures, a log <bcp14>MUST</bcp14> use one of
the signature algorithms from the IANA CT Signature Algorithms registry, the signature algorithms from the IANA "Signature Algorithms" registry,
described in <xref target="signature_algorithms"/>.</t> described in <xref target="signature_algorithms" format="default"/>.</t>
</section>
</section> </section>
</section> <section anchor="submitters" numbered="true" toc="default">
<section anchor="submitters" title="Submitters"> <name>Submitters</name>
<t>Submitters submit certificates or preannouncements of certificates prio
<t>Submitters submit certificates or preannouncements of certificates prior to r to
issuance (precertificates) to logs for public auditing, as described below. In issuance (precertificates) to logs for public auditing, as described below. In
order to enable attribution of each logged certificate or precertificate to its order to enable attribution of each logged certificate or precertificate to its
issuer, each submission MUST be accompanied by all additional certificates issuer, each submission <bcp14>MUST</bcp14> be accompanied by all additional cer
required to verify the chain up to an accepted trust anchor (<xref target="get-a tificates
nchors"/>). required to verify the chain up to an accepted trust anchor (<xref target="get-a
The trust anchor (a root or intermediate CA certificate) MAY be omitted from the nchors" format="default"/>).
The trust anchor (a root or intermediate CA certificate) <bcp14>MAY</bcp14> be o
mitted from the
submission.</t> submission.</t>
<t>If a log accepts a submission, it will return a Signed Certificate Time
<t>If a log accepts a submission, it will return a Signed Certificate Timestamp stamp
(SCT) (see <xref target="sct"/>). The submitter SHOULD validate the returned SCT (SCT) (see <xref target="sct" format="default"/>). The submitter <bcp14>SHOULD</
as described bcp14> validate the returned SCT, as described
in <xref target="tls_clients"/> if they understand its format and they intend to in <xref target="tls_clients" format="default"/>, if they understand its format
use it and they intend to use it
directly in a TLS handshake or to construct a certificate. If the submitter does directly in a TLS handshake or to construct a certificate. If the submitter does
not need the SCT (for example, the certificate is being submitted simply to make not need the SCT (for example, the certificate is being submitted simply to make
it available in the log), it MAY validate the SCT.</t> it available in the log), it <bcp14>MAY</bcp14> validate the SCT.</t>
<section anchor="certificates" numbered="true" toc="default">
<section anchor="certificates" title="Certificates"> <name>Certificates</name>
<t>Any entity can submit a certificate (<xref target="submit-entry" form
<t>Any entity can submit a certificate (<xref target="submit-entry"/>) to a log. at="default"/>) to a log. Since it is
Since it is
anticipated that TLS clients will reject certificates that are not logged, it is anticipated that TLS clients will reject certificates that are not logged, it is
expected that certificate issuers and subjects will be strongly motivated to expected that certificate issuers and subjects will be strongly motivated to
submit them.</t> submit them.</t>
</section>
</section> <section anchor="precertificates" numbered="true" toc="default">
<section anchor="precertificates" title="Precertificates"> <name>Precertificates</name>
<t>CAs may preannounce a certificate prior to issuance by submitting a
<t>CAs may preannounce a certificate prior to issuance by submitting a precertificate (<xref target="submit-entry" format="default"/>) that the log can
precertificate (<xref target="submit-entry"/>) that the log can use to create an use to create an entry that
entry that will be valid against the issued certificate. The CA <bcp14>MAY</bcp14> incorpor
will be valid against the issued certificate. The CA MAY incorporate the ate the
returned SCT in the issued certificate. One example of where the returned SCT is returned SCT in the issued certificate. One example of where the returned SCT is
not incorporated in the issued certificate is when a CA sends the precertificate not incorporated in the issued certificate is when a CA sends the precertificate
to multiple logs, but only incorporates the SCTs that are returned first.</t> to multiple logs but only incorporates the SCTs that are returned first.</t>
<t>A precertificate is a CMS <xref target="RFC5652" format="default"/> <
<t>A precertificate is a CMS <xref target="RFC5652"></xref> <spanx style="verb"> tt>signed-data</tt> object that conforms to the
signed-data</spanx> object that conforms to the
following profile:</t> following profile:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>It <bcp14>MUST</bcp14> be DER encoded, as described in <xref targe
<t>It MUST be DER encoded as described in <xref target="X690"></xref>.</t> t="X690"
<t><spanx style="verb">SignedData.version</spanx> MUST be v3(3).</t> format="default"/>.</li>
<t><spanx style="verb">SignedData.digestAlgorithms</spanx> MUST be the same as <li><tt>SignedData.version</tt> <bcp14>MUST</bcp14> be v3(3).</li>
the <li><tt>SignedData.digestAlgorithms</tt> <bcp14>MUST</bcp14> be the sa
<spanx style="verb">SignerInfo.digestAlgorithm</spanx> OID value (see below).</t me as the
> <tt>SignerInfo.digestAlgorithm</tt> OID value (see below).</li>
<t><spanx style="verb">SignedData.encapContentInfo</spanx>: <li>
<list style="symbols"> <t><tt>SignedData.encapContentInfo</tt>:</t>
<t><spanx style="verb">eContentType</spanx> MUST be the OID 1.3.101.78.</t <ul spacing="normal">
> <li><tt>eContentType</tt> <bcp14>MUST</bcp14> be the OID 1.3.101.7
<t><spanx style="verb">eContent</spanx> MUST contain a TBSCertificate <xre 8.</li>
f target="RFC5280"></xref> that will be identical to <li><tt>eContent</tt> <bcp14>MUST</bcp14> contain a TBSCertificate
the TBSCertificate in the issued certificate, except that the Transparency <xref
Information (<xref target="x509v3_transinfo_extension"/>) extension MUST be omit target="RFC5280" format="default"/> that will be identical to
ted.</t> the TBSCertificate in the issued certificate, except that the Trans
</list></t> parency
<t><spanx style="verb">SignedData.certificates</spanx> MUST be omitted.</t> Information (<xref target="x509v3_transinfo_extension" format="defa
<t><spanx style="verb">SignedData.crls</spanx> MUST be omitted.</t> ult"/>)
<t><spanx style="verb">SignedData.signerInfos</spanx> MUST contain one <spanx extension <bcp14>MUST</bcp14> be omitted.</li>
style="verb">SignerInfo</spanx>: </ul>
<list style="symbols"> </li>
<t><spanx style="verb">version</spanx> MUST be v3(3).</t> <li><tt>SignedData.certificates</tt> <bcp14>MUST</bcp14> be omitted.</
<t><spanx style="verb">sid</spanx> MUST use the <spanx style="verb">subjec li>
tKeyIdentifier</spanx> option.</t> <li><tt>SignedData.crls</tt> <bcp14>MUST</bcp14> be omitted.</li>
<t><spanx style="verb">digestAlgorithm</spanx> MUST be one of the hash alg <li><t><tt>SignedData.signerInfos</tt> <bcp14>MUST</bcp14> contain one
orithm OIDs listed in <tt>SignerInfo</tt>:</t>
the IANA CT Hash Algorithms Registry, described in <ul spacing="normal">
<xref target="hash_algorithms"/>.</t> <li><tt>version</tt> <bcp14>MUST</bcp14> be v3(3).</li>
<t><spanx style="verb">signedAttrs</spanx> MUST be present and MUST contai <li><tt>sid</tt> <bcp14>MUST</bcp14> use the <tt>subjectKeyIdentif
n two attributes: ier</tt>
<list style="symbols"> option.</li>
<t>A content-type attribute whose value is the same as <li><tt>digestAlgorithm</tt> <bcp14>MUST</bcp14> be one of the has
<spanx style="verb">SignedData.encapContentInfo.eContentType</spanx>.</t> h algorithm
<t>A message-digest attribute whose value is the message digest of OIDs listed in the IANA "Hash Algorithms" registry, described in
<spanx style="verb">SignedData.encapContentInfo.eContent</spanx>.</t> <xref target="hash_algorithms" format="default"/>.</li>
</list></t> <li>
<t><spanx style="verb">signatureAlgorithm</spanx> MUST be the same OID as <t><tt>signedAttrs</tt> <bcp14>MUST</bcp14> be present and
<spanx style="verb">TBSCertificate.signature</spanx>.</t> <bcp14>MUST</bcp14> contain two attributes:</t>
<t><spanx style="verb">signature</spanx> MUST be from the same (root or in <ul spacing="normal">
termediate) CA that intends to <li>a content-type attribute whose value is the same as
issue the corresponding certificate (see <xref target="binding_intent_to_issue"/ <tt>SignedData.encapContentInfo.eContentType</tt> and</li>
>).</t> <li>a message-digest attribute whose value is the message dige
<t><spanx style="verb">unsignedAttrs</spanx> MUST be omitted.</t> st of
</list></t> <tt>SignedData.encapContentInfo.eContent</tt>.</li>
</list></t> </ul>
</li>
<t><spanx style="verb">SignerInfo.signedAttrs</spanx> is included in the message <li><tt>signatureAlgorithm</tt> <bcp14>MUST</bcp14> be the same OI
digest calculation process D as
(see Section 5.4 of <xref target="RFC5652"></xref>), which ensures that the <spa <tt>TBSCertificate.signature</tt>.</li>
nx style="verb">SignerInfo.signature</spanx> <li><tt>signature</tt> <bcp14>MUST</bcp14> be from the same (root
or
intermediate) CA that intends to
issue the corresponding certificate (see <xref target="binding_inte
nt_to_issue"
format="default"/>).</li>
<li><tt>unsignedAttrs</tt> <bcp14>MUST</bcp14> be omitted.</li>
</ul>
</li>
</ul>
<t><tt>SignerInfo.signedAttrs</tt> is included in the message digest cal
culation process
(see <xref target="RFC5652" sectionFormat="of" section="5.4"/>), which ensures t
hat the <tt>SignerInfo.signature</tt>
value will not be a valid X.509v3 signature that could be used in conjunction value will not be a valid X.509v3 signature that could be used in conjunction
with the TBSCertificate (from <spanx style="verb">SignedData.encapContentInfo.eC ontent</spanx>) to with the TBSCertificate (from <tt>SignedData.encapContentInfo.eContent</tt>) to
construct a valid certificate.</t> construct a valid certificate.</t>
<section anchor="binding_intent_to_issue" numbered="true" toc="default">
<section anchor="binding_intent_to_issue" title="Binding Intent to Issue"> <name>Binding Intent to Issue</name>
<t>Under normal circumstances, there will be a short delay between pre
<t>Under normal circumstances, there will be a short delay between precertificat certificate
e
submission and issuance of the corresponding certificate. Longer delays are to submission and issuance of the corresponding certificate. Longer delays are to
be expected occasionally (e.g., due to log server downtime), and in some cases be expected occasionally (e.g., due to log server downtime); in some cases,
the CA might not actually issue the corresponding certificate. Nevertheless, a the CA might not actually issue the corresponding certificate. Nevertheless, a
precertificate's <spanx style="verb">signature</spanx> indicates the CA's bindin g intent to issue the precertificate's <tt>signature</tt> indicates the CA's binding intent to issue t he
corresponding certificate, which means that:</t> corresponding certificate, which means that:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Misissuance of a precertificate is considered equivalent to misi
<t>Misissuance of a precertificate is considered equivalent to misissuance of ssuance of
the corresponding certificate. The CA should expect to be held to account, the corresponding certificate. The CA should expect to be held accoun
even if the corresponding certificate has not actually been issued.</t> table,
<t>Upon observing a precertificate, a client can reasonably presume that the even if the corresponding certificate has not actually been issued.</
corresponding certificate has been issued. A client may wish to obtain status li>
information (e.g., by using the Online Certificate Status Protocol <xref target= <li>Upon observing a precertificate, a client can reasonably presume
"RFC6960"></xref> that the
or by checking a Certificate Revocation List <xref target="RFC5280"></xref>) abo corresponding certificate has been issued. A client may wish to obtai
ut a certificate n status
that is presumed to exist, especially if there is evidence or suspicion that information (e.g., by using the Online Certificate Status Protocol <x
the corresponding precertificate was misissued.</t> ref
<t>TLS clients may have policies that require CAs to be able to revoke, and to target="RFC6960" format="default"/>
provide certificate status services for, each certificate that is presumed to or by checking a Certificate Revocation List <xref target="RFC5280"
exist based on the existence of a corresponding precertificate.</t> format="default"/>) about a certificate
</list></t> that is presumed to exist, especially if there is evidence or suspici
on that
</section> the corresponding precertificate was misissued.</li>
</section> <li>TLS clients may have policies that require CAs to be able to rev
</section> oke and to
<section anchor="log-format-and-operation" title="Log Format and Operation"> provide certificate status services for each certificate that is pres
umed to
<t>A log is a single, append-only Merkle Tree of submitted certificate and exist based on the existence of a corresponding precertificate.</li>
</ul>
</section>
</section>
</section>
<section anchor="log-format-and-operation" numbered="true" toc="default">
<name>Log Format and Operation</name>
<t>A log is a single, append-only Merkle Tree of submitted certificate and
precertificate entries.</t> precertificate entries.</t>
<t>When it receives and accepts a valid submission, the log <bcp14>MUST</b
<t>When it receives and accepts a valid submission, the log MUST return an SCT t cp14> return an SCT that
hat
corresponds to the submitted certificate or precertificate. If the log has corresponds to the submitted certificate or precertificate. If the log has
previously seen this valid submission, it SHOULD return the same SCT as it previously seen this valid submission, it <bcp14>SHOULD</bcp14> return the same
returned before, as discussed in <xref target="misbehaving_logs"/>. SCT as it
returned before, as discussed in <xref target="misbehaving_logs" format="default
"/>.
If different SCTs are produced for the same If different SCTs are produced for the same
submission, multiple log entries will have to be created, one for each SCT (as submission, multiple log entries will have to be created, one for each SCT (as
the timestamp is a part of the leaf structure). Note that if a certificate was the timestamp is a part of the leaf structure). Note that if a certificate was
previously logged as a precertificate, then the precertificate's SCT of type previously logged as a precertificate, then the precertificate's SCT of type
<spanx style="verb">precert_sct_v2</spanx> would not be appropriate; instead, a <tt>precert_sct_v2</tt> would not be appropriate; instead, a fresh SCT of type
fresh SCT of type <tt>x509_sct_v2</tt> should be generated.</t>
<spanx style="verb">x509_sct_v2</spanx> should be generated.</t> <t>An SCT is the log's promise to append to its Merkle Tree an entry for t
he
<t>An SCT is the log's promise to append to its Merkle Tree an entry for the accepted submission. Upon producing an SCT, the log <bcp14>MUST</bcp14> fu
accepted submission. Upon producing an SCT, the log MUST fulfil this promise by lfill this
performing the following actions within a fixed amount of time known as the promise by performing the following actions within a fixed amount of time
Maximum Merge Delay (MMD), which is one of the log's parameters (see known as the
<xref target="log_parameters"/>):</t> Maximum Merge Delay (MMD), which is one of the log's parameters (see
<xref target="log_parameters" format="default"/>):</t>
<t><list style="symbols"> <ul spacing="normal">
<t>Allocate a tree index to the entry representing the accepted submission.</t <li>Allocate a tree index to the entry representing the accepted submiss
> ion.</li>
<t>Calculate the root of the tree.</t> <li>Calculate the root of the tree.</li>
<t>Sign the root of the tree (see <xref target="sth"/>).</t> <li>Sign the root of the tree (see <xref target="sth" format="default"/>
</list></t> ).</li>
</ul>
<t>The log may append multiple entries before signing the root of the tree.</t> <t>The log may append multiple entries before signing the root of the tree
.</t>
<t>Log operators SHOULD NOT impose any conditions on retrieving or sharing data <t>Log operators <bcp14>SHOULD NOT</bcp14> impose any conditions on retrie
ving or sharing data
from the log.</t> from the log.</t>
<section anchor="log_parameters" numbered="true" toc="default">
<section anchor="log_parameters" title="Log Parameters"> <name>Log Parameters</name>
<t>A log is defined by a collection of immutable parameters, which are u
<t>A log is defined by a collection of immutable parameters, which are used by sed by
clients to communicate with the log and to verify log artifacts. Except for the clients to communicate with the log and to verify log artifacts. Except for the
Final Signed Tree Head (STH), each of these parameters MUST be established Final STH, each of these parameters <bcp14>MUST</bcp14> be established
before the log operator begins to operate the log.</t> before the log operator begins to operate the log.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Base URL:</dt>
<t hangText="Base URL:"> <dd>The prefix used to construct URLs <xref target="RFC3986" format="d
The prefix used to construct URLs (<xref target="RFC3986"></xref>) for client efault"/>
messages (see for client messages (see <xref target="client_messages" format="default
<xref target="client_messages"/>). The base URL MUST be an "https" URL, MAY cont "/>). The
ain a port, base URL <bcp14>MUST</bcp14> be an "https" URL, <bcp14>MAY</bcp14> cont
MAY contain a path with any number of path segments, but MUST NOT contain a ain a port,
query string, fragment, or trailing "/". and <bcp14>MAY</bcp14> contain a path with any number of path segments
Example: https://ct.example.org/blue</t> but
<t hangText="Hash Algorithm:"> <bcp14>MUST NOT</bcp14> contain a query string, fragment, or trailing "
The hash algorithm used for the Merkle Tree (see <xref target="hash_algorithms /".
"/>).</t> Example: https://ct.example.org/blue.</dd>
<t hangText="Signature Algorithm:"> <dt>Hash Algorithm:</dt>
The signature algorithm used (see <xref target="signatures"/>).</t> <dd>The hash algorithm used for the Merkle Tree (see <xref target="has
<t hangText="Public Key:"> h_algorithms"
The public key used to verify signatures generated by the log. A log MUST NOT format="default"/>).</dd>
use the same keypair as any other log.</t> <dt>Signature Algorithm:</dt>
<t hangText="Log ID:"> <dd>The signature algorithm used (see <xref target="signatures"
The OID that uniquely identifies the log.</t> format="default"/>).</dd>
<t hangText="Maximum Merge Delay:"> <dt>Public Key:</dt>
The MMD the log has committed to. <dd>The public key used to verify signatures generated by the log. A l
This document deliberately does not specify any limits on the value, to allow og
for experimentation.</t> <bcp14>MUST NOT</bcp14> use the same keypair as any other log.</dd>
<t hangText="Version:"> <dt>Log ID:</dt>
The version of the protocol supported by the log (currently 1 or 2).</t> <dd>The OID that uniquely identifies the log.</dd>
<t hangText="Maximum Chain Length:"> <dt>Maximum Merge Delay:</dt>
The longest certificate chain submission the log is willing to accept, if the <dd>The MMD the log has committed to. This document deliberately does
log imposes not specify
any limit.</t> any limits on the value to allow for experimentation.</dd>
<t hangText="STH Frequency Count:"> <dt>Version:</dt>
The maximum number of STHs the log may produce in any period equal to the <dd>The version of the protocol supported by the log (currently 1 or 2
<spanx style="verb">Maximum Merge Delay</spanx> (see <xref target="sth"/>).</t> ).</dd>
<t hangText="Final STH:"> <dt>Maximum Chain Length:</dt>
If a log has been closed down (i.e., no longer accepts new entries), existing <dd>The longest certificate chain submission the log is willing to acc
entries may still be valid. In this case, the client should know the final ept, if the
valid STH in the log to ensure no new entries can be added without detection. log imposes any limit.</dd>
This value MUST be provided in the form of a TransItem of type <dt>STH Frequency Count:</dt>
<spanx style="verb">signed_tree_head_v2</spanx>. <dd>The maximum number of STHs the log may produce in any period equal
If a log is still accepting entries, this value should not be provided.</t> to the
</list></t> <tt>Maximum Merge Delay</tt> (see <xref target="sth" format="default"/>
).</dd>
<t><xref target="JSON.Metadata"></xref> is an example of a metadata format which <dt>Final STH:</dt>
includes the above <dd>If a log has been closed down (i.e., no longer accepts new entries
elements.</t> ), existing
entries may still be valid. In this case, the client should know the fi
</section> nal
<section anchor="evaluating-submissions" title="Evaluating Submissions"> valid STH in the log to ensure no new entries can be added without dete
ction.
<t>A log determines whether to accept or reject a submission by evaluating it This value <bcp14>MUST</bcp14> be provided in the form of a <tt>TransIt
against the minimum acceptance criteria (see <xref target="minimum_criteria"/>) em</tt> of
and against type <tt>signed_tree_head_v2</tt>.
the log's discretionary acceptance criteria (see <xref target="discretionary_cri If a log is still accepting entries, this value should not be provided.
teria"/>).</t> </dd>
</dl>
<t>If the acceptance criteria are met, the log SHOULD accept the submission. (A <t><xref target="JSON.Metadata" format="default"/> is an example of a me
log tadata format
that includes the above elements.</t>
</section>
<section anchor="evaluating-submissions" numbered="true" toc="default">
<name>Evaluating Submissions</name>
<t>A log determines whether to accept or reject a submission by evaluati
ng it
against the minimum acceptance criteria (see <xref target="minimum_criteria" for
mat="default"/>) and against
the log's discretionary acceptance criteria (see <xref target="discretionary_cri
teria" format="default"/>).</t>
<t>If the acceptance criteria are met, the log <bcp14>SHOULD</bcp14> acc
ept the submission. (A log
may decide, for example, to temporarily reject acceptable submissions to protect may decide, for example, to temporarily reject acceptable submissions to protect
itself against denial-of-service attacks).</t> itself against denial-of-service attacks.)</t>
<t>The log <bcp14>SHALL</bcp14> allow retrieval of its list of accepted
<t>The log SHALL allow retrieval of its list of accepted trust anchors (see trust anchors (see
<xref target="get-anchors"/>), each of which is a root or intermediate CA certif <xref target="get-anchors" format="default"/>), each of which is a root or inter
icate. This mediate CA certificate. This
list might usefully be the union of root certificates trusted by major browser list might usefully be the union of root certificates trusted by major browser
vendors.</t> vendors.</t>
<section anchor="minimum_criteria" numbered="true" toc="default">
<section anchor="minimum_criteria" title="Minimum Acceptance Criteria"> <name>Minimum Acceptance Criteria</name>
<t>To ensure that logged certificates and precertificates are attribut
<t>To ensure that logged certificates and precertificates are attributable to an able to an
accepted trust anchor, to set clear expectations for what monitors would accepted trust anchor, to set clear expectations for what monitors would
find in the log, and to avoid being overloaded by invalid submissions, the log find in the log, and to avoid being overloaded by invalid submissions, the log
MUST reject a submission if any of the following conditions are not met:</t> <bcp14>MUST</bcp14> reject a submission if any of the following conditions are n
ot met:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>The <spanx style="verb">submission</spanx>, <spanx style="verb">type</spanx <li>The <tt>submission</tt>, <tt>type</tt>, and <tt>chain</tt> input
> and <spanx style="verb">chain</spanx> inputs MUST be set as described in s
<xref target="submit-entry"/>. The log MUST NOT accommodate misordered CA certif <bcp14>MUST</bcp14> be set as described in
icates or <xref target="submit-entry" format="default"/>. The log <bcp14>MUST N
use any other source of intermediate CA certificates to attempt certification OT</bcp14>
path construction.</t> accommodate misordered CA certificates or
<t>Each of the zero or more intermediate CA certificates in the chain MUST hav use any other source of intermediate CA certificates to attempt certi
e fication
one or both of the following features: path construction.</li>
<list style="symbols"> <li>
<t>The Basic Constraints extension with the cA boolean asserted.</t> <t>Each of the zero or more intermediate CA certificates in the cha
<t>The Key Usage extension with the keyCertSign bit asserted.</t> in
</list></t> <bcp14>MUST</bcp14> have one or both of the following features:</t>
<t>Each certificate in the chain MUST fall within the limits imposed by the ze <ul spacing="normal">
ro <li>The Basic Constraints extension with the cA boolean asserted
or more Basic Constraints pathLenConstraint values found higher up the chain.</t .</li>
> <li>The Key Usage extension with the keyCertSign bit asserted.</
<t>Precertificate submissions MUST conform to all of the requirements in li>
<xref target="precertificates"/>.</t> </ul>
</list></t> </li>
<li>Each certificate in the chain <bcp14>MUST</bcp14> fall within th
</section> e limits
<section anchor="discretionary_criteria" title="Discretionary Acceptance Criteri imposed by the zero
a"> or more Basic Constraints pathLenConstraint values found higher up th
e chain.</li>
<t>If the minimum acceptance criteria are met but the submission is not fully <li>Precertificate submissions <bcp14>MUST</bcp14> conform to all of
valid according to <xref target="RFC5280"></xref> verification rules (e.g., the the
certificate or requirements in
precertificate has expired, is not yet valid, has been revoked, exhibits ASN.1 <xref target="precertificates" format="default"/>.</li>
DER encoding errors but the log can still parse it, etc), then the acceptability </ul>
of the submission is left to the log's discretion. It is useful for logs to </section>
accept such submissions in order to accommodate quirks of CA certificate-issuing <section anchor="discretionary_criteria" numbered="true" toc="default">
software and to facilitate monitoring of CA compliance with applicable policies <name>Discretionary Acceptance Criteria</name>
and technical standards. However, it is impractical for this document to <t>If the minimum acceptance criteria are met but the submission is no
enumerate, and for logs to consider, all of the ways that a submission might t fully
fail to comply with <xref target="RFC5280"></xref>.</t> valid according to <xref target="RFC5280" format="default"/> verificati
on rules
<t>Logs SHOULD limit the length of chain they will accept. The maximum chain len (e.g., the certificate or
gth precertificate has expired, is not yet valid, has been revoked, exhibit
is one of the log's parameters (see <xref target="log_parameters"/>).</t> s ASN.1
DER encoding errors but the log can still parse it, etc.), then the acc
</section> eptability
</section> of the submission is left to the log's discretion. It is useful for log
<section anchor="log_entries" title="Log Entries"> s to
accept such submissions in order to accommodate quirks of CA certificat
<t>If a submission is accepted and an SCT issued, the accepting log MUST store t e-issuing
he software and to facilitate monitoring of CA compliance with applicable
entire chain used for verification. This chain MUST include the certificate or policies
and technical standards. However, it is impractical for this document t
o
enumerate, and for logs to consider, all of the ways that a submission
might
fail to comply with <xref target="RFC5280" format="default"/>.</t>
<t>Logs <bcp14>SHOULD</bcp14> limit the length of chain they will acce
pt. The
maximum chain length is one of the log's parameters (see <xref
target="log_parameters" format="default"/>).</t>
</section>
</section>
<section anchor="log_entries" numbered="true" toc="default">
<name>Log Entries</name>
<t>If a submission is accepted and an SCT is issued, the accepting log <
bcp14>MUST</bcp14> store the
entire chain used for verification. This chain <bcp14>MUST</bcp14> include the c
ertificate or
precertificate itself, the zero or more intermediate CA certificates provided by precertificate itself, the zero or more intermediate CA certificates provided by
the submitter, and the trust anchor used to verify the chain (even if it was the submitter, and the trust anchor used to verify the chain (even if it was
omitted from the submission). The log MUST provide this chain for auditing upon omitted from the submission). The log <bcp14>MUST</bcp14> provide this chain for
request (see <xref target="get-entries"/>) so that the CA cannot avoid blame by auditing upon
request (see <xref target="get-entries" format="default"/>) so that the CA canno
t avoid blame by
logging a partial or empty chain. logging a partial or empty chain.
Each log entry is a <spanx style="verb">TransItem</spanx> structure of type <spa Each log entry is a <tt>TransItem</tt> structure of type <tt>x509_entry_v2</tt>
nx style="verb">x509_entry_v2</spanx> or or
<spanx style="verb">precert_entry_v2</spanx>. However, a log may store its entri <tt>precert_entry_v2</tt>. However, a log may store its entries in any format. I
es in any format. If a f a
log does not store this <spanx style="verb">TransItem</spanx> in full, it must s log does not store this <tt>TransItem</tt> in full, it must store the <tt>timest
tore the <spanx style="verb">timestamp</spanx> amp</tt>
and <spanx style="verb">sct_extensions</spanx> of the corresponding <spanx style and <tt>sct_extensions</tt> of the corresponding <tt>TimestampedCertificateEntry
="verb">TimestampedCertificateEntryDataV2</spanx> DataV2</tt>
structure. The <spanx style="verb">TransItem</spanx> can be reconstructed from t structure. The <tt>TransItem</tt> can be reconstructed from these fields and the
hese fields and the entire entire
chain that the log used to verify the submission.</t> chain that the log used to verify the submission.</t>
</section>
</section> <section anchor="log_id" numbered="true" toc="default">
<section anchor="log_id" title="Log ID"> <name>Log ID</name>
<t>Each log is identified by an OID, which is one of the log's parameter
<t>Each log is identified by an OID, which is one of the log's parameters (see s (see
<xref target="log_parameters"/>) and which MUST NOT be used to identify any othe <xref target="log_parameters" format="default"/>) and which <bcp14>MUST NOT</bcp
r log. A 14> be used to identify any other log. A
log's operator MUST either allocate the OID themselves or request an OID from log's operator <bcp14>MUST</bcp14> either allocate the OID themselves or request
the Log ID registry (see <xref target="log_id_registry"/>). an OID from
the Log ID registry (see <xref target="log_id_registry" format="default"/>).
One way to get an OID arc, from which OIDs can be allocated, is to request One way to get an OID arc, from which OIDs can be allocated, is to request
a Private Enterprise Number from IANA, by completing the a Private Enterprise Number from IANA by completing the
<eref target="https://pen.iana.org/pen/PenApplication.page">registration form</e ref>. <eref target="https://pen.iana.org/pen/PenApplication.page">registration form</e ref>.
The only advantage of the registry is that the DER encoding can be small. The only advantage of the registry is that the DER encoding can be small.
(Recall that OID allocations do not require a central registration, although (Recall that OID allocations do not require a central registration, although
logs will most likely want to make themselves known to potential clients logs will most likely want to make themselves known to potential clients
through out of band means.) through out-of-band means.)
Various data structures include Various data structures include
the DER encoding of this OID, excluding the ASN.1 tag and length bytes, in an the DER encoding of this OID, excluding the ASN.1 tag and length bytes, in an
opaque vector:</t> opaque vector:</t>
<sourcecode type="tls-presentation"><![CDATA[
<figure><artwork><![CDATA[
opaque LogID<2..127>; opaque LogID<2..127>;
]]></artwork></figure> ]]></sourcecode>
<t>Note that the ASN.1 length and the opaque vector length are identical
<t>Note that the ASN.1 length and the opaque vector length are identical in size in size (1
(1
byte) and value, so the full DER encoding (including the tag and length) byte) and value, so the full DER encoding (including the tag and length)
of the OID can be reproduced simply by of the OID can be reproduced simply by
prepending an OBJECT IDENTIFIER tag (0x06) to the opaque vector length and prepending an OBJECT IDENTIFIER tag (0x06) to the opaque vector length and
contents.</t> contents.</t>
<t>The OID used to identify a log is limited such that the DER encoding
<t>The OID used to identify a log is limited such that the DER encoding of its of its
value, excluding the tag and length, MUST be no longer than 127 octets.</t> value, excluding the tag and length, <bcp14>MUST</bcp14> be no longer than 127 o
ctets.</t>
</section> </section>
<section anchor="transitem-structure" title="TransItem Structure"> <section anchor="transitem-structure" numbered="true" toc="default">
<name>TransItem Structure</name>
<t>Various data structures are encapsulated in the <spanx style="verb">TransItem <t>Various data structures are encapsulated in the <tt>TransItem</tt> st
</spanx> structure to ensure ructure to ensure
that the type and version of each one is identified in a common fashion:</t> that the type and version of each one is identified in a common fashion:</t>
<sourcecode type="tls-presentation"><![CDATA[
<figure><artwork><![CDATA[
enum { enum {
x509_entry_v2(0x0100), precert_entry_v2(0x0101), x509_entry_v2(0x0100), precert_entry_v2(0x0101),
x509_sct_v2(0x0102), precert_sct_v2(0x0103), x509_sct_v2(0x0102), precert_sct_v2(0x0103),
signed_tree_head_v2(0x0104), consistency_proof_v2(0x0105), signed_tree_head_v2(0x0104), consistency_proof_v2(0x0105),
inclusion_proof_v2(0x0106), inclusion_proof_v2(0x0106),
/* Reserved Code Points */ /* Reserved Code Points */
reserved_rfc6962(0x0000..0x00FF), reserved_rfc6962(0x0000..0x00FF),
reserved_experimentaluse(0xE000..0xEFFF), reserved_experimentaluse(0xE000..0xEFFF),
reserved_privateuse(0xF000..0xFFFF), reserved_privateuse(0xF000..0xFFFF),
skipping to change at line 872 skipping to change at line 825
select (versioned_type) { select (versioned_type) {
case x509_entry_v2: TimestampedCertificateEntryDataV2; case x509_entry_v2: TimestampedCertificateEntryDataV2;
case precert_entry_v2: TimestampedCertificateEntryDataV2; case precert_entry_v2: TimestampedCertificateEntryDataV2;
case x509_sct_v2: SignedCertificateTimestampDataV2; case x509_sct_v2: SignedCertificateTimestampDataV2;
case precert_sct_v2: SignedCertificateTimestampDataV2; case precert_sct_v2: SignedCertificateTimestampDataV2;
case signed_tree_head_v2: SignedTreeHeadDataV2; case signed_tree_head_v2: SignedTreeHeadDataV2;
case consistency_proof_v2: ConsistencyProofDataV2; case consistency_proof_v2: ConsistencyProofDataV2;
case inclusion_proof_v2: InclusionProofDataV2; case inclusion_proof_v2: InclusionProofDataV2;
} data; } data;
} TransItem; } TransItem;
]]></artwork></figure> ]]></sourcecode>
<t><tt>versioned_type</tt> is a value from the IANA registry in <xref ta
<t><spanx style="verb">versioned_type</spanx> is a value from the IANA registry rget="versioned_trans_types" format="default"/>
in <xref target="versioned_trans_types"/>
that identifies the type of the encapsulated data structure and the earliest that identifies the type of the encapsulated data structure and the earliest
version of this protocol to which it conforms. This document is v2.</t> version of this protocol to which it conforms. This document is v2.</t>
<t><tt>data</tt> is the encapsulated data structure. The various structu
<t><spanx style="verb">data</spanx> is the encapsulated data structure. The vari res named with the
ous structures named with the <tt>DataV2</tt> suffix are defined in later sections of this document.</t>
<spanx style="verb">DataV2</spanx> suffix are defined in later sections of this <t>Note that <tt>VersionedTransType</tt> combines the v1 type enumeratio
document.</t> ns
<tt>Version</tt>, <tt>LogEntryType</tt>, <tt>SignatureType</tt>, and <tt>MerkleL
<t>Note that <spanx style="verb">VersionedTransType</spanx> combines the v1 <xre eafType</tt> <xref target="RFC6962" format="default"/>. Note also that
f target="RFC6962"></xref> type enumerations v1 did not define <tt>TransItem</tt>, but this document provides guidelines (see
<spanx style="verb">Version</spanx>, <spanx style="verb">LogEntryType</spanx>, < <xref target="v1_coexistence" format="default"/>) on how v2 implementations can
spanx style="verb">SignatureType</spanx> and <spanx style="verb">MerkleLeafType< coexist with v1
/spanx>. Note also that
v1 did not define <spanx style="verb">TransItem</spanx>, but this document provi
des guidelines (see
<xref target="v1_coexistence"/>) on how v2 implementations can co-exist with v1
implementations.</t> implementations.</t>
<t>Future versions of this protocol may reuse <tt>VersionedTransType</tt
<t>Future versions of this protocol may reuse <spanx style="verb">VersionedTrans > values defined
Type</spanx> values defined in this document as long as the corresponding data structures are not modified
in this document as long as the corresponding data structures are not modified, and may add new <tt>VersionedTransType</tt> values for new or modified data stru
and may add new <spanx style="verb">VersionedTransType</spanx> values for new or ctures.</t>
modified data structures.</t> </section>
<section anchor="log-artifact-extensions" numbered="true" toc="default">
</section> <name>Log Artifact Extensions</name>
<section anchor="log-artifact-extensions" title="Log Artifact Extensions"> <sourcecode type="tls-presentation"><![CDATA[
<figure><artwork><![CDATA[
enum { enum {
reserved(65535) reserved(65535)
} ExtensionType; } ExtensionType;
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
]]></artwork></figure> ]]></sourcecode>
<t>The <tt>Extension</tt> structure provides a generic extensibility for
<t>The <spanx style="verb">Extension</spanx> structure provides a generic extens log artifacts,
ibility for log artifacts, including SCTs (<xref target="sct" format="default"/>) and STHs
including SCTs (<xref target="sct"/>) and STHs (<xref target="sth" format="default"/>). The interpretation of the <tt>extension
(<xref target="sth"/>). The interpretation of the <spanx style="verb">extension_ _data</tt> field is determined solely
data</spanx> field is determined solely by the value of the <tt>extension_type</tt> field.</t>
by the value of the <spanx style="verb">extension_type</spanx> field.</t> <t>This document does not define any extensions, but it does establish a
registry
<t>This document does not define any extensions, but it does establish a registr for future <tt>ExtensionType</tt> values (see <xref target="log_artifact_extensi
y on_registry" format="default"/>).
for future <spanx style="verb">ExtensionType</spanx> values (see <xref target="l Each document that registers a new <tt>ExtensionType</tt> must specify the conte
og_artifact_extension_registry"/>). xt in
Each document that registers a new <spanx style="verb">ExtensionType</spanx> mus
t specify the context in
which it may be used (e.g., SCT, STH, or both) and describe how to interpret the which it may be used (e.g., SCT, STH, or both) and describe how to interpret the
corresponding <spanx style="verb">extension_data</spanx>.</t> corresponding <tt>extension_data</tt>.</t>
</section>
</section> <section anchor="tree_leaves" numbered="true" toc="default">
<section anchor="tree_leaves" title="Merkle Tree Leaves"> <name>Merkle Tree Leaves</name>
<t>The leaves of a log's Merkle Tree correspond to the log's entries (se
<t>The leaves of a log's Merkle Tree correspond to the log's entries (see e
<xref target="log_entries"/>). Each leaf is the leaf hash (<xref target="mht"/>) <xref target="log_entries" format="default"/>). Each leaf is the leaf hash (<xre
of a <spanx style="verb">TransItem</spanx> f target="mht" format="default"/>) of a <tt>TransItem</tt>
structure of type <spanx style="verb">x509_entry_v2</spanx> or <spanx style="ver structure of type <tt>x509_entry_v2</tt> or <tt>precert_entry_v2</tt>, which enc
b">precert_entry_v2</spanx>, which encapsulates a apsulates a
<spanx style="verb">TimestampedCertificateEntryDataV2</spanx> structure. Note th <tt>TimestampedCertificateEntryDataV2</tt> structure. Note that leaf hashes are
at leaf hashes are calculated as <tt>HASH(0x00 || TransItem)</tt>, where the hash algorithm is one
calculated as HASH(0x00 || TransItem), where the hash algorithm is one of the of the
log's parameters.</t> log's parameters.</t>
<sourcecode type="tls-presentation"><![CDATA[
<figure><artwork><![CDATA[
opaque TBSCertificate<1..2^24-1>; opaque TBSCertificate<1..2^24-1>;
struct { struct {
uint64 timestamp; uint64 timestamp;
opaque issuer_key_hash<32..2^8-1>; opaque issuer_key_hash<32..2^8-1>;
TBSCertificate tbs_certificate; TBSCertificate tbs_certificate;
Extension sct_extensions<0..2^16-1>; Extension sct_extensions<0..2^16-1>;
} TimestampedCertificateEntryDataV2; } TimestampedCertificateEntryDataV2;
]]></artwork></figure> ]]></sourcecode>
<t><tt>timestamp</tt> is the date and time at which the certificate or p
<t><spanx style="verb">timestamp</spanx> is the date and time at which the certi recertificate
ficate or precertificate was was accepted by the log, in the form of a 64-bit unsigned number of milli
accepted by the log, in the form of a 64-bit unsigned number of milliseconds seconds
elapsed since the Unix Epoch (1 January 1970 00:00:00 UTC - see <xref target="UN elapsed since the Unix Epoch (1 January 1970 00:00:00 UTC -- see <xref
IXTIME"></xref>), target="UNIXTIME" format="default"/>),
ignoring leap seconds, in network byte order. Note that the leaves of a log's ignoring leap seconds, in network byte order. Note that the leaves of a l
Merkle Tree are not required to be in strict chronological order.</t> og's
Merkle Tree are not required to be in strict chronological order.</t>
<t><spanx style="verb">issuer_key_hash</spanx> is the HASH of the public key of <t><tt>issuer_key_hash</tt> is the HASH of the public key of the CA that
the CA that issued the issued the
certificate or precertificate, calculated over the DER encoding of the key certificate or precertificate, calculated over the DER encoding of the key
represented as SubjectPublicKeyInfo <xref target="RFC5280"></xref>. This is need ed to bind the CA to represented as SubjectPublicKeyInfo <xref target="RFC5280" format="default"/>. T his is needed to bind the CA to
the certificate or precertificate, making it impossible for the corresponding the certificate or precertificate, making it impossible for the corresponding
SCT to be valid for any other certificate or precertificate whose TBSCertificate SCT to be valid for any other certificate or precertificate whose TBSCertificate
matches <spanx style="verb">tbs_certificate</spanx>. The length of the <spanx st yle="verb">issuer_key_hash</spanx> MUST match matches <tt>tbs_certificate</tt>. The length of the <tt>issuer_key_hash</tt> <bc p14>MUST</bcp14> match
HASH_SIZE.</t> HASH_SIZE.</t>
<t><tt>tbs_certificate</tt> is the DER-encoded TBSCertificate from the s
<t><spanx style="verb">tbs_certificate</spanx> is the DER encoded TBSCertificate ubmission.
from the submission. (Note (Note that a precertificate's TBSCertificate can be reconstructed from th
that a precertificate's TBSCertificate can be reconstructed from the e
corresponding certificate as described in <xref target="reconstructing_tbscertif corresponding certificate, as described in <xref
icate"/>).</t> target="reconstructing_tbscertificate" format="default"/>).</t>
<t><tt>sct_extensions</tt> is byte-for-byte identical to the SCT extensi
<t><spanx style="verb">sct_extensions</spanx> is byte-for-byte identical to the ons of the
SCT extensions of the corresponding SCT.</t>
corresponding SCT.</t> <t>The type of the <tt>TransItem</tt> corresponds to the value of the <t
t>type</tt> parameter
<t>The type of the <spanx style="verb">TransItem</spanx> corresponds to the valu supplied in the <xref target="submit-entry" format="default"/> call.</t>
e of the <spanx style="verb">type</spanx> parameter </section>
supplied in the <xref target="submit-entry"/> call.</t> <section anchor="sct" numbered="true" toc="default">
<name>Signed Certificate Timestamp (SCT)</name>
</section> <t>An SCT is a <tt>TransItem</tt> structure of type <tt>x509_sct_v2</tt>
<section anchor="sct" title="Signed Certificate Timestamp (SCT)"> or <tt>precert_sct_v2</tt>,
which encapsulates a <tt>SignedCertificateTimestampDataV2</tt> structure:</t>
<t>An SCT is a <spanx style="verb">TransItem</spanx> structure of type <spanx st <sourcecode type="tls-presentation"><![CDATA[
yle="verb">x509_sct_v2</spanx> or <spanx style="verb">precert_sct_v2</spanx>,
which encapsulates a <spanx style="verb">SignedCertificateTimestampDataV2</spanx
> structure:</t>
<figure><artwork><![CDATA[
struct { struct {
LogID log_id; LogID log_id;
uint64 timestamp; uint64 timestamp;
Extension sct_extensions<0..2^16-1>; Extension sct_extensions<0..2^16-1>;
opaque signature<1..2^16-1>; opaque signature<1..2^16-1>;
} SignedCertificateTimestampDataV2; } SignedCertificateTimestampDataV2;
]]></artwork></figure> ]]></sourcecode>
<t><tt>log_id</tt> is this log's unique ID, encoded in an opaque vector,
<t><spanx style="verb">log_id</spanx> is this log's unique ID, encoded in an opa as described
que vector as described in in <xref target="log_id" format="default"/>.</t>
<xref target="log_id"/>.</t> <t><tt>timestamp</tt> is equal to the timestamp from the corresponding
<tt>TimestampedCertificateEntryDataV2</tt> structure.</t>
<t><spanx style="verb">timestamp</spanx> is equal to the timestamp from the corr <t><tt>sct_extensions</tt> is a vector of 0 or more SCT extensions. This
esponding vector
<spanx style="verb">TimestampedCertificateEntryDataV2</spanx> structure.</t> <bcp14>MUST NOT</bcp14> include more than one extension with the same
<tt>extension_type</tt>. The
<t><spanx style="verb">sct_extensions</spanx> is a vector of 0 or more SCT exten extensions in the vector <bcp14>MUST</bcp14> be ordered by the value of t
sions. This vector MUST NOT he
include more than one extension with the same <spanx style="verb">extension_type <tt>extension_type</tt> field, smallest value first.
</spanx>. The All SCT extensions are similar to noncritical X.509v3 extensions (i.e.,
extensions in the vector MUST be ordered by the value of the the <tt>mustUnderstand</tt> field is not set), and a recipient <bcp14>SHO
<spanx style="verb">extension_type</spanx> field, smallest value first. ULD</bcp14>
All SCT extensions are similar to non-critical X.509v3 extensions (i.e., ignore any extension it does not understand.
the <spanx style="verb">mustUnderstand</spanx> field is not set), and a recipien Furthermore, an implementation <bcp14>MAY</bcp14> choose to ignore any ex
t SHOULD ignore any tension(s)
extension it does not understand. that it does understand.</t>
Furthermore, an implementation MAY choose to ignore any extension(s) that it <t><tt>signature</tt> is computed over a <tt>TransItem</tt> structure of
does understand.</t> type
<tt>x509_entry_v2</tt> or <tt>precert_entry_v2</tt> (see <xref target="tr
<t><spanx style="verb">signature</spanx> is computed over a <spanx style="verb"> ee_leaves"
TransItem</spanx> structure of type <spanx style="verb">x509_entry_v2</spanx> format="default"/>) using the signature algorithm
or <spanx style="verb">precert_entry_v2</spanx> (see <xref target="tree_leaves"/ declared in the log's parameters (see <xref target="log_parameters"
>) using the signature algorithm format="default"/>).</t>
declared in the log's parameters (see <xref target="log_parameters"/>).</t> </section>
<section anchor="tree_head" numbered="true" toc="default">
</section> <name>Merkle Tree Head</name>
<section anchor="tree_head" title="Merkle Tree Head"> <t>The log stores information about its Merkle Tree in a <tt>TreeHeadDat
aV2</tt>:</t>
<t>The log stores information about its Merkle Tree in a <spanx style="verb">Tre <sourcecode type="tls-presentation"><![CDATA[
eHeadDataV2</spanx>:</t>
<figure><artwork><![CDATA[
opaque NodeHash<32..2^8-1>; opaque NodeHash<32..2^8-1>;
struct { struct {
uint64 timestamp; uint64 timestamp;
uint64 tree_size; uint64 tree_size;
NodeHash root_hash; NodeHash root_hash;
Extension sth_extensions<0..2^16-1>; Extension sth_extensions<0..2^16-1>;
} TreeHeadDataV2; } TreeHeadDataV2;
]]></artwork></figure> ]]></sourcecode>
<t>The length of NodeHash <bcp14>MUST</bcp14> match HASH_SIZE of the log
<t>The length of NodeHash MUST match HASH_SIZE of the log.</t> .</t>
<t><tt>timestamp</tt> is the current date and time, using the format def
<t><spanx style="verb">timestamp</spanx> is the current date and time, using the ined in
format defined in <xref target="tree_leaves" format="default"/>.</t>
<xref target="tree_leaves"/>.</t> <t><tt>tree_size</tt> is the number of entries currently in the log's Me
rkle Tree.</t>
<t><spanx style="verb">tree_size</spanx> is the number of entries currently in t <t><tt>root_hash</tt> is the root of the Merkle Tree.</t>
he log's Merkle Tree.</t> <t><tt>sth_extensions</tt> is a vector of 0 or more STH extensions. This
vector <bcp14>MUST NOT</bcp14>
<t><spanx style="verb">root_hash</spanx> is the root of the Merkle Hash Tree.</t include more than one extension with the same <tt>extension_type</tt>. The
> extensions in the vector <bcp14>MUST</bcp14> be ordered by the value of the
<tt>extension_type</tt> field, smallest value first. If an implementation sees a
<t><spanx style="verb">sth_extensions</spanx> is a vector of 0 or more STH exten n
sions. This vector MUST NOT extension that it does not understand, it <bcp14>SHOULD</bcp14> ignore that exte
include more than one extension with the same <spanx style="verb">extension_type nsion.
</spanx>. The Furthermore, an implementation <bcp14>MAY</bcp14> choose to ignore any extension
extensions in the vector MUST be ordered by the value of the (s) that it
<spanx style="verb">extension_type</spanx> field, smallest value first. If an im
plementation sees an
extension that it does not understand, it SHOULD ignore that extension.
Furthermore, an implementation MAY choose to ignore any extension(s) that it
does understand.</t> does understand.</t>
</section>
</section> <section anchor="sth" numbered="true" toc="default">
<section anchor="sth" title="Signed Tree Head (STH)"> <name>Signed Tree Head (STH)</name>
<t>Periodically, each log <bcp14>SHOULD</bcp14> sign its current tree he
<t>Periodically each log SHOULD sign its current tree head information (see ad
<xref target="tree_head"/>) to produce an STH. When a client requests a log's la information (see <xref target="tree_head" format="default"/>) to produce
test STH (see an STH. When
<xref target="get-sth"/>), the log MUST return an STH that is no older than the a client requests a log's latest STH (see
log's MMD. <xref target="get-sth" format="default"/>), the log <bcp14>MUST</bcp14> r
However, since STHs could be used to mark individual clients (by producing a new eturn an STH
STH for each query), a log MUST NOT produce STHs more frequently than its that is no older than the log's MMD.
parameters declare (see <xref target="log_parameters"/>). In general, there is n However, since STHs could be used to mark individual clients (by producin
o need to g a new
produce a new STH unless there are new entries in the log; however, in the event STH for each query), a log <bcp14>MUST NOT</bcp14> produce STHs more freq
that a log does not accept any submissions during an MMD period, the log MUST uently than
sign the same Merkle Tree Hash with a fresh timestamp.</t> its parameters declare (see <xref target="log_parameters" format="default
"/>). In
<t>An STH is a <spanx style="verb">TransItem</spanx> structure of type <spanx st general, there is no need to
yle="verb">signed_tree_head_v2</spanx>, which produce a new STH unless there are new entries in the log; however, in th
encapsulates a <spanx style="verb">SignedTreeHeadDataV2</spanx> structure:</t> e event
that a log does not accept any submissions during an MMD period, the log
<figure><artwork><![CDATA[ <bcp14>MUST</bcp14> sign the same Merkle Tree Hash with a fresh timestamp
.</t>
<t>An STH is a <tt>TransItem</tt> structure of type <tt>signed_tree_head
_v2</tt>,
which encapsulates a <tt>SignedTreeHeadDataV2</tt> structure:</t>
<sourcecode type="tls-presentation"><![CDATA[
struct { struct {
LogID log_id; LogID log_id;
TreeHeadDataV2 tree_head; TreeHeadDataV2 tree_head;
opaque signature<1..2^16-1>; opaque signature<1..2^16-1>;
} SignedTreeHeadDataV2; } SignedTreeHeadDataV2;
]]></artwork></figure> ]]></sourcecode>
<t><tt>log_id</tt> is this log's unique ID encoded in an opaque vector,
<t><spanx style="verb">log_id</spanx> is this log's unique ID, encoded in an opa as described
que vector as described in in <xref target="log_id" format="default"/>.</t>
<xref target="log_id"/>.</t> <t>The <tt>timestamp</tt> in <tt>tree_head</tt> <bcp14>MUST</bcp14> be a
t least as
<t>The <spanx style="verb">timestamp</spanx> in <spanx style="verb">tree_head</s recent as the most recent SCT
panx> MUST be at least as recent as the most recent SCT timestamp in the tree. Each subsequent timestamp <bcp14>MUST</bcp14> be m
timestamp in the tree. Each subsequent timestamp MUST be more recent than the ore recent
timestamp of the previous update.</t> than the timestamp of the previous update.</t>
<t><tt>tree_head</tt> contains the latest tree head information (see <xr
<t><spanx style="verb">tree_head</spanx> contains the latest tree head informati ef target="tree_head" format="default"/>).</t>
on (see <xref target="tree_head"/>).</t> <t><tt>signature</tt> is computed over the <tt>tree_head</tt> field usin
g the signature algorithm
<t><spanx style="verb">signature</spanx> is computed over the <spanx style="verb declared in the log's parameters (see <xref target="log_parameters" format="defa
">tree_head</spanx> field using the signature algorithm ult"/>).</t>
declared in the log's parameters (see <xref target="log_parameters"/>).</t> </section>
<section anchor="merkle-consistency-proofs" numbered="true" toc="default">
</section> <name>Merkle Consistency Proofs</name>
<section anchor="merkle-consistency-proofs" title="Merkle Consistency Proofs"> <t>To prepare a Merkle consistency proof for distribution to clients, th
e log
<t>To prepare a Merkle Consistency Proof for distribution to clients, the log produces a <tt>TransItem</tt> structure of type <tt>consistency_proof_v2</tt>, w
produces a <spanx style="verb">TransItem</spanx> structure of type <spanx style= hich
"verb">consistency_proof_v2</spanx>, which encapsulates a <tt>ConsistencyProofDataV2</tt> structure:</t>
encapsulates a <spanx style="verb">ConsistencyProofDataV2</spanx> structure:</t> <sourcecode type="tls-presentation"><![CDATA[
<figure><artwork><![CDATA[
struct { struct {
LogID log_id; LogID log_id;
uint64 tree_size_1; uint64 tree_size_1;
uint64 tree_size_2; uint64 tree_size_2;
NodeHash consistency_path<0..2^16-1>; NodeHash consistency_path<0..2^16-1>;
} ConsistencyProofDataV2; } ConsistencyProofDataV2;
]]></artwork></figure> ]]></sourcecode>
<t><tt>log_id</tt> is this log's unique ID encoded in an opaque vector,
<t><spanx style="verb">log_id</spanx> is this log's unique ID, encoded in an opa as described
que vector as described in in <xref target="log_id" format="default"/>.</t>
<xref target="log_id"/>.</t> <t><tt>tree_size_1</tt> is the size of the older tree.</t>
<t><tt>tree_size_2</tt> is the size of the newer tree.</t>
<t><spanx style="verb">tree_size_1</spanx> is the size of the older tree.</t> <t><tt>consistency_path</tt> is a vector of Merkle Tree nodes proving th
e consistency
<t><spanx style="verb">tree_size_2</spanx> is the size of the newer tree.</t> of two STHs, as described in <xref target="consistency" format="default"/
>.</t>
<t><spanx style="verb">consistency_path</spanx> is a vector of Merkle Tree nodes </section>
proving the consistency of <section anchor="merkle-inclusion-proofs" numbered="true" toc="default">
two STHs as described in <xref target="consistency"/>.</t> <name>Merkle Inclusion Proofs</name>
<t>To prepare a Merkle inclusion proof for distribution to clients, the
</section> log
<section anchor="merkle-inclusion-proofs" title="Merkle Inclusion Proofs"> produces a <tt>TransItem</tt> structure of type <tt>inclusion_proof_v2</tt>, whi
ch
<t>To prepare a Merkle Inclusion Proof for distribution to clients, the log encapsulates an <tt>InclusionProofDataV2</tt> structure:</t>
produces a <spanx style="verb">TransItem</spanx> structure of type <spanx style= <sourcecode type="tls-presentation"><![CDATA[
"verb">inclusion_proof_v2</spanx>, which
encapsulates an <spanx style="verb">InclusionProofDataV2</spanx> structure:</t>
<figure><artwork><![CDATA[
struct { struct {
LogID log_id; LogID log_id;
uint64 tree_size; uint64 tree_size;
uint64 leaf_index; uint64 leaf_index;
NodeHash inclusion_path<0..2^16-1>; NodeHash inclusion_path<0..2^16-1>;
} InclusionProofDataV2; } InclusionProofDataV2;
]]></artwork></figure> ]]></sourcecode>
<t><tt>log_id</tt> is this log's unique ID encoded in an opaque vector,
<t><spanx style="verb">log_id</spanx> is this log's unique ID, encoded in an opa as described
que vector as described in in <xref target="log_id" format="default"/>.</t>
<xref target="log_id"/>.</t> <t><tt>tree_size</tt> is the size of the tree on which this inclusion pr
oof is
<t><spanx style="verb">tree_size</spanx> is the size of the tree on which this i based.</t>
nclusion proof is based.</t> <t><tt>leaf_index</tt> is the 0-based index of the log entry correspondi
ng to this
<t><spanx style="verb">leaf_index</spanx> is the 0-based index of the log entry
corresponding to this
inclusion proof.</t> inclusion proof.</t>
<t><tt>inclusion_path</tt> is a vector of Merkle Tree nodes proving the
<t><spanx style="verb">inclusion_path</spanx> is a vector of Merkle Tree nodes p inclusion of the
roving the inclusion of the chosen certificate or precertificate, as described in <xref target="merkle_inclu
chosen certificate or precertificate as described in <xref target="merkle_inclus sion_proof" format="default"/>.</t>
ion_proof"/>.</t> </section>
<section anchor="log_shutdown" numbered="true" toc="default">
</section> <name>Shutting Down a Log</name>
<section anchor="log_shutdown" title="Shutting down a log"> <t>Log operators may decide to shut down a log for various reasons, such
as
<t>Log operators may decide to shut down a log for various reasons, such as
deprecation of the signature algorithm. If there are entries in the log for deprecation of the signature algorithm. If there are entries in the log for
certificates that have not yet expired, simply making TLS clients stop certificates that have not yet expired, simply making TLS clients stop
recognizing that log will have the effect of invalidating SCTs from that log. recognizing that log will have the effect of invalidating SCTs from that log.
In order to avoid that, the following actions SHOULD be taken:</t> In order to avoid that, the following actions <bcp14>SHOULD</bcp14> be taken:</t
>
<t><list style="symbols"> <ul spacing="normal">
<t>Make it known to clients and monitors that the log will be frozen. <li>Make it known to clients and monitors that the log will be frozen.
This is not part of the API, so it will have to be done via a relevant This is not part of the API, so it will have to be done via a relevant
out-of-band mechanism.</t> out-of-band mechanism.</li>
<t>Stop accepting new submissions (the error code "shutdown" should be returne <li>Stop accepting new submissions (the error code "shutdown" should b
d e returned
for such requests).</t> for such requests).</li>
<t>Once MMD from the last accepted submission has passed and all pending <li>Once MMD from the last accepted submission has passed and all pend
submissions are incorporated, issue a final STH and publish it as one of the ing
log's parameters. Having an STH with a timestamp that is after the MMD has submissions are incorporated, issue a final STH and publish it as one o
passed from the last SCT issuance allows clients to audit this log regularly f the
without special handling for the final STH. At this point the log's private log's parameters. Having an STH with a timestamp that is after the MMD
key is no longer needed and can be destroyed.</t> has
<t>Keep the log running until the certificates in all of its entries have expi passed from the last SCT issuance allows clients to audit this log regu
red larly
or exist in other logs (this can be determined by scanning other logs or without special handling for the final STH. At this point, the log's pr
connecting to domains mentioned in the certificates and inspecting the SCTs ivate
served).</t> key is no longer needed and can be destroyed.</li>
</list></t> <li>Keep the log running until the certificates in all of its entries
have expired
</section> or exist in other logs (this can be determined by scanning other logs o
</section> r
<section anchor="client_messages" title="Log Client Messages"> connecting to domains mentioned in the certificates and inspecting the
SCTs
<t>Messages are sent as HTTPS GET or POST requests. Parameters for POSTs and all served).</li>
responses are encoded as JavaScript Object Notation (JSON) objects <xref target= </ul>
"RFC8259"></xref>. </section>
</section>
<section anchor="client_messages" numbered="true" toc="default">
<name>Log Client Messages</name>
<t>Messages are sent as HTTPS GET or POST requests. Parameters for POSTs a
nd all
responses are encoded as JavaScript Object Notation (JSON) objects <xref target=
"RFC8259" format="default"/>.
Parameters for GETs are encoded as order-independent key/value URL parameters, Parameters for GETs are encoded as order-independent key/value URL parameters,
using the "application/x-www-form-urlencoded" format described in the "HTML 4.01 using the "application/x-www-form-urlencoded" format described in the "HTML 4.01
Specification" <xref target="HTML401"></xref>. Binary data is base64 encoded acc Specification" <xref target="HTML401" format="default"/>. Binary data is base64
ording to encoded according to
section 4 of <xref target="RFC4648"></xref> as specified <xref target="RFC4648" sectionFormat="of" section="4"/>, as specified
in the individual messages.</t> in the individual messages.</t>
<t>Clients are configured with a log's base URL, which is one of the log's
<t>Clients are configured with a log's base URL, which is one of the log's
parameters. Clients construct URLs for requests by appending suffixes to this parameters. Clients construct URLs for requests by appending suffixes to this
base URL. This structure places some degree of restriction on how log operators base URL. This structure places some degree of restriction on how log operators
can deploy these services, as noted in <xref target="RFC8820"></xref>. However, operational can deploy these services, as noted in <xref target="RFC8820" format="default"/> . However, operational
experience with version 1 of this protocol has not indicated that these experience with version 1 of this protocol has not indicated that these
restrictions are a problem in practice.</t> restrictions are a problem in practice.</t>
<t>Note that JSON objects and URL parameters may contain fields not specif
<t>Note that JSON objects and URL parameters may contain fields not specified he ied here
re, to allow for experimentation. Any fields that are not understood <bcp14>SHOULD</
to allow for experimentation. Any fields that are not understood SHOULD bcp14>
be ignored.</t> be ignored.</t>
<t>In practice, log servers may include multiple front-end machines. Since
<t>In practice, log servers may include multiple front-end machines. Since it is it is
impractical to keep these machines in perfect sync, errors may occur that are impractical to keep these machines in perfect sync, errors that are
caused by skew between the machines. Where such errors are possible, the caused by skew between the machines may occur. Where such errors are possible, t
front-end will return additional information (as specified below) making it he
possible for clients to make progress, if progress is possible. Front-ends MUST front end will return additional information (as specified below), making it
only serve data that is free of gaps (that is, for example, no front-end will possible for clients to make progress, if progress is possible. Front ends <bcp1
4>MUST</bcp14>
only serve data that is free of gaps (that is, for example, no front end will
respond with an STH unless it is also able to prove consistency from all log respond with an STH unless it is also able to prove consistency from all log
entries logged within that STH).</t> entries logged within that STH).</t>
<t>For example, when a consistency proof between two STHs is requested, th
<t>For example, when a consistency proof between two STHs is requested, the e
front-end reached may not yet be aware of one or both STHs. In the case where it front end reached may not yet be aware of one or both STHs. In the case where it
is unaware of both, it will return the latest STH it is aware of. Where it is is unaware of both, it will return the latest STH it is aware of. Where it is
aware of the first but not the second, it will return the latest STH it is aware aware of the first but not the second, it will return the latest STH it is aware
of and a consistency proof from the first STH to the returned STH. The case of and a consistency proof from the first STH to the returned STH. The case
where it knows the second but not the first should not arise (see the "no gaps" where it knows the second but not the first should not arise (see the "no gaps"
requirement above).</t> requirement above).</t>
<t>If the log is unable to process a client's request, it <bcp14>MUST</bcp
<t>If the log is unable to process a client's request, it MUST return an HTTP 14> return an HTTP
response code of 4xx/5xx (see <xref target="RFC7231"></xref>), and, in place of response code of 4xx/5xx (see <xref target="RFC7231" format="default"/>), and, i
the responses n place of the responses
outlined in the subsections below, the body SHOULD be a JSON Problem Details outlined in the subsections below, the body <bcp14>SHOULD</bcp14> be a JSON prob
Object (see <xref target="RFC7807"></xref> Section 3), containing:</t> lem details
object (see <xref target="RFC7807" sectionFormat="of" section="3"/>) containing:
<t><list style="hanging"> </t>
<t hangText="type:"> <dl newline="false" spacing="normal">
A URN reference identifying the problem. To facilitate automated response <dt>type:</dt>
to errors, this document defines a set of standard tokens for use in the <dd>A URN reference identifying the problem. To facilitate automated res
<spanx style="verb">type</spanx> field, within the URN namespace of: "urn:ietf:p ponse
arams:trans:error:".</t> to errors, this document defines a set of standard tokens for use in the
<t hangText="detail:"> <tt>type</tt> field within the URN namespace of: "urn:ietf:params:trans:e
A human-readable string describing the error that prevented the log from rror:".</dd>
processing the request, ideally with sufficient detail to enable the error to <dt>detail:</dt>
be rectified.</t> <dd>A human-readable string describing the error that prevented the log
</list></t> from
processing the request, ideally with sufficient detail to enable the erro
<t>e.g., In response to a request of r to
<spanx style="verb">&lt;Base URL&gt;/ct/v2/get-entries?start=100&amp;end=99</spa be rectified.</dd>
nx>, the log would return a </dl>
<spanx style="verb">400 Bad Request</spanx> response code with a body similar to <t>For example, in response to a request of
the following:</t> <tt>&lt;Base URL&gt;/ct/v2/get-entries?start=100&amp;end=99</tt>, the log would
return a
<figure><artwork><![CDATA[ <tt>400 Bad Request</tt> response code with a body similar to the following:</t>
<sourcecode type="json"><![CDATA[
{ {
"type": "urn:ietf:params:trans:error:endBeforeStart", "type": "urn:ietf:params:trans:error:endBeforeStart",
"detail": "'start' cannot be greater than 'end'" "detail": "'start' cannot be greater than 'end'"
} }
]]></artwork></figure> ]]></sourcecode>
<t>Most error types are specific to the type of request and are defined in
<t>Most error types are specific to the type of request and are defined in the the
respective subsections below. The one exception is the "malformed" error type, respective subsections below. The one exception is the "malformed" error type,
which indicates that the log server could not parse the client's request because which indicates that the log server could not parse the client's request because
it did not comply with this document:</t> it did not comply with this document:</t>
<table align="center">
<texttable> <thead>
<ttcol align='left'>type</ttcol> <tr>
<ttcol align='left'>detail</ttcol> <th align="left">type</th>
<c>malformed</c> <th align="left">detail</th>
<c>The request could not be parsed.</c> </tr>
</texttable> </thead>
<tbody>
<t>Clients SHOULD treat <spanx style="verb">500 Internal Server Error</spanx> an <tr>
d <spanx style="verb">503 Service Unavailable</spanx> <td align="left">malformed</td>
responses as transient failures and MAY retry the same request without <td align="left">The request could not be parsed.</td>
modification at a later date. Note that as per <xref target="RFC7231"></xref>, i </tr>
n the case of a 503 </tbody>
response the log MAY include a <spanx style="verb">Retry-After:</spanx> header f </table>
ield in order to request a <t>Clients <bcp14>SHOULD</bcp14> treat <tt>500 Internal Server Error</tt>
minimum time for the client to wait before retrying the request. and <tt>503
In the absence of this header field, this document does not specify a minimum.</ Service Unavailable</tt>
t> responses as transient failures and <bcp14>MAY</bcp14> retry the same requ
est without
<t>Clients SHOULD treat any 4xx error as a problem with the request and not modification at a later date. Note that in the case of a 503 response, the
attempt to resubmit without some modification to the request. The full log
status code MAY provide additional details.</t> <bcp14>MAY</bcp14> include a <tt>Retry-After</tt> header field per <xref t
arget="RFC7231" format="default"/> in
<t>This document deliberately does not provide more specific guidance order to request a minimum time for the client to wait before retrying the
on the use of HTTP status codes.</t> request.
In the absence of this header field, this document does not specify a mini
<section anchor="submit-entry" title="Submit Entry to Log"> mum.</t>
<t>Clients <bcp14>SHOULD</bcp14> treat any 4xx error as a problem with the
<t>POST &lt;Base URL&gt;/ct/v2/submit-entry</t> request and
not attempt to resubmit without some modification to the request. The full
<t><list style="hanging"> status code <bcp14>MAY</bcp14> provide additional details.</t>
<t hangText="Inputs:"> <t>This document deliberately does not provide more specific guidance
<list style="hanging"> on the use of HTTP status codes.</t>
<t hangText="submission:"> <section anchor="submit-entry" numbered="true" toc="default">
The base64 encoded certificate or precertificate.</t> <name>Submit Entry to Log</name>
<t hangText="type:"> <t>POST &lt;Base URL&gt;/ct/v2/submit-entry</t>
The <spanx style="verb">VersionedTransType</spanx> integer value that in <dl newline="true" spacing="normal">
dicates the type of the <dt>Inputs:</dt>
<spanx style="verb">submission</spanx>: 1 for <spanx style="verb">x509_entry_v2< <dd>
/spanx>, or 2 for <spanx style="verb">precert_entry_v2</spanx>.</t> <dl newline="false" spacing="normal">
<t hangText="chain:"> <dt>submission:</dt>
An array of zero or more JSON strings, <dd>The base64-encoded certificate or precertificate.</dd>
each of which is a base64 encoded CA certificate. The first element <dt>type:</dt>
is the certifier of the <spanx style="verb">submission</spanx>; the second certi <dd>The <tt>VersionedTransType</tt> integer value that indicates t
fies the first; etc. he type of the
The last element of <spanx style="verb">chain</spanx> (or, if <spanx style="verb <tt>submission</tt>: 1 for <tt>x509_entry_v2</tt> or 2 for
">chain</spanx> is an empty array, the <tt>precert_entry_v2</tt>.</dd>
<spanx style="verb">submission</spanx>) is certified by an accepted trust anchor <dt>chain:</dt>
.</t> <dd>An array of zero or more JSON strings,
</list> each of which is a base64-encoded CA certificate. The first element
</t> is the certifier of the <tt>submission</tt>, the second certifies t
<t hangText="Outputs:"> he first,
<list style="hanging"> etc. The last element of <tt>chain</tt> (or, if <tt>chain</tt> is a
<t hangText="sct:"> n empty
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st array, the <tt>submission</tt>) is certified by an accepted trust a
yle="verb">x509_sct_v2</spanx> or <spanx style="verb">precert_sct_v2</spanx>, nchor.</dd>
signed by this log, that corresponds to the <spanx style="verb">submission</span </dl>
x>.</t> </dd>
</list> <dt>Outputs:</dt>
<dd>
If the submitted entry is immediately appended to (or already exists in) this <dl newline="false" spacing="normal">
log's tree, then the log SHOULD also output: <dt>sct:</dt>
<list style="hanging"> <dd><t>A base64-encoded <tt>TransItem</tt> of type <tt>x509_sct_v2
<t hangText="sth:"> </tt> or
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st <tt>precert_sct_v2</tt>, signed by this log, that corresponds to th
yle="verb">signed_tree_head_v2</spanx>, signed by this e
log.</t> <tt>submission</tt>.</t></dd>
<t hangText="inclusion:"> </dl>
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st <t>If the submitted entry is immediately appended to (or already e
yle="verb">inclusion_proof_v2</spanx> whose xists in) this
<spanx style="verb">inclusion_path</spanx> array of Merkle Tree nodes proves the log's tree, then the log <bcp14>SHOULD</bcp14> also output:</t>
inclusion of the <dl newline="false" spacing="normal" indent="3">
<spanx style="verb">submission</spanx> in the returned <spanx style="verb">sth</ <dt>sth:</dt>
spanx>.</t> <dd>A base64-encoded <tt>TransItem</tt> of type <tt>signed_tree_he
</list> ad_v2</tt>
</t> signed by this log.</dd>
</list></t> <dt>inclusion:</dt>
<dd>A base64-encoded <tt>TransItem</tt> of type <tt>inclusion_proo
<t>Error codes:</t> f_v2</tt>
whose <tt>inclusion_path</tt> array of Merkle Tree nodes proves the
<texttable> inclusion
<ttcol align='left'>type</ttcol> of the <tt>submission</tt> in the returned <tt>sth</tt>.</dd>
<ttcol align='left'>detail</ttcol> </dl>
<c>badSubmission</c> </dd>
<c><spanx style="verb">submission</spanx> is neither a valid certificate n </dl>
or a valid precertificate.</c> <t>Error codes:</t>
<c>badType</c> <table align="center">
<c><spanx style="verb">type</spanx> is neither 1 nor 2.</c> <thead>
<c>badChain</c> <tr>
<c>The first element of <spanx style="verb">chain</spanx> is not the certi <th align="left">type</th>
fier of the <spanx style="verb">submission</spanx>, or the second element does n <th align="left">detail</th>
ot certify the first, etc.</c> </tr>
<c>badCertificate</c> </thead>
<c>One or more certificates in the <spanx style="verb">chain</spanx> are n <tbody>
ot valid (e.g., not properly encoded).</c> <tr>
<c>unknownAnchor</c> <td align="left">badSubmission</td>
<c>The last element of <spanx style="verb">chain</spanx> (or, if <spanx st <td align="left">
yle="verb">chain</spanx> is an empty array, the <spanx style="verb">submission</ <tt>submission</tt> is neither a valid certificate nor a valid p
spanx>) both is not, and is not certified by, an accepted trust anchor.</c> recertificate.</td>
<c>shutdown</c> </tr>
<c>The log is no longer accepting submissions.</c> <tr>
</texttable> <td align="left">badType</td>
<td align="left">
<t>If the version of <spanx style="verb">sct</spanx> is not v2, then a v2 client <tt>type</tt> is neither 1 nor 2.</td>
may be unable to verify the </tr>
signature. It MUST NOT construe this as an error. This is to avoid forcing an <tr>
<td align="left">badChain</td>
<td align="left">The first element of <tt>chain</tt> is not the ce
rtifier of the <tt>submission</tt>, or the second element does not certify the f
irst, etc.</td>
</tr>
<tr>
<td align="left">badCertificate</td>
<td align="left">One or more certificates in <tt>chain</tt> are no
t valid (e.g., not properly encoded).</td>
</tr>
<tr>
<td align="left">unknownAnchor</td>
<td align="left">The last element of <tt>chain</tt> (or, if <tt>ch
ain</tt> is an empty array, the <tt>submission</tt>) is not, nor is it certified
by, an accepted trust anchor.</td>
</tr>
<tr>
<td align="left">shutdown</td>
<td align="left">The log is no longer accepting submissions.</td>
</tr>
</tbody>
</table>
<t>If the version of <tt>sct</tt> is not v2, then a v2 client may be una
ble to verify the
signature. It <bcp14>MUST NOT</bcp14> construe this as an error. This is to avoi
d forcing an
upgrade of compliant v2 clients that do not use the returned SCTs.</t> upgrade of compliant v2 clients that do not use the returned SCTs.</t>
<t>If a log detects bad encoding in a chain that otherwise verifies corr
<t>If a log detects bad encoding in a chain that otherwise verifies correctly th ectly, then
en the log <bcp14>MUST</bcp14> either log the certificate or return the "badCertifi
the log MUST either log the certificate or return the "bad certificate" error. cate" error.
If the certificate is logged, an SCT MUST be issued. Logging the certificate is If the certificate is logged, an SCT <bcp14>MUST</bcp14> be issued. Logging the
useful, because monitors (<xref target="monitor"/>) can then detect these encodi certificate is
ng errors, useful, because monitors (<xref target="monitor" format="default"/>) can then de
tect these encoding errors,
which may be accepted by some TLS clients.</t> which may be accepted by some TLS clients.</t>
<t>If <tt>submission</tt> is an accepted trust anchor whose certifier is
<t>If <spanx style="verb">submission</spanx> is an accepted trust anchor whose c neither an
ertifier is neither an accepted trust anchor nor the first element of <tt>chain</tt>, then the log <bcp
accepted trust anchor nor the first element of <spanx style="verb">chain</spanx> 14>MUST</bcp14> return
, then the log MUST return the "unknownAnchor" error. A log is not able to generate an SCT for a
the "unknown anchor" error. A log is not able to generate an SCT for a
submission if it submission if it
does not have access to the issuer's public key.</t> does not have access to the issuer's public key.</t>
<t>If the returned <tt>sct</tt> is intended to be provided to TLS client
<t>If the returned <spanx style="verb">sct</spanx> is intended to be provided to s, then <tt>sth</tt> and
TLS clients, then <spanx style="verb">sth</spanx> and <tt>inclusion</tt> (if returned) <bcp14>SHOULD</bcp14> also be provided to TLS c
<spanx style="verb">inclusion</spanx> (if returned) SHOULD also be provided to T lients. For
LS clients. For
example, if example, if
<spanx style="verb">type</spanx> was 2 (indicating <spanx style="verb">precert_s ct_v2</spanx>) then all three <spanx style="verb">TransItem</spanx>s could be <tt>type</tt> was 2 (indicating <tt>precert_sct_v2</tt>), then all three <tt>Tra nsItem</tt>s could be
embedded in the certificate.</t> embedded in the certificate.</t>
</section>
</section> <section anchor="get-sth" numbered="true" toc="default">
<section anchor="get-sth" title="Retrieve Latest STH"> <name>Retrieve Latest STH</name>
<t>GET &lt;Base URL&gt;/ct/v2/get-sth</t>
<t>GET &lt;Base URL&gt;/ct/v2/get-sth</t> <t>No inputs.</t>
<dl newline="true" spacing="normal">
<t>No inputs.</t> <dt>Outputs:</dt>
<dd>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Outputs:"> <dt>sth:</dt>
<list style="hanging"> <dd>A base64-encoded <tt>TransItem</tt> of type <tt>signed_tree_he
<t hangText="sth:"> ad_v2</tt>
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st signed by this log that is no older than the log's MMD.</dd>
yle="verb">signed_tree_head_v2</spanx>, signed by this </dl>
log, that is no older than the log's MMD.</t> </dd>
</list> </dl>
</t> </section>
</list></t> <section anchor="get-sth-consistency" numbered="true" toc="default">
<name>Retrieve Merkle Consistency Proof between Two STHs</name>
</section> <t>GET &lt;Base URL&gt;/ct/v2/get-sth-consistency</t>
<section anchor="get-sth-consistency" title="Retrieve Merkle Consistency Proof b <dl newline="true" spacing="normal">
etween Two STHs"> <dt>Inputs:</dt>
<dd>
<t>GET &lt;Base URL&gt;/ct/v2/get-sth-consistency</t> <dl newline="false" spacing="normal">
<dt>first:</dt>
<t><list style="hanging"> <dd>The <tt>tree_size</tt> of the older tree, in decimal.</dd>
<t hangText="Inputs:"> <dt>second:</dt>
<list style="hanging"> <dd>The <tt>tree_size</tt> of the newer tree, in decimal (optional)
<t hangText="first:"> .</dd>
The tree_size of the older tree, in decimal.</t> </dl>
<t hangText="second:"> <t>Both tree sizes must be from existing v2 STHs. However, because of
The tree_size of the newer tree, in decimal (optional).</t> skew, the
</list> receiving front end may not know one or both of the existing STHs. If b
</t> oth are
</list></t> known, then only the <tt>consistency</tt> output is returned. If the fi
rst is known
<t><list style='empty'> but the second is not (or has been omitted), then the latest known STH
<t>Both tree sizes must be from existing v2 STHs. However, because of skew, th is
e returned, along with a consistency proof between the first STH and the
receiving front-end may not know one or both of the existing STHs. If both are latest.
known, then only the <spanx style="verb">consistency</spanx> output is returned. If neither are known, then the latest known STH is returned without a
If the first is known consistency proof.</t>
but the second is not (or has been omitted), then the latest known STH is </dd>
returned, along with a consistency proof between the first STH and the latest. </dl>
If neither are known, then the latest known STH is returned without a <dl newline="true" spacing="normal">
consistency proof.</t> <dt>Outputs:</dt>
</list></t> <dd>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>consistency:</dt>
<t hangText="Outputs:"> <dd>A base64-encoded <tt>TransItem</tt> of type <tt>consistency_pr
<list style="hanging"> oof_v2</tt>
<t hangText="consistency:"> whose <tt>tree_size_1</tt> <bcp14>MUST</bcp14> match the <tt>first<
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st /tt> input.
yle="verb">consistency_proof_v2</spanx>, whose If the <tt>sth</tt> output is omitted,
<spanx style="verb">tree_size_1</spanx> MUST match the <spanx style="verb">first then <tt>tree_size_2</tt> <bcp14>MUST</bcp14> match the <tt>second<
</spanx> input. If the <spanx style="verb">sth</spanx> output is omitted, /tt> input.
then <spanx style="verb">tree_size_2</spanx> MUST match the <spanx style="verb"> If <tt>first</tt> and <tt>second</tt> are equal and correspond to a
second</spanx> input. known STH,
If <spanx style="verb">first</spanx> and <spanx style="verb">second</spanx> are the returned consistency proof <bcp14>MUST</bcp14> be empty (a
equal and correspond to a known STH, the <tt>consistency_path</tt> array with zero elements).</dd>
returned consistency proof MUST be empty (a <spanx style="verb">consistency_path <dt>sth:</dt>
</spanx> array with <dd>A base64-encoded <tt>TransItem</tt> of type <tt>signed_tree_he
zero elements).</t> ad_v2</tt>,
<t hangText="sth:"> signed by this log.</dd>
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st </dl>
yle="verb">signed_tree_head_v2</spanx>, signed by this <t>Note that no signature is required for the <tt>consistency</tt> out
log.</t> put, as it is
</list> used to verify the consistency between two signed STHs.</t>
</t> </dd>
</list></t> </dl>
<t>Error codes:</t>
<t><list style='empty'> <table align="center">
<t>Note that no signature is required for the <spanx style="verb">consistency< <thead>
/spanx> output as it is used <tr>
to verify the consistency between two STHs, which are signed.</t> <th align="left">type</th>
</list></t> <th align="left">detail</th>
</tr>
<t>Error codes:</t> </thead>
<tbody>
<texttable> <tr>
<ttcol align='left'>type</ttcol> <td align="left">firstUnknown</td>
<ttcol align='left'>detail</ttcol> <td align="left"><tt>first</tt> is before the latest known STH but
<c>firstUnknown</c> is not from
<c><spanx style="verb">first</spanx> is before the latest known STH but is an existing STH.</td>
not from an existing STH.</c> </tr>
<c>secondUnknown</c> <tr>
<c><spanx style="verb">second</spanx> is before the latest known STH but i <td align="left">secondUnknown</td>
s not from an existing STH.</c> <td align="left"><tt>second</tt> is before the latest known STH bu
<c>secondBeforeFirst</c> t is not from
<c><spanx style="verb">second</spanx> is smaller than <spanx style="verb"> an existing STH.</td>
first</spanx>.</c> </tr>
</texttable> <tr>
<td align="left">secondBeforeFirst</td>
<t>See <xref target="verify_consistency"/> for an outline of how to use the <spa <td align="left"><tt>second</tt> is smaller than <tt>first</tt>.</
nx style="verb">consistency</spanx> td>
</tr>
</tbody>
</table>
<t>See <xref target="verify_consistency" format="default"/> for an outli
ne of how to use the <tt>consistency</tt>
output.</t> output.</t>
</section>
</section> <section anchor="get-proof-by-hash" numbered="true" toc="default">
<section anchor="get-proof-by-hash" title="Retrieve Merkle Inclusion Proof from <name>Retrieve Merkle Inclusion Proof from Log by Leaf Hash</name>
Log by Leaf Hash"> <t>GET &lt;Base URL&gt;/ct/v2/get-proof-by-hash</t>
<dl newline="true" spacing="normal">
<t>GET &lt;Base URL&gt;/ct/v2/get-proof-by-hash</t> <dt>Inputs:</dt>
<dd>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Inputs:"> <dt>hash:</dt>
<list style="hanging"> <dd>A base64-encoded v2 leaf hash.</dd>
<t hangText="hash:"> <dt>tree_size:</dt>
A base64 encoded v2 leaf hash.</t> <dd>The <tt>tree_size</tt> of the tree on which to base the proof,
<t hangText="tree_size:"> in decimal.</dd>
The tree_size of the tree on which to base the proof, in decimal.</t> </dl>
</list> <t>The <tt>hash</tt> must be calculated as defined in <xref target="tr
</t> ee_leaves"
</list></t> format="default"/>. A v2 STH must
exist for the <tt>tree_size</tt>. Because of skew, the front end may n
<t><list style='empty'> ot know
<t>The <spanx style="verb">hash</spanx> must be calculated as defined in <xref the requested tree head. In that case, it will return the latest STH it
target="tree_leaves"/>. A v2 STH must knows, along
exist for the <spanx style="verb">tree_size</spanx>. Because of skew, the front with an inclusion proof to that STH. If the front end knows the request
-end may not know ed tree head,
the requested tree head. In that case, it will return the latest STH it knows, a then only <tt>inclusion</tt> is returned.</t>
long </dd>
with an inclusion proof to that STH. If the front-end knows the requested tree h </dl>
ead <dl newline="true" spacing="normal">
then only <spanx style="verb">inclusion</spanx> is returned.</t> <dt>Outputs:</dt>
</list></t> <dd>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>inclusion:</dt>
<t hangText="Outputs:"> <dd>A base64-encoded <tt>TransItem</tt> of type <tt>inclusion_proo
<list style="hanging"> f_v2</tt>
<t hangText="inclusion:"> whose <tt>inclusion_path</tt> array of Merkle Tree nodes proves the
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st inclusion
yle="verb">inclusion_proof_v2</spanx> whose of the certificate (as specified by the <tt>hash</tt> parameter) in
<spanx style="verb">inclusion_path</spanx> array of Merkle Tree nodes proves the the
inclusion of the selected STH.</dd>
certificate (as specified by the <spanx style="verb">hash</spanx> parameter) in <dt>sth:</dt>
the selected STH.</t> <dd>A base64-encoded <tt>TransItem</tt> of type <tt>signed_tree_he
<t hangText="sth:"> ad_v2</tt>,
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st signed by this log.</dd>
yle="verb">signed_tree_head_v2</spanx>, signed by this </dl>
log.</t> <t>Note that no signature is required for the <tt>inclusion</tt> out
</list> put, as it is
</t> used to verify inclusion in the selected STH, which is signed.</t>
</list></t> </dd>
</dl>
<t><list style='empty'> <t>Error codes:</t>
<t>Note that no signature is required for the <spanx style="verb">inclusion</s <table align="center">
panx> output as it is used to <thead>
verify inclusion in the selected STH, which is signed.</t> <tr>
</list></t> <th align="left">type</th>
<th align="left">detail</th>
<t>Error codes:</t> </tr>
</thead>
<texttable> <tbody>
<ttcol align='left'>type</ttcol> <tr>
<ttcol align='left'>detail</ttcol> <td align="left">hashUnknown</td>
<c>hashUnknown</c> <td align="left">
<c><spanx style="verb">hash</spanx> is not the hash of a known leaf (may b <tt>hash</tt> is not the hash of a known leaf (may be caused by
e caused by skew or by a known certificate not yet merged).</c> skew or by a known certificate not yet merged).</td>
<c>treeSizeUnknown</c> </tr>
<c><spanx style="verb">hash</spanx> is before the latest known STH but is <tr>
not from an existing STH.</c> <td align="left">treeSizeUnknown</td>
</texttable> <td align="left">
<tt>hash</tt> is before the latest known STH but is not from an
<t>See <xref target="verify_inclusion"/> for an outline of how to use the <spanx existing STH.</td>
style="verb">inclusion</spanx> output.</t> </tr>
</tbody>
</section> </table>
<section anchor="get-all-by-hash" title="Retrieve Merkle Inclusion Proof, STH an <t>See <xref target="verify_inclusion" format="default"/> for an outline
d Consistency Proof by Leaf Hash"> of how to use the <tt>inclusion</tt> output.</t>
</section>
<t>GET &lt;Base URL&gt;/ct/v2/get-all-by-hash</t> <section anchor="get-all-by-hash" numbered="true" toc="default">
<name>Retrieve Merkle Inclusion Proof, STH, and Consistency Proof by Lea
<t><list style="hanging"> f Hash</name>
<t hangText="Inputs:"> <t>GET &lt;Base URL&gt;/ct/v2/get-all-by-hash</t>
<list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="hash:"> <dt>Inputs:</dt>
A base64 encoded v2 leaf hash.</t> <dd>
<t hangText="tree_size:"> <dl newline="false" spacing="normal">
The tree_size of the tree on which to base the proofs, in decimal.</t> <dt>hash:</dt>
</list> <dd>A base64-encoded v2 leaf hash.</dd>
</t> <dt>tree_size:</dt>
</list></t> <dd>The <tt>tree_size</tt> of the tree on which to base the proofs,
in decimal.</dd>
<t><list style='empty'> </dl>
<t>The <spanx style="verb">hash</spanx> must be calculated as defined in <xref <t>The <tt>hash</tt> must be calculated as defined in <xref target="
target="tree_leaves"/>. A v2 STH must tree_leaves"
exist for the <spanx style="verb">tree_size</spanx>.</t> format="default"/>. A v2 STH must exist for the <tt>tree_size</tt>.</t>
</list></t> </dd>
</dl>
<t>Because of skew, the front-end may not know the requested tree head or the re <t>Because of skew, the front end may not know the requested tree head o
quested r the
hash, which leads to a number of cases:</t> requested hash, which leads to a number of cases:</t>
<table align="center">
<texttable> <thead>
<ttcol align='left'>Case</ttcol> <tr>
<ttcol align='left'>Response</ttcol> <th align="left">Case</th>
<c>latest STH &lt; requested tree head</c> <th align="left">Response</th>
<c>Return latest STH</c> </tr>
<c>latest STH &gt; requested tree head</c> </thead>
<c>Return latest STH and a consistency proof between it and the requested <tbody>
tree head (see <xref target="get-sth-consistency"/>)</c> <tr>
<c>index of requested hash &lt; latest STH</c> <td align="left">latest STH &lt; requested tree head</td>
<c>Return <spanx style="verb">inclusion</spanx></c> <td align="left">Return latest STH.</td>
</texttable> </tr>
<tr>
<t>Note that more than one case can be true, in which case the returned data is <td align="left">latest STH &gt; requested tree head</td>
their union. It is also possible for none to be true, in which case the <td align="left">Return latest STH and a consistency proof between
front-end MUST return an empty response.</t> it and the requested tree head (see <xref target="get-sth-consistency" format="
default"/>).</td>
<t><list style="hanging"> </tr>
<t hangText="Outputs:"> <tr>
<list style="hanging"> <td align="left">index of requested hash &lt; latest STH</td>
<t hangText="inclusion:"> <td align="left">Return <tt>inclusion</tt>.</td>
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st </tr>
yle="verb">inclusion_proof_v2</spanx> whose </tbody>
<spanx style="verb">inclusion_path</spanx> array of Merkle Tree nodes proves the </table>
inclusion of the <t>Note that more than one case can be true; in which case, the returned
certificate (as specified by the <spanx style="verb">hash</spanx> parameter) in data is
the selected STH.</t> their union. It is also possible for none to be true; in which case, the
<t hangText="sth:"> front end <bcp14>MUST</bcp14> return an empty response.</t>
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st <dl newline="true" spacing="normal">
yle="verb">signed_tree_head_v2</spanx>, signed by this <dt>Outputs:</dt>
log.</t> <dd>
<t hangText="consistency:"> <dl newline="false" spacing="normal">
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st <dt>inclusion:</dt>
yle="verb">consistency_proof_v2</spanx> that proves the <dd>A base64-encoded <tt>TransItem</tt> of type <tt>inclusion_proo
consistency of the requested tree head and the returned STH.</t> f_v2</tt>
</list> whose <tt>inclusion_path</tt> array of Merkle Tree nodes proves the
</t> inclusion
</list></t> of the certificate (as specified by the <tt>hash</tt> parameter) in
the
<t><list style='empty'> selected STH.</dd>
<t>Note that no signature is required for the <spanx style="verb">inclusion</s <dt>sth:</dt>
panx> or <spanx style="verb">consistency</spanx> <dd>A base64-encoded <tt>TransItem</tt> of type <tt>signed_tree_he
outputs as they are used to verify inclusion in and consistency of STHs, which ad_v2</tt>,
are signed.</t> signed by this log.</dd>
</list></t> <dt>consistency:</dt>
<dd>A base64-encoded <tt>TransItem</tt> of type <tt>consistency_pr
<t>Errors are the same as in <xref target="get-proof-by-hash"/>.</t> oof_v2</tt>
that proves the consistency of the requested tree head and the retu
<t>See <xref target="verify_inclusion"/> for an outline of how to use the <spanx rned
style="verb">inclusion</spanx> output, STH.</dd>
and see <xref target="verify_consistency"/> for an outline of how to use the <sp </dl>
anx style="verb">consistency</spanx> <t>Note that no signature is required for the <tt>inclusion</tt> or
<tt>consistency</tt> outputs, as they are used to verify inclusion in
and
consistency of signed STHs.</t>
</dd>
</dl>
<t>Errors are the same as in <xref target="get-proof-by-hash" format="de
fault"/>.</t>
<t>See <xref target="verify_inclusion" format="default"/> for an outline
of how to use the <tt>inclusion</tt> output,
and see <xref target="verify_consistency" format="default"/> for an outline of h
ow to use the <tt>consistency</tt>
output.</t> output.</t>
</section>
</section> <section anchor="get-entries" numbered="true" toc="default">
<section anchor="get-entries" title="Retrieve Entries and STH from Log"> <name>Retrieve Entries and STH from Log</name>
<t>GET &lt;Base URL&gt;/ct/v2/get-entries</t>
<t>GET &lt;Base URL&gt;/ct/v2/get-entries</t> <dl newline="true" spacing="normal">
<dt>Inputs:</dt>
<t><list style="hanging"> <dd>
<t hangText="Inputs:"> <dl newline="false" spacing="normal">
<list style="hanging"> <dt>start:</dt>
<t hangText="start:"> <dd>0-based index of first entry to retrieve, in decimal.</dd>
0-based index of first entry to retrieve, in decimal.</t> <dt>end:</dt>
<t hangText="end:"> <dd>0-based index of last entry to retrieve, in decimal.</dd>
0-based index of last entry to retrieve, in decimal.</t> </dl>
</list> </dd>
</t> <dt>Outputs:</dt>
<t hangText="Outputs:"> <dd>
<list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="entries:"> <dt>entries:</dt>
An array of objects, each consisting of <dd>
<t>An array of objects, each consisting of:</t>
<list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="log_entry:"> <dt>log_entry:</dt>
The base64 encoded <spanx style="verb">TransItem</spanx> structure <dd>The base64-encoded <tt>TransItem</tt> structure of type
of type <spanx style="verb">x509_entry_v2</spanx> or <tt>x509_entry_v2</tt> or
<spanx style="verb">precert_entry_v2</spanx> (see <xref target="log_entries"/>). <tt>precert_entry_v2</tt> (see <xref target="log_entries"
</t> format="default"/>).</dd>
<t hangText="submitted_entry:"> <dt>submitted_entry:</dt>
JSON object equivalent to inputs that were submitted to <dd>JSON object equivalent to inputs that were submitted to
<spanx style="verb">submit-entry</spanx>, with the addition of the trust anchor <tt>submit-entry</tt>, with the addition of the trust anchor to
to the <spanx style="verb">chain</spanx> the
field if the submission did not include it.</t> <tt>chain</tt> field if the submission did not include it.</dd>
<t hangText="sct:"> <dt>sct:</dt>
The base64 encoded <spanx style="verb">TransItem</spanx> of type < <dd>The base64-encoded <tt>TransItem</tt> of type <tt>x509_sct
spanx style="verb">x509_sct_v2</spanx> or <spanx style="verb">precert_sct_v2</sp _v2</tt> or
anx> <tt>precert_sct_v2</tt>, corresponding to this log entry.</dd>
corresponding to this log entry.</t> <dt>sth:</dt>
</list> <dd>A base64-encoded <tt>TransItem</tt> of type
</t> <tt>signed_tree_head_v2</tt>, signed by this log.</dd>
<t hangText="sth:"> </dl>
A base64 encoded <spanx style="verb">TransItem</spanx> of type <spanx st </dd>
yle="verb">signed_tree_head_v2</spanx>, signed by this </dl>
log.</t> </dd>
</list> </dl>
</t> <t>Note that this message is not signed -- the <tt>entries</tt> data can
</list></t> be verified by
<t>Note that this message is not signed -- the <spanx style="verb">entries</span
x> data can be verified by
constructing the Merkle Tree Hash corresponding to a retrieved STH. All leaves constructing the Merkle Tree Hash corresponding to a retrieved STH. All leaves
MUST be v2. However, a compliant v2 client MUST NOT construe an unrecognized <bcp14>MUST</bcp14> be v2. However, a compliant v2 client <bcp14>MUST NOT</bcp14
TransItem type as an error. This means it may be unable to parse some entries, > construe an unrecognized
<tt>TransItem</tt> type as an error. This means it may be unable to parse some e
ntries,
but note that each client can inspect the entries it does recognize as well as but note that each client can inspect the entries it does recognize as well as
verify the integrity of the data by treating unrecognized leaves as opaque input verify the integrity of the data by treating unrecognized leaves as opaque input
to the tree.</t> to the tree.</t>
<t>The <tt>start</tt> and <tt>end</tt> parameters <bcp14>SHOULD</bcp14>
<t>The <spanx style="verb">start</spanx> and <spanx style="verb">end</spanx> par be within the range 0 &lt;= x &lt; <tt>tree_size</tt>,
ameters SHOULD be within the range 0 &lt;= x &lt; <spanx style="verb">tree_size< as returned by <tt>get-sth</tt> in <xref target="get-sth" format="default"/>.</t
/spanx> >
as returned by <spanx style="verb">get-sth</spanx> in <xref target="get-sth"/>.< <t>The <tt>start</tt> parameter <bcp14>MUST</bcp14> be less than or equa
/t> l to the <tt>end</tt> parameter.</t>
<t>Each <tt>submitted_entry</tt> output parameter <bcp14>MUST</bcp14> in
<t>The <spanx style="verb">start</spanx> parameter MUST be less than or equal to clude the trust anchor that the
the <spanx style="verb">end</spanx> parameter.</t> log used to verify the <tt>submission</tt>, even if that trust anchor was not pr
ovided
<t>Each <spanx style="verb">submitted_entry</spanx> output parameter MUST includ to <tt>submit-entry</tt> (see <xref target="submit-entry" format="default"/>). I
e the trust anchor that the f the <tt>submission</tt> does not certify
log used to verify the <spanx style="verb">submission</spanx>, even if that trus itself, then the first element of <tt>chain</tt> <bcp14>MUST</bcp14> be present
t anchor was not provided and <bcp14>MUST</bcp14> certify the
to <spanx style="verb">submit-entry</spanx> (see <xref target="submit-entry"/>). <tt>submission</tt>.</t>
If the <spanx style="verb">submission</spanx> does not certify <t>Log servers <bcp14>MUST</bcp14> honor requests where 0 &lt;= <tt>star
itself, then the first element of <spanx style="verb">chain</spanx> MUST be pres t</tt> &lt; <tt>tree_size</tt> and <tt>end</tt> &gt;=
ent and MUST certify the <tt>tree_size</tt> by returning a partial response covering only the valid entri
<spanx style="verb">submission</spanx>.</t> es in
the specified range. <tt>end</tt> &gt;= <tt>tree_size</tt> could be caused by sk
<t>Log servers MUST honor requests where 0 &lt;= <spanx style="verb">start</span ew. Note that the
x> &lt; <spanx style="verb">tree_size</spanx> and <spanx style="verb">end</spanx
> &gt;=
<spanx style="verb">tree_size</spanx> by returning a partial response covering o
nly the valid entries in
the specified range. <spanx style="verb">end</spanx> &gt;= <spanx style="verb">t
ree_size</spanx> could be caused by skew. Note that the
following restriction may also apply:</t> following restriction may also apply:</t>
<t>Logs <bcp14>MAY</bcp14> restrict the number of entries that can be re
<t>Logs MAY restrict the number of entries that can be retrieved per <spanx styl trieved per <tt>get-entries</tt>
e="verb">get-entries</spanx>
request. If a client requests more than the permitted number of entries, the log request. If a client requests more than the permitted number of entries, the log
SHALL return the maximum number of entries permissible. These entries SHALL be <bcp14>SHALL</bcp14> return the maximum number of entries permissible. These ent
sequential beginning with the entry specified by <spanx style="verb">start</span ries <bcp14>SHALL</bcp14> be
x>. sequential beginning with the entry specified by <tt>start</tt>.
Note that limit on the number of entries is not immutable and therefore Note that a limit on the number of entries is not immutable, and therefore
the restriction may be changed or lifted at any time and is not listed the restriction may be changed or lifted at any time and is not listed
with the other Log Parameters in <xref target="log_parameters"/>.</t> with the other Log Parameters in <xref target="log_parameters" format="default"/
>.</t>
<t>Because of skew, it is possible the log server will not have any entries betw <t>Because of skew, it is possible the log server will not have any entr
een ies between
<spanx style="verb">start</spanx> and <spanx style="verb">end</spanx>. In this c <tt>start</tt> and <tt>end</tt>. In this case, it <bcp14>MUST</bcp14> return an
ase it MUST return an empty <spanx style="verb">entries</spanx> array.</t> empty <tt>entries</tt> array.</t>
<t>In any case, the log server <bcp14>MUST</bcp14> return the latest STH
<t>In any case, the log server MUST return the latest STH it knows about.</t> it knows about.</t>
<t>See <xref target="verify_hash" format="default"/> for an outline of h
<t>See <xref target="verify_hash"/> for an outline of how to use a complete list ow to use a complete list of <tt>log_entry</tt>
of <spanx style="verb">log_entry</spanx> entries to verify the <tt>root_hash</tt>.</t>
entries to verify the <spanx style="verb">root_hash</spanx>.</t> <t>Error codes:</t>
<table align="center">
<t>Error codes:</t> <thead>
<tr>
<texttable> <th align="left">type</th>
<ttcol align='left'>type</ttcol> <th align="left">detail</th>
<ttcol align='left'>detail</ttcol> </tr>
<c>startUnknown</c> </thead>
<c><spanx style="verb">start</spanx> is greater than the number of entries <tbody>
in the Merkle tree.</c> <tr>
<c>endBeforeStart</c> <td align="left">startUnknown</td>
<c><spanx style="verb">start</spanx> cannot be greater than <spanx style=" <td align="left">
verb">end</spanx>.</c> <tt>start</tt> is greater than the number of entries in the Merk
</texttable> le Tree.</td>
</tr>
</section> <tr>
<section anchor="get-anchors" title="Retrieve Accepted Trust Anchors"> <td align="left">endBeforeStart</td>
<td align="left">
<t>GET &lt;Base URL&gt;/ct/v2/get-anchors</t> <tt>start</tt> cannot be greater than <tt>end</tt>.</td>
</tr>
<t>No inputs.</t> </tbody>
</table>
<t><list style="hanging"> </section>
<t hangText="Outputs:"> <section anchor="get-anchors" numbered="true" toc="default">
<list style="hanging"> <name>Retrieve Accepted Trust Anchors</name>
<t hangText="certificates:"> <t>GET &lt;Base URL&gt;/ct/v2/get-anchors</t>
An array of JSON strings, each of which <t>No inputs.</t>
is a base64 encoded CA certificate that is acceptable to the log.</t> <dl newline="true" spacing="normal">
<t hangText="max_chain_length:"> <dt>Outputs:</dt>
If the server has chosen to limit the length of chains it accepts, this <dd>
is <dl newline="false" spacing="normal">
the maximum number of certificates in the chain, in decimal. If there is no <dt>certificates:</dt>
limit, this is omitted.</t> <dd>An array of JSON strings, each of which
</list> is a base64-encoded CA certificate that is acceptable to the log.</
</t> dd>
</list></t> <dt>max_chain_length:</dt>
<dd>If the server has chosen to limit the length of chains it acce
<t><list style='empty'> pts, this is
<t>This data is not signed and the protocol depends on the security guarantees the maximum number of certificates in the chain, in decimal. If the
of TLS to ensure correctness.</t> re is no
</list></t> limit, this is omitted.</dd>
</dl>
</section> <t>This data is not signed, and the protocol depends on the security
</section> guarantees
<section anchor="tls_servers" title="TLS Servers"> of TLS to ensure correctness.</t>
</dd>
<t>CT-using TLS servers MUST use at least one of the mechanisms described below </dl>
</section>
</section>
<section anchor="tls_servers" numbered="true" toc="default">
<name>TLS Servers</name>
<t>CT-using TLS servers <bcp14>MUST</bcp14> use at least one of the mechan
isms described below
to present one or more SCTs from one or more logs to each TLS client during full to present one or more SCTs from one or more logs to each TLS client during full
TLS handshakes, when requested by the client, where each SCT corresponds to the server certificate. TLS handshakes, when requested by the client, where each SCT corresponds to the server certificate.
(Of course, a server can only send a TLS extension if the client has (Of course, a server can only send a TLS extension if the client has
specified it first.) specified it first.)
Servers Servers
SHOULD also present corresponding inclusion proofs and STHs.</t> <bcp14>SHOULD</bcp14> also present corresponding inclusion proofs and STHs.</t>
<t>A server can provide SCTs using
<t>A server can provide SCTs using a TLS 1.3 extension (<xref target="RFC8446" sectionFormat="of" section="4.2"/>)
a TLS 1.3 extension (Section 4.2 of <xref target="RFC8446"></xref>) with type <s with type <tt>transparency_info</tt>
panx style="verb">transparency_info</spanx> (see <xref target="tls_transinfo_extension" format="default"/>). This mechanism
(see <xref target="tls_transinfo_extension"/>). This mechanism allows TLS server allows TLS servers to
s to
participate in CT without the cooperation of CAs, unlike the other two participate in CT without the cooperation of CAs, unlike the other two
mechanisms. It also allows SCTs and inclusion proofs to be updated on the fly.</ t> mechanisms. It also allows SCTs and inclusion proofs to be updated on the fly.</ t>
<t>The server may also use an Online Certificate Status Protocol (OCSP)
<t>The server may also use an Online Certificate Status Protocol (OCSP) <xref target="RFC6960" format="default"/> response extension (see <xref target="
<xref target="RFC6960"></xref> response extension (see <xref target="ocsp_transi ocsp_transinfo_extension" format="default"/>),
nfo_extension"/>),
providing the OCSP response as part of the TLS handshake. Providing providing the OCSP response as part of the TLS handshake. Providing
a response during a TLS handshake is popularly known as "OCSP stapling." a response during a TLS handshake is popularly known as "OCSP stapling".
For TLS For TLS
1.3, the information is encoded as an extension in the <spanx style="verb">statu 1.3, the information is encoded as an extension in the <tt>status_request</tt>
s_request</spanx> extension data; see <xref target="RFC8446" sectionFormat="of" section="4.4.2.1"/
extension data; see Section 4.4.2.1 of <xref target="RFC8446"></xref>. For TLS 1 >. For TLS 1.2 <xref target="RFC5246" format="default"/>, the information
.2 (<xref target="RFC5246"></xref>), the information is encoded in the <tt>CertificateStatus</tt> message; see <xref target="RFC6066"
is encoded in the <spanx style="verb">CertificateStatus</spanx> message; see Sec sectionFormat="of" section="8"/>. Using stapling also
tion 8
of <xref target="RFC6066"></xref>. Using stapling also
allows SCTs and inclusion proofs to be updated on the fly.</t> allows SCTs and inclusion proofs to be updated on the fly.</t>
<t>CT information can also be encoded as an extension in the X.509v3 certi
<t>CT information can also be encoded as an extension in the X.509v3 certificate ficate
(see <xref target="cert_transinfo_extension"/>). This (see <xref target="cert_transinfo_extension" format="default"/>). This
mechanism allows the use of unmodified TLS servers, but the SCTs and inclusion mechanism allows the use of unmodified TLS servers, but the SCTs and inclusion
proofs cannot be updated on the fly. Since the logs from which the SCTs and proofs cannot be updated on the fly. Since the logs from which the SCTs and
inclusion proofs originated won't necessarily be accepted by TLS clients for inclusion proofs originated won't necessarily be accepted by TLS clients for
the full lifetime of the certificate, there is a risk that TLS clients may the full lifetime of the certificate, there is a risk that TLS clients may
subsequently consider the certificate to be non-compliant and in need of subsequently consider the certificate to be noncompliant. In such an event, one
re-issuance or the use of one of the other two methods for delivering CT of
information.</t> the other two mechanisms will need to be used to deliver CT information, or, if
this is
<section anchor="tls-client-authentication" title="TLS Client Authentication"> not possible, the certificate will need to be reissued.</t>
<section anchor="tls-client-authentication" numbered="true" toc="default">
<t>This specification includes no description of how a TLS server can <name>TLS Client Authentication</name>
<t>This specification includes no description of how a TLS server can
use CT for TLS client certificates. use CT for TLS client certificates.
While this may be useful, it is not documented here for the following While this may be useful, it is not documented here for the following
reasons:</t> reasons:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The greater security exposure is for clients to end up interacting
<t>The greater security exposure is for clients to end up interacting with an with an
illegitimate server.</t> illegitimate server.</li>
<t>In general, TLS client certificates are not expected to be submitted to <li>In general, TLS client certificates are not expected to be submitt
CT logs, particularly those intended for general public use.</t> ed to
</list></t> CT logs, particularly those intended for general public use.</li>
</ul>
<t>A future version could include such information.</t> <t>A future version could include such information.</t>
</section>
</section> <section anchor="multiple-scts" numbered="true" toc="default">
<section anchor="multiple-scts" title="Multiple SCTs"> <name>Multiple SCTs</name>
<t>CT-using TLS servers <bcp14>SHOULD</bcp14> send SCTs from multiple lo
<t>CT-using TLS servers SHOULD send SCTs from multiple logs, because:</t> gs because:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The set of logs trusted by TLS clients is neither unified nor stat
<t>One or more logs may not have become acceptable to all CT-using TLS clients ic; each
. client vendor may maintain an independent list of trusted logs, and, o
Note that client discovery, trust, and distrust of logs is expected to ver time, new logs
be handled out-of-band and is out of scope of this document.</t> may become trusted and current logs may become distrusted.
<t>If a CA and a log collude, it is possible to temporarily hide misissuance f Note that client discovery, trust, and distrust of logs are expected to
rom be handled out of band and are out of scope of this document.</li>
clients. When a TLS client requires SCTs from multiple logs to be provided, it <li>If a CA and a log collude, it is possible to temporarily hide misi
is more difficult to mount this attack.</t> ssuance from
<t>If a log misbehaves or suffers a key compromise, a consequence may be that clients. When a TLS client requires SCTs from multiple logs to be provi
clients cease to trust it. Since the time an SCT may be in use can be ded, it
considerable (several years is common in current practice when embedded in a is more difficult to mount this attack.</li>
certificate), including SCTs from multiple logs reduces the probability of the <li>If a log misbehaves or suffers a key compromise, a consequence may
certificate being rejected by TLS clients.</t> be that
<t>TLS clients may have policies related to the above risks requiring TLS serv clients cease to trust it. Since the time an SCT may be in use can be
ers considerable (several years is common in current practice when embedded
to present multiple SCTs. For example, at the time of writing, Chromium in a
<xref target="Chromium.Log.Policy"></xref> requires multiple SCTs to be presente certificate), including SCTs from multiple logs reduces the probability
d with EV of the
certificates in order for the EV indicator to be shown.</t> certificate being rejected by TLS clients.</li>
</list></t> <li>TLS clients may have policies related to the above risks requiring
TLS servers
<t>To select the logs from which to obtain SCTs, a TLS server can, for example, to present multiple SCTs. For example, at the time of writing, Chromium
<xref target="Chromium.Log.Policy" format="default"/> requires multiple
SCTs to be
presented with Extended Validation (EV)
certificates in order for the EV indicator to be shown.</li>
</ul>
<t>To select the logs from which to obtain SCTs, a TLS server can, for e
xample,
examine the set of logs popular TLS clients accept and recognize.</t> examine the set of logs popular TLS clients accept and recognize.</t>
</section>
</section> <section anchor="transitemlist-structure" numbered="true" toc="default">
<section anchor="transitemlist-structure" title="TransItemList Structure"> <name>TransItemList Structure</name>
<t>Multiple SCTs, inclusion proofs, and indeed <tt>TransItem</tt> struct
<t>Multiple SCTs, inclusion proofs, and indeed <spanx style="verb">TransItem</sp ures of any
anx> structures of any type, type are combined into a list as follows:</t>
are combined into a list as follows:</t> <sourcecode type="tls-presentation"><![CDATA[
<figure><artwork><![CDATA[
opaque SerializedTransItem<1..2^16-1>; opaque SerializedTransItem<1..2^16-1>;
struct { struct {
SerializedTransItem trans_item_list<1..2^16-1>; SerializedTransItem trans_item_list<1..2^16-1>;
} TransItemList; } TransItemList;
]]></artwork></figure> ]]></sourcecode>
<t>Here, <tt>SerializedTransItem</tt> is an opaque byte string that cont
<t>Here, <spanx style="verb">SerializedTransItem</spanx> is an opaque byte strin ains the
g that contains the serialized <tt>TransItem</tt> structure. This encoding ensures that TLS c
serialized <spanx style="verb">TransItem</spanx> structure. This encoding ensure lients can
s that TLS clients can decode each <tt>TransItem</tt> individually (so, for example, if there is
decode each <spanx style="verb">TransItem</spanx> individually (so, for example, a version
if there is a version upgrade, out-of-date clients can still parse old <tt>TransItem</tt> struc
upgrade, out-of-date clients can still parse old <spanx style="verb">TransItem</ tures while
spanx> structures while skipping over new <tt>TransItem</tt> structures whose versions they don't
skipping over new <spanx style="verb">TransItem</spanx> structures whose version understand).</t>
s they don't understand).</t> </section>
<section anchor="presenting_transitems" numbered="true" toc="default">
</section> <name>Presenting SCTs, Inclusions Proofs, and STHs</name>
<section anchor="presenting_transitems" title="Presenting SCTs, inclusions proof <t>In each <tt>TransItemList</tt> that is sent during a TLS handshake, t
s and STHs"> he TLS
server <bcp14>MUST</bcp14> include a <tt>TransItem</tt> structure of type <tt>x5
<t>In each <spanx style="verb">TransItemList</spanx> that is sent during a TLS h 09_sct_v2</tt> or
andshake, the TLS <tt>precert_sct_v2</tt>.</t>
server MUST include a <spanx style="verb">TransItem</spanx> structure of type <s <t>Presenting inclusion proofs and STHs in the TLS handshake helps to pr
panx style="verb">x509_sct_v2</spanx> or otect the
<spanx style="verb">precert_sct_v2</spanx>.</t> client's privacy (see <xref target="fetching_inclusion_proofs" format="default"/
>) and reduces load on log
<t>Presenting inclusion proofs and STHs in the TLS handshake helps to protect th servers. Therefore, if the TLS server can obtain them, it <bcp14>SHOULD</bcp14>
e also include
client's privacy (see <xref target="fetching_inclusion_proofs"/>) and reduces lo <tt>TransItem</tt>s of type <tt>inclusion_proof_v2</tt> and <tt>signed_tree_head
ad on log _v2</tt> in the
servers. Therefore, if the TLS server can obtain them, it SHOULD also include <tt>TransItemList</tt>.</t>
<spanx style="verb">TransItem</spanx>s of type <spanx style="verb">inclusion_pro </section>
of_v2</spanx> and <spanx style="verb">signed_tree_head_v2</spanx> in the <section anchor="tls_transinfo_extension" numbered="true" toc="default">
<spanx style="verb">TransItemList</spanx>.</t> <name>transparency_info TLS Extension</name>
<t>Provided that a TLS client includes the <tt>transparency_info</tt> ex
</section> tension type in
<section anchor="tls_transinfo_extension" title="transparency_info TLS Extension the ClientHello and the TLS server supports the <tt>transparency_info</tt> exten
"> sion:</t>
<ul spacing="normal">
<t>Provided that a TLS client includes the <spanx style="verb">transparency_info <li>The TLS server <bcp14>MUST</bcp14> verify that the received
</spanx> extension type in <tt>extension_data</tt> is empty.</li>
the ClientHello and the TLS server supports the <spanx style="verb">transparency <li>The TLS server <bcp14>MUST</bcp14> construct a <tt>TransItemList</
_info</spanx> extension:</t> tt> of
relevant <tt>TransItem</tt>s (see
<t><list style="symbols"> <xref target="presenting_transitems" format="default"/>), which
<t>The TLS server MUST verify that the received <spanx style="verb">extension_ <bcp14>SHOULD</bcp14> omit any <tt>TransItem</tt>s that are
data</spanx> is empty.</t> already embedded in the server certificate or the stapled OCSP response
<t>The TLS server MUST construct a <spanx style="verb">TransItemList</spanx> o (see
f relevant <spanx style="verb">TransItem</spanx>s (see <xref target="x509v3_transinfo_extension" format="default"/>). If the c
<xref target="presenting_transitems"/>), which SHOULD omit any <spanx style="ver onstructed
b">TransItem</spanx>s that are <tt>TransItemList</tt> is not
already embedded in the server certificate or the stapled OCSP response (see empty, then the TLS server <bcp14>MUST</bcp14> include the
<xref target="x509v3_transinfo_extension"/>). If the constructed <spanx style="v <tt>transparency_info</tt> extension with
erb">TransItemList</spanx> is not the <tt>extension_data</tt> set to this <tt>TransItemList</tt>. If the
empty, then the TLS server MUST include the <spanx style="verb">transparency_inf list is
o</spanx> extension with empty, then the server <bcp14>SHOULD</bcp14> omit the <tt>extension_dat
the <spanx style="verb">extension_data</spanx> set to this <spanx style="verb">T a</tt>
ransItemList</spanx>. If the list is empty element but <bcp14>MAY</bcp14> send it with an empty array.</li>
then the server SHOULD omit the <spanx style="verb">extension_data</spanx> eleme </ul>
nt, but MAY send <t>TLS servers <bcp14>MUST</bcp14> only include this extension in the fo
it with an empty array.</t> llowing messages:</t>
</list></t> <ul spacing="normal">
<li>the ServerHello message (for TLS 1.2 or earlier)</li>
<t>TLS servers MUST only include this extension in the following messages:</t> <li>the Certificate or CertificateRequest message (for TLS 1.3)</li>
</ul>
<t><list style="symbols"> <t>TLS servers <bcp14>MUST NOT</bcp14> process or include this extension
<t>the ServerHello message (for TLS 1.2 or earlier).</t> when a TLS session is
<t>the Certificate or CertificateRequest message (for TLS 1.3).</t>
</list></t>
<t>TLS servers MUST NOT process or include this extension when a TLS session is
resumed, since session resumption uses the original session information.</t> resumed, since session resumption uses the original session information.</t>
</section>
</section> </section>
</section> <section anchor="certification-authorities" numbered="true" toc="default">
<section anchor="certification-authorities" title="Certification Authorities"> <name>Certification Authorities</name>
<section anchor="x509v3_transinfo_extension" numbered="true" toc="default"
<section anchor="x509v3_transinfo_extension" title="Transparency Information X.5 >
09v3 Extension"> <name>Transparency Information X.509v3 Extension</name>
<t>The Transparency Information X.509v3 extension, which has OID 1.3.101
<t>The Transparency Information X.509v3 extension, which has OID 1.3.101.75 and .75 and
SHOULD be non-critical, contains one or more <spanx style="verb">TransItem</span <bcp14>SHOULD</bcp14> be noncritical, contains one or more <tt>TransItem<
x> structures in a /tt>
<spanx style="verb">TransItemList</spanx>. This extension MAY be included in OCS structures in a <tt>TransItemList</tt>. This extension <bcp14>MAY</bcp14>
P responses (see be
<xref target="ocsp_transinfo_extension"/>) and certificates (see included in OCSP responses (see
<xref target="cert_transinfo_extension"/>). Since RFC5280 requires the <spanx st <xref target="ocsp_transinfo_extension" format="default"/>) and certifica
yle="verb">extnValue</spanx> field (an tes (see
OCTET STRING) of each X.509v3 extension to include the DER encoding of an ASN.1 <xref target="cert_transinfo_extension" format="default"/>). Since <xref
value, a <spanx style="verb">TransItemList</spanx> MUST NOT be included directly target="RFC5280" format="default"/> requires the <tt>extnValue</tt> field
. Instead, it MUST be (an
wrapped inside an additional OCTET STRING, which is then put into the OCTET STRING) of each X.509v3 extension to include the DER encoding of an
<spanx style="verb">extnValue</spanx> field:</t> ASN.1
value, a <tt>TransItemList</tt> <bcp14>MUST NOT</bcp14> be included direc
<figure><artwork><![CDATA[ tly.
Instead, it <bcp14>MUST</bcp14> be
wrapped inside an additional OCTET STRING, which is then put into the
<tt>extnValue</tt> field:</t>
<sourcecode type="asn.1"><![CDATA[
TransparencyInformationSyntax ::= OCTET STRING TransparencyInformationSyntax ::= OCTET STRING
]]></artwork></figure> ]]></sourcecode>
<t><tt>TransparencyInformationSyntax</tt> contains a <tt>TransItemList</
<t><spanx style="verb">TransparencyInformationSyntax</spanx> contains a <spanx s tt>.</t>
tyle="verb">TransItemList</spanx>.</t> <section anchor="ocsp_transinfo_extension" numbered="true" toc="default"
>
<section anchor="ocsp_transinfo_extension" title="OCSP Response Extension"> <name>OCSP Response Extension</name>
<t>A certification authority <bcp14>MAY</bcp14> include a Transparency
<t>A certification authority MAY include a Transparency Information X.509v3 Information
extension in the <spanx style="verb">singleExtensions</spanx> of a <spanx style= X.509v3 extension in the <tt>singleExtensions</tt> of a <tt>SingleRespo
"verb">SingleResponse</spanx> in an OCSP response. nse</tt> in
All included SCTs and inclusion proofs MUST be for the certificate identified by an OCSP response. All included SCTs and inclusion proofs <bcp14>MUST</b
the <spanx style="verb">certID</spanx> of that <spanx style="verb">SingleRespons cp14> be for
e</spanx>, or for a precertificate that corresponds the certificate identified by the <tt>certID</tt> of that <tt>SingleRes
to that certificate.</t> ponse</tt>
or for a precertificate that corresponds to that certificate.</t>
</section> </section>
<section anchor="cert_transinfo_extension" title="Certificate Extension"> <section anchor="cert_transinfo_extension" numbered="true" toc="default"
>
<t>A certification authority MAY include a Transparency Information X.509v3 <name>Certificate Extension</name>
extension in a certificate. All included SCTs and inclusion proofs MUST be for a <t>A certification authority <bcp14>MAY</bcp14> include a Transparency
Information X.509v3
extension in a certificate. All included SCTs and inclusion proofs <bcp14>MUST</
bcp14> be for a
precertificate that corresponds to this certificate.</t> precertificate that corresponds to this certificate.</t>
</section>
</section> </section>
</section> <section anchor="tls-feature-x509v3-extension" numbered="true" toc="defaul
<section anchor="tls-feature-x509v3-extension" title="TLS Feature X.509v3 Extens t">
ion"> <name>TLS Feature X.509v3 Extension</name>
<t>A certification authority <bcp14>SHOULD NOT</bcp14> issue any certifi
<t>A certification authority SHOULD NOT issue any certificate that identifies th cate that identifies the
e <tt>transparency_info</tt> TLS extension in a TLS feature extension <xref target
<spanx style="verb">transparency_info</spanx> TLS extension in a TLS feature ext ="RFC7633" format="default"/>, because
ension <xref target="RFC7633"></xref>, because TLS servers are not required to support the <tt>transparency_info</tt> TLS exten
TLS servers are not required to support the <spanx style="verb">transparency_inf sion in
o</spanx> TLS extension in order to participate in CT (see <xref target="tls_servers" format="default"/>).<
order to participate in CT (see <xref target="tls_servers"/>).</t> /t>
</section>
</section> </section>
</section> <section anchor="clients" numbered="true" toc="default">
<section anchor="clients" title="Clients"> <name>Clients</name>
<t>There are various different functions clients of logs might perform. We
<t>There are various different functions clients of logs might perform. We descr describe
ibe here some typical clients and how they should function. Any inconsistency
here some typical clients and how they should function. Any inconsistency may be may be
used as evidence that a log has not behaved correctly, and the signatures on the used as evidence that a log has not behaved correctly, and the signatures
data structures prevent the log from denying that misbehavior.</t> on the
data structures prevent the log from denying that misbehavior.</t>
<t>All clients need various parameters in order to communicate with logs and ver <t>All clients need various parameters in order to communicate with logs a
ify nd verify
their responses. These parameters are described in <xref target="log_parameters" their responses. These parameters are described in <xref target="log_param
/>, but note eters"
that this document does not describe how the parameters are obtained, which is format="default"/>, but note
implementation-dependent (see, for example, <xref target="Chromium.Policy"></xre that this document does not describe how the parameters are obtained, whic
f>).</t> h is
implementation dependent (for example, see <xref target="Chromium.Policy"
<section anchor="tls_clients" title="TLS Client"> format="default"/>).</t>
<section anchor="tls_clients" numbered="true" toc="default">
<section anchor="receiving_transitems" title="Receiving SCTs and inclusion proof <name>TLS Client</name>
s"> <section anchor="receiving_transitems" numbered="true" toc="default">
<name>Receiving SCTs and Inclusion Proofs</name>
<t>TLS clients receive SCTs and inclusion proofs alongside or in certificates. <t>TLS clients receive SCTs and inclusion proofs alongside or in certi
CT-using TLS clients MUST implement all of the three mechanisms by which TLS ficates.
servers may present SCTs (see <xref target="tls_servers"/>).</t> CT-using TLS clients <bcp14>MUST</bcp14> implement all of the three mec
hanisms by
<t>TLS clients that support the <spanx style="verb">transparency_info</spanx> TL which TLS servers may present SCTs (see <xref target="tls_servers"
S extension format="default"/>).</t>
(see <xref target="tls_transinfo_extension"/>) SHOULD include it in ClientHello <t>TLS clients that support the <tt>transparency_info</tt> TLS extensi
messages, on
with empty <spanx style="verb">extension_data</spanx>. If a TLS server includes (see <xref target="tls_transinfo_extension" format="default"/>)
the <spanx style="verb">transparency_info</spanx> <bcp14>SHOULD</bcp14> include it in ClientHello messages,
TLS extension when resuming a TLS session, the TLS client MUST abort the with empty <tt>extension_data</tt>. If a TLS server includes the
handshake.</t> <tt>transparency_info</tt> TLS extension when resuming a TLS session, t
he TLS
</section> client <bcp14>MUST</bcp14> abort the handshake.</t>
<section anchor="reconstructing_tbscertificate" title="Reconstructing the TBSCer </section>
tificate"> <section anchor="reconstructing_tbscertificate" numbered="true" toc="def
ault">
<t>Validation of an SCT for a certificate (where the <spanx style="verb">type</s <name>Reconstructing the TBSCertificate</name>
panx> of the <spanx style="verb">TransItem</spanx> is <t>Validation of an SCT for a certificate (where the <tt>type</tt> of
<spanx style="verb">x509_sct_v2</spanx>) uses the unmodified TBSCertificate comp the <tt>TransItem</tt> is
onent of the certificate.</t> <tt>x509_sct_v2</tt>) uses the unmodified TBSCertificate component of the certif
icate.</t>
<t>Before an SCT for a precertificate (where the <spanx style="verb">type</spanx <t>Before an SCT for a precertificate (where the <tt>type</tt> of the
> of the <spanx style="verb">TransItem</spanx> is <tt>TransItem</tt> is
<spanx style="verb">precert_sct_v2</spanx>) can be validated, the TBSCertificate <tt>precert_sct_v2</tt>) can be validated, the TBSCertificate component of the
component of the
precertificate needs to be reconstructed from the TBSCertificate component of precertificate needs to be reconstructed from the TBSCertificate component of
the certificate as follows:</t> the certificate as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Remove the Transparency Information extension
<t>Remove the Transparency Information extension (see <xref target="x509v3_transinfo_extension" format="default"/>).</
(see <xref target="x509v3_transinfo_extension"/>).</t> li>
<t>Remove embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2 (see <li>Remove embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4
section 3.3 of <xref target="RFC6962"></xref>). This allows embedded v1 and v2 S .2 (see
CTs to co-exist in <xref target="RFC6962" sectionFormat="of" section="3.3"/>). This allo
a certificate (see <xref target="v1_coexistence"/>).</t> ws embedded
</list></t> v1 and v2 SCTs to co-exist in
a certificate (see <xref target="v1_coexistence" format="default"/>).
</section> </li>
<section anchor="validating-scts" title="Validating SCTs"> </ul>
</section>
<t>In order to make use of a received SCT, the TLS client MUST first validate it <section anchor="validating-scts" numbered="true" toc="default">
as <name>Validating SCTs</name>
<t>In order to make use of a received SCT, the TLS client <bcp14>MUST<
/bcp14> first validate it as
follows:</t> follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Compute the signature input by constructing a <spanx style="verb">TransItem <t>Compute the signature input by constructing a <tt>TransItem</tt
</spanx> of type > of type
<spanx style="verb">x509_entry_v2</spanx> or <spanx style="verb">precert_entry_v <tt>x509_entry_v2</tt> or <tt>precert_entry_v2</tt>, depending on t
2</spanx>, depending on the SCT's <spanx style="verb">TransItem</spanx> he SCT's
type. The <spanx style="verb">TimestampedCertificateEntryDataV2</spanx> structur <tt>TransItem</tt>
e is constructed in the type. The <tt>TimestampedCertificateEntryDataV2</tt> structure is c
following manner: onstructed
<list style="symbols"> in the following manner:
<t><spanx style="verb">timestamp</spanx> is copied from the SCT.</t> </t>
<t><spanx style="verb">tbs_certificate</spanx> is the reconstructed TBSCer <ul spacing="normal">
tificate portion of the server <li><tt>timestamp</tt> is copied from the SCT.</li>
certificate, as described in <xref target="reconstructing_tbscertificate"/>.</t <li><tt>tbs_certificate</tt> is the reconstructed TBSCertificate
> portion of
<t><spanx style="verb">issuer_key_hash</spanx> is computed as described in the server certificate, as described in <xref
<xref target="tree_leaves"/>.</t> target="reconstructing_tbscertificate" format="default"/>.</li>
<t><spanx style="verb">sct_extensions</spanx> is copied from the SCT.</t> <li><tt>issuer_key_hash</tt> is computed as described in <xref
</list></t> target="tree_leaves" format="default"/>.</li>
<t>Verify the SCT's <spanx style="verb">signature</spanx> against the computed <li><tt>sct_extensions</tt> is copied from the SCT.</li>
signature input using the </ul>
public key of the corresponding log, which is identified by the <spanx style="ve </li>
rb">log_id</spanx>. The <li>Verify the SCT's <tt>signature</tt> against the computed signatu
required signature algorithm is one of the log's parameters.</t> re input using the
</list></t> public key of the corresponding log, which is identified by the <tt>log_id</tt>.
The
<t>If the TLS client does not have the corresponding log's parameters, it cannot required signature algorithm is one of the log's parameters.</li>
</ul>
<t>If the TLS client does not have the corresponding log's parameters,
it cannot
attempt to validate the SCT. When evaluating compliance (see attempt to validate the SCT. When evaluating compliance (see
<xref target="evaluating_compliance"/>), the TLS client will consider only those SCTs that it <xref target="evaluating_compliance" format="default"/>), the TLS client will co nsider only those SCTs that it
was able to validate.</t> was able to validate.</t>
<t>Note that SCT validation is not a substitute for the normal validat
<t>Note that SCT validation is not a substitute for the normal validation of the ion of the
server certificate and its chain.</t> server certificate and its chain.</t>
</section>
</section> <section anchor="fetching_inclusion_proofs" numbered="true" toc="default
<section anchor="fetching_inclusion_proofs" title="Fetching inclusion proofs"> ">
<name>Fetching Inclusion Proofs</name>
<t>When a TLS client has validated a received SCT but does not yet possess <t>When a TLS client has validated a received SCT but does not yet pos
a corresponding inclusion proof, the TLS client MAY request the inclusion sess
proof directly from a log using <spanx style="verb">get-proof-by-hash</spanx> (< a corresponding inclusion proof, the TLS client <bcp14>MAY</bcp14> request the i
xref target="get-proof-by-hash"/>) or nclusion
<spanx style="verb">get-all-by-hash</spanx> (<xref target="get-all-by-hash"/>).< proof directly from a log using <tt>get-proof-by-hash</tt> (<xref target="get-pr
/t> oof-by-hash" format="default"/>) or
<tt>get-all-by-hash</tt> (<xref target="get-all-by-hash" format="default"/>).</t
<t>Note that fetching inclusion proofs directly from a log will disclose to the >
<t>Note that fetching inclusion proofs directly from a log will disclo
se to the
log which TLS server the client has been communicating with. This may be log which TLS server the client has been communicating with. This may be
regarded as a significant privacy concern, and so it is preferable for the TLS regarded as a significant privacy concern, and so it is preferable for the TLS
server to send the inclusion proofs (see <xref target="presenting_transitems"/>) server to send the inclusion proofs (see <xref target="presenting_transitems" fo
.</t> rmat="default"/>).</t>
</section>
</section> <section anchor="validating_inclusion_proofs" numbered="true" toc="defau
<section anchor="validating_inclusion_proofs" title="Validating inclusion proofs lt">
"> <name>Validating Inclusion Proofs</name>
<t>When a TLS client has received, or fetched, an inclusion proof (and
<t>When a TLS client has received, or fetched, an inclusion proof (and an STH), an STH),
it SHOULD proceed to verifying the inclusion proof to the provided STH. it <bcp14>SHOULD</bcp14> proceed to verify the inclusion proof to the provided S
The TLS client SHOULD also verify consistency between the provided STH TH.
The TLS client <bcp14>SHOULD</bcp14> also verify consistency between the provide
d STH
and an STH it knows about.</t> and an STH it knows about.</t>
<t>If the TLS client holds an STH that predates the SCT, it <bcp14>MAY
<t>If the TLS client holds an STH that predates the SCT, it MAY, in the process </bcp14>, in the process of
of auditing, request a new STH from the log (<xref target="get-sth" format="default
auditing, request a new STH from the log (<xref target="get-sth"/>), then verify "/>) and then verify it by
it by requesting a consistency proof (<xref target="get-sth-consistency" format="defau
requesting a consistency proof (<xref target="get-sth-consistency"/>). Note that lt"/>). Note that if the TLS
if the TLS client uses <tt>get-all-by-hash</tt>, then it will already have the new STH.</t>
client uses <spanx style="verb">get-all-by-hash</spanx>, then it will already ha </section>
ve the new STH.</t> <section anchor="evaluating_compliance" numbered="true" toc="default">
<name>Evaluating Compliance</name>
</section> <t>It is up to a client's local policy to specify the quantity and for
<section anchor="evaluating_compliance" title="Evaluating compliance"> m of
evidence (SCTs, inclusion proofs, or a combination) needed to achieve
<t>It is up to a client's local policy to specify the quantity and form of compliance and how to handle noncompliance.</t>
evidence (SCTs, inclusion proofs or a combination) needed to achieve <t>A TLS client can only evaluate compliance if it has given the TLS s
compliance and how to handle non-compliance.</t> erver the
<t>A TLS client can only evaluate compliance if it has given the TLS server the
opportunity to send SCTs and inclusion proofs by any of the three mechanisms opportunity to send SCTs and inclusion proofs by any of the three mechanisms
that are mandatory to implement for CT-using TLS clients (see that are mandatory to implement for CT-using TLS clients (see
<xref target="receiving_transitems"/>). Therefore, a TLS client MUST NOT evaluat <xref target="receiving_transitems" format="default"/>). Therefore, a TLS client
e compliance <bcp14>MUST NOT</bcp14> evaluate compliance
if it did not include both the <spanx style="verb">transparency_info</spanx> and if it did not include both the <tt>transparency_info</tt> and <tt>status_request
<spanx style="verb">status_request</spanx> TLS </tt> TLS
extensions in the ClientHello.</t> extensions in the ClientHello.</t>
</section>
</section> </section>
</section> <section anchor="monitor" numbered="true" toc="default">
<section anchor="monitor" title="Monitor"> <name>Monitor</name>
<t>Monitors watch logs to check for correct behavior, for certificates o
<t>Monitors watch logs to check that they behave correctly, for certificates of f
interest, or both. For example, a monitor may be configured to report on all interest, or for both. For example, a monitor may be configured to report on all
certificates that apply to a specific domain name when fetching new entries for certificates that apply to a specific domain name when fetching new entries for
consistency validation.</t> consistency validation.</t>
<t>A monitor <bcp14>MUST</bcp14> at least inspect every new entry in eve
<t>A monitor MUST at least inspect every new entry in every log it watches, and ry log it watches, and it
it <bcp14>MAY</bcp14> also choose to keep copies of entire logs.</t>
MAY also choose to keep copies of entire logs.</t> <t>To inspect all of the existing entries, the monitor <bcp14>SHOULD</bc
p14> follow these steps
<t>To inspect all of the existing entries, the monitor SHOULD follow these steps
once for each log:</t> once for each log:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>Fetch the current STH (<xref target="get-sth" format="default"/>).<
<t>Fetch the current STH (<xref target="get-sth"/>).</t> /li>
<t>Verify the STH signature.</t> <li>Verify the STH signature.</li>
<t>Fetch all the entries in the tree corresponding to the STH (<xref target="g <li>Fetch all the entries in the tree corresponding to the STH (<xref
et-entries"/>).</t> target="get-entries" format="default"/>).</li>
<t>If applicable, check each entry to see if it's a certificate of interest.</ <li>If applicable, check each entry to see if it's a certificate of in
t> terest.</li>
<t>Confirm that the tree made from the fetched entries produces the same hash <li>Confirm that the tree made from the fetched entries produces the s
as ame hash as
that in the STH.</t> that in the STH.</li>
</list></t> </ol>
<t>To inspect new entries, the monitor <bcp14>SHOULD</bcp14> follow thes
<t>To inspect new entries, the monitor SHOULD follow these steps repeatedly for e steps
each log:</t> repeatedly for each log:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>Fetch the current STH (<xref target="get-sth" format="default"/>).
<t>Fetch the current STH (<xref target="get-sth"/>). Repeat until the STH chan Repeat until
ges. the STH changes. To allow for experimentation, this document does not s
This document does not specify the polling frequency, to allow for pecify the polling frequency.</li>
experimentation.</t> <li>Verify the STH signature.</li>
<t>Verify the STH signature.</t> <li>Fetch all the new entries in the tree corresponding to the STH
<t>Fetch all the new entries in the tree corresponding to the STH (<xref target="get-entries" format="default"/>). If they remain unavail
(<xref target="get-entries"/>). If they remain unavailable for an extended perio able for an
d, then extended period, then this should be viewed as misbehavior on the part
this should be viewed as misbehavior on the part of the log.</t> of the
<t>If applicable, check each entry to see if it's a certificate of interest.</ log.</li>
t> <li>If applicable, check each entry to see if it's a certificate of in
<t>Either: <list style="numbers"> terest.</li>
<t>Verify that the updated list of all entries generates a tree with the <li>
same hash as the new STH.</t> <t>Either:</t>
</list> <ol spacing="normal" type="a">
Or, if it is not keeping all log entries: <list style="numbers"> <li>Verify that the updated list of all entries generates a tree wi
<t>Fetch a consistency proof for the new STH with the previous STH th the
(<xref target="get-sth-consistency"/>).</t> same hash as the new STH.</li>
<t>Verify the consistency proof.</t> </ol>
<t>Verify that the new entries generate the corresponding elements in the <t>Or, if it is not keeping all log entries:</t>
consistency proof.</t> <ol spacing="normal" type="a">
</list></t> <li>Fetch a consistency proof for the new STH with the previous STH
<t>Repeat from step 1.</t> (<xref target="get-sth-consistency" format="default"/>).</li>
</list></t> <li>Verify the consistency proof.</li>
<li>Verify that the new entries generate the corresponding element
</section> s in the
<section anchor="auditing" title="Auditing"> consistency proof.</li>
</ol>
<t>Auditing ensures that the current published state of a log is reachable from </li>
previously published states that are known to be good, and that the promises <li>Repeat from Step 1.</li>
made by the log in the form of SCTs have been kept. Audits are performed by </ol>
</section>
<section anchor="auditing" numbered="true" toc="default">
<name>Auditing</name>
<t>Auditing ensures that the current published state of a log is reachab
le from
previously published states that are known to be good and that the promises
made by the log, in the form of SCTs, have been kept. Audits are performed by
monitors or TLS clients.</t> monitors or TLS clients.</t>
<t>In particular, there are four properties of log behavior that should
<t>In particular, there are four log behavior properties that should be checked: be checked:</t>
</t> <ul spacing="normal">
<li>the Maximum Merge Delay (MMD)</li>
<t><list style="symbols"> <li>the STH Frequency Count</li>
<t>The Maximum Merge Delay (MMD).</t> <li>the append-only property</li>
<t>The STH Frequency Count.</t> <li>the consistency of the log view presented to all query sources</li
<t>The append-only property.</t> >
<t>The consistency of the log view presented to all query sources.</t> </ul>
</list></t> <t>A benign, conformant log publishes a series of STHs over time, each d
erived from
<t>A benign, conformant log publishes a series of STHs over time, each derived f
rom
the previous STH and the submitted entries incorporated into the log since the previous STH and the submitted entries incorporated into the log since
publication of the previous STH. This can be proven through auditing of STHs. publication of the previous STH. This can be proven through auditing of STHs.
SCTs returned to TLS clients can be audited by verifying against the SCTs returned to TLS clients can be audited by verifying against the
accompanying certificate, and using Merkle Inclusion Proofs, against the log's accompanying certificate and using Merkle inclusion proofs against the log's
Merkle tree.</t> Merkle Tree.</t>
<t>The action taken by the auditor, if an audit fails, is not specified,
<t>The action taken by the auditor if an audit fails is not specified, but note but note
that in general if audit fails, the auditor is in possession of signed proof of that in general, if an audit fails, the auditor is in possession of signed proof
of
the log's misbehavior.</t> the log's misbehavior.</t>
<t>A monitor (<xref target="monitor" format="default"/>) can audit by ve
<t>A monitor (<xref target="monitor"/>) can audit by verifying the consistency o rifying the consistency of STHs it
f STHs it receives, ensuring that each entry can be fetched and that the STH is indeed the
receives, ensure that each entry can be fetched and that the STH is indeed the
result of making a tree from all fetched entries.</t> result of making a tree from all fetched entries.</t>
<t>A TLS client (<xref target="tls_clients" format="default"/>) can audi
<t>A TLS client (<xref target="tls_clients"/>) can audit by verifying an SCT aga t by verifying an SCT against any STH
inst any STH
dated after the SCT timestamp + the Maximum Merge Delay by requesting a Merkle dated after the SCT timestamp + the Maximum Merge Delay by requesting a Merkle
inclusion proof (<xref target="get-proof-by-hash"/>). It can also verify that th e SCT inclusion proof (<xref target="get-proof-by-hash" format="default"/>). It can al so verify that the SCT
corresponds to the server certificate it arrived with (i.e., the log entry is corresponds to the server certificate it arrived with (i.e., the log entry is
that certificate, or is a precertificate corresponding to that certificate).</t> that certificate or is a precertificate corresponding to that certificate).</t>
<t>Checking of the consistency of the log view presented to all entities
<t>Checking of the consistency of the log view presented to all entities is more is more
difficult to perform because it requires a way to share log responses among a difficult to perform because it requires a way to share log responses among a
set of CT-using entities, and is discussed in <xref target="misbehaving_logs"/>. set of CT-using entities and is discussed in <xref target="misbehaving_logs" for
</t> mat="default"/>.</t>
</section>
</section> </section>
</section> <section anchor="algorithm-agility" numbered="true" toc="default">
<section anchor="algorithm-agility" title="Algorithm Agility"> <name>Algorithm Agility</name>
<t>It is not possible for a log to change either of its algorithms part wa
<t>It is not possible for a log to change any of its algorithms part way through y through
its lifetime:</t> its lifetime:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Signature algorithm:</dt>
<t hangText="Signature algorithm:"> <dd>SCT signatures must remain valid so signature algorithms can only be
SCT signatures must remain valid so signature algorithms can only be added, added,
not removed.</t> not removed.</dd>
<t hangText="Hash algorithm:"> <dt>Hash algorithm:</dt>
A log would have to support the old and new hash algorithms to allow <dd>A log would have to support the old and new hash algorithms to allow
backwards-compatibility with clients that are not aware of a hash algorithm backwards compatibility with clients that are not aware of a hash algorit
change.</t> hm
</list></t> change.</dd>
</dl>
<t>Allowing multiple signature or hash algorithms for a log would require that a <t>Allowing multiple signature or hash algorithms for a log would require
ll that all
data structures support it and would significantly complicate client data structures support it and would significantly complicate client
implementation, which is why it is not supported by this document.</t> implementation, which is why it is not supported by this document.</t>
<t>If it should become necessary to deprecate an algorithm used by a live
<t>If it should become necessary to deprecate an algorithm used by a live log, t log, then
hen the log <bcp14>MUST</bcp14> be frozen, as specified in <xref target="log_shutdow
the log MUST be frozen as specified in <xref target="log_shutdown"/> and a new l n" format="default"/>, and a new log <bcp14>SHOULD</bcp14> be
og SHOULD be
started. Certificates in the frozen log that have not yet expired and require started. Certificates in the frozen log that have not yet expired and require
new SCTs SHOULD be submitted to the new log and the SCTs from that log used new SCTs <bcp14>SHOULD</bcp14> be submitted to the new log and the SCTs from tha t log used
instead.</t> instead.</t>
</section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>The assignment policy criteria mentioned in this section refer to the p
<t>The assignment policy criteria mentioned in this section refer to the policie olicies
s outlined in <xref target="RFC8126" format="default"/>.</t>
outlined in <xref target="RFC8126"></xref>.</t> <section anchor="additions-to-existing-registries" numbered="true" toc="de
fault">
<section anchor="additions-to-existing-registries" title="Additions to existing <name>Additions to Existing Registries</name>
registries"> <t>This subsection defines additions to existing registries.</t>
<section anchor="new-entry-to-the-tls-extensiontype-registry" numbered="
<t>This sub-section defines additions to existing registries.</t> true" toc="default">
<name>New Entry to the TLS ExtensionType Registry</name>
<section anchor="new-entry-to-the-tls-extensiontype-registry" title="New Entry t <t>IANA has added the following entry
o the TLS ExtensionType Registry"> to the "TLS ExtensionType Values" registry defined in <xref target="RFC8446" for
mat="default"/>,
<t>IANA is asked to add the following entry
to the "TLS ExtensionType Values" registry defined in <xref target="RFC8446"></x
ref>,
with an assigned Value:</t> with an assigned Value:</t>
<table align="center">
<texttable> <thead>
<ttcol align='left'>Value</ttcol> <tr>
<ttcol align='left'>Extension Name</ttcol> <th align="left">Value</th>
<ttcol align='left'>TLS 1.3</ttcol> <th align="left">Extension Name</th>
<ttcol align='left'>Recommended</ttcol> <th align="left">TLS 1.3</th>
<ttcol align='left'>Reference</ttcol> <th align="left">DTLS-Only</th>
<c>TBD</c> <th align="left">Recommended</th>
<c>transparency_info</c> <th align="left">Reference</th>
<c>CH, CR, CT</c> </tr>
<c>Y</c> </thead>
<c>RFCXXXX</c> <tbody>
</texttable> <tr>
<td align="left">52</td>
</section> <td align="left">transparency_info</td>
<section anchor="urn-sub-namespace-for-trans-urnietfparamstrans" title="URN Sub- <td align="left">CH, CR, CT</td>
namespace for TRANS (urn:ietf:params:trans)"> <td align="left">N</td>
<td align="left">Y</td>
<t>IANA is requested to add a new entry in the <td align="left">RFC 9162</td>
"IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" </tr>
registry, following the template in <xref target="RFC3553"/>:</t> </tbody>
</table>
<t>Registry name: trans</t> </section>
<section anchor="urn-sub-namespace-for-trans-urnietfparamstrans" numbere
<t>Specification: RFCXXXX</t> d="true" toc="default">
<name>URN Sub-namespace for TRANS (urn:ietf:params:trans)</name>
<t>Repository: https://www.iana.org/assignments/trans</t> <t>IANA has added a new entry in the
"IETF URN Sub-namespace for Registered Protocol Parameter Identifiers"
<t>Index value: No transformation needed.</t> registry, following the template in <xref target="RFC3553" format="defa
ult"/>:</t>
</section> <dl newline="false" spacing="compact">
</section> <dt>Registry name:</dt>
<section anchor="new-ct-related-registries" title="New CT-Related registries"> <dd>trans</dd>
<dt>Specification:</dt>
<t>IANA is requested to add a new protocol registry, "Public Notary <dd>RFC 9162</dd>
<dt>Repository:</dt>
<dd><eref brackets="angle"
target="https://www.iana.org/assignments/trans"/></dd>
<dt>Index value:</dt>
<dd>No transformation needed.</dd>
</dl>
</section>
</section>
<section anchor="new-ct-related-registries" numbered="true" toc="default">
<name>New CT-Related Registries</name>
<t>IANA has added a new protocol registry, "Public Notary
Transparency", to the list that appears at Transparency", to the list that appears at
https://www.iana.org/assignments/</t> <eref brackets="angle" target="https://www.iana.org/assignments/"/></t>
<t>The rest of this section defines the subregistries that have been cre
<t>The rest of this section defines sub-registries to be ated within the new "Public Notary Transparency" registry.</t>
created within the new Public Notary Transparency registry.</t> <section anchor="hash_algorithms" numbered="true" toc="default">
<name>Hash Algorithms</name>
<section anchor="hash_algorithms" title="Hash Algorithms"> <t>IANA has established a registry of hash algorithm values, named
"Hash Algorithms", with the following registration procedures:</t>
<t>IANA is asked to establish a registry of hash algorithm values, named <table align="center">
"Hash Algorithms", that initially consists of:</t> <thead>
<tr>
<texttable> <th align="left">Range</th>
<ttcol align='left'>Value</ttcol> <th align="left">Registration Procedures</th>
<ttcol align='left'>Hash Algorithm</ttcol> </tr>
<ttcol align='left'>OID</ttcol> </thead>
<ttcol align='left'>Reference / Assignment Policy</ttcol> <tbody>
<c>0x00</c> <tr>
<c>SHA-256</c> <td>0x00-0xDF</td>
<c>2.16.840.1.101.3.4.2.1</c> <td>Specification Required</td>
<c><xref target="RFC6234"></xref></c> </tr>
<c>0x01 - 0xDF</c> <tr>
<c>Unassigned</c> <td>0xE0-0xEF</td>
<c>&#160;</c> <td>Experimental Use</td>
<c>Specification Required</c> </tr>
<c>0xE0 - 0xEF</c> <tr>
<c>Reserved</c> <td>0xF0-0xFF</td>
<c>&#160;</c> <td>Private Use</td>
<c>Experimental Use</c> </tr>
<c>0xF0 - 0xFF</c> </tbody>
<c>Reserved</c> </table>
<c>&#160;</c> <t>The "Hash Algorithms" registry initially consists of:</t>
<c>Private Use</c> <table align="center">
</texttable> <thead>
<tr>
<t>The Designated Expert(s) should ensure that the proposed algorithm has a publ <th align="left">Value</th>
ic <th align="left">Hash Algorithm</th>
<th align="left">OID</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x00</td>
<td align="left">SHA-256</td>
<td align="left">2.16.840.1.101.3.4.2.1</td>
<td align="left">
<xref target="RFC6234" format="default"/></td>
</tr>
<tr>
<td align="left">0x01 - 0xDF</td>
<td align="left">Unassigned</td>
<td align="left">&nbsp;</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0xE0 - 0xEF</td>
<td align="left">Reserved for Experimental Use</td>
<td align="left">&nbsp;</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0xF0 - 0xFF</td>
<td align="left">Reserved for Private Use</td>
<td align="left">&nbsp;</td>
<td align="left">RFC 9162</td>
</tr>
</tbody>
</table>
<t>The designated expert(s) should ensure that the proposed algorithm
has a public
specification and is suitable for use as a cryptographic hash algorithm with no specification and is suitable for use as a cryptographic hash algorithm with no
known preimage or collision attacks. These attacks can damage the integrity of known preimage or collision attacks. These attacks can damage the integrity of
the log.</t> the log.</t>
</section>
</section> <section anchor="signature_algorithms" numbered="true" toc="default">
<section anchor="signature_algorithms" title="Signature Algorithms"> <name>Signature Algorithms</name>
<t>IANA has established a registry of signature algorithm values, name
<t>IANA is asked to establish a registry of signature algorithm values, named d
"Signature Algorithms".</t> "Signature Algorithms".</t>
<t>The following notes have been added to the registry:</t>
<blockquote>
<dl newline="true">
<dt><strong>Note:</strong></dt>
<dd>This is a subset of the "TLS SignatureScheme" registry, limi
ted to those
algorithms that are appropriate for CT. A major advantage of this is
leveraging the expertise of the TLS Working Group and its designated
expert(s).</dd>
</dl>
</blockquote>
<blockquote>
<dl newline="true">
<dt><strong>Note:</strong></dt>
<dd>The value <tt>0x0403</tt> appears twice. While this may be c
onfusing,
it is okay because the verification
process is the same for both algorithms, and the choice of which to u
se
when generating a signature is purely internal to the log server.</dd
>
</dl>
</blockquote>
<t>The "Signature Algorithms" registry has the following registration
procedures:</t>
<table align="center">
<thead>
<tr>
<th align="left">Range</th>
<th align="left">Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x0000-0x0807</td>
<td>Specification Required</td>
</tr>
<tr>
<td>0x0808-0xFDFF</td>
<td>Expert Review</td>
</tr>
<tr>
<td>0xFE00-0xFEFF</td>
<td>Experimental Use</td>
</tr>
<tr>
<td>0xFF00-0xFFFF</td>
<td>Private Use</td>
</tr>
</tbody>
</table>
<t>The following notes should be added:</t> <t>The "Signature Algorithms" registry initially consists of:</t>
<table align="center">
<t><list style="symbols"> <thead>
<t>This is a subset of the TLS SignatureScheme Registry, limited to those <tr>
algorithms that are appropriate for CT. A major advantage of this is <th align="left">SignatureScheme Value</th>
leveraging the expertise of the TLS working group and its Designated <th align="left">Signature Algorithm</th>
Expert(s).</t> <th align="left">Reference</th>
<t>The value <spanx style="verb">0x0403</spanx> appears twice. While this may </tr>
be confusing, </thead>
it is okay because the verification <tbody>
process is the same for both algorithms, and the choice of which to use <tr>
when generating a signature is purely internal to the log server.</t> <td align="left">0x0000 - 0x0402</td>
</list></t> <td align="left">Unassigned</td>
<td align="left">&nbsp;</td>
<t>The registry should initially consist of:</t> </tr>
<tr>
<texttable> <td align="left">ecdsa_secp256r1_sha256 (0x0403)</td>
<ttcol align='left'>SignatureScheme Value</ttcol> <td align="left">ECDSA (NIST P-256) with SHA-256</td>
<ttcol align='left'>Signature Algorithm</ttcol> <td align="left">
<ttcol align='left'>Reference / Assignment Policy</ttcol> <xref target="FIPS186-4" format="default"/></td>
<c>0x0000 - 0x0402</c> </tr>
<c>Unassigned</c> <tr>
<c>Specification Required</c> <td align="left">ecdsa_secp256r1_sha256 (0x0403)</td>
<c>ecdsa_secp256r1_sha256(0x0403)</c> <td align="left">Deterministic ECDSA (NIST P-256) with HMAC-SHA2
<c>ECDSA (NIST P-256) with SHA-256</c> 56</td>
<c><xref target="FIPS186-4"></xref></c> <td align="left">
<c>ecdsa_secp256r1_sha256(0x0403)</c> <xref target="RFC6979" format="default"/></td>
<c>Deterministic ECDSA (NIST P-256) with HMAC-SHA256</c> </tr>
<c><xref target="RFC6979"></xref></c> <tr>
<c>0x0404 - 0x0806</c> <td align="left">0x0404 - 0x0806</td>
<c>Unassigned</c> <td align="left">Unassigned</td>
<c>Specification Required</c> <td align="left">&nbsp;</td>
<c>ed25519(0x0807)</c> </tr>
<c>Ed25519 (PureEdDSA with the edwards25519 curve)</c> <tr>
<c><xref target="RFC8032"></xref></c> <td align="left">ed25519 (0x0807)</td>
<c>0x0808 - 0xFDFF</c> <td align="left">Ed25519 (PureEdDSA with the edwards25519 curve)
<c>Unassigned</c> </td>
<c>Expert Review</c> <td align="left">
<c>0xFE00 - 0xFEFF</c> <xref target="RFC8032" format="default"/></td>
<c>Reserved</c> </tr>
<c>Experimental Use</c> <tr>
<c>0xFF00 - 0xFFFF</c> <td align="left">0x0808 - 0xFDFF</td>
<c>Reserved</c> <td align="left">Unassigned</td>
<c>Private Use</c> <td align="left">&nbsp;</td>
</texttable> </tr>
<tr>
<t>The Designated Expert(s) should ensure that the proposed algorithm has a publ <td align="left">0xFE00 - 0xFEFF</td>
ic <td align="left">Reserved for Experimental Use</td>
specification, has a value assigned to it in the TLS SignatureScheme Registry <td align="left">RFC 9162</td>
(that IANA was asked to establish in <xref target="RFC8446"></xref>), and is sui </tr>
table for use as a <tr>
<td align="left">0xFF00 - 0xFFFF</td>
<td align="left">Reserved for Private Use</td>
<td align="left">RFC 9162</td>
</tr>
</tbody>
</table>
<t>The designated expert(s) should ensure that the proposed algorithm
has a public
specification, has a value assigned to it in the "TLS SignatureScheme" registry
(which was established by <xref target="RFC8446" format="default"/>), and is sui
table for use as a
cryptographic signature algorithm.</t> cryptographic signature algorithm.</t>
</section>
</section> <section anchor="versioned_trans_types" numbered="true" toc="default">
<section anchor="versioned_trans_types" title="VersionedTransTypes"> <name>VersionedTransTypes</name>
<t>IANA has established a registry of <tt>VersionedTransType</tt> valu
<t>IANA is asked to establish a registry of <spanx style="verb">VersionedTransTy es, named
pe</spanx> values, named
"VersionedTransTypes".</t> "VersionedTransTypes".</t>
<t>The following note has been added:</t>
<t>The following note should be added:</t> <blockquote>
<dl newline="true">
<t><list style="symbols"> <dt><strong>Note:</strong></dt>
<t>The range 0x0000..0x00FF is reserved so that v1 SCTs are distinguishable fr <dd>The range 0x0000..0x00FF is reserved so that v1 SCTs are disting
om v2 uishable from
SCTs and other <spanx style="verb">TransItem</spanx> structures.</t> v2 SCTs and other <tt>TransItem</tt> structures.</dd>
</list></t> </dl>
</blockquote>
<t>The registry should initially consist of:</t> <t>The registration procedures for the "VersionedTransTypes" registry
are the following:</t>
<texttable> <table align="center">
<ttcol align='left'>Value</ttcol> <thead>
<ttcol align='left'>Type and Version</ttcol> <tr>
<ttcol align='left'>Reference / Assignment Policy</ttcol> <th align="left">Range</th>
<c>0x0000 - 0x00FF</c> <th align="left">Registration Procedures</th>
<c>Reserved</c> </tr>
<c><xref target="RFC6962"></xref></c> </thead>
<c>0x0100</c> <tbody>
<c>x509_entry_v2</c> <tr>
<c>RFCXXXX</c> <td>0x0100-0xDFFF</td>
<c>0x0101</c> <td>Specification Required</td>
<c>precert_entry_v2</c> </tr>
<c>RFCXXXX</c> <tr>
<c>0x0102</c> <td>0xE000-0xEFFF</td>
<c>x509_sct_v2</c> <td>Experimental Use</td>
<c>RFCXXXX</c> </tr>
<c>0x0103</c> <tr>
<c>precert_sct_v2</c> <td>0xF000-0xFFFF</td>
<c>RFCXXXX</c> <td>Private Use</td>
<c>0x0104</c> </tr>
<c>signed_tree_head_v2</c> </tbody>
<c>RFCXXXX</c> </table>
<c>0x0105</c> <t>The "VersionedTransTypes" registry initially consists of:</t>
<c>consistency_proof_v2</c> <table align="center">
<c>RFCXXXX</c> <thead>
<c>0x0106</c> <tr>
<c>inclusion_proof_v2</c> <th align="left">Value</th>
<c>RFCXXXX</c> <th align="left">Type and Version</th>
<c>0x0107 - 0xDFFF</c> <th align="left">Reference</th>
<c>Unassigned</c> </tr>
<c>Specification Required</c> </thead>
<c>0xE000 - 0xEFFF</c> <tbody>
<c>Reserved</c> <tr>
<c>Experimental Use</c> <td align="left">0x0000 - 0x00FF</td>
<c>0xF000 - 0xFFFF</c> <td align="left">Reserved</td>
<c>Reserved</c> <td align="left">
<c>Private Use</c> <xref target="RFC6962" format="default"/></td>
</texttable> </tr>
<tr>
<t>The Designated Expert(s) should review the public specification to ensure tha <td align="left">0x0100</td>
t it is <td align="left">x509_entry_v2</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0x0101</td>
<td align="left">precert_entry_v2</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0x0102</td>
<td align="left">x509_sct_v2</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0x0103</td>
<td align="left">precert_sct_v2</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0x0104</td>
<td align="left">signed_tree_head_v2</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0x0105</td>
<td align="left">consistency_proof_v2</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0x0106</td>
<td align="left">inclusion_proof_v2</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0x0107 - 0xDFFF</td>
<td align="left">Unassigned</td>
<td align="left">&nbsp;</td>
</tr>
<tr>
<td align="left">0xE000 - 0xEFFF</td>
<td align="left">Reserved for Experimental Use</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0xF000 - 0xFFFF</td>
<td align="left">Reserved for Private Use</td>
<td align="left">RFC 9162</td>
</tr>
</tbody>
</table>
<t>The designated expert(s) should review the public specification to
ensure that it is
detailed enough to ensure implementation interoperability.</t> detailed enough to ensure implementation interoperability.</t>
</section>
</section> <section anchor="log_artifact_extension_registry" numbered="true" toc="d
<section anchor="log_artifact_extension_registry" title="Log Artifact Extension efault">
Registry"> <name>Log Artifact Extensions</name>
<t>IANA has established a registry of <tt>ExtensionType</tt> values, n
<t>IANA is asked to establish a registry of <spanx style="verb">ExtensionType</s amed "Log
panx> values, named "Log Artifact Extensions".</t>
Artifact Extensions", that initially consists of:</t> <t>The registration procedures for the "Log Artifact Extensions" regis
try are the following:</t>
<texttable> <table align="center">
<ttcol align='left'>ExtensionType</ttcol> <thead>
<ttcol align='left'>Status</ttcol> <tr>
<ttcol align='left'>Use</ttcol> <th align="left">Range</th>
<ttcol align='left'>Reference / Assignment Policy</ttcol> <th align="left">Registration Procedures</th>
<c>0x0000 - 0xDFFF</c> </tr>
<c>Unassigned</c> </thead>
<c>n/a</c> <tbody>
<c>Specification Required</c> <tr>
<c>0xE000 - 0xEFFF</c> <td>0x0000-0xDFFF</td>
<c>Reserved</c> <td>Specification Required</td>
<c>n/a</c> </tr>
<c>Experimental Use</c> <tr>
<c>0xF000 - 0xFFFF</c> <td>0xE000-0xEFFF</td>
<c>Reserved</c> <td>Experimental Use</td>
<c>n/a</c> </tr>
<c>Private Use</c> <tr>
</texttable> <td>0xF000-0xFFFF</td>
<td>Private Use</td>
<t>The "Use" column should contain one or both of the following values:</t> </tr>
</tbody>
<t><list style="symbols"> </table>
<t>"SCT", for extensions specified for use in Signed Certificate Timestamps.</ <t>The "Log Artifact Extensions" registry initially consists of:</t>
t> <table align="center">
<t>"STH", for extensions specified for use in Signed Tree Heads.</t> <thead>
</list></t> <tr>
<th align="left">ExtensionType</th>
<t>The Designated Expert(s) should review the public specification to ensure tha <th align="left">Status</th>
t it is <th align="left">Use</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x0000 - 0xDFFF</td>
<td align="left">Unassigned</td>
<td align="left">n/a</td>
<td align="left">&nbsp;</td>
</tr>
<tr>
<td align="left">0xE000 - 0xEFFF</td>
<td align="left">Reserved for Experimental Use</td>
<td align="left">n/a</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">0xF000 - 0xFFFF</td>
<td align="left">Reserved for Private Use</td>
<td align="left">n/a</td>
<td align="left">RFC 9162</td>
</tr>
</tbody>
</table>
<t>The "Use" column should contain one or both of the following values
:</t>
<ul spacing="normal">
<li>"SCT", for extensions specified for use in Signed Certificate Ti
mestamps.</li>
<li>"STH", for extensions specified for use in Signed Tree Heads.</l
i>
</ul>
<t>The designated expert(s) should review the public specification to
ensure that it is
detailed enough to ensure implementation interoperability. They should detailed enough to ensure implementation interoperability. They should
also verify that the extension is appropriate to the contexts in which it is also verify that the extension is appropriate to the contexts in which it is
specified to be used (SCT, STH, or both).</t> specified to be used (SCT, STH, or both).</t>
</section>
</section> <section anchor="log_id_registry" numbered="true" toc="default">
<section anchor="log_id_registry" title="Log IDs Registry"> <name>Log IDs</name>
<t>IANA has established a registry of Log IDs, named "Log IDs".</t>
<t>IANA is asked to establish a registry of Log IDs, named "Log IDs", <t>The registry's registration procedure is First Come First Served.</
that initially consists of:</t> t>
<t>The "Log IDs" registry initially consists of:</t>
<texttable> <table align="center">
<ttcol align='left'>Log ID</ttcol> <thead>
<ttcol align='left'>Log Base URL</ttcol> <tr>
<ttcol align='left'>Log Operator</ttcol> <th align="left">Log ID</th>
<ttcol align='left'>Reference / Assignment Policy</ttcol> <th align="left">Log Base URL</th>
<c>1.3.101.8192 - 1.3.101.16383</c> <th align="left">Log Operator</th>
<c>Unassigned</c> <th align="left">Reference</th>
<c>Unassigned</c> </tr>
<c>First Come First Served</c> </thead>
<c>1.3.101.80.0 - 1.3.101.80.*</c> <tbody>
<c>Unassigned</c> <tr>
<c>Unassigned</c> <td align="left">1.3.101.8192 - 1.3.101.16383</td>
<c>First Come First Served</c> <td align="left">Unassigned</td>
</texttable> <td align="left">Unassigned</td>
<td align="left">&nbsp;</td>
<t>All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been set aside </tr>
<tr>
<td align="left">1.3.101.80.0 - 1.3.101.80.*</td>
<td align="left">Unassigned</td>
<td align="left">Unassigned</td>
<td align="left">&nbsp;</td>
</tr>
</tbody>
</table>
<t>The following notes have been added to the registry:</t>
<blockquote>
<dl newline="true">
<dt><strong>Note:</strong></dt>
<dd>All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have be
en set aside
for Log IDs. for Log IDs.
This is a limited resource of 8,192 OIDs, each of which has an encoded length of This is a limited resource of 8,192 OIDs, each of which has an encoded length of
4 octets.</t> 4 octets.</dd>
</dl>
<t>The 1.3.101.80 arc has also been set aside for Log IDs. </blockquote>
<blockquote>
<dl newline="true">
<dt><strong>Note:</strong></dt>
<dd>The 1.3.101.80 arc has also been set aside for Log IDs.
This is an unlimited resource, but only This is an unlimited resource, but only
the 128 OIDs from 1.3.101.80.0 to 1.3.101.80.127 have an encoded length of only the 128 OIDs from 1.3.101.80.0 to 1.3.101.80.127 have an encoded length of only
4 octets.</t> 4 octets.</dd>
</dl>
<t>Each application for the allocation of a Log ID MUST be accompanied by:</t> </blockquote>
<t>Each application for the allocation of a Log ID <bcp14>MUST</bcp14>
<t><list style="symbols"> be accompanied by:</t>
<t>the Log's Base URL (see <xref target="log_parameters"/>).</t> <ul spacing="normal">
<t>the Log Operator's contact details.</t> <li>the Log's Base URL (see <xref target="log_parameters"
</list></t> format="default"/>) and</li>
<li>the Log Operator's contact details.</li>
<t>IANA is asked to reject any request to update a Log ID or Log Base URL in thi </ul>
s <t>IANA is asked to reject any request to update a Log ID or Log Base
registry, because these fields are immutable (see <xref target="log_parameters"/ URL in this
>).</t> registry because these fields are immutable (see <xref target="log_parameters" f
ormat="default"/>).</t>
<t>IANA is asked to accept requests from log operators to update their contact <t>IANA is asked to accept requests from log operators to update their
contact
details in this registry.</t> details in this registry.</t>
<t>Since log operators can choose to not use this registry (see <xref
<t>Since log operators can choose to not use this registry (see <xref target="lo target="log_id" format="default"/>), it is
g_id"/>), it is
not expected to be a global directory of all logs.</t> not expected to be a global directory of all logs.</t>
</section>
</section> <section anchor="error-types-registry" numbered="true" toc="default">
<section anchor="error-types-registry" title="Error Types Registry"> <name>Error Types</name>
<t>IANA has created a new registry for errors,
<t>IANA is requested to create a new registry for errors,
the "Error Types" registry.</t> the "Error Types" registry.</t>
<t>The registration procedure for this registry is Specification Requi
<t>Requirements for this registry are Specification Required.</t> red.</t>
<t>This registry has the following three fields:</t>
<t>This registry should have the following three fields:</t> <table align="center">
<thead>
<texttable> <tr>
<ttcol align='left'>Field Name</ttcol> <th align="left">Field Name</th>
<ttcol align='left'>Type</ttcol> <th align="left">Type</th>
<ttcol align='left'>Reference</ttcol> <th align="left">Reference</th>
<c>identifier</c> </tr>
<c>string</c> </thead>
<c>RFCXXXX</c> <tbody>
<c>meaning</c> <tr>
<c>string</c> <td align="left">Identifier</td>
<c>RFCXXXX</c> <td align="left">string</td>
<c>reference</c> <td align="left">RFC 9162</td>
<c>string</c> </tr>
<c>RFCXXXX</c> <tr>
</texttable> <td align="left">Meaning</td>
<td align="left">string</td>
<t>The initial values are as follows, taken from the text above:</t> <td align="left">RFC 9162</td>
</tr>
<texttable> <tr>
<ttcol align='left'>Identifier</ttcol> <td align="left">Reference</td>
<ttcol align='left'>Meaning</ttcol> <td align="left">string</td>
<ttcol align='left'>Reference</ttcol> <td align="left">RFC 9162</td>
<c>malformed</c> </tr>
<c>The request could not be parsed.</c> </tbody>
<c>RFCXXXX</c> </table>
<c>badSubmission</c> <t>The initial values of the "Error Types" registry, which are taken f
<c><spanx style="verb">submission</spanx> is neither a valid certificate n rom the text in <xref target="client_messages" format="default"/>, are as follow
or a valid precertificate</c> s:</t>
<c>RFCXXXX</c> <table align="center">
<c>badType</c> <thead>
<c><spanx style="verb">type</spanx> is neither 1 nor 2</c> <tr>
<c>RFCXXXX</c> <th align="left">Identifier</th>
<c>badChain</c> <th align="left">Meaning</th>
<c>The first element of <spanx style="verb">chain</spanx> is not the certi <th align="left">Reference</th>
fier of the <spanx style="verb">submission</spanx>, or the second element does n </tr>
ot certify the first, etc.</c> </thead>
<c>RFCXXXX</c> <tbody>
<c>badCertificate</c> <tr>
<c>One or more certificates in the <spanx style="verb">chain</spanx> are n <td align="left">malformed</td>
ot valid (e.g., not properly encoded)</c> <td align="left">The request could not be parsed.</td>
<c>RFCXXXX</c> <td align="left">RFC 9162</td>
<c>unknownAnchor</c> </tr>
<c>The last element of <spanx style="verb">chain</spanx> (or, if <spanx st <tr>
yle="verb">chain</spanx> is an empty array, the <spanx style="verb">submission</ <td align="left">badSubmission</td>
spanx>) both is not, and is not certified by, an accepted trust anchor</c> <td align="left"><tt>submission</tt> is neither a valid certific
<c>RFCXXXX</c> ate nor a
<c>shutdown</c> valid precertificate.</td>
<c>The log is no longer accepting submissions</c> <td align="left">RFC 9162</td>
<c>RFCXXXX</c> </tr>
<c>firstUnknown</c> <tr>
<c><spanx style="verb">first</spanx> is before the latest known STH but is <td align="left">badType</td>
not from an existing STH.</c> <td align="left"><tt>type</tt> is neither 1 nor 2.</td>
<c>RFCXXXX</c> <td align="left">RFC 9162</td>
<c>secondUnknown</c> </tr>
<c><spanx style="verb">second</spanx> is before the latest known STH but i <tr>
s not from an existing STH.</c> <td align="left">badChain</td>
<c>RFCXXXX</c> <td align="left">The first element of <tt>chain</tt> is not the
<c>secondBeforeFirst</c> certifier of
<c><spanx style="verb">second</spanx> is smaller than <spanx style="verb"> the <tt>submission</tt>, or the second element does not certify t
first</spanx>.</c> he first,
<c>RFCXXXX</c> etc.</td>
<c>hashUnknown</c> <td align="left">RFC 9162</td>
<c><spanx style="verb">hash</spanx> is not the hash of a known leaf (may b </tr>
e caused by skew or by a known certificate not yet merged).</c> <tr>
<c>RFCXXXX</c> <td align="left">badCertificate</td>
<c>treeSizeUnknown</c> <td align="left">One or more certificates in <tt>chain</tt> are
<c><spanx style="verb">hash</spanx> is before the latest known STH but is not valid
not from an existing STH.</c> (e.g., not properly encoded).</td>
<c>RFCXXXX</c> <td align="left">RFC 9162</td>
<c>startUnknown</c> </tr>
<c><spanx style="verb">start</spanx> is greater than the number of entries <tr>
in the Merkle tree.</c> <td align="left">unknownAnchor</td>
<c>RFCXXXX</c> <td align="left">The last element of <tt>chain</tt> (or, if <tt>
<c>endBeforeStart</c> chain</tt> is
<c><spanx style="verb">start</spanx> cannot be greater than <spanx style=" an empty array, the <tt>submission</tt>) is not, nor is it certif
verb">end</spanx>.</c> ied
<c>RFCXXXX</c> by, an accepted trust anchor.</td>
</texttable> <td align="left">RFC 9162</td>
</tr>
</section> <tr>
</section> <td align="left">shutdown</td>
<section anchor="oid-assignment" title="OID Assignment"> <td align="left">The log is no longer accepting submissions.</td
>
<t>IANA is asked to assign one object identifier from the "SMI <td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">firstUnknown</td>
<td align="left"><tt>first</tt> is before the latest known STH b
ut is not
from an existing STH.</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">secondUnknown</td>
<td align="left"><tt>second</tt> is before the latest known STH
but is not
from an existing STH.</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">secondBeforeFirst</td>
<td align="left"><tt>second</tt> is smaller than <tt>first</tt>.
</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">hashUnknown</td>
<td align="left"><tt>hash</tt> is not the hash of a known leaf (
may be caused
by skew or by a known certificate not yet merged).</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">treeSizeUnknown</td>
<td align="left"><tt>hash</tt> is before the latest known STH bu
t is not from
an existing STH.</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">startUnknown</td>
<td align="left"><tt>start</tt> is greater than the number of en
tries in the
Merkle Tree.</td>
<td align="left">RFC 9162</td>
</tr>
<tr>
<td align="left">endBeforeStart</td>
<td align="left"><tt>start</tt> cannot be greater than <tt>end</
tt>.</td>
<td align="left">RFC 9162</td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="oid-assignment" numbered="true" toc="default">
<name>OID Assignment</name>
<t>IANA has assigned an object identifier from the "SMI
Security for PKIX Module Identifier" registry to identify the Security for PKIX Module Identifier" registry to identify the
ASN.1 module in <xref target="asn1_module"/> of this document with an assigned ASN.1 module in <xref target="asn1_module" format="default"/> of this document.<
Decimal value.</t> /t>
<table align="center">
<texttable> <thead>
<ttcol align='left'>Decimal</ttcol> <tr>
<ttcol align='left'>Description</ttcol> <th align="left">Decimal</th>
<ttcol align='left'>References</ttcol> <th align="left">Description</th>
<c>TBD</c> <th align="left">References</th>
<c>id-mod-public-notary-v2</c> </tr>
<c>RFCXXXX</c> </thead>
</texttable> <tbody>
<tr>
</section> <td align="left">102</td>
</section> <td align="left">id-mod-public-notary-v2</td>
<section anchor="security-considerations" title="Security Considerations"> <td align="left">RFC 9162</td>
</tr>
<t>With CAs, logs, and servers performing the actions described here, TLS client </tbody>
s </table>
</section>
</section>
<section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<t>With CAs, logs, and servers performing the actions described here, TLS
clients
can use logs and signed timestamps to reduce the likelihood that they will can use logs and signed timestamps to reduce the likelihood that they will
accept misissued certificates. If a server presents a valid signed timestamp for accept misissued certificates. If a server presents a valid signed timestamp for
a certificate, then the client knows that a log has committed to publishing the a certificate, then the client knows that a log has committed to publishing the
certificate. From this, the client knows that monitors acting for the subject of certificate. From this, the client knows that monitors acting for the subject of
the certificate have had some time to notice the misissuance and take some the certificate have had some time to notice the misissuance and take some
action, such as asking a CA to revoke a misissued certificate. A signed action, such as asking a CA to revoke a misissued certificate. A signed
timestamp does not guarantee this though, since appropriate monitors might not timestamp does not guarantee this, though, since appropriate monitors might not
have checked the logs or the CA might have refused to revoke the certificate.</t > have checked the logs or the CA might have refused to revoke the certificate.</t >
<t>In addition, if TLS clients will not accept unlogged certificates, then
<t>In addition, if TLS clients will not accept unlogged certificates, then site site
owners will have a greater incentive to submit certificates to logs, possibly owners will have a greater incentive to submit certificates to logs, possibly
with the assistance of their CA, increasing the overall transparency of the with the assistance of their CA, increasing the overall transparency of the
system.</t> system.</t>
<section anchor="misissued-certificates" numbered="true" toc="default">
<section anchor="misissued-certificates" title="Misissued Certificates"> <name>Misissued Certificates</name>
<t>Misissued certificates that have not been publicly logged, and thus d
<t>Misissued certificates that have not been publicly logged, and thus do not ha o not have
ve
a valid SCT, are not considered compliant. Misissued certificates that do have a valid SCT, are not considered compliant. Misissued certificates that do have
an SCT from a log will appear in that public log within the Maximum Merge Delay, an SCT from a log will appear in that public log within the Maximum Merge Delay,
assuming the log is operating correctly. Since a log is allowed to serve an STH assuming the log is operating correctly. Since a log is allowed to serve an STH
of any age up to the MMD, the maximum period of time during which a misissued of any age up to the MMD, the maximum period of time during which a misissued
certificate can be used without being available for audit is twice the MMD.</t> certificate can be used without being available for audit is twice the MMD.</t>
</section>
</section> <section anchor="detection-of-misissue" numbered="true" toc="default">
<section anchor="detection-of-misissue" title="Detection of Misissue"> <name>Detection of Misissue</name>
<t>The logs do not themselves detect misissued certificates; they rely i
<t>The logs do not themselves detect misissued certificates; they rely instead o nstead on
n
interested parties, such as domain owners, to monitor them and take corrective interested parties, such as domain owners, to monitor them and take corrective
action when a misissue is detected.</t> action when a misissue is detected.</t>
</section>
</section> <section anchor="misbehaving_logs" numbered="true" toc="default">
<section anchor="misbehaving_logs" title="Misbehaving Logs"> <name>Misbehaving Logs</name>
<t>A log can misbehave in several ways. Examples include the following:
<t>A log can misbehave in several ways. Examples include: failing to incorporate failing to incorporate a
a
certificate with an SCT in the Merkle Tree within the MMD; presenting different, certificate with an SCT in the Merkle Tree within the MMD; presenting different,
conflicting views of the Merkle Tree at different times and/or to different conflicting views of the Merkle Tree at different times and/or to different
parties; issuing STHs too frequently; mutating the signature of a logged parties; issuing STHs too frequently; mutating the signature of a logged
certificate; and failing to present a chain containing the certifier of a logged certificate; and failing to present a chain containing the certifier of a logged
certificate.</t> certificate.</t>
<t>Violation of the MMD contract is detected by log clients requesting a
<t>Violation of the MMD contract is detected by log clients requesting a Merkle Merkle
inclusion proof (<xref target="get-proof-by-hash"/>) for each observed SCT. Thes inclusion proof (<xref target="get-proof-by-hash" format="default"/>) for each o
e checks can bserved SCT. These checks can
be asynchronous and need only be done once per certificate. However, note that be asynchronous and need only be done once per certificate. However, note that
there may be privacy concerns (see <xref target="fetching_inclusion_proofs"/>).< there may be privacy concerns (see <xref target="fetching_inclusion_proofs" form
/t> at="default"/>).</t>
<t>Violation of the append-only property or the STH issuance rate limit
<t>Violation of the append-only property or the STH issuance rate limit can be can be
detected by multiple clients comparing their instances of the STHs. detected by multiple clients comparing their instances of the STHs.
This technique, known as "gossip," is an active area of research and not This technique, known as "gossip", is an active area of research and not
defined here. defined here.
Proof of misbehavior in such cases would be: a series of STHs that were Proof of misbehavior in such cases would be either a series of STHs that
issued too closely together, proving violation of the STH issuance rate limit; were
or an STH with a root hash that does not match the one calculated from a copy of issued too closely together, proving violation of the STH issuance rate l
the log, proving violation of the append-only property.</t> imit,
or an STH with a root hash that does not match the one calculated from a
<t>Clients that report back SCTs can be tracked or traced if a log copy of
the log, proving violation of the append-only property.</t>
<t>Clients that report back SCTs can be tracked or traced if a log
produces multiple STHs or SCTs with the same timestamp and data but different produces multiple STHs or SCTs with the same timestamp and data but different
signatures. Logs SHOULD mitigate this risk by either:</t> signatures. Logs <bcp14>SHOULD</bcp14> mitigate this risk by either:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>using deterministic signature schemes or</li>
<t>Using deterministic signature schemes, or</t> <li>producing no more than one SCT for each distinct submission and no
<t>Producing no more than one SCT for each distinct submission and no more tha more than one
n one STH for each distinct <tt>tree_size</tt>. Each of these SCTs and STHs c
STH for each distinct tree_size. Each of these SCTs and STHs can be stored by an be stored by
the log and served to other clients that submit the same certificate or request the log and served to other clients that submit the same certificate or
the same STH.</t> request
</list></t> the same STH.</li>
</ul>
</section> </section>
<section anchor="requiring_multiple_scts" title="Multiple SCTs"> <section anchor="requiring_multiple_scts" numbered="true" toc="default">
<name>Multiple SCTs</name>
<t>By requiring TLS servers to offer multiple SCTs, each from a different log, T <t>By requiring TLS servers to offer multiple SCTs, each from a differen
LS t log, TLS
clients reduce the effectiveness of an attack where a CA and a log collude clients reduce the effectiveness of an attack where a CA and a log collude
(see <xref target="multiple-scts"/>).</t> (see <xref target="multiple-scts" format="default"/>).</t>
</section>
</section> <section anchor="leakage-of-dns-information" numbered="true" toc="default"
<section anchor="leakage-of-dns-information" title="Leakage of DNS Information"> >
<name>Leakage of DNS Information</name>
<t>Malicious monitors can use logs to learn about the existence of domain names <t>Malicious monitors can use logs to learn about the existence of domai
n names
that might not otherwise be easy to discover. Some subdomain labels may reveal that might not otherwise be easy to discover. Some subdomain labels may reveal
information about the service and software for which the subdomain is used, information about the service and software for which the subdomain is used,
which in turn might facilitate targeted attacks.</t> which in turn might facilitate targeted attacks.</t>
</section>
</section> </section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Erwann Abelea, Robin Alden, Andrew Ayer, Rich
ard
Barnes, Al Cutter, David Drysdale, Francis Dupont, Adam Eijdenberg, Stephen
Farrell, Daniel Kahn Gillmor, Paul Hadfield, Brad Hill, Jeff Hodges, Paul
Hoffman, Jeffrey Hutzelman, Kat Joyce, Stephen Kent, SM, Alexey Melnikov, Linus
Nordberg, Chris Palmer, Trevor Perrin, Pierre Phaneuf, Eric Rescorla, Rich Salz,
Melinda Shore, Ryan Sleevi, Martin Smith, Carl Wallace and Paul Wouters for
their valuable contributions.</t>
<t>A big thank you to Symantec for kindly donating the OIDs from the 1.3.101 arc
that are used in this document.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4648.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5652.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6066.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6979.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7231.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7633.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7807.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8259.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8391.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<references title='Normative References'> <reference anchor="HTML401" target="https://www.w3.org/TR/2018/SPSD-html
401-20180327">
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <front>
<front> <title>HTML 4.01 Specification</title>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <author initials="D." surname="Raggett" fullname="David Raggett">
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a <organization/>
uthor> </author>
<date month='March' year='1997'/> <author initials="A." surname="Le Hors" fullname="Arnaud Le Hors">
<abstract><t>In many standards track documents several words are used to signify <organization/>
the requirements in the specification. These words are often capitalized. This </author>
document defines these words as they should be interpreted in IETF documents. <author initials="I." surname="Jacobs" fullname="Ian Jacobs">
This document specifies an Internet Best Current Practices for the Internet Comm <organization/>
unity, and requests discussion and suggestions for improvements.</t></abstract> </author>
</front> <date year="2018" month="March"/>
<seriesInfo name='BCP' value='14'/> </front>
<seriesInfo name='RFC' value='2119'/> <seriesInfo name="W3C Recommendation" value="SPSD-html401-20180327"/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/> </reference>
</reference>
<reference anchor='RFC3986' target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname='T. Berners-Lee' initials='T.' surname='Berners-Lee'><organizat
ion/></author>
<author fullname='R. Fielding' initials='R.' surname='Fielding'><organization/><
/author>
<author fullname='L. Masinter' initials='L.' surname='Masinter'><organization/><
/author>
<date month='January' year='2005'/>
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of charac
ters that identifies an abstract or physical resource. This specification defin
es the generic URI syntax and a process for resolving URI references that might
be in relative form, along with guidelines and security considerations for the u
se of URIs on the Internet. The URI syntax defines a grammar that is a superset
of all valid URIs, allowing an implementation to parse the common components of
a URI reference without knowing the scheme-specific requirements of every possi
ble identifier. This specification does not define a generative grammar for URI
s; 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='RFC4648' target='https://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'><organization/
></author>
<date month='October' year='2006'/>
<abstract><t>This document describes the commonly used base 64, base 32, and bas
e 16 encoding schemes. It also discusses the use of line-feeds in encoded data,
use of padding in encoded data, use of non-alphabet characters in encoded data,
use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK
]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>
<reference anchor='RFC5246' target='https://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author fullname='T. Dierks' initials='T.' surname='Dierks'><organization/></aut
hor>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/><
/author>
<date month='August' year='2008'/>
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security
(TLS) protocol. The TLS protocol provides communications security over the Int
ernet. The protocol allows client/server applications to communicate in a way t
hat is designed to prevent eavesdropping, tampering, or message forgery. [STAND
ARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>
<reference anchor='RFC5280' target='https://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revo
cation List (CRL) Profile</title>
<author fullname='D. Cooper' initials='D.' surname='Cooper'><organization/></aut
hor>
<author fullname='S. Santesson' initials='S.' surname='Santesson'><organization/
></author>
<author fullname='S. Farrell' initials='S.' surname='Farrell'><organization/></a
uthor>
<author fullname='S. Boeyen' initials='S.' surname='Boeyen'><organization/></aut
hor>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></a
uthor>
<author fullname='W. Polk' initials='W.' surname='Polk'><organization/></author>
<date month='May' year='2008'/>
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificat
e revocation list (CRL) for use in the Internet. An overview of this approach a
nd model is provided as an introduction. The X.509 v3 certificate format is des
cribed in detail, with additional information regarding the format and semantics
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 sta
ndard and Internet-specific extensions. An algorithm for X.509 certification pa
th validation is described. An ASN.1 module and examples are provided in the ap
pendices. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>
<reference anchor='RFC5652' target='https://www.rfc-editor.org/info/rfc5652'>
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></a
uthor>
<date month='September' year='2009'/>
<abstract><t>This document describes the Cryptographic Message Syntax (CMS). Th
is syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary
message content. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='70'/>
<seriesInfo name='RFC' value='5652'/>
<seriesInfo name='DOI' value='10.17487/RFC5652'/>
</reference>
<reference anchor='RFC6066' target='https://www.rfc-editor.org/info/rfc6066'>
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organiz
ation/></author>
<date month='January' year='2011'/>
<abstract><t>This document provides specifications for existing TLS extensions.
It is a companion document for RFC 5246, &quot;The Transport Layer Security (TL
S) Protocol Version 1.2&quot;. The extensions specified are server_name, max_fr
agment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and stat
us_request. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6066'/>
<seriesInfo name='DOI' value='10.17487/RFC6066'/>
</reference>
<reference anchor='RFC6234' target='https://www.rfc-editor.org/info/rfc6234'>
<front>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organiz
ation/></author>
<author fullname='T. Hansen' initials='T.' surname='Hansen'><organization/></aut
hor>
<date month='May' year='2011'/>
<abstract><t>Federal Information Processing Standard, FIPS</t></abstract>
</front>
<seriesInfo name='RFC' value='6234'/>
<seriesInfo name='DOI' value='10.17487/RFC6234'/>
</reference>
<reference anchor='RFC6960' target='https://www.rfc-editor.org/info/rfc6960'>
<front>
<title>X.509 Internet Public Key Infrastructure Online Certificate Status Protoc
ol - OCSP</title>
<author fullname='S. Santesson' initials='S.' surname='Santesson'><organization/
></author>
<author fullname='M. Myers' initials='M.' surname='Myers'><organization/></autho
r>
<author fullname='R. Ankney' initials='R.' surname='Ankney'><organization/></aut
hor>
<author fullname='A. Malpani' initials='A.' surname='Malpani'><organization/></a
uthor>
<author fullname='S. Galperin' initials='S.' surname='Galperin'><organization/><
/author>
<author fullname='C. Adams' initials='C.' surname='Adams'><organization/></autho
r>
<date month='June' year='2013'/>
<abstract><t>This document specifies a protocol useful in determining the curren
t status of a digital certificate without requiring Certificate Revocation Lists
(CRLs). Additional mechanisms addressing PKIX operational requirements are spec
ified in separate documents. This document obsoletes RFCs 2560 and 6277. It al
so updates RFC 5912.</t></abstract>
</front>
<seriesInfo name='RFC' value='6960'/>
<seriesInfo name='DOI' value='10.17487/RFC6960'/>
</reference>
<reference anchor='RFC6979' target='https://www.rfc-editor.org/info/rfc6979'>
<front>
<title>Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic
Curve Digital Signature Algorithm (ECDSA)</title>
<author fullname='T. Pornin' initials='T.' surname='Pornin'><organization/></aut
hor>
<date month='August' year='2013'/>
<abstract><t>This document defines a deterministic digital signature generation
procedure. Such signatures are compatible with standard Digital Signature Algor
ithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signat
ures and can be processed with unmodified verifiers, which need not be aware of
the procedure described therein. Deterministic signatures retain the cryptograp
hic security features associated with digital signatures but can be more easily
implemented in various environments, since they do not need access to a source o
f high-quality randomness.</t></abstract>
</front>
<seriesInfo name='RFC' value='6979'/>
<seriesInfo name='DOI' value='10.17487/RFC6979'/>
</reference>
<reference anchor='RFC7231' target='https://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author fullname='R. Fielding' initials='R.' role='editor' surname='Fielding'><o
rganization/></author>
<author fullname='J. Reschke' initials='J.' role='editor' surname='Reschke'><org
anization/></author>
<date month='June' year='2014'/>
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application
- level protocol for distributed, collaborative, hypertext information systems.
This document defines the semantics of HTTP/1.1 messages, as expressed by reque
st methods, request header fields, response status codes, and response header fi
elds, along with the payload of messages (metadata and body content) and mechani
sms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>
<reference anchor='RFC7633' target='https://www.rfc-editor.org/info/rfc7633'>
<front>
<title>X.509v3 Transport Layer Security (TLS) Feature Extension</title>
<author fullname='P. Hallam-Baker' initials='P.' surname='Hallam-Baker'><organiz
ation/></author>
<date month='October' year='2015'/>
<abstract><t>The purpose of the TLS feature extension is to prevent downgrade at
tacks that are not otherwise prevented by the TLS protocol. In particular, the
TLS feature extension may be used to mandate support for revocation checking fea
tures in the TLS protocol such as Online Certificate Status Protocol (OCSP) stap
ling. Informing clients that an OCSP status response will always be stapled per
mits an immediate failure in the case that the response is not stapled. This in
turn prevents a denial-of-service attack that might otherwise be possible.</t><
/abstract>
</front>
<seriesInfo name='RFC' value='7633'/>
<seriesInfo name='DOI' value='10.17487/RFC7633'/>
</reference>
<reference anchor='RFC7807' target='https://www.rfc-editor.org/info/rfc7807'>
<front>
<title>Problem Details for HTTP APIs</title>
<author fullname='M. Nottingham' initials='M.' surname='Nottingham'><organizatio
n/></author>
<author fullname='E. Wilde' initials='E.' surname='Wilde'><organization/></autho
r>
<date month='March' year='2016'/>
<abstract><t>This document defines a &quot;problem detail&quot; as a way to carr
y machine- readable details of errors in a HTTP response to avoid the need to de
fine new error response formats for HTTP APIs.</t></abstract>
</front>
<seriesInfo name='RFC' value='7807'/>
<seriesInfo name='DOI' value='10.17487/RFC7807'/>
</reference>
<reference anchor='RFC8032' target='https://www.rfc-editor.org/info/rfc8032'>
<front>
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'><organization/
></author>
<author fullname='I. Liusvaara' initials='I.' surname='Liusvaara'><organization/
></author>
<date month='January' year='2017'/>
<abstract><t>This document describes elliptic curve signature scheme Edwards-cur
ve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with reco
mmended parameters for the edwards25519 and edwards448 curves. An example imple
mentation and test vectors are provided.</t></abstract>
</front>
<seriesInfo name='RFC' value='8032'/>
<seriesInfo name='DOI' value='10.17487/RFC8032'/>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
r>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='RFC8259' target='https://www.rfc-editor.org/info/rfc8259'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author fullname='T. Bray' initials='T.' role='editor' surname='Bray'><organizat
ion/></author>
<date month='December' year='2017'/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, lan
guage-independent data interchange format. It was derived from the ECMAScript P
rogramming Language Standard. JSON defines a small set of formatting rules for
the portable representation of structured data.</t><t>This document removes inco
nsistencies with other specifications of JSON, repairs specification errors, and
offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='STD' value='90'/>
<seriesInfo name='RFC' value='8259'/>
<seriesInfo name='DOI' value='10.17487/RFC8259'/>
</reference>
<reference anchor='RFC8391' target='https://www.rfc-editor.org/info/rfc8391'> <reference anchor="FIPS186-4" target="http://nvlpubs.nist.gov/nistpubs/F
<front> IPS/NIST.FIPS.186-4.pdf">
<title>XMSS: eXtended Merkle Signature Scheme</title> <front>
<author fullname='A. Huelsing' initials='A.' surname='Huelsing'><organization/>< <title>Digital Signature Standard (DSS)</title>
/author> <author>
<author fullname='D. Butin' initials='D.' surname='Butin'><organization/></autho <organization>National Institute of Standards and Technology</orga
r> nization>
<author fullname='S. Gazdag' initials='S.' surname='Gazdag'><organization/></aut </author>
hor> <date year="2013" month="July"/>
<author fullname='J. Rijneveld' initials='J.' surname='Rijneveld'><organization/ </front>
></author> <seriesInfo name="FIPS PUB" value="186-4"/>
<author fullname='A. Mohaisen' initials='A.' surname='Mohaisen'><organization/>< </reference>
/author>
<date month='May' year='2018'/>
<abstract><t>This note describes the eXtended Merkle Signature Scheme (XMSS), a
hash-based digital signature system that is based on existing descriptions in sc
ientific literature. This note specifies Winternitz One-Time Signature Plus (WO
TS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a mu
lti-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building bl
ock. XMSS provides cryptographic digital signatures without relying on the conje
ctured hardness of mathematical problems. Instead, it is proven that it only re
lies on the properties of cryptographic hash functions. XMSS provides strong se
curity guarantees and is even secure when the collision resistance of the underl
ying hash function is broken. It is suitable for compact implementations, is re
latively simple to implement, and naturally resists side-channel attacks. Unlike
most other signature systems, hash-based signatures can so far withstand known
attacks using quantum computers.</t></abstract>
</front>
<seriesInfo name='RFC' value='8391'/>
<seriesInfo name='DOI' value='10.17487/RFC8391'/>
</reference>
<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'> <reference anchor="UNIXTIME" target="http://pubs.opengroup.org/onlinepub
<front> s/9699919799.2016edition/basedefs/V1_chap04.html#tag_04_16">
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <front>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/>< <title>The Open Group Base Specifications Issue 7</title>
/author> <author>
<date month='August' year='2018'/> <organization>IEEE</organization>
<abstract><t>This document specifies version 1.3 of the Transport Layer Security </author>
(TLS) protocol. TLS allows client/server applications to communicate over the <date year="2016"/>
Internet in a way that is designed to prevent eavesdropping, tampering, and mess </front>
age forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs <seriesInfo name="IEEE Std" value="1003.1-2008"/>
5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 <refcontent>Section 4.16 Seconds Since the Epoch</refcontent>
implementations.</t></abstract> </reference>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>
<reference anchor="HTML401" target="http://www.w3.org/TR/1999/REC-html401-199912 <reference anchor="X690">
24"> <front>
<front> <title>Information technology - ASN.1 encoding rules: Specification
<title>HTML 4.01 Specification</title> of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
<author initials="D." surname="Raggett" fullname="David Raggett"> Encoding Rules (DER)</title>
<organization></organization> <author>
</author> <organization>ITU-T</organization>
<author initials="A." surname="Le Hors" fullname="Arnaud Le Hors"> </author>
<organization></organization> <date year="2021" month="February"/>
</author> </front>
<author initials="I." surname="Jacobs" fullname="Ian Jacobs"> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<organization></organization> <seriesInfo name="ISO/IEC" value="8825-1"/>
</author> </reference>
<date year="1999" month="December" day="24"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-html401
-19991224"/>
</reference>
<reference anchor="FIPS186-4" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST
.FIPS.186-4.pdf">
<front>
<title>FIPS PUB 186-4</title>
<author >
<organization>NIST</organization>
</author>
<date year="2013" month="July" day="01"/>
</front>
</reference>
<reference anchor="UNIXTIME" target="http://pubs.opengroup.org/onlinepubs/969991
9799.2016edition/basedefs/V1_chap04.html#tag_04_16">
<front>
<title>The Open Group Base Specifications Issue 7 IEEE Std 1003.1-2008, 2016
Edition</title>
<author >
<organization>IEEE</organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="X690" >
<front>
<title>Information technology - ASN.1 encoding Rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding
Rules (DER)</title>
<author >
<organization>ITU-T</organization>
</author>
<date year="2015" month="November"/>
</front>
<seriesInfo name="ISO/IEC" value="8825-1:2002"/>
</reference>
<reference anchor='RFC3553' target='https://www.rfc-editor.org/info/rfc3553'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.3553.xml"/>
<title>An IETF URN Sub-namespace for Registered Protocol Parameters</title> </references>
<author fullname='M. Mealling' initials='M.' surname='Mealling'><organization/>< <references>
/author> <name>Informative References</name>
<author fullname='L. Masinter' initials='L.' surname='Masinter'><organization/>< <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
/author> FC.6962.xml"/>
<author fullname='T. Hardie' initials='T.' surname='Hardie'><organization/></aut <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
hor> FC.8126.xml"/>
<author fullname='G. Klyne' initials='G.' surname='Klyne'><organization/></autho <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
r> FC.8820.xml"/>
<date month='June' year='2003'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<abstract><t>This document describes a new sub-delegation for the 'ietf' URN nam FC.5912.xml"/>
espace for registered protocol items. The 'ietf' URN namespace is defined in RF <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
C 2648 as a root for persistent URIs that refer to IETF- defined resources. Thi FC.6268.xml"/>
s document specifies an Internet Best Current Practices for the Internet Communi
ty, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='73'/>
<seriesInfo name='RFC' value='3553'/>
<seriesInfo name='DOI' value='10.17487/RFC3553'/>
</reference>
</references> <reference anchor="CrosbyWallach" target="http://static.usenix.org/event
/sec09/tech/full_papers/crosby.pdf">
<front>
<title>Efficient Data Structures for Tamper-Evident Logging</title>
<author initials="S." surname="Crosby" fullname="Scott A. Crosby">
<organization/>
</author>
<author initials="D." surname="Wallach" fullname="Dan S. Wallach">
<organization/>
</author>
<date year="2009" month="August"/>
</front>
<refcontent>Proceedings of the 18th USENIX Security Symposium, Montrea
l</refcontent>
</reference>
<references title='Informative References'> <reference anchor="Chromium.Policy" target="https://googlechrome.github.
io/CertificateTransparency/ct_policy.html">
<front>
<title>Chromium Certificate Transparency Policy</title>
<author>
<organization>The Chromium Projects</organization>
</author>
</front>
</reference>
<reference anchor='RFC6962' target='https://www.rfc-editor.org/info/rfc6962'> <reference anchor="JSON.Metadata" target="https://www.gstatic.com/ct/log
<front> _list/log_list_schema.json">
<title>Certificate Transparency</title> <front>
<author fullname='B. Laurie' initials='B.' surname='Laurie'><organization/></aut <title>Chromium Log Metadata JSON Schema</title>
hor> <author>
<author fullname='A. Langley' initials='A.' surname='Langley'><organization/></a <organization>The Chromium Projects</organization>
uthor> </author>
<author fullname='E. Kasper' initials='E.' surname='Kasper'><organization/></aut </front>
hor> </reference>
<date month='June' year='2013'/>
<abstract><t>This document describes an experimental protocol for publicly loggi
ng the existence of Transport Layer Security (TLS) certificates as they are issu
ed or observed, in a manner that allows anyone to audit certificate authority (C
A) activity and notice the issuance of suspect certificates as well as to audit
the certificate logs themselves. The intent is that eventually clients would re
fuse to honor certificates that do not appear in a log, effectively forcing CAs
to add all issued certificates to the logs.</t><t>Logs are network services that
implement the protocol operations for submissions and queries that are defined
in this document.</t></abstract>
</front>
<seriesInfo name='RFC' value='6962'/>
<seriesInfo name='DOI' value='10.17487/RFC6962'/>
</reference>
<reference anchor='RFC8126' target='https://www.rfc-editor.org/info/rfc8126'> <reference anchor="Chromium.Log.Policy" target="https://googlechrome.git
<front> hub.io/CertificateTransparency/log_policy.html">
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <front>
<author fullname='M. Cotton' initials='M.' surname='Cotton'><organization/></aut <title>Chromium Certificate Transparency Log Policy</title>
hor> <author>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho <organization>The Chromium Projects</organization>
r> </author>
<author fullname='T. Narten' initials='T.' surname='Narten'><organization/></aut </front>
hor> </reference>
<date month='June' year='2017'/>
<abstract><t>Many protocols make use of points of extensibility that use constan
ts to identify various protocol parameters. To ensure that the values in these
fields do not have conflicting uses and to promote interoperability, their alloc
ations are often coordinated by a central record keeper. For IETF protocols, th
at role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To ma
ke assignments in a given registry prudently, guidance describing the conditions
under which new values should be assigned, as well as when and how modification
s to existing values can be made, is needed. This document defines a framework
for the documentation of these guidelines by specification authors, in order to
assure that the provided guidance for the IANA Considerations is clear and addre
sses the various issues that are likely in the operation of a registry.</t><t>Th
is is the third edition of this document; it obsoletes RFC 5226.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>
<reference anchor='RFC8820' target='https://www.rfc-editor.org/info/rfc8820'> <reference anchor="CABBR" target="https://cabforum.org/wp-content/upload
<front> s/CA-Browser-Forum-BR-1.7.3.pdf">
<title>URI Design and Ownership</title> <front>
<author fullname='M. Nottingham' initials='M.' surname='Nottingham'><organizatio <title>Baseline Requirements for the Issuance and Management of Publ
n/></author> icly-Trusted Certificates</title>
<date month='June' year='2020'/> <author>
<abstract><t>Section 1.1.1 of RFC 3986 defines URI syntax as &quot;a federated a <organization>CA/Browser Forum</organization>
nd extensible naming system wherein each scheme's specification may further rest </author>
rict the syntax and semantics of identifiers using that scheme.&quot; In other <date month="October" year="2020"/>
words, the structure of a URI is defined by its scheme. While it is common for s </front>
chemes to further delegate their substructure to the URI's owner, publishing ind <seriesInfo name="Version" value="1.7.3"/>
ependent standards that mandate particular forms of substructure in URIs is ofte </reference>
n problematic.</t><t>This document provides guidance on the specification of URI
substructure in standards.</t><t>This document obsoletes RFC 7320 and updates R
FC 3986.</t></abstract>
</front>
<seriesInfo name='BCP' value='190'/>
<seriesInfo name='RFC' value='8820'/>
<seriesInfo name='DOI' value='10.17487/RFC8820'/>
</reference>
<reference anchor="CrosbyWallach" target="http://static.usenix.org/event/sec09/t <reference anchor="X.680">
ech/full_papers/crosby.pdf"> <front>
<front> <title>Information technology - Abstract Syntax Notation One (ASN.1)
<title>Efficient Data Structures for Tamper-Evident Logging</title> : Specification of basic notation</title>
<author initials="S." surname="Crosby" fullname="Scott A. Crosby"> <author>
<organization></organization> <organization>ITU-T</organization>
</author> </author>
<author initials="D." surname="Wallach" fullname="Dan S. Wallach"> <date year="2021" month="February"/>
<organization></organization> </front>
</author> <seriesInfo name="ITU-T Recommendation" value="X.680"/>
<date year="2009" month="August"/> </reference>
</front>
<seriesInfo name="Proceedings of the 18th USENIX Security Symposium," value="M
ontreal"/>
</reference>
<reference anchor="Chromium.Policy" target="http://www.chromium.org/Home/chromiu
m-security/certificate-transparency">
<front>
<title>Chromium Certificate Transparency</title>
<author >
<organization>The Chromium Projects</organization>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="JSON.Metadata" target="https://www.gstatic.com/ct/log_list/lo
g_list_schema.json">
<front>
<title>Chromium Log Metadata JSON Schema</title>
<author >
<organization>The Chromium Projects</organization>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="Chromium.Log.Policy" target="http://www.chromium.org/Home/chr
omium-security/certificate-transparency/log-policy">
<front>
<title>Chromium Certificate Transparency Log Policy</title>
<author >
<organization>The Chromium Projects</organization>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="CABBR" target="https://cabforum.org/wp-content/uploads/CA-Bro
wser-Forum-BR-1.7.3.pdf">
<front>
<title>Baseline Requirements for the Issuance and Management of Publicly-Tru
sted Certificates</title>
<author >
<organization>CA/Browser Forum</organization>
</author>
<date year="2020"/>
</front>
<format type="PDF" target="https://cabforum.org/wp-content/uploads/CA-Browser-
Forum-BR-1.7.3.pdf"/>
</reference>
</references>
</references> </references>
<section anchor="v1_coexistence" title="Supporting v1 and v2 simultaneously (Inf <section anchor="v1_coexistence" numbered="true" toc="default">
ormative)"> <name>Supporting v1 and v2 Simultaneously (Informative)</name>
<t>Certificate Transparency logs have to be either v1 (conforming to <xref
<t>Certificate Transparency logs have to be either v1 (conforming to <xref targe target="RFC6962" format="default"/>) or
t="RFC6962"></xref>) or v2 (conforming to this document), as the data structures are incompatible, and s
v2 (conforming to this document), as the data structures are incompatible and so o
a v2 log could not issue a valid v1 SCT.</t> a v2 log could not issue a valid v1 SCT.</t>
<t>CT clients, however, can support v1 and v2 SCTs for the same certificat
<t>CT clients, however, can support v1 and v2 SCTs, for the same certificate, e
simultaneously, as v1 SCTs are delivered in different TLS, X.509 and OCSP simultaneously, as v1 SCTs are delivered in different TLS, X.509, and OCSP
extensions than v2 SCTs.</t> extensions than v2 SCTs.</t>
<t>v1 and v2 SCTs for X.509 certificates can be validated independently. F
<t>v1 and v2 SCTs for X.509 certificates can be validated independently. For or
precertificates, v2 SCTs should be embedded in the TBSCertificate before precertificates, v2 SCTs should be embedded in the TBSCertificate before
submission of the TBSCertificate (inside a v1 precertificate, as described in submission of the TBSCertificate (inside a v1 precertificate, as described in
Section 3.1. of <xref target="RFC6962"></xref>) to a v1 log so that TLS clients <xref target="RFC6962" sectionFormat="of" section="3.1"/>) to a v1 log so that T
conforming to LS clients conforming to
<xref target="RFC6962"></xref> but not this document are oblivious to the embedd <xref target="RFC6962" format="default"/> but not this document are oblivious to
ed v2 SCTs. An issuer the embedded v2 SCTs. An issuer
can follow these steps to produce an X.509 certificate with embedded v1 and v2 can follow these steps to produce an X.509 certificate with embedded v1 and v2
SCTs:</t> SCTs:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Create a CMS precertificate, as described in <xref target="precertif
<t>Create a CMS precertificate as described in <xref target="precertificates"/ icates"
> and submit it format="default"/>, and submit it to v2 logs.</li>
to v2 logs.</t> <li>Embed the obtained v2 SCTs in the TBSCertificate, as described in
<t>Embed the obtained v2 SCTs in the TBSCertificate, as described in <xref target="cert_transinfo_extension" format="default"/>.</li>
<xref target="cert_transinfo_extension"/>.</t> <li>Use that TBSCertificate to create a v1 precertificate, as described
<t>Use that TBSCertificate to create a v1 precertificate, as described in in
Section 3.1. of <xref target="RFC6962"></xref> and submit it to v1 logs.</t> <xref target="RFC6962" sectionFormat="of" section="3.1"/>, and submit it
<t>Embed the v1 SCTs in the TBSCertificate, as described in Section 3.3 of to v1
<xref target="RFC6962"></xref>.</t> logs.</li>
<t>Sign that TBSCertificate (which now contains v1 and v2 SCTs) to issue the <li>Embed the v1 SCTs in the TBSCertificate, as described in
final X.509 certificate.</t> <xref target="RFC6962" sectionFormat="of" section="3.3"/>.</li>
</list></t> <li>Sign that TBSCertificate (which now contains v1 and v2 SCTs) to issu
e the
</section> final X.509 certificate.</li>
<section anchor="asn1_module" title="An ASN.1 Module (Informative)"> </ul>
</section>
<t>The following ASN.1 module may be useful to implementors.</t> <section anchor="asn1_module" numbered="true" toc="default">
<name>An ASN.1 Module (Informative)</name>
<figure><artwork><![CDATA[ <t>The following ASN.1 <xref target="X.680" format="default"/> module may
be useful to implementors. This module references <xref target="RFC5912" format=
"default"/> and <xref target="RFC6268" format="default"/>.</t>
<sourcecode type="asn.1"><![CDATA[
CertificateTransparencyV2Module-2021 CertificateTransparencyV2Module-2021
-- { id-mod-public-notary-v2 from above, in -- { id-mod-public-notary-v2 from above, in
iso(1) identified-organization(3) ... iso(1) identified-organization(3) ...
form } form }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
IMPORTS IMPORTS
EXTENSION EXTENSION
skipping to change at line 3048 skipping to change at line 2928
IDENTIFIED BY id-ce-embeddedSCT-CTv1 IDENTIFIED BY id-ce-embeddedSCT-CTv1
CRITICALITY { FALSE } } CRITICALITY { FALSE } }
id-ce-embeddedSCT-CTv1 OBJECT IDENTIFIER ::= { id-ce-embeddedSCT-CTv1 OBJECT IDENTIFIER ::= {
1 3 6 1 4 1 11129 2 4 2 } 1 3 6 1 4 1 11129 2 4 2 }
SignedCertificateTimestampList ::= OCTET STRING SignedCertificateTimestampList ::= OCTET STRING
END END
]]></artwork></figure> ]]></sourcecode>
</section>
</section> <section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Erwann Abelea"/>, <c
ontact
fullname="Robin Alden"/>, <contact fullname="Andrew Ayer"/>, <contact full
name="Richard
Barnes"/>, <contact fullname="Al Cutter"/>, <contact fullname="David Drysd
ale"/>,
<contact fullname="Francis Dupont"/>, <contact fullname="Adam Eijdenberg"/
>, <contact
fullname="Stephen Farrell"/>, <contact fullname="Daniel Kahn Gillmor"/>, <
contact
fullname="Paul Hadfield"/>, <contact fullname="Brad Hill"/>, <contact full
name="Jeff
Hodges"/>, <contact fullname="Paul
Hoffman"/>, <contact fullname="Jeffrey Hutzelman"/>, <contact fullname="Ka
t Joyce"/>,
<contact fullname="Emilia Kasper"/>, <contact fullname="Stephen Kent"/>, <
contact
fullname="Adam Langley"/>, <contact fullname="SM"/>, <contact fullname="Al
exey
Melnikov"/>, <contact fullname="Linus
Nordberg"/>, <contact fullname="Chris Palmer"/>, <contact fullname="Trevor
Perrin"/>,
<contact fullname="Pierre Phaneuf"/>, <contact fullname="Eric Rescorla"/>,
<contact
fullname="Rich Salz"/>, <contact fullname="Melinda Shore"/>, <contact full
name="Ryan
Sleevi"/>, <contact fullname="Martin Smith"/>, <contact fullname="Carl Wal
lace"/>,
and <contact fullname="Paul Wouters"/> for their valuable contributions.</
t>
<t>A big thank you to Symantec for kindly donating the OIDs from the 1.3.1
01 arc
that are used in this document.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIALh5LmEAA+y9aVsbWbYu+D1+RVzyeTqhSpIBD2mTWdmXxLjMKU9tcFad
znSjQAogCkmhowiBKdv3t/d617CHiBDgnE7dfppzKg1SxJ73mte7+v1+Uhf1
JN9J1/byRV2cFqOsztOjRTar5tkin42u0x/zRVWUs3R7sLmWjMvRLJvS8+NF
dlr3i7w+7dd4ur84HT168mi7f1JU/QfbSXlSlZO8zqudFB8naPesXFzvpPmH
eZIU8wX1WS+WVb29uflkc3stoe6ynfQwHy0XRX2dXJ3tpEdvd18dputvlieT
YpS+KutscR0NbiNJqjqbjY+zSTmjUV3nVVJNs0V9/F/LkjsvT0+TebGT/lSX
o15alYt6kZ9W9Nv1FL+8T5JsWZ+Xi50k7Scp/cj0fshn6YuMRpLzh+WCRvPX
sjyb5Om7v6Uv6vGAP89OThb5pX3FH+XTrJjspCf5bPI/z/jjwaicxq3vjrMp
NT+jL69b7R/MRrc1np2tbnt/WkyKLP1bVs3zRavxw6ui/le+mNCapX+dnjy/
paP8gptZ3RntRfoyr6p8UfzChcqpienKDt6WJ+khHbDxpJid+R7olNTFWdlu
X78IO1iUJ/+zko+5/WRWLqZZXVzmtOfp22d721tbT/TX+08eP9JfHzx68Fh/
fbj94JH79fGm/fro4bb++mjzkT3waPv+A/v1yaNN9+s31sU32/e37NdH9+/b
r483v9FfH2/et3Yfb31jjT3efmgtPL7/xFp4/EBG9vzo5YsHm/xpmtItOcvr
nfS8ruc79+5dXV0Nru4PaN3uHb29t/XkyZN7b/f3+uf1dEKv9PHB1vb2A3lV
iAGaSx8MNrfSw3k+EqpAJEBW2q4L//T13zQtZnTbng7St9kZ9V67z2Ufn2aX
xbjxXePd3UH6Ik+fl4uq8e7uYpYtx40vGy8fDNL/yEZEdBrvHtD5DL4YExXa
STHl/tZ2XyeNw5tXxey0tFmt/b1cTMbp34txnv49P0n3yhkoR7Gcpm9zOkPT
fDbmFVmjE9q9ls8O3hxuPX7Uf9C5J7PLyXx5Ug1mRVUPzsrLe/gFn9zDe/de
HRweDfDbgJsYzMen4fbgm/TNux9S/rZjV/iOoJFg0tubW/f7m9/0N7fow3ev
Dv5xdPByv3NwPLJyns/OFuVyzgennNH9y3mATx5hknSenwyoyUf5uMBC3DvJ
qnxMBPXej1vHo/NsvvlggFX5qs7OjjcfHG89CidwdJ6nr6mD9K/oIf2B3o1P
WpUeVNUyT79JD/b394kCjNOtzc37g60+cYvHPUzmUbovXa+aP96kv//x6Mnm
Ttj52gHtNFMAYmp1PjqflZPy7Drtp7uHrwZbKfGVckzUJn27nICDRAMjfoLh
Ejfajx5L13/Yf7vRS/eyWTmjZyet7/fo+xRk9yltNX2+LKrzfNx67Ck9thZs
26vyMp+e5AtM+eHKqR696x+tOMsHh6/vHezv7aSPiYT0t3ZoAbeJ/9oaOCoI
Lu3IzraRM3qJV29vUVYn13/PJpNsdN55aogP18VosKzyWfGBD01+mc/qe0R6
N5/cwzrfO11OJsfzjBhKdW/EDTZP9v4pLXRBrxHBqDNQ/uWoXi5oYWi46VE2
pXf7+0RK8MiL8uzMuMKNVOlwoONvEIfDUVnXoDvRt22SptNukbQZWg6/tJu2
+aS/+XgVbXmzKEd5jj2vcJpqugtbj+vz9N3hPt1KJwClh9fTeVkRzekRlXlZ
zkhwySbYivNFOaWPB29KkoquV9L8kT2HvXheTvN79km/0j7ujbzQJ2KcylXh
nlh/6SoJcdWpxC13L9Os/0lMuIrWaQvE6z8OX78avMzrjD7N2rOpdDpnesCI
/N4b1ffoyh5P6Ca5X46r0Tlx/ME/KyUJzeHTcUmtG+6U9h9v/Mrhu+2g9n/P
LcFE+3Nu/4t2h+f9xr/3K2a6+8MPb7s3aJSd0AXViV3N+yM6rrj8y/mkzMbV
vb3d/g+L8opuQ/8Znuv/8La/NfhmcL9JAL7XcYElgOUQv/2vZbHIiePWQgRw
X8AcstkoZ3r6MptlZ/wAXSd9XTSGyXX/CBoGkdlgdapVy7C3e08HmfIgoxXY
3uQ/hWraa2+ePvut1iDp9/skxVa05aM6SY7OiyolZWvJ8xrn1WhRnBAZvPTK
mBGPlRu/vne0kcwXJWk+5YTXbq7Lkk6EdPL7+Qe6PTlWkxqUBkjWIfXkmhbC
UaP1oxeHGwkNnkaQBme0SrMKzVyn1GtagGuPaTlTkrjw7LhHVDTN0mk2m+XY
vKxOiWDSMiTZ7Jp0trQuaS+IkweNYoKyP9zz3i4xTpLfL/EXdnxWEiHIefCF
nQTa+mpJusqobo3uKp9MeJTWE14MHsJq8BymdOYu82qAC0EcErtHHcigmZkt
aejX6WhS8Gm8KpckJJIWSTwPjZ+XpFnEvfOr4xIjTrL5PM8WshzUYy/NT0+h
llzm1Cbtzggbsrcr4xyPsUy2nnGbJcaaYNCD5kFxWjd4NyveA5IAsORVmVYi
yGBR0ll+ldKO0ubTLPlE8VCLKqHJjNEH8fFxepktinJZpXtHGDJtMQ2DtgId
v8CiYc9neX1VLi7A6i5pW3TSxXQ+kUuJ1XankMTKhUp4OJDV8mRKc8TfCXb2
v5bML/WcUOMkUhIVGGPV6nCmNICff8IcIQTSPU6pN0iRyzkubPo1ffUP+vka
M6EdwtEr4xZ6SYlzU9SyVrMlS1n0wMWsvJr16GGSTc/Oefiu1zTdpZXs8Yev
D54mGY39DOM7yelMp1MiNrLWfrPxKP6ajYsPOIUF/YKNHA/Sn98ncu+nxXhM
WnHyFSn/9aIck9ADwTZZebWzYsoHYUoS8Bm+1UU+oTXHNaZF7Tg6yck1HiLx
CUdNBtUn0f5abgC91/ES3wZ5QA5ycFOIuvC9sP5wE3vpybIWikAni2Q3PQ90
nUiOAy2e4xhB1uVfRstJtqAh0HWv8gSiFe92OISNdESy1pjONd3uajk6D/sb
wC6knfAGFzjfZzmRGxKXpiR3ZqRcTeWBEV/ZEzonOOXMTtyy1gFdJNrEpB5r
clLMYHaC2NAjGnMC7sgXhPh3ekHbyQs3G02WfI+IUNNMi2xAe9k4cUSJUl5u
o+cJTh+ohyfOfCu7yOx6McgH1MR5vlDS1+oy4alfZpMi2kLbVdr9zHq5idhu
DJLdtL6esxrDF7Aw1WdNXl/jDTnBuJcz3q6fWDh4T9dyn4RhJhbgfxmJ0NFQ
aDfoI0yjoMe0FaYCda1DZLYwANUiapR/AEkHRcL26eBBJK8KIo/ogtZxSQ2D
WtKqFAuQNlribsqZgOPQWk/LhZzpb4lqX9EZXvSiYZ6XkzFxWh4g3+egJ+mF
aETSNbFMXqKNX7iTzkehXIyFCmWXJe0PX6iTHIeNzh59lY9BekkHrLAK2GBP
HLH0E4hcSqb4rlbzpRDncI7EbnndFiI26brl2BMeId3JMRaP9I0sZfMrLfjo
vFwY/SdOO8rnuhe13HycB+zoNLuW1ZgUU2Wjk3x2Rm2pKCJd8Ah4g1jEKLXJ
bxO+urJQAakEn5EBzfTJjMhYNLhB8vfzHHxTO4hHqew0S5UW18WUCA3pinhw
kZP+OIMc4o5cMqGVWjgqQAMUokiiEGuWI+bmuIfG6ZW42ATPM2xdPkvcwR1E
j8sBWKJz3gUn9jSFA0hNPBE6NoncWzA9+qyczolsyfya0xK2T9SSplTyCyOw
MsySJMhyGZFjHsy0nIFL2n7yMb1Q+W9KZ+VMaTDIEIYJ6SDHgceBAl92MyKN
aXQBIkRvLoiyTXkz8Z4sL+YESz5NncRIkiywlefZJf7TuI16Q21tiSoWLNql
cudJs6ZvEvmmlBMi9N2bb3ppxEKucEj4hVOQZVn1cDES7Nw5Mz6WTLGNRG3G
ct1GJJzISQ4FjfS5EYiTBcnx1A3JURlWryeDw9oUs8vyQkVprOsJEeYZrrLj
P7JIY1Lh8T3PxjHpJL7BfE0gt5JU5R5mSX8XB5MUr5YES2yY+qcplYtE2qZ9
AfVVWhHddGjLVdgStUsaVnmJc/z6FExyUeU9pcQJDtlVZue6eZRwPGglT2Xd
SQwqaLFwUyP+A2ZVLha0rZPrRCZNQlR2kbNgDw6k16HKiakUEO8OicbwtvZE
NODDzieJnpm1L0V6SgosGJw7EcKFaMx835Mx6fq01RluOy1JxLT5XT4vIHfp
wanND2NfzoQgeTqBE5KslwsoN+M8dwuQ8iRx8FnCaqwBaXeQlbgvXcbqa3pl
DmGI9Bfrf6PniLEjSEpg3TJ6Qdq+4oEfMY2iKwq7mH8EnVfXMxgbZuAYoMlQ
wjyB47nBLMWnDTRknE8yWnsSVeYkXSTzspLLzLtXuUNq0j+RoFkeKmkY02V2
li1kdrSri/yKehXqlUfiJ/VNY6UX6bnc5Aem8uc4TuMU1wnWm8XFBJJwnoci
RBJQ8twMiNLqpdFekueCg0E0q86CZbXuiKDDOJnDktB8B6Ius1v3Ms8y7lJl
VFWbErrhJzmd2aJcVGFf6/ngbNDjpWRps825mBJHBwjzgIAHCkl8pyLW4mXW
fExCW8IiE+0IKWEVRFaoPIvc+D8rcJWxfaa8JqPQPp/ko4z1WBliwpoyBhdQ
MBNb2+qYSXKjYkEfQCVQ1uyXgJrCCHg7KhK66OWCFOAFC8Y418QsKla5L4v8
SrSRmgSiU0zDPZroiQV3KOgsBKMD1xGBakxnZkInaqyq9AKUmCZG+gX1vKiJ
u7L1VY/pIsdIWSrD7Ge5vEii5gzkXmgns02RYBp90mWphCis5CGk2X0VW7Lg
/F1mZ7nchQuifHSLSDJbe/nu8GitJ/+mr17z72/3/693B2/3n+L3w+e7L164
X+yJw+ev372g7xP9zb+59/rly/1XT+Vl+jRtfPRy9z/XhMevvX5zdPD61e6L
NdvexG0v5oklyUWPo7uADc4aR+KHvTfp1oP048f/oV7Vz5/1DzgyP39OwKCl
M7728qeIQd44AjEpI5pDwiGL0zgsJHPRNsk6Nj0DH7+CanZcuU8+Jwk/4z+J
TAnonn08+J0krcVYxVQh4DOcXjZQTDI6EbS7CY2K/cpESe9jc39Sz+v7lv2F
bhCdXFER2UkBewvd/fXXB09JjaVO9FMxy9KH6Tqxs+TjR5ixi/Hnzxs91eXz
8PLvvTxMh/meWBSPruf5kN+j1Y0frNAAW1L+MXi4+eTyvjfwVE2t2lrAZ8es
BkOyOnYvUFNYq+T13uEbE+f8W+Womq94S9gQZtw04RCtzhYjoQFX2FrSd1i7
Gy/5fEEd5hvqnHCy5S+zfxI9fKpEADYmZqJ7R+nWYLO5B6DTGCgfM2cPYzmH
n+ftg2nsvTNL9RDOcoVjUM5ot4kan9NIzjIed9AVzWU+Ka/lCssxTk+JXJxk
JBSrDIEzNJ0uib1fiyFxyoMHyTiTk7iTJP30eVadcxMg/RlOKZ38Myjh5yTF
nBUTen8nJW6kmrH7Uo1uxLzNnjdO4KpKD3ZfQY47IyoKnjtAL2/iY6TW68bp
8i3imMnpJd0lYxGf9momh4l6ieVUYcBMOCsi2iWJWWZTDjuFCyybmIGNFgaM
iygytbfwJDENLtmDwdZge7BtVw0xF+95Om9FSm3eDixhQ95yxL357LwsxEHk
TuyOaXa0P+hy3rVmRPTpqDtlhRilrBnxBXoNcTZgGyRAY5hsGqXjvxMJM1hg
RxPU1IFbEq20Kt3nOB3CAalpNXsQlxjwC5DdzE+OYUzZA2JNhufgmsczZNvh
QZ1Ph54o7giPgqo3jqgli7wmTs2IFFdLCNAkslaI3KiJ+jB3piuBFwfpbtDB
C+p12EuVm/ONIlE7MLoEY6HGPInumQjBXZPsZYYuWvDhIYtHgTX0yAQl7g+0
hBrjN2GLsvvNk1ehkQQhWCtIf6hkw4fyBYTJF3l2GqyM0+9pFeeTbORsIdRH
51LaVYAFurKDdcJXWK/4dD4Ry7vYTLLTcO5onfUvIUD0ALteIIKqP4h2mufy
biZnBy24y8xyh2sLguNJSRpgeIYxiPhY4wKIgi/nEprQGPs6m8gJPPrhMLQ+
r/N2ZLExz1oocJ88VdXG5PrhvC8igrBhdyTdVXdCuu+Y1E50u674tAnLvuGQ
96h7ve6ijuNNlSggLvOkQF/2jiq2TrPdCR8cPRc6ufvmAJx+TqLcDuj3HEyj
e7PlynmzUnh75Yzg8NdFDfGcpevKqTWuEe6U1O8+XeX+yXUf932H76LItzyg
U3ajQYsXk3Sgr4oKq3PmLiO902Tp0bU9KYp+lU1zVjK4f7Fe9bGL183Oe3r2
uefxuC+GL9af6S86S/KJMRkotniUV5gNENwvLaY3Z1dsP5zLw/JkXZ6JIclM
HK2pNKZcqSYI3Uz1qUAaZ2LhziG1ZaIHm9cbo8ShGKTrzcHLWSExpIaBmfRB
OENFveqD5EVOM6Ukor0dB2f82Glyw4abzdkO0yZ1SYehu/8YYlXjZR7Dj8RO
veHeSQU72BhIUjkdmEksMGD6l3jtOlpScBZe1F7jifD8nJB+D1JIWj5fFxHf
4+ezlJoBb2C2dVZciq3WrhHsTbZbC5L4LjPafyZhxYxunJERnp1SAtLbR6R0
B/FgLLWzrw/CBEwOEA3TvcX1nE7RIpufwzFAXRIBJelMxEYh/SxqsdGAdIXp
eU36wW6KWCTVXuZmRmk+f5OBMPEGwh9o9KewU4nhOzOPEbMcYWN8+2flrM/T
npHuIfaGgM+TBFJMSFWdDRB9QEdNFAEVm+gZ+57frJkdY1cGye5YAuFoXQLb
aMtFw4ETgXuRl/RtriJ1UqnwRT2pznb/ydbnzyyAk9IVuYHQVGCMkWU99q6i
z6LWQvBhjcgtSWuFcZCcASU1o4NoEFicxAvFwt4rkSacLeXrCjSW6FrNepYo
J1Cm/KdQSRo6Au4myVTVOQ/O+AizXO+B4M0JrpFqavj42H+sCg87i8tl3XT5
OWnOT4T2ApYW9tLQ6i/UTlGlz3cPnzu5tSr+ldvRENaEF0+uNagBzx4fHvzf
+7JWfJMSVWLDreGl5lNp15ClPb1z3yq7NU7OXrUTtpOfy7DYC6pSy2VeNXbf
baSMwsZZsUkL4e2JG2drVIP0r0Ip1DcGuUaHOJP5ELF5+vPxLP1L8nH880+b
70lN+/mnLfpnMBjw77P+1vvPve45r788er4h4RvLyiv/VXJacvzJjpxRu4E0
inw6J4GNx1BUkRjuvoRqNTujV/+X/0moo/WPpCz/hTdlnQ5b+G3cizTP7A7n
mHlvus7yCMcdiIWOqQTewQS6ehvTavgeNz9sbqafPqX4tNk7aMks/T7d6lGr
dXoBksDbCXciDWVeXgl5AYGvpiSPmDAzS9TlfJH+/B218fN3f0m3L/gqdSy3
rNKsn2vUB8+Td0/Wcua2YIGQokrCXmg7WpN7ejwLZ7aFmfHnP23uXLzf8H9e
7Mzeb2z04vkyvaUl+1P686efaUnyGfJA2ENGfHkmcez07U73V+xphX8Ezzz9
+aeLrZ0LEmn/kj79+ufj9Yvt/sXWhnuT1xHz/Dj+GueTHhvjFRzUr3FS7YM/
00fEHuXY0jfcTt99v41jzD2LN5X6Sfsp9UTENwxu0HM0yiYwSfsoGr2aEhoF
KV7Mpd8aLYIziOg7KKK5A7x/uGSGTTLaqBQtoZiSnA2DTyF27mgQV7lFgXjf
ZtMLLFydF0Zshll0yuQAUfvLSd2w6rOEyPcVPdCbJ9kEQxgHbnqxEWVzJqBi
TVDD+2LK50ulKc84ZXlI1sM0EO1I8w87RZhBxUIgh3c5QTlTIkATKY2d/xQF
QrMFaV5W2aRHUho7csslPE2OWdJFGk9YyZr1WeSoWQ5x9uzJ9YZy2B8DcUqu
VZ6NlUTuK3n++JUIXcc4B8RkzSsuYvs5046W2DVU4j4UC9Vwc5gu54iFGGIs
x8xn+unWkM/PlfBE2jfpSY4QN5XBHoZ/ZSXOMbwhBD8ezTAxlSgIHHABm7ye
vr+h0GyhxDxlxxxxAogBgdnTLd4apIdEtYZ0EkcXQ2aTnhTTR7R22yIvsYQ1
LJqTTBuTpDYRuEntvlnSVRpG9FMX6qfi/Qb3pd0O5J1tHcs0J8p5PCKxqh6a
2ZimAWJ6mU2WpCujd1OCN8RTJnaMF4c/rBfp9xbkmgZNUY/m3MlrC/PBC0Nn
emIeTL2wuQuSMe35CXyl2hqCTESbgiuhh4a6RytXw16DaAnT7miJWMR0uDWs
VGik6S/4imb16u75iBW2SPcHJFLO4XNq9Ax9SBffNqCc0/mBqdU2LVpuXXJ+
apKfrn7ofnMvmWPgFfzLHTS38765eMXaxYYp5nnMkyfOICnaHb/FCnEe6tE8
P4yCPadjGF/WNWynX9T5lGWlwzqf0zTuIzDjMt9IaTGKiSiZJiJZh2hqkXNA
BQ3xgUhU8gH2IBiWXQeVUkJaxgzCbh1rYmg2uHlikDq3ODgONFnIpSWCnonN
Sm+6zGY+n4iNObztSrS06wOnpb8RLZ0UAv7m2Cmbx6xqsuqlLzWtGeLyVL2Q
fuvSxnhEcBDgtoEqJZA7vP4j7E93LlyXkN9hzhrI1ZJjklMLhapZqt0XxQ36
mjRa60jygq+aDpifKDl8VFsXv0HCr1yVNrDplHRYEjYm1xoxSvdHpay6vMrg
AfSyNukVu7UZjugYLeeJG8F6+Di2ZQMBUDwM54doLrAM7oSZJCRQbo1fcWMm
MfQ0WwxapKSrObUSmEqQGL/hmDU6sDLlVQsv39JE2cyjsRu8lhrfjEmZRCF7
oVEZ/EW0yp3DIy14dK5CWr1YSoM9EUW7nudogSDUi8fCAT1VuPdy8L9K/8oB
prVa5hoXIEluVW2MFqNNU3PSDjUn6VRzmoN/s0sS8VTa2XD3f336560NkstE
IKOGpiSGbrIgP2WZnkOgvGqUxqqRv5aijzKx8vdTzBsSSUh0s+8JlBP/nooQ
rOrbZ743YN4NlYZHv9lLvVrz8fNvpsUIHY3mktjC2JB5aTQy3+3T97RI+kD1
RUqM2wxRZNyfqr/shOoLD2mafpdefMvO1u6XoQ2gAXllJ1KHpIHv/0JPtPXO
HY0TAmlF6qFTaELHbCjw0hp8/Ngw5ny2Mx+IqK0j72VTdzY7BVR4IYpLtum3
TrGFxeCV0PaOfb2e58mwwU2OL7eHG91iq29aFFM5lEPmXcJpErFTNlljwONu
E1Kj8NGcqal2cMUrqV4QkyN8wyLY7gnrhXSTnR4jkOzD0JOzrrl6/wG4sXHp
YAZMI6P26NyeIQTIrkPJYh9z+lg6Hsr5Ps2KibpNsSOXgbFZZG0WgU9nIlCF
PfHiVfpFLHSLxMVvLuR7kyEeBMK7CM/D+dCtWLAEWU3Lmi0W2bUKkZgoeqMJ
EuUgDW0uVL22mDc2U984G2sGUvnpTARwFr7ByE9llqBYbrGoP2EgXosIJxXJ
n3MWPjeGTndo9uREfV53FlP71XlBUiu777h3t6Y8honLXxUpUkWQ5vgxfBs7
aSI60dd4lq5JfoexL3gCNvZnxQx9924bIydziW/pYXC69UhsBh9Rn6GIGYqV
4b7awmMUmz29nUNnIA1eY3LGjwcMHvonKA7fTvPNxYRBz6FfnN4tRyaQefcC
J4mTegPPCVE/fbLljqtcaOLqMEgv9pjAnLTdeiIyt2xxzB5YErCAVwldBK8a
X8JLRYRLfA/yKLGSKbES7fa0WNDOTFUK7bGs8BcVFpzJqzyNhO1klbDtzAgq
VlnjKgVp334D2chdQjiFoQTMewmfU4dPkzMINMkEypREbXJ8mkrZOkIRsBOE
5RT11OJdZQBQz537wQ/XrWAvUN/XMwm8RD8bieOa0kkYvdBsR5Z3kP7deC6n
OjhuwpGd6n0WuU3MWhskSs8KEmbak++SQtsn8ncXQ9ub8ubt69fPYknUn7/w
pCbPm8evl0I07ZZMmwKj60WkpMN3P4Qf9Vjg34jFIVJp7DGZw0lZ0gmfKd8h
7V48wZXLblBlnuXcETNRVers0BaRvc0e7fCPhW/zyjA16/GNtjjeXme/K+62
XljLVrSM1QImTNiHmV/ZdHE1KjHkiT0WqyP01D3SlG9bfhIakKc5U1rzmZPm
wSynRhxkNX1CiDQPgYhO+5mwEs5OklzAdRi3JGrMbCsdK57euOLJbSuOL613
OeMd4/OD6nkf3BftwkbjlMancqqnskO7CdhPvXKpO51cQtNqcevjPtvZvG0o
p9mkkrGIy2W60aFx2VX8ZSqXm0ZRJat0p57GcygnJP63YMLN9g62kNBEDk6V
BV3I+rAc4vbGXJfQbUg9Etsa6+0mR1JvCybvrL7/PQ8TA0TTP+1sDvqVpVdZ
bLpGwJD64NkJbpX2fuOy00qetKgV98JfRHphg3ZhBb63+d86XokyHHlmmioz
tbknbu43r+WqyafR5BPte/Blkw+VWncgI922rc96p05k6fPOJGfpOoEFWxLi
LjnCjtTOyTrJhNvrs42N9M+kgf2+KvJeRxDNEV0V59sJ3Dmx2Njl1QlcLixB
HXtNlr9iXUu+GvbC55OhePa6X5DvhuZu2Ey/UwHtO3UIDoUYnjN9NM29g++7
MCG1d96qygdNBMr8nVVuJ1Z2iMWiXkORiDphFRIMxDxIrE6q7tjWFqEstNVf
tCqrbE19QACjI4bbqoDM4S2YNXZLLZuwpLdHxqMJNGXTsWU/nIPOqdjqsFX9
+kFbwfxS5VK0Sh5dh54qWh1Gpi0srIWF8yvJUEUCMB1+9UQfBbq/T2gyM8Bo
eFsT/4aGgNMubXqE/5wuNoY//2z6u/g0Vz5c/W9gN+gcfcWWg9GvsBx8Q/ru
KaxVKuSxZFObjhNicqw6FlFWEtvJwAF6LUWUN8tCKSSyzG2wfB/cXPOCIYoj
aKK6pYmI9FobKl3CRUqTZ5sEHV01Lux/yDBvYU1x0NyRs7d/Y4HszHCdIxQ/
HDMX/H0P//k5aXwQfXTPfvGf3fPPuw+Dz/ynF2n0M0n00Z/DT+/p42jh5/Bj
bUda/jn8XL45s0nJP4X888/EdaD/2p+fEkQa8q+jdIx/iCbxn+NHSfqJ/o+f
kn/pn2S8mY638PV2Or5P/zxIxw8TJ2x0OSjpDdqtn3866aXnJBi/H9zw6H15
dNRLz2579IE8etpL/9lLL2589JE8WgTPSVg3a/Any2ICwXckWTVM1wvoO8sF
C9VNTZqXl87Mpt8X/Ln1l4ukYyd5c9yeNTZZN62xm9GJ0w0due/cDvs9/eTf
c5vs95V2Sn6CjfZb636CvXab7H6iXU+Cu4GZb6cdP41bdS9tLksw0+bN6niy
dQftgxUPdt3C9r40nw0/WvGoezi6x4X/tfN+34t39+eOX/XP9kmxC7mSGjSO
j9vZVUSiQSP4CuOXVbSjQTpa82iRlAZFcT+rKU2D0Lif2wmQ+1lFmGJtaLUY
LldaJXeO/xWl6z4Mcz998x6aGFOmsSNOIFOs8zREbG5KtAB6eCIAJS7iAmKj
AYadl1fWXRJojcyyuJXBXYa91THsB9GwabQWCMm5/yLNOZQApV/czOROXW53
dPko6rJwhJlU1mLVMm3LMv2TVYNftETbku96aDmh0BFdgmhluqHlO8Z5e2wm
h9ODU8cRYS6R8mKpbmeZVt44xtlUe0e+33TXP+WzrKJk748fXZtRNDynZRwq
MM6iShL/u2YcxXmakpqTzWaksI/U247okvCZ+aKA3lomDtVmvZHCyrnVjEcS
QGlZOkEvzlRnuxJiXBKHyZQLxEdWC8iTuocse/MsBpLSIUfgDJy7LMgmi57T
aQy+iXfkpAXsAzttELwUQbV1+lAMgEhCGx1eEp4KAV7WP37k3DL+y9If8sYz
krTDKk7oMtnbjXL10pe7/4mRl5qGbEcm8bMbsH1Kjp6Mh8P/3fecF8OJBRIh
Sl9KPmeMXGkJU8n64d7RhmVyVKPaZZQb2tIiVZADRkwy9DsXfkqvxzoAH9Z6
Uh0rdsTnzw6vBjaiBVcQ4LhizfV1uYSMAclbwAkbdTIuBMNGDBtIzkKAb3UO
JBs+oZL8hxsZw3e46CU/iXFJ2wxtTgAn6DuMfJ0zYkQLEGtIA0VGIC48ZBon
lzLWx5RGkdBaZ5ek7fJ5LpwndIN3AZsZLRr1KBQnwkdNdmfXnLhZSzqlXtsY
j4QOWZhACLQAnEnBoTksBFsRdC6DLbKYZw7FLYTK0nPxzxZup0OAxArJHTRs
sxgTrgV0t5BIeEXqczktIJTl7IyWalrWxaUMp1QILyzGVFbiTSM3/uNXTYiF
JAEAnSYzGuFqrI5RLA9QCiAv2TQ2bCUNCtK1nM5ArThGijMqvg02PnH6CPsP
bZaKIha419tIeHKd6KbjPDCk0Lxc6JFIonukB6iridcIlZVzClrpcQnjBuSI
B52MVzfKsHFi/KTBVQxVJ0abKHUZRx3mXvQsaGbI6dUkX9dPZQc8OEtuaKzb
DxCM2tgGdjABBuEnrfDw3tI7++C2QwP3UDRJTrdzkKzebkkyxmkxkTyUg9rR
/6f7bz30SAM85ScA1UOj+5PluwPEZKCAv0PXxuX99fsbrcfGBZwynmv750PT
tVgf5b0FYPCb7w0ZX0DD2EGBmVe2u2NcAIUjQTtDICL/qQlREg4B7W4N7g+2
NrcG3zwexI/ro96Z38g+dygQsu521r2fQ4JEuKPGqysPm8vYcNeshWkeFgqg
+/mBEVVWQaX4FF+btvLM1uKFxGR4+9OLyR2eqtyWVo3FhBAY7Ljt1KpzxV9W
xXjoxUgxZQk5/Vt+feBwbeg2zMWEym+1zpIbtM/YbKRCMkgMYhL4Drg9NHmU
fZyBKPrWRNHo6vBrHXmZbjJYpV0S7YJ1tDR0BhAPlwvOCxMDYWFD239Kd1NF
8+7De+EfAChdZU5vi0+Xy6Za+E23ZhBdl4Hrawr8rrO8Lwt6c2/6bKrPOgT0
O/U7DJaIJfmOzXNTYuSRKh3GF2zg3m015ttwigY3tN4leG4wuqEhBTPllzvN
N1cEoZXgeiosnhT81bFAdx/X5TG/zAIwD2056zwM/lKFpDF6tGgHdDZWPsjK
k4yQqkp4XIZq83DwwCHagLFsONgQhkkOQs+bo5DVTGTfmfhpepyB/RrYk9fy
OtCOAf9Uzv5JwgrnQDpUySbSh6TZ3On4QORLQom3hT2sZu0fZGeQf64Oc6nv
QtLVqk1LkncQzlOu1jRRZDnJSJSEhEXuGEGmqFGMWehU+4bYEOhjLO975Pib
T9cgfcEYP9J6pVhoMDw4QbQcjbLKlH11fSqkFWQ3hXMel1czuDk2xExA+8EQ
0iOgxrCSTjdgyv54bG82Urj5O1yAQfoKyZH0DPCDey3p8usqupYGQa6oWLv0
te5CWrgNct0mK7u1A+yxkVjgeRmgz3LOc1vGYtuHRKRBz6Vjo71Oo3eT9LZ5
qyCrCU2yIRrlRIsxVvRh5KDBdQOw8tuhOuFxj3aAsYBEgmDG+24O+wAXOJDI
u3iCPe+8h9QO2JwS9gUBP1lOfehJG7mlMYywZzAhaRWqByLeMTsBiEGqXr2s
GAgskFnkJJ5cB1E2r7mSU6R6H/K7CBkUjH5FUNkEggrQhK4dpChk4+DFt/ml
4lClwGHyYtqG4hBHOlGinrOisnUQiCmE6pAwxmhmcuCD1DwPgIpiAdWcNEmt
VdB5NhonDWFnDmWXty7UPbGMDCjLVVVc2QFLbNZSDCAvCv8qKLsaHlYKfArj
wUZgZLKarhrCaWkGoSaaZ2MlGJMMy8iltNJSuExUnSO7cbpseQOu0jNvxnht
GLCJYngH2Ay9KPg49DICXdwZGBpAUk3F1aO3sG2yqC3FQ9RwbxES3hDahUy3
ZT5sxiGGaZId9pN1cardw2oZ5CIIXwSvBCHQlcSp0EK0R0SjV9uSDscJLWpV
Kuogzzmnvc3FuFhUo2VVmWU0AD09hoYKWZQG5LK+RS0FI5kzHItCFFlnSTik
UNWNcTr47MoJ1XDHHovapxZVwfakTHhLBIouKMkORQUpXc6MvBEWVChOG3aN
q3gt1TjKIUpNIlhbIH6LF2FcLhBIvz2uRjXnuEhVFRNwfEzgtwy8m2cIzySB
Mq/O43agnblGfIKrFIIQ6W53pjYJOxpfcyQ+LbWUoeHbYDiU4X1wphZLIHN2
18AMKmxBNlRzpA4Nxced8tPl5JRDUQrf9cl1QrcUZNuIdBAANRKYB0hrrBmf
Fh+w4FOwNJ58gSoUBh2Csb3MPhTT5RQTIOn0KYtE6y9fPnXy5h0wdJIODB3m
7bsCPZhbiBkn/9jllDVykdQusLNjsdDWnkVOiNmome+JRyCFdn7r7MP1OYv3
Dm+IaxTIRrqbY7dGLqxzn6zoFRTUQgKr1OPpoqQN1C9gjyGso5CdKcHh0b7A
9y0ATrEw70ziNB8uowD7Ipfj8qv98avGQgeE2qIPucYBceaJh2gqptOloBT5
Vx0ip3mn6GAFAN8KSyrX2IR/NtrPQi9DXOcn3RcjiR18Dukx+72HqVg/PHq+
oWxOVrMKR+Y0LY+7NE50N2wULgrzhJT8GY9YPsqD9eNKke/evthJdjStk5bo
g/OveVWEnqGT/JOWdNU0SROfRHHTkw7TgXxxbF84j8OJducdOLN0jet9reHj
HhtQvdUKUHEQMxufZrTWWuDiOohg5c+r/IxdXmLDNNBn/za1hppIhjzUI8qX
nQmylBSvKbiewNq9Nai4Gj0U1CSrB2qj5apkJ6RAJklsVbGlbFhmfIGcRty5
XrwOFCxg9rf8h9Z8F8wt92EX2Xs5uSmt+fy3/NrttUNBbfpe/bue3IflS9Jd
T4BpdQUq1LN2anGeFQvmYsAV5Og4OW8C0mwjgAWE2aKDnXF4rlVwSDsIsLVA
ZDgUSyx+n2fTxCgjdbM44ckA36bMNfSPQX+5TI6UYalMUmTzQM9h+yfiSKIr
VHAkkMY6ajVvG5DVk1MS6Op0OeDDEM1lXSPpaTxbOH7bG8Fs99gz+YKRgKx1
BsetYh+NeDADZdxa76oZ4wor8ANMfysG+9TJ48wdPU+fce4GnPt74IvW/VSH
5u8cEAxde+LBYflLwKmvgbdclOMoig8G844dHbY4kJLGo+fo3nlEnRY3mpQ4
tTACGOSDgw92UnJQeAXkVMuJBGCtGLNAU5qvx9eZgiFBXYZC6FQKumAgVY7P
nXEFUZF7sXDeQShecK7XRcMKxmGZbQIv6atD1PnIbL9HKkwv88C+ypqRM5ZZ
Ma0sdcHgTnRLHYImpw0jah1CHFp2y+gQOWWlGBDFCtTUvnudsUqPNgjanJ+i
KqPvffC2+a8yYgtaG1S9wCosGTIuSzIIJU0MFED4+T56lvDUw6CanXJxh0sV
pJXZ4cYVUtdn6C9nKBbfKGkcoTePUwLpKCpOIVf40fJfdiL1kWP7XIHczSmY
eKkPagsJL7BcLa5vajJ6MGxYnP9eyovfZnBqjVXm5VBpSufvFDoVoNd5zRKc
8TFRuXEuwKTeG04XMp/CvbcoJtdu7TxiY1BOUPPycUoTrSNhy0g0u8gm/fK0
r0o6LOzZ6KIK5UgpryBVUlS+o9uteIyWRdkZfuEk6DgGw0tHTgq/UwjGgK+X
oKuIdZCYF6DErs06T9xIKLggo0RedC31QUdKYOhPpAJpckkCMo3LUpr1UO36
PdyzPfz4Ves80So5YmFFaxoxMlUH5rRovObNMKMKagJ0LWNPilDShCbAcRbT
XgB6d3XOIKhSRke0xoTLPnmaZpYaLe4hkRN0gxcoyCqrUsyaRoDKndZE7RLt
G1qchgjEXlsL1AILXaDjz4rTkTrRtIlhLx3W7CTlKHhmikPLyTUiitk33MQs
rsaBAq5AoxcfOc5oWnKYB3Voyb/xwaoEDGKpKo2IPVW5XIit6YYjKQWEatzF
RtlW2MQg1jpB3HS9fa8ZpP/KF6XDg7+xG0vgY5GBZwebB8ySgijPuQStXTjN
RRgUTycWRyq27/GgUBirCry1ThUa7bqU4KyiO8I2A2uB5ND0Hbt7Ot4kARJm
UVZWgYjmX7eZR+bv1qROEQimGj6fPZHrRN5xEhiWTSyyvHDtOWHlSf7yHwlT
NDS3cyIeKMAw993zABs1IkIaap5RAYFlwdIDOQfVbPRctmqRGHhwxGa6icwK
DuPYy018T9mMFR6NbqpIzUwvrcJeWPPFRxaEOUHpYgnQRrWf140gLLo2DRso
hDwiUIjX61mX13ktglYvrCegZdryD+fFCfZ49/DVYCtxcSEs1ywWoGg2GQv+
EfGHdGqORKMm6tFGYGQzLshVBywjOl4Izht1gIUx/9d6m8pbBFWUqyKXSp0F
ByE8HEVY0zIgODgXF1IhIrrOfS13lVTlaX3FrECo82k2wqilxgTTc60bgfeR
BlTwdosKjRyakRg+1GrP5W6Iz5/POBSEo/kAjRZU7hNgbrpPXEwBT4lmG6pb
NNOcFAVWuDzIuS6Cc1j1wjtwBXegVhkMlpq5dCIpZwJ6hlpHGH1YzYSLhKg8
1FVPU+hDjTDEKy/4DiLFRp6Rd5JfDI1tVimPMoqHVLz+rNGd8VFyHJvlSjOr
alk/dxqt5heTEYCoij/RSkJIKKvZGaKcPFEpAhKpYvgd7qIIe70v5DROXzm5
TkI/w8KDAUThs+08VB3tuvkYCy5xlDQDZ4OF3Ghw7rC6oLbG+BlWiW05Jwar
KAW2nZAxbadIzK9KH0WAKSI6sTbxZwJjB83PFTmW8nYQaxeaEqtcwdXwFYsu
i6qdxTBMh0vF/M6PswGe9sVZ9t2nwY3MnAYu5wK00JcTcfWXs5o9OVnCupSz
gehRQqJiMCqsF9F5vu4MDuOOHMlarh5DImmHo9qHb1XD7iCAoQtKjorP4J5c
IzLix+1h4kt6iIgXjEcV50XupKHgHKDoc5FPxr5QkVyLxO59EPvZcdgiU7re
34OnenWL8eegDjMoX0fZoV/pDRDYNW7BiZ1BfrYrcxZb1NLdRHpw1l5+2cA0
zblQO2ObVRoXXVmOvpZNcviaOneH4h9QumJ8bB8zqUPQ6lXG0dIofqotZYtR
TzZGJsRRaWb20DEJY2cnMI8iyUhw4jBi0E2UxIMr55VYmrgtBLGx8z1IZQX5
+0lHJJIGTvn7dbPXzvPZgLhdxtZa+uPem3y2KyyP6eKcJFCN5hcM2TGKaWRn
uRfLdBGKIJ4oEi+s5jYQOwbJ+ttc4GLwbLO2VAPpG55AOvrZJA1nAI4Im9DZ
ecLMkpkVF6eYFBcwXaJ2rIWnhzsqTiuo6WUt4NvmmU8szxeWJuTqcP0fBJkM
NpIfpbZmM/nFOETSmrAW7JAzn3/AU+b9YekrpfWTZCHhvVxioafl6sp5RttN
N29Eh7Ujd1K/pyN48PS77cFga/ub77+NM7ViBHfpUruyqx/14r5sInkwZMP6
VoIByv1Tk2+l6ffAF4+mvi6LYtONJ7phUiK23dEq55DWvAI4JwXLQH2ar3/4
j33i9gdP918dHTw7oO7QLFLAH22YdNk9n9k40ShKqwGLntsUw6gWS0XsNjQE
rq69Rd6NrkO8ufFse06r9lZXRquhHUtLIs1mz/P2SVdjMll56Bi2zNdI82CP
nczSmVg9/oqEk2IrvSFe7ESzvEG5Cy2qMwXVyKpztuK3DiRk2PSjyyyN2DLn
6W9uktrQZM3yzdZGL35R3Ony5XbwWvj5/eClDjOuPPRgw9WEixA/5NuHQRNt
2Et55hE94/Nl/5S+zTmqbkwaMIlMb0rWgP90zz2y0O+PF6cjlINikPfNzcEA
/z57FvTongycJTSEnN7Y1zf2n3W/MRcOIA8/04efxQ+v6yf8wedU/S/5mE8I
An+/lXmp49JvXftJOyRYYn7RrTvX0UzX4+83gsbwA/9AfCB20lslnG/bTTQP
zy9rJThgO+nqAn+3juJXNNFxXK0duDrh2V75btdp3glBfxiBb+Xr7WO+4xF1
O1/9zMTnWz1Gjr40mM0wPgKCUmOgbFG6p5cUELEUvIaW+WUS84RQNbycTLOU
d0TEr1FH0gm22YL4OolMkbNRAmDE20iEUYVRn1SjOqDTz+HjQXrsUPJwNIjn
hv5FINdS3CHRnmVT9WSxPDZUUV6QID80a9Zy8fhUq2NVXbWdPYMftu/s0DDX
FR5vKyiUyAtpRgf2GlkDMA+TTME3iFvpSUQ2GzaPvN1YHPOoXykpBBK6xeWE
OIKOuhsX4g9T5MmAM/XUxhSusuqgVXq2LOCAnuVOBbjcOh6VLhwRKgDqm5RX
tC0wrYhTTCVHiBOjsi/xjLzSl1tJ4yG4TJd8UPRcVO2DAQVxAfravbRq39Td
SlpVybOKWb1Vcom1uy5ezhZ7Ei1OGetFyk5eM+YZPKI3jQGaOp5ha4M00OzB
a2odhS9v5eTGdNYfPXx4/6GxE9fATZwkesgbsBtMRIU2/zWG/x2xtO3/Z+tR
f+v7b5tdfttGJBi6L0O5xx2qTOIzilGjSKpa2nzcUS/xkivHSq5bKrDAVh49
r5J153vXCmhamNzVcWJBLJ7OUJRuCa5yFYNQI3pynaidXYhl+32hp/x+q+63
M004fNfroPK2XLRCH3MxUEHlOQ7WOJXbMIy2yx2wQKu1ZfIWjFjLZdXfGzYl
qBnfc26sHOVGJ2Iv0dgSuSu0nh+QjZM40hxisKltnCMcaTt65o6RDTKXFdMH
BtvVzWGK27CyNLZoENZu5JCjF1Lf6uNXzKkF+8hKDLqqdJnaLiIUUNdRbPc2
S1Ng3PBGNC36IYUOfMVeCZBaZ+g/Jn6nsVEsuYtRLG0bxXwWkONkqAx5B9tT
yOo8D3JjFZKWBPhUWjbQ1Ttyg9/oBfm7zWqFoX0oadqHBitV4jit6Lst0JHt
B0xHuqnUkg7Jowc+ULlFmSS7+/gil/pX393fRpuPHWnCTyOZqT6pwrKs37ZJ
YhpbAjvo3R2E21gEC2q/6vkZa+y8ROu62JK2MbsjgcF7x30kVq8dVvPoQR+u
R8twC2KepgiqEiSyKskndMhYu4dLBU28m5HMsz8vaTzrW+l/ZLMlnHRbT77Z
TDc3d/j/03dHe2kfgfPpT+9eHfzj6ODl/ntScagn8dXQmZsrYKRYTmZ5jRKt
bEsRL1F4ROuuixshiBsvDlEwTth1ijhIYAWcL8pZSS+ycUR6oKVvHBG3AVxZ
02LcfByhfuIyDyVJmEnUTdvSC0HfEE/QaZhQz3Di4qHlBh5KIq3ENyKdlsTd
wDEkUi98iFxPnideqCCNcZbJraemB1ObhA6JD5n47CR3wZwR9U042aL0yAHs
cXA221tOJ6ejxlcusbo7w8bdG6q3IyoV2N4wttJwG750KHa22ZrtbJhS37j8
HS4XLQKYqNOulZnQaOFGC/7qvLhWbv/Hj0ETSAqh2QTPixeu5ZMA2Afdnz5t
SZ8vUpjvzhPD5vk3jEbH4xKIj6OG3hb5KdppNrEMJJKPI/qJQzJUKtSMSGEE
co9ktArpJRWkl49fQbILszPu5myyXI+Qq+pnvaSLp1pS62obQdBZh2mtxbHY
6puKn+HbO/CxOzOdgOm52GbhoBFnut3kETMmGaleHRhYmZlLMHPK1nG9SIXU
DIisuM1AJHOwcJRHg+dFKJg+88hdyJgEfZmo031RMhsmnZFN5/KN74fSVn3Q
RYOba7lRBbAd5iNFLBsKgUDvB5dQ70TYy0nu6i906BhJt47RU1B1h6irmCW7
k0nz3mec1EJ8PuNgDNQaRWwMUwpLDQ8e13oYfLUh979zIEiBeqQws5qrDE1l
VMw5qlhjFpj5s6bjZ+90HLztsZUGpOgjOXkxlXy5WcNeIAkT52UpeVi+ZT/q
9UrxcADChB7C1pMouTkowce8+Qtd10mnlG7qV6iBkBLg82o78huScY4i9nkY
kvglMRkR2j+ybFQBgqkyqLDOXu4qSvyV7NtmFpuBcYeWzeFqn9YrIgXPm3L2
l4ru9o3Vg/LfWPOpK+PTSSjr81uk84ahtmWS8AKH69HLGL6MeuAAb9Mzplla
RSCS5cP6BRo27k2HSeO4cLu+3pa26wV1F3DvsiyicxNsJVoKqh8Vvgzkyvrs
uCTRWt5ENo+e/3+NbHIUSYvuVDkHKgcETGlMFxULs4OVRPHT7uXfncx5eaqR
eQcZqkZB6DecvwLCjyIYFgGigwaJYqIQFsSQogIRaoAYRTypEWQ3y5RBtNfR
80EaVynQqIjKmWFY5qr5KAXh8GKwW535TU9bZvysTMvJ2Ly0wTV4+XSQuDgi
0WM5rSdGO+GAA9JAgWtxWYyXProgXT+5DtN0YQ/jLCKXN80ZdxsRnCbCW2wF
uDc+9qcLq94jo4QvOiDvSv9Xk3mk7kjG2sQgTWTmAglYJm7R2WiHQS5ngPjQ
h1lNDlJ1PL0IC6YrkMAlPWWKTxROpQGeOIhhfOd4uVCXP7LWJDMq3rmksvRc
vuOt6jRaHFSStR1F1URsZB/dQdTvygxSk1nSLd43GNxvIdLHTaZuML9AWr+R
X/2OEvpRHAXHZaTdPDwUkhgQK3adQAYSJwq2mEN69COSP5MAUCCojiu206Cc
g3/MuuCbow3Z3Q5ac5mIWjNsOR8LtkU4XM2PVeuskJrV1CyNqdltAqPovL4z
kYn/CFGvXVOQU20QgMPx0iufE2h4eAAMvhaRx0LvfD6LUpM73LrO6iyrrl23
0/s31aVNajreuuG77Q7hslkkokOCXOWz/+N0Zz87J8txrJdeBWWDKsUF8+18
mvhB8HR3BZxA6guJttRUYm+dHvUQNxtI0lelcL+2gSssYfQ5OtTN4vDdR7pZ
Tvg3PtAd1XS7jzORxa44jN/lNLe+8fV0O45yXA234yB3x4/88ce481hKacSZ
83wYoF5cn56hj9BYo4YxWtjsCzCSQI54dU2D1GOrJ9ueiipp9ME+gkZV4S+6
EFH5WDa2wgY+u8VQ3r4uU+7luHEs7eYcni8FJpizxUVcSzW4u6Lv8PHnJlKJ
T5sVqHlkafvXOcVCY2EEkazS2qZZRdwLA44c5x1MzkCVVPBsC53oJPScaAgy
4xRZSpRLk9L4UnVVhLhcqOGEamPl2az4l6sNifYD2CNItKeniHrjXEVFtXbx
AmpqlPcGKP7pc5U4GwLftaqNaYyP6ktIr80uuMjTn9KXiF4mBdBFLdtoOUjE
0lCjsH1DJ6Sx/Cv3ifJqXAsRmHbfHHAUrwGlB8hOY2jVl0hyo22b5Aj3RhLg
skb+sgZGj0iKKqqpIOZwNTOXfgPtIBTq13nhkGGW4p6na3ac1gLMJEO4oo5O
GXeNTokpeIIF/BpaF9QCj2/DQmMb6UdKMGeMjcWWRCSxSTQxNR8OjeOdA5zo
nkIQZoJbwBoDJxUvJXqCEy1D33TakroGpIdcGhYTva4KiRc2TdnMTmsV/DCp
c0Zv1UHHM7REJ85I4+zwKg0wdjhXx1FWRF0QX1lwAS5DTlCcOwaOZ7AL88u5
WQ7SXW1jjrDWUJ6UeFNqDd5LURU1llndhVgg9VoRxakX5bWmof4tz+fuZC6W
M0ZAknpgDYeiJOBMXLK73XM+lHp9JQ/VVdl0CR58wIrKD8HF2AD+HOlI7Bz1
j3MKMskOs3xUK90el1MW7WE34WArlzHbTC+np+b2nnjDsG8SJrXh0PD2xELx
0lB/Pn7VhPtBpW79kk3pqvU8Pzp6c5j+df8Ic33zmi0VcgkGIYLTqX5b2flO
hA9VPj7cAL//I7vMDokNkLb9WnDEX5VqG1oHQMWGwotX7BB+vP3wyftB0uiK
xtNql2lbH4wRVwvDp/NxT+xfgC8KMKISr8esZT6z5N6H/tXVFVyN0/5yMdG2
17xRM+Be/O7zo5cv0geDza3kkKOGtJ219Cd882Bz6/0AqK+IJeAwOGXuJOS4
cQd5uInGV6YOIvfBoweP32NuEpRUWHhfHlp0bAdpr/eMHEvJ0tPibLmwKE+z
SRmc0w2pT0lIPKzNBqzUqc9Fqjifam7pERJBmldO/LAe1YYahMRNMsitDAA7
zs8UdHGRS3gD82EJrgyhsaoE94o2eVKyPRQhzAozySiExFYUSx6n5/E2wgmc
paw0JMhskkike+6yai0wd6sdgWlgqIYZO3Y8rkKtADdeBXfAiyeTHPXdU822
zaMQWRxzd8pxYeLzyVKMoV9pgpyHPYLPGfJHLzGUo7QL5ShF/Qp9OaojodbU
shwrjweKr9hhQSUP/Jh7AXCvDMrZuw1VjhjDDC5vxIiOzhEpG9e9CNONabgX
SoCr3D3Pi5QvWIqprmejnuV+o79yNFou3PBp5xXSLa0uiKeH9VZ9939n4Yz5
tbbEGJMaAcLiTuKHHdVk8WVoIutJeAG1GICPLkmi2JKADXKqF50EOteAIy5O
3R+MeapvDdJnNhaBGkg4p40XXYiGsedTvR9npKiBw/CnDXAYYoXx1BIL/VPs
tdB8KgnhHCdtOCRSFDpUeJnzgxFC1TQuqFAnDq0hYxs34z+Fo9EyFjcUyjVV
uqjSoPJ4vEMLmKNzCUI2ARpGOs6ep8ZCGAw0plhQgimtIX20Tcjrn7mX8HSr
Jk9gR2PLrKyPvmIHS+u5WEMitKDkK8JbMT5WHDgM7As6QBqa+Jjbq+WEL+mH
/QMSVeCrjEBgOtI5JzZnltOrYEDRGKW1ACwq4+xNttExd6PDhLO2lgQwF4L+
FCAeaZrachYcIcC+O6/I125rpfpO7OyAeOFEBZHGacYPPny49/DDBxkL6Pg3
2/e33osbnm35zDl8uqdKGgmJlpMiEJbYBKuUme+tKDsn5fg60G8yocdvlGg/
zYnuTqpEhRM/hseb37x3QPb3JZkLJJroAGlHMLEA9GyXiPkrGhOD3I5yl9Jn
AofyBtquCPQhW9Yk8oG12HSA7VwqCVN8rwAW75RpZyY1a08d4AO9QsqasGcu
1zRTrWAYuQcDnBWMFskg1VyWdCddo73ZKfL6dIdZUrXD2TA7PJKdNdr6Ma+Q
TPZ8Oc1mfbqjYwGfqgX2U0Qlm7PoWkwnYNKWMECnLyOFObVz4zBJ3ZkZ5+zI
YwLGssWokCWoFVxC65YFHQEiRkLWJG2QxiyR2gczt7xSqMnSqcvTZPidAWt+
f29U37vcvhfgCvyftMCL+i9bm5v/B9Gkvzx5MvReIAHrtTOdDB9sbqY/ZOP0
rbQ9TOPzrdIYH8IgYCXSwjvMa96utoatXLtln2iUPzC26CEGvuZT8dZk4fD+
1zyprw0hAUDBDKGs7savqY2v18SuFlvQXsINomuNHCnRGFQEdiFPGmnnM9bH
zbSimkstif5y2XFdhaaJS52VeQHeYOo0zSZg0ZDP/Ugs5i0E9w+MEVqDYORI
niDJMLNoECsaAEsbqCVm2UMhikl0H2m7PvXjnz/3b/35lHySRXI/n+xUr/75
9Et7cuulPR35SxYsyEkuazIe/NKenBKiBLbGkUqHD+lSoPDFgvV72Yd97Jsm
cT3cvM8fA4nu3cxVbxuGeiSg3FB2CNcfyDKSsYTiNbv/yfh0194Pa1NTi0Mi
+Uhq3hP3L5/0sVSOcKI5DDX0sWM6znXM0gRHatNQPctyrmCpIsbScZYO32I0
fa7ivTNkhxwQESSuLDDDubuRGLQTB8e7KGXR2pEZmBW1QTfzTBt0kq17+Duj
K+QKetARDbtucZEWnqohTA1WbCPc48Sc9cYp4rmwTRfqEt53ajwxjDSerlaa
c3YgqH7R1jjJRqbFxxQ5/YmWFGASisU2oJhAaJfLU7UTkzpBZK0BdsU64oWU
P9i1EgVlXcquQ05JgyFoHpuU9WTQIMbTgKnl41dRIHCSsNXk5xZ3CZ+C2gXU
OyIkO4E9EOBtOw6EOTAb3Iz7jwA1EUfs9c6kPeQjwWomJhItOxQWRQlipZkL
hNB9O6Qn45g2Agc5BWpbvmlD32BgDO0iI9udabV66iNCKWJ5TESJSjhXB2xk
Y0nagJEm4ipUKbdjcWzypIScsas7mNq3ocRsT1ZeZv4WsGNSqOrITKLaB5oz
HMN1wDcW/m9FW2WIIZ52r3NhN9gXr70aVE0nOCQt5+tl7Y/NqNZlbS5N6Bb8
gvBxdupJqBWHnok9t5dqWaVWvHw4C97qRrXPsUdSKqaKQTUxy5FEK62Dqkwg
TV6LYRXmgQ0xI5llW2q814b5FiKqQpUteUl20H8FEOa7r0h3lE28ArwoEh4Z
wDR8SS8dTljJIZGT0HTMuQvS7ZLTc9nyyDVPlXExpzEiEBK7tO/cIFWHFHMX
lv9H/7TFprvITX/0T1t6+nddy5Ns7DGbsZbxuUESliJTtSuboTCZ+7xZfea3
XEuM8ijY9E+m0Abj2+LRbP+GHf+SUQoEvI2yxYVCDqFO0FsZkpQ58DzJmnKi
jLx97VkUI2N2LoSNMtjDT1zG1nhvF/asDdhMyLLfmv2sshRJzQi3FdK38Ss3
AaNcztjNvCtYg7qWv47ZNhgtmwxlE7QaXbicwn17q9kvj9Jcx9GOq1GsCW3v
alZXGlP+h/z870KJzKIYAKQgycldk8tt5foZwDaCKnCIdnbmRw8PmLjojYEr
P6xlReCCUuzETA4KuKBPO3UBEiTHahmjZDk/W2RinjQ81toPRA0NChZnlTXC
KtBVWCJeKgfAGTf26bKCbeWRD9lDfAWbrMCCIisCUtdIQq3zmYHYR/iBXMbg
vJUdG1ig19Br8LUaUAa2AY0yhROtO64IpxbBagX5XiiQZvvNRHB0e2ZK8REi
ABCQ3xFXP5Lw15muivqHGlDAZtnRDQ/zwVmJDGJnZKGbXGzVNdYEXk+AQ463
ApadGU19A2lvyKeB0Zv3bE1pmzZnG5DuespRO5+MVXOxDeDk5LCQJ+OsJo4Z
cIgChl05yVwSjBE74dK+vQU/EAn1tknxWZdw7mBh6c9gmXWOLEgyrp2XXYke
F6eu4Y1IPl/d4AA1+xLnPSpOE+XxqGC4DRw/Vk4ZLqOhrGwoZWAQR0jIgejt
kyKSfHqSj4OCHM0arelbKXKQpy+8l+bjV5a0kSSIg2hr8vo9PLyKXt9UzX4/
RaSX3ilXJJrcygBq88sdmV/Ozb0fhrbesg7hs5Fhg2+LN0q4WMl2jC9b3RDH
N80mrGqJ5HPDuz7iN3yX5IK5GIfgsvo+/QEcn6Mw8W4liC9Wm9kqzYCqiyPR
xQ0YBYOn5SIXNxI1J0UeOX4p8IOLm5ILznRA9Lte1Fcpvkh2b38vgXV6sdgP
LNKXX8+h6rfiMZX75eo8CjUqFFWUmnNY8CI3KmGBku3Q2BWaOURRVw+lUChJ
UeG5Sm+AOgWclLoxbnDuRh5Lw0GTxgfUIA3a0dlFHk19xSg8qTL7YUbttEbQ
uHzB919yCVdG/ztVPQpZD9Ipec945lrMwm2Q0Eq/g7r4YmoRahpFtjcblX20
VvktcDrtSzCd9REOjuIMdI6GizCAMr+q3gbl1ra9o65wHYvT61naEVEvdgrs
C7fG5jyrEbQx+P2tMd8HNnyihD5yV0MLGEDF7OqdNyqziAjEmFB7DWDzYFWa
4QthzUEZ4O2Glf5vKoV32ETS39Qs0qFE/PYz4HP8TkUjnYG7SK5yZSdxOFnW
rswFR6zMIkI7EJVSLkfYw6fgUv3KHnwH4nh9xrQv7kDScpVF69TurAb+AXuQ
HHKClpz74yidRUFxUo2xwEVVXDPTdqJblcit6pY8WnkuWFD4TuheA8dRMidF
+GAS1D+57iPN+0bRI3oyEjzwwQraQ7zegYWJ48QI8A3CRiOPo5SgSo3uKE8b
0sv34oKRNHWTOGJEssAn3syXpyGLPMKvUmMScOxImc84oYP0Q4ecskI2AYXz
jjZWcDR1UAOoYOTnYnq3BjFxmJHKBdSshZo1U1tqrcvAt8VEFjc2H6vUMSQZ
rMpEoZ4RikEx2/83N86HqnIjwFClPjkvLip0wwU1Mc6xBn39uzHWYGu62CpC
c743turXpWNmQXjynVnqH2jW6mK4f6AXoosV/MGzx/FscFIHxGFWbUZR5JgJ
eY4p7bqacBrBvFCTrt2TsY9Bgj6nKDwK0zIvPh3fQ6J6NoSw+18nKPz7L37M
pd01uhOPbl3QO3HontPhOowGbZ5NQs6dOHbw3H8nv67+uxh2knwBw17FG805
5L5KMHCjnzQs8dBnAcgO+PoqraTj5w+mLHvYnFsvIYofSAjW7/3TLXd3/PzB
6xQIYd91HgxbJxbbgqd/v3UKe/n+i8a0KvjddO2idiakrmaDSmBNa+XnDR6Z
y5j2rzN7+i4chRtZSCd/t9W621b/sazFC3sxppXUe5CMRnjPmGQKiRllTXeX
JrvB11EspDSv1VZkH0CUMjND8+JpWNFwkAzSSB8Qi5QFY/7/GsDvFOj0W5pQ
U00DsMWRtYggNlbeck8BgryXX6OiLBpGi+9VKKoU8OeabXqN0nOR3iLW1Wj0
gUmQGmwbBSVcvrZI5awSKaJt7AAQwm8p6kkxh+r3NfFYAU0tUeBtOyIa+oqa
q8VCfSYOikWqghy+FgaGemEtCFcrlbedSLl5kFotSFjJLQ2EtEWH2I5j1axO
LXSuyyVg2IndKYmI3eE/O8N7v7jMpLCU1YidDXB/RbC0uMx4PEFyKjwIxWU2
0SB0rczN9+xKkiwtspNTbngMYVjzsOfDwi1O28vkgT/dIkjFe65Nabh8q4qv
pWNYuH1R24QkAvYOi3rnKFgdSieuisdd+QOIcAgcX1SW9O1AauW1n/t9WUfd
66FwYmXbGkXC5V1DIG5+pYVb15py5u6F5hsChFe0nsQ8RJfbUXnTjkCZjjgc
Gt1yZlAnpL744nNSGK4VocNVEMNaHD75kPN5OCBEl6CXaM6jAVXytZShjNhI
yelH4po1MBcNrXNjwhiuctQfrpLAJ8QB9AvUbtEzzauNvUOyhGBL+HkZ2j+g
CrSWA+5TYulSAlZ1JG5CInbq0MvhOghyw33eYpDERytGh2Ez/e4v6QeSaAMd
M8kCtykNbagi8tAzHcajbHTtOnTOP0VcBHtYxNjWjSEOtOzqsEFfnEWw0XZY
1TgmCpq6lawo/xqHSFrJYXkrCvDJooSPMVY8JlNGJmME943AbxvEEjWjLpOg
2HLo9e6IUrS11FoIkrvE5eV9AGfSCKN/EaTg87Pn5SzEXpBkX95627zoAASn
6Pu/RABVJ9d6MuI6yEG2IhYbrMsiESTu02MeSZVoJ7fyKRy4zqJROGDS2OzX
qIiReByiEAaC609xnvp8PiFGJXXDJetLa2FwDEgLRVi9GFrAwKgXEryGgaAx
TFy6EUfoNeFcvSbEJiOguTDTa/XnQdkOn+++eBF6TKxaeXuM3J6BARxp7Jt8
Ja2c5IkCSWJ7TvKzQhBkHGsVwSXSH/QoDAK+IfXVNa2pPQzlJMV0uqyZnKqw
vWBjaiJid7wlJ1zvewYoANSuKk7ZOCZZYlLkxQedTAo2TbkxC/wNDncA7cIk
qYkO2WUlE4+CUyMtzk7zO9lb5UPhgC2sk1RrQtKisOrzYtSeKu9IVBdN0zNW
FvgELgMdiKesMY6wiRVeM0Epb8r5Iv3fLI5nVlI557VlMuNky6GDamiQTA+Y
/cfkfvxOyRq/U0wzu/BxMrxj45OjqnQ2ovToFddoFopTAgeLZuN87KDZFcnX
eir/WxYh0ud2LQD2iHmqhONbZKBw2Ju1OX1mdXRkmHHQVqiiXMA4D9Ay+m7J
BUwdwBlPxWRFvawsuxN1PmYefSxI+TIMy1+T24yQOQU6pLeFmnIbDlufW2Dx
UXoy2AYV5LvZQFe+BTcUaZ8edZDpqSgGGILrwoLJ1H9RVA5yKlAQzIDikI0E
LKsytlDloyULtGdLosAk3uYI/aNRIkzXVW62MPQZiYSMMIZvD1VG+fhVPamO
VWKhg7F31Be0LTwUCTJMxQxqOcCgclh+IWAk4wEkjC8islMZ5Kx4tMPwU8ZW
w6BxZnycsWF6c1YxPgYIXXWeXeSVQtZ405Na4uRFqw/H7SESuyMH0hAGwsDi
9ddIGVguwCEy90Sm0QxVzpZvDCQoIXIa9MtQfJ670/ESOP+NRNc8CeOrbX1i
/a0Ri+HMM9i/3XBMlhXNS8obl8jgtgZB/ZR03XBQHgy2Da3s8YMHj95vqFjC
Oi6n6wPiFhZAQCoNE4OipjMiyfz0qS/IoIUsWcfTQ2AAg+HxASg8pNVRMedU
g1lKu2ExoRKt55C+MLq9Xdra5WxSXOSB8FFflYk/a2ygFiFTOuQVEIS9xtqJ
sVowucd2dU4n16pD6Wo6oZXP+Sx9PWMuHmZeHUpC+Ru7jeuv9w7fbCRaHHfz
vZfFg5WXBSxH1XzFCvYS2URT7dGob4mRKD3qZnQBBhiKvJlk/hUDwY8fFgls
LtiO6mGnxte4O2JucwA7DtYYEopeTOgA9VRt9thaqJPkIfzYGe/ugOaeSdb9
sV7KYVCngmtBsz3Tn0Y6j4Ot6ERyWoEe4e10XarM4aS2RpMEo7Heg+2S3Rqa
7SXu+XGifT7afIQ+03dM9Gwd+CQkv+ZkAXMzWDjcVcunuGUFrfpRQJTsGrKp
66Z7mLTuIVpUWXw5c1V+g9vZc2Hn7XkmOk8v9HTMVQHklD8rYffFIq3VJqwx
ECAL0o24uaty9nWdznJkwWSLYtJKGgqxdoHYy50vYdEqTnNWXspWNlRQnoJu
R1FdiGQRNkWXPvHA/5NrsQCPFVc1Ekp467hMlbOSyVpJ4YvylLTSvoNZVe+F
rnzALR0to3NJBHAs2E+AvFDtfQ9latzBEWs9hqyQoLtL2C1qxd9Q6IwqhLM0
Cw2nmAhHnhtlhUKSBbuPnUXeV6qJSgHbDQWdQfL382KiKXi+oi5nixUuQMcA
PBTw0IPEmpEgURBnBicG6TUR2skx+QdSEtUV1MDnA99dztmIxxCFLqdhhtT+
yYT0bDoH2CqZ2oD6CEuVrJiaS5IFIOOodllUDVs5rQ8Od0/MLiOlojXnorn8
K4xY+7PUrSW7OXetTrIlS4p5xUxpDH7Y2vSXBtrIN+jjVwbi2K9G9UpJzcrm
YLW8mOXwH2UOmh6zI6jIDQnMYlhYGacnYZyNJXGkbUWdu0S+NDAPmfRWVGyY
QkYvNBLJ3GWU/KWowdwrSLnfAMEDY7RhXK0AOFpNFBAcYF0YlQZ5UkTl7f8k
liFSLCRQAVo+cWysdtsaQaJgPgWAMxOecwaZKSp3lRXwzGW9aRGh4Dyp07Ja
teKNxDyMIGFNiFedSPIpThT7bKblcqY+g6yus9GFnwzmQOM6yc+lCu2C4dWk
PDaglUGXqOtC5FYQMqZqo9xuLLbFT4RuQSawarITRR1ScrUHsdysrxOlW7qg
AvMyE6nkY0EM6pLP/XWeLSqtTzIVpmalmwynVKT2MLkvSyL/+kYvbZRS71jT
RS5lFFQ/Osm0Lrtz2YfU+yQXG+U/5YTFDIWXuMEV5PjPywng69CZhJKp2sCo
isxSzGPduIcCBmiy/TS8ySLfuLRJhTszFnaFGoizs166d469XOLk/WS/D16Q
/vsGY7p+7w9d1Lo7ala9l2nk/o/xelQe1cqI9P6PhiYk/j2QQOIWoEVHpYYw
dPP4Mi1PGPoW/fda7CWGPOV8UcjVon15AqCiabQPrsjT2Pt2lCGaz+kFbGmH
5nNNkoho9loSm+IGELVe5baV8s6wiDI+nUAzT080epD9amy/yyrla1UH+J+r
rUQaX5FN4E5yfUVVlvTpVi2OtOtNgVM7LujXY4yhVa9JagsGK9OopPEcMMTp
sKNpS7nWYXPlXsWGVPggX7soqdz73UuoKqHPCGcrRNWWviB8jHOGCGMlPWzN
I2YTTV6vygZybnEaCnfKVi3pv2csg+seBr3RGGFrFrdjOVl5BK4g7STVRTGf
s0PlksHqr1Y/XlaOt2sgypglWl8KT4smvZGLaYQtOKFVU9Unlj93T6vUTz2D
9ZNc01gw7PbQWc6qwG7SUAN7pkYmodU7gML7oirGSdMBT7MMprjSjGG6Tqyh
nueTeaWgtAYtkDikRy4kMLo2jZrEfkBInzXrkXCNUyEZwiAmZcb6Cvw8Sp7Z
cSOeEjtKDaplNI2+mYZFFFmH09VKoqz1G0PSJNezI4TAYDUbOymHpWWP4UH6
QqNiu+vSB7ELlrQv1fMCccXpBxrf3DT6BCopz0gdh6KAPM+J6DnDZLBoKLBd
Luo7tOrE/+BtPoXO86FMUfK1QWZ82UwYEaReMzw8g1VNefj7rHVLOKhUypLE
wANc9DGls9V971AEUnieHgaYcJlXRK04+PPUY6M1gAzaZkcHGQQDBD0YG4Hc
wD6waWClCcAQQYLK783Ji66G6CqsX+AFb65g6Oe/+ZBoFrHEFjQ2Cize4m+a
Z9yGy/zUdjRJ/ZB0OOFqd3airnuxZMDNDPUHEnbtktsCaCFINE3bNpt2/YxZ
G2mYZbyr2yo48DlmEwc3JTfDIn3WTwMrFhfpXND9WUgpGr5O8eYHfyoQcVdT
9ze6Rq+FPhlChB5dMY8rr7dUuUKRVEBGJaVpbFVJ7Rv+WMwGy0pJhdprJv71
WGUN5oBvYalAESYODTSZTc8QaebeNmYGr5Cw3XDQxWp7a2vuBbu0cAi9PniK
VRxsbW4NvnnIZikfoBPWIO95kSf0UawQAFiFaR3vo3j9cTBPctsdpgXRLa+s
6OwNtmKJXw0FeX3nRsugqHVsSH286RUHu0uzH4EoajUj10koe713tH9EjPrt
wau/brC7FNJGa2UlyNCTiaf7b73Ux2J0unv4arCVMGRpr4MUu+MbLsy4ENAk
OPmrmgioR6InxfNqAQRKLqTDeLJRHYhw4EFKIlMUBnGYiQaXtObdIcWHRyw4
YYfXdDA+pDs7f4m6axStu/HloBhoa02Y9X8lR8PlzIRXY+XxgJ1pFF3BTK/g
dQPv+LbLk3SY9WlPJ7kbRzWURMHhIX9uAx1KjHV8sAcJQg/d9q42p1u8lcNT
DvGpBJdf4yEl+pS+PngqMZrguc2xMA4fB2U0a9s1IVETy3VuIgx9FZHpcBdW
XrjfaxeyGC/3FyxpltyyDI5Tt4CWwDSe5RKl3yLXN81YqSuuuFZGQ/RNy9lv
mysKZpe40XC4Gic71UH5rxgK/NH9+++dnTNimGbudYkGqDsooutKUafZd+IA
wdtuzcBhak51KZhrlZmYfWk5QituCBNgzjay0+VMEfVNbTUDybQ4O6+59A6d
k0H699x52xOpoANDLcnrXLsnLPR3LrmI11Y7xLqQkkOoXufTIcTUl3DIH7HL
HCqEmARdCW4rriR2yLHHuOs5rcBldFigQsKxDQHD1LISLgKL7UnU1bWzOJil
s2DgZJx2mxO7W2zl5lE0mtsXGB+XMzlhLALyEmJ8omNoqpNjvRbJFzQntQ+i
ApjNULeeFWjJEx/q3YZrt1ZsJ5q9iKoJGcwYFuowiUzL96nva6TheDVMId48
qKbBjZbTSBRFXcDPQtjeOjCs1dTj41cOMis2QIRWHNXSbmiGkSaYW7N02nAt
dbkSVAWxVbDSfmwpZcC4IOjk5FrXzRs1xIRr5lce2Kp7GXbKm/hFxOD2+Aij
gD77gQlFoEubOtGTaEuLXIx1HA11DZS027T4JKZaGilDUr03Cqkc70xCUcx/
dqKrkPh4A3dymukIRz8choySz03wzHF9UgWbTgfoR619Km7JECoxTrSTEB6Z
IoMLGt5uZLpMIrvUhldZQpd3PER4S0iyn9UdjmMOYWVMgmhgDe5557G1wA8t
wUPWQEto3TbAJvMGGTRzf7DaeVD984YWk6Z8Fdmz/0R7PC21ZO1KMcXfgtSu
1832iaBhZxG53DJDaCjgOUXt0WBr8ID+t7W1tf1ksI14EbOGWPnF+4P7FkDy
6Mmj7fcWkqQBEGFPzAC2naNkVPatHCiMNfHJ07y7reNRyQ+BDyorpzvwY1y7
N4mq9XIpuaXVH3FWLHqw+6pJAoIdBykSm4S7sUc7t6zzmLlKdCYWK7qOWVf+
EipKtdLQOhLQehphKGkEFr/xdWi7GWq1CinZMDyyurR5CFLNFTZaVcjFLegP
qqt2FdhWstksXyCe8090q6ztobw5L8LTTQMb6HMnxNx85676dnwtGrcBRD7I
bxOqKm6UKIakXQf7Ztr2WQclIK7HF7nEh+sUeB/HHY3GoBTSBAhGHmhcqxaB
TsiPPmhcN8ydk2GanUHVtFA7HULzHLkaq9S3x5111DEKT2QgU6ddxzeXKaCW
bOczkqRe2O6o0N1V0TQsh+yAb8OQ0Ag8t3N8USNsQJAgprC+jbtxtpLi289h
rpC7bbE+o9wMLf7LY/8lm4YbY+SsBhdOpDk58BMJ9WG1p06Q7OSwsHU4Ufog
2M+lZ5YGNszFt+qiBlUwdXkGyjwJn1bO0WFuZjkNTjGELitNe6YelbYARwx9
tbslSdoREVASHHtr0EAWmt0OAikIoRgkiiTZzVGwbeLJGUViLJXYwChuzRmS
FDoolcQ0BiRuZW8PgXLdkdO9wV6uBvqNezhEzmHe4DfudOVqdg2LTwtiZSZl
ZeHunEjnRFuT++oo0FhQYb26Y2FRFpYr+twiP8sWFnLIl5DPAcdkiFONDiod
j5nocFLVnSvqoi5iZtAPDc8hNOdcVb7WJJV/rvKktNloh/Jx6b69+6mzkybG
H+yBgqE34e3WJZyIK6H2Eu/hY0N6mLxoMm4nPl6Ajs3gBkfxCQ29hurd6kQm
bbST+LG1U4/a5PC8RNVgfd7KNo5dXSiWOwq+Lq48mnMXnCZc/51jTlwpMHZ2
OzQAU9LXg/xTAyA2jAXIIZaWJ1JIGxtmfRXgS5hV6L2x6vkVYb51A7V/Azs0
T5tjCDoDPWf7nST941fd1JzWWCDw5pJI7VzQkxLGFY4KYuQBK8SGDv9rSfcJ
Ji/sHYRkrK0zoKx3x6OkovFwgAmT7A2W6+X4oURyfpknwYidPafU6LgoInUk
sYZhpKOlLehE83D6DETPl+asuGx7AUGBStaFibTU1+66r9bzufjV9SpFPXFl
racoflqXgt7glXyQmE5jgLLeTluERD47Z37WEq5heuyYfSKzb4ITMLj3KtVf
vPhxfDufVC+k2f0KFHyN5pQCCojj1FIKqMupBRauGDPaQgWJZI0unBf8Wi1t
oaGNQ2NDLxAdNQ6M5RKsimDeDDSzeg4uF9RXnGcQDbZ6lIzKn0SNy74hlVeu
gyu+Ny6niJFAOVqxLzieh9tnKXYI1w6JgZdP+LTaqMToYPlFluePqMJr1xzM
lfoRV16oZeVyi+uqE4gETG1H56VyUi5iznJzpZl/hca6SmybdRXYmBzEYJQo
bCNVoi5KC74BhkGdz6uk5HhR9vbKfpL2tjUQwUoYt4ZCgrZG5JSGsj2IpHh6
wldESZL71owUTcibGYyMutOBe5GHfUWYIg/EpkT7SvvMpdbl4PHYHbgK2Dhf
la+rhoZMa2Vnjlp7OADWIGmyUx+/wWOaogqLr4ktHNlnUy9KH8bJ+DqM8pVx
Cp7WOLRZxNsVHLE7bg/OOOLNxxC9ULriizcpfcstpEs6QxO3uJJUXQ2aZSyb
5TqZ79KopACBBOciAkNTmGRMH+Z0Bpzl98uPRXjz7nI0sM7t06GhGUAc4Cu+
9CVeLc2Zad5Y0vOLUmxYM9k1RKCdG4DAZZFfieQZmPTNuBCmNkly529+Kve5
ZsGOhFpuBYuph9QyWiwrGwtpC2i1XNAJr6Llw1ugZnhiG2IHvn4tVa58igRo
kaQXTRwcDeMS2eh0M7vKypuWp6KZS82HL4V9Ibqbqd/RDlFLeooPVVdJBjx1
v71a4fFylW7aCriVEvAmHjGsdHT0yN0qJhK4qbQQzDN3VTIlNqG/xbGk4WVl
k0UF0lLVeg4yK8+zwOGRs4tYflswIgONt3zwlibIiXn1rCzH5t3SbjXSvkqY
vKnZg7uzaCEWAEVY0lQKYpAX+bweyLzE96P+PPFqu4JLUSZOJbAFPvHE8poy
zrFZSg0pd7Oktlvt4DT8TeSLlI9d+N1LTW5+CaDe9Gk+Iblg/eXLpxsuqg7n
7JlRKqLvS02uwHdSB7TP0qX26cPxOgDiMEjQgiA2XXNJqHngYdBMRrkkuJ7k
M6JxHIPD5mbaX7xuu1VJXq4ydI4n5RBd2As153xMX1+qoSxp3hLvqIxKnQrJ
pIOMXJDa4r1t7BwflYhlLLSuRC2r2q0GfkbNw3lYlMszutV2iHXQg4RPh4P7
icsrWSP8lpjWvD4aWPRQ8oqk2kx8p7HpEilTLE13wwRDbApMg2w1S0IoBAm1
ysTOXmcXNBk96jwqePPYecN/cY1vB0ziEqCbTtLC5WTxy/7NXtww0w61DOlq
a1a80EP1YYipr+EtdrJAu3KZdBgtZpME2pkicVKtCUAykFR6D0olvEg3ycSa
iEZoFRzNNsBWwf82YS4zzS5ETWa2IoYgugoN8aipzq2Lp9EcuaunpH4r211o
ZeAOao47rdWOhGeckT39M3/WRRUYeijQ7eWMNDM6V1nQOFXbJcA2g3xpDMmd
MvPZL7KQa83Mb70Y5AOP4qIKguqZ0UWQ89Ty4HXIRPGboIR7oJp6aztOys2k
DcpGrXA9CCBMomQvJf6uXFURpJJlpNqIqHOeiboSBApmU5R0yhJNoHFKs3Xn
ymPCorisKnMyuGtCOjQUIEbrIT7rbPG7Z5xEZQYQhuEKwV+FpbKOyhBmqu4z
N7NGNGGdhy+UD5BbLlGX2M9h2wuwk+zwaQxCRxjJW+VPQbKqyi4HQuWtHCeM
WygVmiTIB85GYGwwRl7UmxTvu2LmKFajOBAI6SFYRUg859HblRPZkaeYjS6u
ssW4YisMMQZNQ+MTGgUWWORRdpUtVD6J201SXVYJeFGHmCU0+ZlLPbBoQH5v
ZEJ6jLRjUuibATg2U8VplrcCw/DkWm0lI59C04hKCTxAV+fXgZCrbXtcxDAz
84DFYSeUcHqp5X3zeR/nuKVaQNF7iQyFDOlXl7mV0msW1ZTacP/KGdogwOCw
6B0r//r5syaGYneDkuTA7gLOD6q07YU2EBPrpHEp2pmp/8ncGKS7sZNLkk94
AxKW1sHlfZhxmFnsZGq0aFKJz3gUIDCF00sKiYblK3uw+2pXwP3HCpxRKbOu
sIusgKqdEiHNyNhK8SE9aI5XzhMS1s5mfmfQ1qTHRIGs+HGGZ9jafvReJXMN
uZXMbLOWLPIz5PVywLfkpS9P+taHQPBXLlp31atqsX1Fi7Jv6p5ZJl3IIdeW
fivvgFphNbg67IXS3vFYxXC7R8wdDLxxrd0YxwJXazaQ67BkgMOm0BAdHMxK
hRF+j2iaQDl1YYR/WvlH9NefE24q/RSEmb6CesmoVgbpkgocOxw+on3jL44d
HNGrv8Uojn54yp20k48+pXvPe+ne2x7iHD+l/xliWyG6/B/0wzhXv8Eo+Ay8
e/sqPaQjBAMjDUVta0dvd18dpuskM+8UeX26w27eaofHu+HPQgBILechi82I
kMfWDvaPnq3oRk5XjgvtAF8c9l16YD7vRbWW2JnpBeeNDS85EUwNDf348X/Q
Et1/+PD+5890XOzssvF0RxabGGOI47Bja4qniQtDir3eSc/rel7t3Lt3dXU1
KLJZNigXZ/f8ra/uaVsHDJbMkfc76atSuvDBO+JmkNuMu0YyxFtNcg6v8S2r
6YCp/BKsvZHggVclEdLrJIweWus5IK+CdQ6xK3PGeFYnt85MKBxMOy7nv0ld
QHH8+EV/T0YMMzEOEVgx+GigcZiTTUeJEUsPu57dfvwKDPjYM+DPHTQIUjXr
q+z/1u0uTxu8W3aIJDYchHGy1uhqzQrGkhJTcC6syp9QfVsogC08uZUAc7ch
zwEDT+iRXfB4YKhCf/C0E+YuIEj30l3PjiQ6tQWDd/cx31aAAWPe/LC56Udy
+Hy3v/3wkf9ge7D1aPD4wSYiyjYRXyb4Q58kemz7/oP3q6D70PJW2qd/nj6j
59/NHAeQllf80BgibJa3FgkTtby/yS3vP5M6KVB9xq6BlS3ve1vxJH3XrKwi
LT+Tlp99WctvEBVAdKvVqLX8C3fw9lPHN/xpLsIuDZXnWK9XGyYyhnq4GuKI
NkLqckfznKMcxFKTxNA4qhZVy6J2tuyloGxlJChdz+vybJHNSa5tXlNm/LMy
EbsgiajFFLl5DMg5oVvOrTNihwsm1z9ZPRln/LjEEXgYapNelc54xSgiNk70
/4UUpyvqqkF2unpeU/uPZ2qw4oS2fVa2iAr1xezFOjbDKUV4Za7tw9E5qQ9O
busJJKIJwijaEepYpjMRh6A9JgFWQ50Qp7WbTrN/QucZI4uXN0IZAun/E4Yi
cVXu2aVSF1UejumqXLBSf0YK6txFQ/mDl7iDN5Dp5bJi6ZDowIPN+0PHuOqr
YpQjcqwJkATjJavlHF2CKLcL/kJ0fQxEEN4VyckiMorAF3Zqxaj9uvgsi9F5
CTAVQ9dUoNmEHbFqmhdrTVRgY07/cq4rSTEzDwruYXAHxmX1/OhutxhQF//5
BVf+F9KJT61TFXIrIbztI72K4vmXvox3/ZHzBWfbFGpOB3C7PfQGS7rLz23c
SaBwR+MqOyZBa06sdLFFOnRGv6zLPdgAH9p7eribrr86IAX8Dfitgko2uG/c
8U/PDt4cbj1+1O9kuXfq9ykk8SkdTFIhRytH8fzl7l6fhsIjUUb/5JsnNzL6
B5sPZKEfb7aG/zsu9Hj74cOtJ+vc7zcb7Tb25YF0/Q2d6v0x5utBxcdshZIH
Rku6yRu60FBeN+9v3zjhx5uPRU54SpLCbzNhIaA0U7aMdvf7bF9P9LP9rn4b
AssX9HubVPTM+n32m/X7ZTLTH0c5fl+JqqffCXN0x6QuNdHpNhkgWed+WZTh
WOi2LBMaYDZ6N4pwSSzCdcg9FncqWD2KgAQDEMeb2qcSYHaMNIcvErSG7XaH
TUmro+tuQWuFnOWqhzA/GAzwLx1i1tH12FbqydDcGkllFEPbkgbtPOHp5Xbi
ovkEmLIb4ODXygQ3ndIv1UTltrHNDsPW5Yyv75fy8F87vpA3b3bpWtHYXaZS
NyVRXdPrsXgnSt5ptOdNbze2txW+08z8+QXtRe8E+Xet+d6xvftd42s3eef2
HoTvdGAvfWl7D8P2umrlfWF7gWTxKW3EtwdzvnN736h14lmHfSJ8/o4WiU2z
Sdx6nu9mhwg57s3tfTkn/XX391YOuRAZhpmj2Axjq4JH2te0HmihUjWDffkc
/eEfit1oooox/rm4DpVFodbKLjxQ2agOXALOcPzxKzi0Mn3C54kdG5X+IsYV
OUMaPCtdo7Ek7bF8oXGytRl/vjN9jV01fIYFil0ODA7Kryb7dx9NQO3bt+1T
OruX/fpLZs38yrtlzfzKK3XXteGbtEadrMEqtpzO7AYp3I1hKbFNQ60xXuiR
Q8fhaWsklqwZzoGLrfcOXRP6gDoq6x6mdrqcVIF2XTs8ev5ljUlZPZTiHvzb
UQeIgCaBJZ0RNQFUSRVZz9TWg82gZ9iprS58HpNfEcW1hxKwztlDtIIur2Aj
IFAHT6smRSrGv4gCaWshycHfa73kC0nM6lN8258dB/qTjqvj0gjpwddWRUf/
fM2lLGixfrU16deP3rDOHm892SYSYX9uPbr/+H5TSmj9+YzT0vcQoSG/Hkbu
g7D5zcFm0Dz9+fOfOhr80vZ/39VhUJnXOMFRVUZWjKJ1o1MbL5yP54WlO0MM
RgIiomdWEwHYGm4WblKiOL4VR/1xD62+5tMeFUgSXXrmCkS4UkXJg7Qc1Xlt
5MgvNOl2I3lNikuEY0q7xzTj0irxsCRIEzFU7JHY2n4sKxMvBnY5WAz6e2v7
G6va1h61tBcMnetMamg/EzeLaUcwlQ+qzezSWUiPRbhKhrmDXXzBoZ/u9gW1
c0OQHo+4GF7OryvhSaNay5txlHWTWAlgOEe5uTzjUjMG/DB1ld1ANLomCAsI
jP5VLnhzopX78n03jL4d3SK42K7gIe8SLPilzq4Khlkz0pFOVvlO5SKAAke3
oATGzcB15TOpEOgk0wjeDEdejDkzVNhJR1GFLD2blCfZRFOgSyH9mgxhkT9S
5k5sMu0QnygQQRz7GovgBsSMnit39/g0rwUtroUzVqlMMhXkLIYTwwZ1i3ED
jW9qGkRc9mkYB8IBvrzlTX7159YvSrafMRIjR/+oqSO2a3y6YzsOmQHMSPG8
41CdT1ydF59zFyueWbieVz5zh/Ew6VJGrsKeOPgc9ExPg8xduhjkFEHbX7l2
q3+aq3EQrsZLP+1VvP329b5739Nsonke2FG2pQk9kUogWl2HgcnHg9b6n2Tj
Q19Q+1Nc4BZRlzknOYkdtogQQoEK4T5vxD/7mWpv2teRrwD5ybCNgl62uM3t
7nf3AChh77JRc1V1XY0WZYlUBiUV9vBBXCvYsJGBuzJ2TTUL+8rFQ2/EVuvR
oGNswdw/RZVPuqr62TgtbleWcD0fnA16VqCYCCWSq4XzbTR6XEpVSinBaMsh
pevbq7FeSq5YsDoxbHGvtTAbokfJOjrDuF8RYZcMfuBKKUWVluPhWmxsGu6e
ZlDNyhQYbjhi3BLXynIjqRot8Sb4mpxyjPhDnteJYGux21lKrMqTyJeAGKKT
kKSImY8R5fya5qD5TIR94Xbwh7++r66uBBhM5NW4q4ru+MTVA5Xp3lwRNKY2
QVeIPWnMyWEI2Z3h+BSWluS5SZ6dpusWexBVbWbN7do9GVMHiV2eIttjvNGc
M+ylh8W/chtMOJBft41fuCK/R5nXqIPfo+Br2MGv4h8I0kS4ndchu6RC/lJM
LCcstwbs33HUtcOXB8mh1duC0PPmbwf/SF+W4yUSxNwbQSQ0nHnyuVQ8Z0xn
opv8Boe2ZtVs61g++Py5VY8pbQZNJ0+lTKoIAYOQs69emtgglcD9L43gN1/k
rLEBxsKraA++oBcJh2YT/bhPU+yLjac/46jR/uV2bKD/Rb0goN9tSTOo/+9Y
PK6IKcW7GKBHUS41gcginTKFjvXQYudc8SXIKkwg0UOGd4Co5rF1NjNRfJCV
r6G6F/mkIB3AZ7ZdM+ZKomqI1srKY2ByBazUNC5NjKqcJNLslZPfszhrq7Y6
AJr9JjA4DShaRMK7bApNEDUgswgw+f9t7vqe00aS8Lv+iqm7F1wFPkPixFk/
YcAxibFdhttNnrZkJGOdBfJJEIek8r9ff909o5EQifeqruq2KlsGpPnR09PT
PTP9fecyAxLNM9wt02XfKrucDU5pnePZ1ACayP7+Qxgp+C44nCRMSlR4Po8Y
39sCMiAeDmSs2sL9Jgffcltr0JcB+JI9IrJplC4uwOlUKiXo/CFHBizTEDSr
iwcL8O/vB7oeC7Yw0NEEaUQShe3FsMI6YNQ0eZKfoqCAF5mytTXxKN265nuw
d+Pntzrad9WjzYrqWtTUSLUAYC8BmX4oPb8nmw7OJKNrZKBsFhcSbKo+HSig
hb9P0tm2JbU9rBIoeub2giCFy4M+Y/WAr9BOroz5zdJKXoQDWNtSRLpUoBc3
YH4CURBMGqdJLY2IN3DEwqSMcbKIXeY5cKIzh3oX2JnE+7PWR7V4c6jF0lQe
mp9VHWVanCKd1iDJ5JajrJ/h2m5wy8/uMn1Dymg7ILFunGVSN1JZfhmFKbcg
/7Lv4JL1ObFO1IqNh+JaBUrLhbuegsvENU+GCv6hTRAwCh4XzEblQJLdNW8y
BZU0UMnhZWW2rMRCGFcDveA820SvfNr6ZdRxF21uN7CsvCXi5RmkI0fvLIs4
BX9fxG/ssZ6nYmb1qianfRkQ3iqyBZKgw1wyPa0BUTAemSRt4RKUJGhUWlof
lXzyxdogSwxiW8J5o9w4mx8yKdNGsdPFZJT1TFJkKjPLIgnTsRRCbywx4HO4
pUVhJHBEhQVc+o1zvzX91ku+x10eb4isBzFlWl3fl5tZWA779WR4akrUuRJa
vQ0QonvSXv4aRzaFjTb9ojAlHBo7G1eI7h9Ciud+CVT8p4xqr14trExmkV1I
tU8NNvccRrKXwKnYFIuqIp4KdFgpDwtgHQpMoz1FcznrftTcVCCN3u9JllbQ
Ckg+XA64GP2RRoDA4+dQvf/rfO8SASm705NIBteUW/G8uAj3G3YEiy3Fonm2
AoCCpNvGkUvmjdiZhXl4qrG0mwsyEqRYbbkqxdSWa0bF0AioBmxYvIQ2rEle
TTAXdj2UBH9d3llreV/dUmT6onVpvA7dATvaSrCHFQezPGRHVSsWhAjeZqRi
HlbJv0GhUvJ2L7CQPbX/pjsFIU9pLAShEFwVZLdhGVa8uxTYdEbI6DC4UQiF
CiYPJiuMyTxEjvmzXj77bRdsg5eCZyooUNMFvWfkSoYII514wMgwoiHPtZpM
98jtNBBkIYduExpq5loiXV2s1MVZhhasCRoyD1MAozjsa8DnPPnpFT9pyx4Y
k4Gfua3YaEj1lgt1umJgEsFPgjrQn0gW1YkYOFyrkp2TYUpyKcA5H3zNv/Th
mBsXqdqMkeqsTZkVfygGWLOJSWjJQjb5sRsNimvStdgiHnWU1TyqXJQu7VDB
dzELbLDh4Rtus1w/lG0xjnQhYQuCLtgqHMjP194OkKpZ9a2AESR33uI7WAWo
PM1IT7/kXMRdRWRRqYwLWsFix/li06TVrIB7lLckawj+d5YqjMVbo1lTyxa4
3y1M5A7jsqN2/dOO4p/KvXy2beZ95RZh1KqsrHrOp8pZri+smiXUZeHHXTE9
xHN6JTidPMk5o8gI8HwzvbFlJKiyRSvgqrmMw0fNlhleTX00d3JQQ+R9ww67
uKASLMKFJpuyEiBSvWmgwOgo0EMDVAwOF1bIKD0jB+cOXJ+FZPorNTS5gAif
aNi0CHK54lTyaMATEqY+I7pXPYSeaGRVZPfr51BZx0v2+bJQ4HkWgIbQKw/k
LmzylbbxPpzjdgVPpZCcWIZJ0WwuRsiYw/CmcbSQ0yLNtWeaG2sqESgriMjq
0Yzy53C1Mn3qSRy2zW12RzX20yimQKi/ivL42fS3sJK31Jowj4IzEi3mYj81
gw0FtPTTkOxyZIb5tohCIKGdU+gxp34MN08Z6O76Ubg0o+RfVOgdud5tM13H
T8BEOA/Jx0tTlLBK4tR8DB9W5j3580vsMt+Em9RchBEfSrXNWU7O5UWCxz+Q
0tHKGoGNgh8LLkiblyDxxU85uaQXm/W3OOWvPtIQf8i2OD3Wis1HOFpmOkE3
4q/0+CROV8lj9qVtLpPVpgiusjyStg4eyF5RJekSXZ0hhMzNTZzTlKK6yauh
sbwhUcab+zZJkwzXbUz6kqehyMxMw/RbO6AKklUUmukD43/ebrGApHH8JWlT
XEITnz6SNaD4dxDmqfmDwotQVYbl8AcpEyYu9h9kJWasUPj87CYlZImxqSK4
VMlCh3ebbTDW0y3AqeI5ax0F8IAWJKeldPrKU/R1eW6PQ/sSDXVTeIgMHlJG
p9PhJYd3hwRSg1cwR2NQJJjkJCHBMmu52Yzcj+9/r1EX0JrmX5Hyo1ie3hYD
BRNUznmoppYicKlDWnIsYMmgJtR+r3ThoG1B8ergI3zyvbJ4KamdwAhpe2rL
7KGYkkZprCsX2rE8z6zJbwMPVzxBJvhVXJMq2UO73MypLQjtoCpFbnPl3nwM
vJFchqi03GS028KExfWA78xHgeUlUCun5taoJ9AYebcSj9dpQRg5Sol/ECif
k8yrJ3jUMVtmmSxQJxut8R7Itn3grd02LbL6XMsS7EEc1Wp3SBGwoaxcHN3D
KhmHQMZSEZxhqIkJFZgzX4OC8m68oobVtpKFL4mGhBcq3QUoKT5U4mRhRXNy
3u9sgAIVkmFebMPV7mAYpeKpU4dwuoRQctirB4PJtH6uusvuUBs2hZ9RRyVZ
C128KL/cWRyhanFwlR3KjXTjsO4OCehi97NCciX/LPROYm3o/ZsVLxh8kJXv
Gf5qN7mT3aZO2hn3sr559YH6hRrgKuRycYuzsWMtWftpKS8JGKtzk/VVjM5a
qEmY8XRHQcQrUH5Le3pSt8D+sUg9w6dyiKIxK60E95u0AoqdMQNGhVrS65Bv
xX/vSSs6vaNeNzC0eHzfe2QhjiiuVbRlAOW/pMha3QOPz6OT5QvyIL6x49V6
dWAODw/5aYYt+xEMR+fjq/FsfA1fcnJzOR6MZ2bWfz9ldsyz0fvxFdYxM/p0
c307m5r+5SU1LAjoWXymokafZqOrKRVAf5/fXk/4NKozyJZLuexdUHdI8lQG
jbA5ftftcf3fX9DWKItabw400zle09Pa0UKPWlrHBx48OT49PSZfW28PVG6t
I/uGlSP9LE3rHPVax/TgDwClDq6vqBOzzuzzzch2Y+Anok2E4Uu4P6lD3SNj
e/Sm9+ak2qMlrE7eucuibasHKqvWyeujA5MXYVQkrW731fHrd2jpvCh7hE+d
dy36vlhSLNnqUr9FtQrqhG3+fCnSbB2faMur08Mfgu7oK67pJev/N/l3O7Ft
Gcagi56cQsmgZ6Vd6B0aimcrRhfPBPN1Z31X+DbBHz1W2+8QDD7sSGc8pAfH
5+PR0Jx9RqN2SyOxNn5/ffZhRE6LK+FWqjJd88rAI3x7glervXgLa/oXaJO5
g2TjO/4RBd4oZ5nroJl+vpr1P/2c4xbP7fY53ikfzw1uyQ4M+pfj2Wfq1nn/
cjoyP6w4dl/5tUCO8fJfpOBtECBEuIdL18kLjLr/W6FBc5ur+ZXs9r/ZLMJA
pkvTKNWkc0KywTT5JZ2fk5P1h2ih7AxmtHDuF5EkUvhLld3jAsnxPsWqV/AC
xdpp0x7FQlHQrTf0/9f0jwnlTI/+7qGwn7e3QdNGV8PquvwfsjTIkZiiAQA=
</rfc> </rfc>
 End of changes. 191 change blocks. 
3878 lines changed or deleted 3145 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/