rfc9321xml2.original.xml   rfc9321.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc [
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.5 (Ruby
2.6.8) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2119.xml">
<!ENTITY RFC3125 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.3125.xml">
<!ENTITY RFC3161 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.3161.xml">
<!ENTITY RFC3647 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.3647.xml">
<!ENTITY RFC5035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5035.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5280.xml">
<!ENTITY RFC5652 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5652.xml">
<!ENTITY RFC6931 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6931.xml">
<!ENTITY RFC7515 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7515.xml">
<!ENTITY RFC7518 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7518.xml">
<!ENTITY RFC7519 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7519.xml">
<!ENTITY RFC8610 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8610.xml">
]> ]>
<rfc ipr="trust200902" docName="draft-santesson-svt-08" category="info" submissi <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
onType="independent" tocInclude="true" sortRefs="true" symRefs="true"> -santesson-svt-08" number="9321" submissionType="independent" category="info" to
cInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang=
"en" version="3">
<front> <front>
<title>Signature Validation Token</title> <title>Signature Validation Token</title>
<seriesInfo name="RFC" value="9321"/>
<author initials="S." surname="Santesson" fullname="Stefan Santesson"> <author initials="S." surname="Santesson" fullname="Stefan Santesson">
<organization abbrev="IDsec Solutions">IDsec Solutions AB</organization> <organization abbrev="IDsec Solutions">IDsec Solutions AB</organization>
<address> <address>
<postal> <postal>
<street>Forskningsbyn Ideon</street> <street>Forskningsbyn Ideon</street>
<city>Lund</city> <city>Lund</city>
<code>223 70</code> <code>223 70</code>
<country>SE</country> <country>Sweden</country>
</postal> </postal>
<email>sts@aaa-sec.com</email> <email>sts@aaa-sec.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<street>516 Dranesville Road</street> <street>516 Dranesville Road</street>
<city>Herndon, VA</city> <city>Herndon</city>
<region>VA</region>
<code>20170</code> <code>20170</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date year="2022" month="October"/>
<date year="2022" month="May" day="17"/> <keyword>digital signature</keyword>
<keyword>electronic signature</keyword>
<area>Security</area> <keyword>long-term archive</keyword>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>Electronic signatures have a limited lifespan with respect to the time period that they <t>Electronic signatures have a limited lifespan with respect to the time period that they
can be validated and determined to be authentic. The Signature Validation Token (SVT) can be validated and determined to be authentic. The Signature Validation Token (SVT)
defined in this specification provides evidence that asserts the validity of an defined in this specification provides evidence that asserts the validity of an
electronic signature. The SVT is provided by a trusted authority, which asserts that electronic signature. The SVT is provided by a trusted authority, which asserts that
a particular signature was successfully validated according to defined procedure s at a particular signature was successfully validated according to defined procedure s at
a certain time. Any future validation of that electronic signature can be satisf ied by a certain time. Any future validation of that electronic signature can be satisf ied by
validating the SVT without any need to also validate the original electronic sig nature or validating the SVT without any need to also validate the original electronic sig nature or
the associated digital certificates. SVT supports electronic signatures in CMS, the associated digital certificates. The SVT supports electronic signatures in C
XML, ryptographic Message Syntax (CMS), XML,
PDF and JSON documents.</t> PDF, and JSON documents.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro">
<section anchor="intro"><name>Introduction</name> <name>Introduction</name>
<t>Electronic signatures have a limited lifespan regarding when they can b
<t>Electronic signatures have a limited lifespan regarding when they can be vali e validated
dated
and determined to be authentic. Many factors make it more difficult to validate and determined to be authentic. Many factors make it more difficult to validate
electronic signatures over time. For example:</t> electronic signatures over time. For example:</t>
<ul spacing="normal">
<li>Trusted information about the validity of the certificate containing
the signer's public key is not available.</li>
<li>Trusted information about the time when the signature was actually c
reated is not available.</li>
<li>Algorithms used to create the electronic signature may no longer be
considered secure at the time of validation and may therefore no longer be avail
able in software libraries.</li>
<li>Services necessary to validate the signature are no longer available
at the time of validation.</li>
<li>Supporting evidence such as certification authority (CA) certificate
s, Online Certificate Status Protocol (OCSP) responses, Certificate Revocation L
ists (CRLs), or timestamps is not available or can't be validated.</li>
<t><list style="symbols"> </ul>
<t>Trusted information about the validity of the certificate containing the si <t>The challenges to validation of an electronic signature increase
gner's public key is not available.</t>
<t>Trusted information about the date and time when the signature was actually
created is not available.</t>
<t>Algorithms used to create the electronic signature may no longer be conside
red secure at the time of validation and may therefore no longer be available in
software libraries.</t>
<t>Services necessary to validate the signature are no longer available at the
time of validation.</t>
<t>Supporting evidence such as CA certificates, OCSP responses, CRLs, or times
tamps.</t>
</list></t>
<t>The challenges to validation of an electronic signature increases
over time, and eventually it may simply be impossible to verify the over time, and eventually it may simply be impossible to verify the
signature with a sufficient level of assurance.</t> signature with a sufficient level of assurance.</t>
<t>Existing standards, such as the ETSI XAdES <xref target="XADES"/> profi
<t>Existing standards, such as the ETSI XAdES <xref target="XADES"/> profile for le for XML
XML
signatures <xref target="XMLDSIG11"/>, ETSI PAdES <xref target="PADES"/> profile for PDF signatures signatures <xref target="XMLDSIG11"/>, ETSI PAdES <xref target="PADES"/> profile for PDF signatures
<xref target="ISOPDF2"/>, and ETSI CAdES <xref target="CADES"/> profile for CMS signatures <xref target="ISOPDF2"/>, and ETSI CAdES <xref target="CADES"/> profile for CMS signatures
<xref target="RFC5652"/> can be used to extend the time within which a signature <xref target="RFC5652"/>, can be used to extend the time within which a signatur
can be e can be
validated at the cost of significant complexity which involves storing and validated at the cost of significant complexity, which involves storing and
validating significant amounts of external evidence data such as revocation data , validating significant amounts of external evidence data such as revocation data ,
signature time stamps and archival time stamps.</t> signature time stamps, and archival time stamps.</t>
<t>The Signature Validation token (SVT) defined in this specification takes a <t>The Signature Validation Token (SVT) defined in this specification takes a
trusted signature validation process as an input and preserves the validation re sult trusted signature validation process as an input and preserves the validation re sult
for the associated signature and signed document. The SVT asserts that a particu lar for the associated signature and signed document. The SVT asserts that a particu lar
electronic signature was successfully validated by a trusted authority according to electronic signature was successfully validated by a trusted authority according to
defined procedures at a certain date and time. Those procedures MUST include che cks defined procedures at a certain time. Those procedures <bcp14>MUST</bcp14> inclu de checks
that the signature match the signed document, checks that the signature can be v alidated by that the signature match the signed document, checks that the signature can be v alidated by
the signing certificate and checks that the signing certificate pass certificate the signing certificate, and checks that the signing certificate pass certificat e
path validation <xref target="RFC5280"/>. path validation <xref target="RFC5280"/>.
Those procedures MAY also include checks associated with a particular trust poli cy such as Those procedures <bcp14>MAY</bcp14> also include checks associated with a partic ular trust policy such as
that an acceptable certificate policy <xref target="RFC5280"/> <xref target="RFC 3647"/> was used to issue the that an acceptable certificate policy <xref target="RFC5280"/> <xref target="RFC 3647"/> was used to issue the
signer's certificate and checks that an acceptable signature policy was used by signer's certificate and checks that an acceptable signature policy was used by
the signer <xref target="RFC3125"/>.</t> the signer <xref target="RFC3125"/>.</t>
<t>Once the SVT is issued by a trusted
<t>Once the SVT is issued by a trusted
authority, any future validation of that electronic signature can be satisfied b y validating authority, any future validation of that electronic signature can be satisfied b y validating
the SVT, without any need to also re-validate the original electronic signature. </t> the SVT without any need to also revalidate the original electronic signature.</ t>
<t>As SVT is used to preserve validation result obtained through applying existi ng <t>As the SVT is used to preserve validation results obtained through applying e xisting
standards for signature validation, it is complementary to and not a replacement for such standards, standards for signature validation, it is complementary to and not a replacement for such standards,
including the ETSI standards for long term validation listed above. including the ETSI standards for long-term validation listed above.
SVT do however have the potentially positive effect that it may significantly re The SVT does, however, have the potentially positive effect that it may signific
duce the need to antly reduce the need to
apply complex long-term validation and preservation techniques for signature val idation apply complex long-term validation and preservation techniques for signature val idation
if an SVT is issued and applied to the signed document at an early stage where t he signature if an SVT is issued and applied to the signed document at an early stage where t he signature
can be validated without support of large amounts of external evidence. can be validated without support of large amounts of external evidence.
The use of SVT may therefore drastically reduce the complexity of re-validation of old The use of SVTs may therefore drastically reduce the complexity of revalidation of old
archived electronic signatures.</t> archived electronic signatures.</t>
<t>The SVT can be signed with private keys and algorithms that
<t>The SVT can be signed with private keys and algorithms that
provide confidence for a considerable time period. In fact, multiple SVTs can be used provide confidence for a considerable time period. In fact, multiple SVTs can be used
to offer greater assurance. For example, one SVT could be produced with a large RSA to offer greater assurance. For example, one SVT could be produced with a large RSA
private key, a second one with a strong elliptic curve, and a third one with a q uantum private key, a second one with a strong elliptic curve, and a third one with a q uantum
safe digital signature algorithm to protect against advances in computing power and safe digital signature algorithm to protect against advances in computing power and
cryptanalytic capabilities. Further, the trusted authority can add additional SV Ts cryptanalytic capabilities. Further, the trusted authority can add additional SV Ts
in the future using fresh private keys and signatures to extend the lifetime of in the future using fresh private keys and signatures to extend the lifetime of
the, the SVTs if necessary.</t>
if necessary.</t>
</section> </section>
<section anchor="defs"><name>Definitions</name> <section anchor="defs">
<name>Definitions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", <t>
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> < IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
xref target="RFC8174"/> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
when, and only when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>This document use the following terms:</t> <t>This document use the following terms:</t>
<t><list style="symbols"> <dl>
<t>Signed Data -- The data covered by a particular electronic signature. This <dt>Signed Data:
is typically </dt>
equivalent to the signed content of a document, and it represents the data that <dd>The data covered by a particular electronic signature. This is
the typically equivalent to the signed content of a document, and it
signer intended to sign. In some cases, such as in some XML signatures, the sign represents the data that the signer intended to sign. In some cases,
ed data such as in some XML signatures, the Signed Data can be the collection
can be the collection of several data fragments each referenced by the signature of several data fragments each referenced by the signature. In the
. In the case of PDF, this is the data covered by the "ByteRange" parameter in
case of PDF, this is the data covered by the "ByteRange" parameter in the signat the signature dictionary. In JSON Web Signature (JWS), this is the
ure unencoded payload data (before base64url encoding).
dictionary. In JWS, this is the unencoded payload data (before base64url encodin </dd>
g).</t>
<t>Signed Bytes -- These are the actual bytes of data that were hashed and sig <dt>Signed Bytes:
ned by the </dt>
digital signature algorithm. In most cases, this is not the actual Signed Data, <dd>These are the actual bytes of data that were hashed and signed by
but a the digital signature algorithm. In most cases, this is not the actual
collection of signature metadata that includes references (hash) of the Signed D Signed Data but a collection of signature metadata that includes
ata as references (hash) of the Signed Data as well as information about
well as information about algorithms and other data bound to a signature. In XML algorithms and other data bound to a signature. In XML, this is the
, this canonicalized SignedInfo element. In CMS and PDF signatures, this is
is the canonicalized SignedInfo element. In CMS and PDF signatures, this is the the DER-encoded SignedAttributes structure. In JWS, this is the
DER-encoded SignedAttributes structure. In JWS, this is the protected header and protected header and payload data formatted according to <xref
payload target="RFC7515"/>.
data formatted according to <xref target="RFC7515"/>.</t> </dd>
</list></t> </dl>
<t>When these terms are used as defined in this section, they appear with a <t>When these terms are used as defined in this section, they appear with a
capitalized first letter.</t> capitalized first letter.</t>
</section>
<section anchor="svt">
<name>Signature Validation Token</name>
</section> <section anchor="svt-function">
<section anchor="svt"><name>Signature Validation Token</name> <name>Signature Validation Token Function</name>
<t>The Signature Validation Token (SVT) is created by a trusted service
<section anchor="svt-function"><name>Signature Validation Token Function</name> to assert
<t>Signature Validation Token (SVT) is created by a trusted service to assert
evidence of successful electronic signature validation using a well-defined and evidence of successful electronic signature validation using a well-defined and
trustworthy signature validation process. The SVT binds the validation result to trustworthy signature validation process. The SVT binds the validation result to
the validated signature, the document signed by the signature and the certificat e of the signer. the validated signature, the document signed by the signature, and the certifica te of the signer.
This allows a relying party to verify the validity of a signed document This allows a relying party to verify the validity of a signed document
without having to re-validate the original signature or to re-use any of its ass ociated without having to revalidate the original signature or to reuse any of its assoc iated
cryptographic algorithms for as long as the SVT itself can be validated. cryptographic algorithms for as long as the SVT itself can be validated.
The SVT achieves this by binding the following information to The SVT achieves this by binding the following information to
a specific electronic signature:</t> a specific electronic signature:</t>
<ul spacing="normal">
<li>A unique identification of the electronic signature.</li>
<li>The data and metadata signed by the electronic signature.</li>
<li>The signer's certificate that was validated as part of electronic
signature verification.</li>
<li>The certification path that was used to validate the signer's cert
ificate.</li>
<li>An assertion providing evidence of signature verification, the tim
e the verification was performed, the procedures used to verify the electronic s
ignature, and the outcome of the verification.</li>
<li>An assertion providing evidence of the time at which the signature
is known to have existed, the procedures used to validate the time of existence
, and the outcome of the validation.</li>
</ul>
<t>The SVT aims to support long-term validation that can be further exte
nded into the future by applying the following strategies:</t>
<ul spacing="normal">
<li>by using secure algorithms with long life expectancy when signing
the SVT</li>
<li>by reissuing the SVT before it becomes insecure or is considered e
xpired</li>
<li>optionally, by issuing multiple SVTs with different algorithms to
provide redundancy in case one algorithm is broken</li>
</ul>
</section>
<section anchor="svt-syntax">
<name>Signature Validation Token Syntax</name>
<t>The SVT is carried in a JSON Web Token (JWT) as defined in <xref targ
et="RFC7519"/>.</t>
<section anchor="svt-syntax-dt">
<name>Data Types</name>
<t>The contents of claims in an SVT are specified using the following
data types:</t>
<t><list style="symbols"> <dl>
<t>A unique identification of the electronic signature.</t>
<t>The data and metadata signed by the electronic signature.</t>
<t>The signer's certificate that was validated as part of electronic signature
verification.</t>
<t>The certification path that was used to validate the signer's certificate.<
/t>
<t>An assertion providing evidence of that the signature was verified, the dat
e and time the verification was performed, the procedures used to verify the ele
ctronic signature, and the outcome of the verification.</t>
<t>An assertion providing evidence of the date and time at which the signature
is known to have existed, the procedures used to validate the date and time of
existence, and the outcome of the validation.</t>
</list></t>
<t>The SVT aims to support long term validation that can be further extended int <dt>String:
o the future by applying the following strategies:</t> </dt>
<dd>JSON Data Type of string that contains an arbitrary
case-sensitive string value.
</dd>
<t><list style="symbols"> <dt>Base64Binary:
<t>By using secure algorithms with long life exepectancy when signing the SVT. </dt>
</t> <dd>JSON Data Type of string that contains a Base64-encoded byte
<t>By re-issuing the SVT before it becomes insecure or is considered expired.< array of binary data.
/t> </dd>
<t>Optionally, by issuing multipple SVT:s with different algorithms to provide
redundancy in case one algorithm is broken.</t>
</list></t>
</section> <dt>StringOrURI:
<section anchor="svt-syntax"><name>Signature Validation Token Syntax</name> </dt>
<dd>JSON Data Type of string that contains an arbitrary string or
a URI as defined in <xref target="RFC7519"/>. It is <bcp14>REQUIRED</
bcp14> to contain the colon character (":") to be a URI.
</dd>
<t>The SVT is carried in a JSON Web Token (JWT) as defined in <xref target="RFC7 <dt>URI:
519"/>.</t> </dt>
<dd>JSON Data Type of string that contains a URI as defined in
<xref target="RFC7519"/>.
</dd>
<section anchor="svt-syntax-dt"><name>Data Types</name> <dt>Integer:
</dt>
<dd>JSON Data Type of number that contains a 32-bit signed integer value (from
-2<sup>31</sup> to 2<sup>31</sup>-1).
</dd>
<t>The contents of claims in an SVT are specified using the following data types <dt>Long:
:</t> </dt>
<dd>JSON Data Type of number that contains a 64-bit signed integer value (from
-2<sup>63</sup> to 2<sup>63</sup>-1).
</dd>
<t><list style="symbols"> <dt>NumericDate:
<t>String -- JSON Data Type of string that contains an arbitrary case sensitiv </dt>
e string value.</t> <dd>JSON Data Type of number that contains data as defined in <xref
<t>Base64Binary -- JSON Data Type of string that contains of Base64 encoded by target="RFC7519"/>, which is the number of seconds from 1970-01-01T00:00:00Z UTC
te array of binary data.</t> until the specified
<t>StringOrURI -- JSON Data Type of string that contains an arbitrary string o UTC date/time, ignoring leap seconds.
r an URI as defined in <xref target="RFC7519"/>, which REQUIRES a value containi </dd>
ng the colon character (":") to be a URI.</t>
<t>URI -- JSON Data Type of string that contains an URI as defined in <xref ta
rget="RFC7519"/>.</t>
<t>Integer -- JSON Data Type of number that contains a 32-bit signed integer v
alue (from -2^31 to 2^31-1).</t>
<t>Long -- JSON Data Type of number that contains a 64-bit signed integer valu
e (from -2^63 to 2^63-1).</t>
<t>NumericDate -- JSON Data Type of number that contains a data as defined in
<xref target="RFC7519"/>, which is the number of seconds from 1970-01-01T00:00:0
0Z UTC until the specified UTC date/time, ignoring leap seconds.</t>
<t>Boolean -- JSON Data Type of boolean that contains explicit value of true o
r false.</t>
<t>Object&lt;Class&gt; -- A JSON object holding a claims object of a class def
ined in this specification (see <xref target="svt-syntax-claim"/>).</t>
<t>Map&lt;Type&gt; -- A JSON object with name-value pairs where the value is a
n object of the specified Type in the notation. For example, Map&lt;String&gt; i
s a JSON object with name value pairs where all values are of type String.</t>
<t>Array -- A JSON array of a specific data type as defined in this section. A
n array is expressed in this specification by square brackets. For example, [Str
ing] indicates an array of String values, and [Object&lt;DocHash&gt;] indicates
an array of DocHash objects.</t>
<t>Null -- A JSON null that represents an absent value. A claim with a null va
lue is equivalent with an absent claim.</t>
</list></t>
</section> <dt>Boolean:
<section anchor="svt-syntax-claim"><name>Signature Validation Token JWT Claims</ </dt>
name> <dd> JSON Data Type of boolean that contains the explicit value of true or
false.
</dd>
<t>The SVT MUST contain only JWT claims in the following list:</t> <dt>Object&lt;Class&gt;:
</dt>
<dd>A JSON object holding a claims object of a class defined in this
specification (see <xref target="svt-syntax-claim"/>).
</dd>
<t><list style="symbols"> <dt>Map&lt;Type&gt;:
<t>jti -- A String data type that is a "JWT ID" registered claim according to </dt>
<xref target="RFC7519"/>. It is RECOMMENDED that the identifier holds a hexadeci <dd>A JSON object with name-value pairs where the value is an object of the
mal string representation of a 128-bit unsigned integer. A SVT MUST contain one specified Type in the notation. For example, Map&lt;String&gt; is a JSON
"JWT ID" claim.</t> object with name-value pairs where all values are of type String.
<t>iss -- A StringOrURI data type that is an "Issuer" registered claim accord </dd>
ing to <xref target="RFC7519"/>, which is an arbitrary unique identifier of the
SVT issuer. This value SHOULD have the value of an URI based on a domain owned b
y the issuer. A SVT MUST contain one "Issuer" claim.</t>
<t>iat -- A NumericDate data type that is an "Issued At" registered claim acco
rding to <xref target="RFC7519"/>, which expresses the date and time when this S
VT was issued. A SVT MUST contain one "Issued At" claim.</t>
<t>aud -- A [StringOrURI] data type or a StringOrURI data type that is an "Aud
ience" registered claim according to <xref target="RFC7519"/>. The audience clai
m is an array of one or more identifiers, identifying intended recipients of the
SVT. Each identifier MAY identify a single entity, a group of entities or a com
mon policy adopted by a group of entities. If only one value is provided it MAY
be provided as a single StringOrURI data type value instead of as an array of va
lues. Inclusion of the "Audience" claim in a SVT is OPTIONAL.</t>
<t>exp -- A NumericDate data type that is an "Expiration Time" registered clai
m according to <xref target="RFC7519"/>, which expresses the date and time when
services and responsibilities related to this SVT is no longer provided by the S
VT issuer. The precise meaning of the expiration time claim is defined by local
policies. See implementation note below. Inclusion of the "Expiration Time" clai
m in a SVT is OPTIONAL.</t>
<t>sig_val_claims -- A Object&lt;SigValidation&gt; data type that contains sig
nature validation claims for this SVT extending the standard registered JTW clai
ms above. A SVT MUST contain one sig_val_claims claim.</t>
</list></t>
<t>Note: An SVT asserts that a particular validation process was undertaken at a <dt>Array:
stated </dt>
date and time. This fact never changes and never expires. However, some other as <dd>A JSON array of a specific data type as defined in this section. An array
pects is expressed in this specification by square brackets. For example, [String]
of the SVT such as liability for false claims or service provision related to a indicates an array of String values, and [Object&lt;DocHash&gt;] indicates an
specific array of DocHash objects.
SVT may expire after a certain period of time, such as a service where an old SV </dd>
T can be
upgraded to a new SVT signed with fresh keys and algorithms.</t>
</section> <dt>Null:
<section anchor="sigvalidation-obj-class"><name>SigValidation Object Class</name </dt>
> <dd>A JSON null that represents an absent value. A claim with a null value is
equivalent with an absent claim.
</dd>
<t>The sig_val_claims JWT claim uses the SigValidation object class. A SigValida </dl>
tion object
holds all custom claims, and a SigValidation object contains the following param
eters:</t>
<t><list style="symbols"> </section>
<t>ver -- A String data type representing the version. This parameter MUST be
present, and the version in this specification indicated by the value "1.0".</t>
<t>profile -- A StringOrURI data type representing the name of a profile that
defines conventions followed for specific claims and any extension points used b
y the SVT issuer. This parameter MUST be present.</t>
<t>hash_algo -- A URI data type that identifies the hash algorithm used to com
pute the hash values within the SVT. The URI identifier MUST be one defined in <
xref target="RFC6931"/> or in the IANA registry defined by this specification. T
his parameter MUST be present.</t>
<t>sig -- A [Object&lt;Signature&gt;] data type that gives information about v
alidated electronic signatures as an array of Signature objects. If the SVT cont
ains signature validation evidence for more than one signature, then each signat
ure is represented by a separate Signature object. At least one Signature object
MUST be present.</t>
<t>ext -- A Map&lt;String&gt; data type that provides additional claims relate
d to the SVT. Extension claims are added at the discretion of the SVT issuer; ho
wever, extension claims MUST follow any conventions defined in a profile of this
specification (see <xref target="profiles"/>). Inclusion of this parameter is O
PTIONAL.</t>
</list></t>
</section> <section anchor="svt-syntax-claim">
<section anchor="signature-obj-class"><name>Signature Claims Object Class</name> <name>Signature Validation Token JWT Claims</name>
<t>The SVT <bcp14>MUST</bcp14> contain only JWT claims in the followin
g list:</t>
<t>The sig parameter in the SigValidation object class uses the Signature object <dl>
class. The Signature object contains claims related to signature validation
evidence for one signature, and it contains the following parameters:</t>
<t><list style="symbols"> <dt>"jti":
<t>sig_ref -- A Object&lt;SigReference&gt; data type that contains reference i </dt>
nformation identifying the target signature. This parameter MUST be present.</t> <dd> A String data type that is a "JWT ID" registered claim according to
<t>sig_data_ref -- A [Object&lt;SignedDataReference&gt;] data type that contai <xref target="RFC7519"/>. It is <bcp14>RECOMMENDED</bcp14> that the
ns an array of references to Signed Data that was signed by the target electroni identifier holds a hexadecimal string representation of a 128-bit unsigned
c signature. At least one SignedDataReference object MUST be present.</t> integer. An SVT <bcp14>MUST</bcp14> contain one "JWT ID" claim.
<t>signer_cert_ref -- A Object&lt;CertReference&gt; data type that references </dd>
the signer's certificate and optionally reference to a supporting certification
path that was used to verify the target electronic signature. This parameter MUS
T be present.</t>
<t>sig_val -- A [Object&lt;PolicyValidation&gt;] data type that contains an ar
ray of results of signature verification according to defined procedures. At lea
st one PolicyValidation object MUST be present.</t>
<t>time_val -- A [Object&lt;TimeValidation&gt;] data type that contains an arr
ay of time verification results that the target signature has existed at a speci
fic date and time in the past. Inclusion of this parameter is OPTIONAL.</t>
<t>ext -- A MAP&lt;String&gt; data type that provides additional claims relate
d to the target signature. Extension claims are added at the discretion of the S
VT Issuer; however, extension claims MUST follow any conventions defined in a pr
ofile of this specification (see <xref target="profiles"/>). Inclusion of this p
arameter is OPTIONAL.</t>
</list></t>
</section> <dt>"iss":
<section anchor="sigreference-obj-class"><name>SigReference Claims Object Class< </dt>
/name> <dd>A StringOrURI data type that is an "Issuer" registered claim according
to <xref target="RFC7519"/>, which is an arbitrary unique identifier of the
SVT issuer. This value <bcp14>SHOULD</bcp14> have the value of a URI based
on a domain owned by the issuer. An SVT <bcp14>MUST</bcp14> contain one
"Issuer" claim.
</dd>
<t>The sig_ref parameter in the Signature object class uses the SigReference obj <dt>"iat":
ect </dt>
class. The SigReference object provides information used to match the Signature <dd>A NumericDate data type that is an "Issued At" registered claim
claims object to a specific target electronic signature and to verify the integr according to <xref target="RFC7519"/>, which expresses the time
ity when this SVT was issued. An SVT <bcp14>MUST</bcp14> contain one "Issued At"
of the target signature value and Signed Bytes, and it contains the following pa claim.
rameters:</t> </dd>
<t><list style="symbols"> <dt>"aud":
<t>id -- A String data type that contains an identifier assigned to the target </dt>
signature. Inclusion of this parameter is OPTIONAL.</t> <dd>A [StringOrURI] data type or a StringOrURI data type that is an
<t>sig_hash -- A Base64Binary data type that contains a hash value of the targ "Audience" registered claim according to <xref target="RFC7519"/>. The
et electronic signature value. This parameter MUST be present.</t> audience claim is an array of one or more identifiers, identifying intended
<t>sb_hash -- A Base64Binary data type that contains a hash value of the Signe recipients of the SVT. Each identifier <bcp14>MAY</bcp14> identify a single
d Bytes of the target electronic signature. This parameter MUST be present.</t> entity, a group of entities, or a common policy adopted by a group of
</list></t> entities. If only one value is provided, it <bcp14>MAY</bcp14> be provided
as a single StringOrURI data type value instead of as an array of
values. Inclusion of the "Audience" claim in an SVT is
<bcp14>OPTIONAL</bcp14>.
</dd>
</section> <dt>"exp":
<section anchor="signeddatareference-obj-class"><name>SignedDataReference Claims </dt>
Object Class</name> <dd>A NumericDate data type that is an "Expiration Time" registered claim
according to <xref target="RFC7519"/>, which expresses the time
when services and responsibilities related to this SVT are no longer
provided by the SVT issuer. The precise meaning of the expiration time claim
is defined by local policies. See implementation note below. Inclusion of
the "Expiration Time" claim in an SVT is <bcp14>OPTIONAL</bcp14>.
</dd>
<t>The sig_data_ref parameter in the Signature object class uses the SignedDataR <dt>"sig_val_claims":
eference object </dt>
class. The SignedDataReference object provides information used to verify the ta <dd>An Object&lt;SigValidation&gt; data type that contains signature
rget electronic validation claims for this SVT extending the standard registered JWT claims
signature references to Signed Data as well as to verify the integrity of all da above. An SVT <bcp14>MUST</bcp14> contain one sig_val_claims claim.
ta that </dd>
is signed by the target signature, and it contains the following parameters:</t>
<t><list style="symbols"> </dl>
<t>ref -- A String data type that contains a reference identifier for the data
or data fragment covered by the target electronic signature. This parameter MUS
T be present.</t>
<t>hash -- A Base64Binary data type that contains the hash value for the data
covered by the target electronic signature. This parameter MUST be present.</t>
</list></t>
</section> <t>Note: An SVT asserts that a particular validation process was under
<section anchor="policyval-obj-class"><name>PolicyValidation Claims Object Class taken at a stated
</name> time. This fact never changes and never expires. However, some other aspects
of the SVT such as liability for false claims or service provision related to a
specific
SVT may expire after a certain period of time, such as a service where an old SV
T can be
upgraded to a new SVT signed with fresh keys and algorithms.</t>
</section>
<section anchor="sigvalidation-obj-class">
<name>SigValidation Object Class</name>
<t>The sig_val parameter in the Signature object class uses the PolicyValidation <t>The sig_val_claims JWT claim uses the SigValidation object class. A
object SigValidation object
class. The PolicyValidation object provides information about the result of a va holds all custom claims, and a SigValidation object contains the following param
lidation eters:</t>
process according to a spefific policy, and it contains the following parameters
:</t>
<t><list style="symbols"> <dl>
<t>pol -- A StringOrURI data type that contains the identifier of the policy g <dt>"ver":
overning the electronic signature verification process. This parameter MUST be p </dt>
resent.</t> <dd>A String data type representing the version. This parameter
<t>res -- A String data type that contains the result of the electronic signat <bcp14>MUST</bcp14> be present and the version in this specification
ure verification process. The value MUST be one of "PASSED", "FAILED" or "INDETE indicated by the value "1.0".
RMINATE" as defined by <xref target="ETSI319102-1"/>. This parameter MUST be pre </dd>
sent.</t>
<t>msg -- A String data type that contains a message describing the result. In
clusion of this parameter is OPTIONAL.</t>
<t>ext -- A MAP&lt;String&gt; data type that provides additional claims relate
d to the target signature. Extension claims are added at the discretion of the S
VT Issuer; however, extension claims MUST follow any conventions defined in a pr
ofile of this specification (see <xref target="profiles"/>). Inclusion of this p
arameter is OPTIONAL.</t>
</list></t>
</section> <dt>"profile":
<section anchor="timever-obj-class"><name>TimeValidation Claims Object Class</na </dt>
me> <dd>A StringOrURI data type representing the name of a profile that defines
conventions followed for specific claims and any extension points used by
the SVT issuer. This parameter <bcp14>MUST</bcp14> be present.
</dd>
<t>The time_val parameter in the Signature object class uses the TimeValidation <dt>"hash_algo":
object </dt>
class. The TimeValidation claims object provides information about the result of <dd>A URI data type that identifies the hash algorithm used to compute the
validating evidence of time asserting that the target signature existed at a par hash values within the SVT. The URI identifier <bcp14>MUST</bcp14> be one
ticular defined in <xref target="RFC9231"/> or in the IANA registry defined by this
date and time in the past. Evidence of time is typically a timestamp according t specification. This parameter <bcp14>MUST</bcp14> be present.
o <xref target="RFC3161"/> but other types of evidence may be used such as a pre </dd>
viously issued SVT for this signature. The TimeValidation claims object contains
the following parameters:</t>
<t><list style="symbols"> <dt>"sig":
<t>time -- A NumericDate data type that contains the verified time. This param </dt>
eter MUST be present.</t> <dd>An [Object&lt;Signature&gt;] data type that gives information about
<t>type -- A StringOrURI data type that contains an identifier of the type of validated electronic signatures as an array of Signature objects. If the SVT
evidence of time. This parameter MUST be present.</t> contains signature validation evidence for more than one signature, then each
<t>iss -- A StringOrURI data type that contains an identifier of the entity th signature is represented by a separate Signature object. At least one
at issued the evidence of time. This parameter MUST be present.</t> Signature object <bcp14>MUST</bcp14> be present.
<t>id -- A String data type that contains an unique identifier assigned to the </dd>
evidence of time. Inclusion of this parameter is OPTIONAL.</t>
<t>hash -- A Base64Binary data type that contains the hash value of the valida
ted evidence of time. Inclusion of this parameter is OPTIONAL.</t>
<t>val -- A [Object&lt;PolicyValidation&gt;] data type that contains an array
of results of the time evidence validation according to defined validation proce
dures. Inclusion of this parameter is OPTIONAL.</t>
<t>ext -- A MAP&lt;String&gt; data type that provides additional claims relate
d to the target signature. Extension claims are added at the discretion of the S
VT Issuer; however, extension claims MUST follow any conventions defined in a pr
ofile of this specification (see <xref target="profiles"/>). Inclusion of this p
arameter is OPTIONAL.</t>
</list></t>
</section> <dt>"ext":
<section anchor="certref-obj-class"><name>CertReference Claims Object Class</nam </dt>
e> <dd>A Map&lt;String&gt; data type that provides additional claims related to
the SVT. Extension claims are added at the discretion of the SVT issuer;
however, extension claims <bcp14>MUST</bcp14> follow any conventions defined
in a profile of this specification (see <xref target="profiles"/>). Inclusion
of this parameter is <bcp14>OPTIONAL</bcp14>.
</dd>
<t>The signer_cert_ref parameter in the Signature object class uses the CertRefe </dl>
rence object
class. The CertReference object references a single X.509 certificate or a X.509
certification path, either by providing the certificate data or by providing has
h
references for certificates that can be located in the target electronic signatu
re, and
it contains the following parameters:</t>
<t><list style="symbols"> </section>
<t>type -- A StringOrURI data type that contains an identifier of the type of <section anchor="signature-obj-class">
reference. The type identifier MUST be one of the identifiers defined below, an <name>Signature Claims Object Class</name>
identifier specified by the selected profile, or a URI identifier. This paramete <t>The sig parameter in the SigValidation object class uses the Signat
r MUST be present.</t> ure object
<t>ref -- A [String] data type that contains an array of string parameters acc class. The Signature object contains claims related to signature validation
ording to conventions defined by the type identifier. At least one parameter MUS evidence for one signature, and it contains the following parameters:</t>
T be present.</t>
</list></t>
<t>The following type identifiers are defined:</t> <dl>
<t><list style="symbols"> <dt>"sig_ref":
<t>chain -- The ref contains an array of Base64 encoded X.509 certificates <xr </dt>
ef target="RFC5280"/>. The certificates MUST be provided in the order starting w <dd>An Object&lt;SigReference&gt; data type that contains reference
ith the end entity certificate. Any following certificate must be able to valida information identifying the target signature. This parameter
te the signature on the previous certificate in the array.</t> <bcp14>MUST</bcp14> be present.
<t>chain_hash -- The ref contains an array of one or more Base64 encoded hash </dd>
values where each hash value is a hash over a X.509 certificate <xref target="RF
C5280"/> used to validate the signature. The certificates MUST be provided in t
he order starting with the end entity certificate. Any following certificate mu
st be able to validate the signature on the previous certificate in the array. T
his option MUST NOT be used unless all hashed certificates are present in the ta
rget electronic signature.</t>
</list></t>
<t>Note: All certificates referenced using the identifiers above are X.509 certi <dt>"sig_data_ref":
ficates. </dt>
Profiles of this specification MAY define alternative types of public key contai <dd>An [Object&lt;SignedDataReference&gt;] data type that contains an array of
ners; references to Signed Data that was signed by the target electronic
however, a major function of these referenced certificates is not just to refere signature. At least one SignedDataReference object <bcp14>MUST</bcp14> be
nce present.
the public key, but also to provide the subject name of the signer. It is theref </dd>
ore
important for the full function of an SVT that the referenced public key contain
er also
provides the means to identify of the signer.</t>
</section> <dt>"signer_cert_ref":
<section anchor="svt-jose-header"><name>SVT JOSE Header</name> </dt>
<dd>An Object&lt;CertReference&gt; data type that references the signer's
certificate and optionally references a supporting certification path that
was used to verify the target electronic signature. This parameter
<bcp14>MUST</bcp14> be present.
</dd>
<t>The SVT JWT MUST contain the following JOSE header parameters in accordance w <dt>"sig_val":
ith </dt>
Section 5 of <xref target="RFC7519"/>:</t> <dd>An [Object&lt;PolicyValidation&gt;] data type that contains an array of
results of signature verification according to defined procedures. At least
one PolicyValidation object <bcp14>MUST</bcp14> be present.
</dd>
<t><list style="symbols"> <dt>"time_val":
<t>typ -- This parameter MUST have the string value "JWT" (upper case).</t> </dt>
<t>alg -- This parameter identifies the algorithm used to sign the SVT JWT. Th <dd>An [Object&lt;TimeValidation&gt;] data type that contains an array of time
e algorithm identifier MUST be specified in <xref target="RFC7518"/> or the IANA verification results showing that the target signature has existed at a specific
JSON Web Signature and Encryption Algorithms Registry [ add a ref ]. The specif time in the past. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
ied signature hash algorithm MUST be identical to the hash algorithm specified i </dd>
n the hash_algo parameter of the SigValidation object within the sig_val_claims
claim.</t>
</list></t>
<t>The SVT header MUST contain a public key or a reference to a public key used <dt>"ext":
to verify the signature on the SVT in accordance with <xref target="RFC7515"/>. </dt>
Each profile, as discussed in <xref target="profiles"/>, MUST define the require <dd>A MAP&lt;String&gt; data type that provides additional claims related to
ments for how the key or key reference is included in the header.</t> the target signature. Extension claims are added at the discretion of the SVT
issuer; however, extension claims <bcp14>MUST</bcp14> follow any conventions
defined in a profile of this specification (see <xref
target="profiles"/>). Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
</dd>
</section> </dl>
</section>
</section>
<section anchor="profiles"><name>Profiles</name>
<t>Each signed document and signature type will have to define the precise conte </section>
nt and <section anchor="sigreference-obj-class">
use of several claims in the SVT.</t> <name>SigReference Claims Object Class</name>
<t>The sig_ref parameter in the Signature object class uses the SigRef
erence object
class. The SigReference object provides information used to match the Signature
claims object to a specific target electronic signature and to verify the integr
ity
of the target signature value and Signed Bytes, and it contains the following pa
rameters:</t>
<t>Each profile MUST as a minimum define:</t> <dl>
<t><list style="symbols"> <dt>"id":
<t>The identifier of the profile.</t> </dt>
<t>How to reference the Signed Data content of the signed document.</t> <dd>A String data type that contains an identifier assigned to the target
<t>How to reference to the target electronic signature and the Signed Bytes of signature. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
the signature.</t> </dd>
<t>How to reference certificates supporting each electronic siganture.</t>
<t>How to include public keys or references to public keys in the SVT.</t>
<t>Whether each electronic signature is supported by a single SVT, or whether
one SVT may support multiple electronic signatures of the same document.</t>
</list></t>
<t>A profile MAY also define:</t> <dt>"sig_hash":
</dt>
<dd>A Base64Binary data type that contains a hash value of the target
electronic signature value. This parameter <bcp14>MUST</bcp14> be present.
</dd>
<t><list style="symbols"> <dt>"sb_hash":
<t>Explicit information on how to perform signature validation based on an SVT </dt>
.</t> <dd>A Base64Binary data type that contains a hash value of the Signed Bytes of
<t>How to attach an SVT to an electronic signature or signed document.</t> the target electronic signature. This parameter <bcp14>MUST</bcp14> be
</list></t> present.
</dd>
<section anchor="defined-profiles"><name>Defined Profiles</name> </dl>
<t>The following profiles are defined in Appendixes of this document:</t> </section>
<section anchor="signeddatareference-obj-class">
<name>SignedDataReference Claims Object Class</name>
<t>The sig_data_ref parameter in the Signature object class uses the S
ignedDataReference object
class. The SignedDataReference object provides information used to verify the ta
rget electronic
signature references to Signed Data as well as to verify the integrity of all da
ta that
is signed by the target signature, and it contains the following parameters:</t>
<t><list style="symbols"> <dl>
<t><xref target="appendix-xml-profile"/>: XML Profile</t> <dt>"ref":
<t><xref target="appendix-pdf-profile"/>: PDF Profile</t> </dt>
<t><xref target="appendix-jws-profile"/>: JWS Profile</t> <dd>A String data type that contains a reference identifier for the data or
</list></t> data fragment covered by the target electronic signature. This parameter
<bcp14>MUST</bcp14> be present.
</dd>
<t>Other documents MAY define other profiles that MAY complement, ammend or supe <dt>"hash":
rsede these profiles.</t> </dt>
<dd>A Base64Binary data type that contains the hash value for the data covered
by the target electronic signature. This parameter <bcp14>MUST</bcp14> be
present.
</dd>
</dl>
</section> </section>
</section> <section anchor="policyval-obj-class">
<section anchor="signature-verification-with-a-svt"><name>Signature Verification <name>PolicyValidation Claims Object Class</name>
with a SVT</name> <t>The sig_val parameter in the Signature object class uses the Policy
Validation object
class. The PolicyValidation object provides information about the result of a va
lidation
process according to a specific policy, and it contains the following parameters
:</t>
<t>Signature verification based on an a SVT MUST follow these steps:</t> <dl>
<t><list style="numbers"> <dt>"pol":
<t>Locate all available SVTs available for the signed document that are releva </dt>
nt for the target electronic signature.</t> <dd>A StringOrURI data type that contains the identifier of the policy
<t>Select the most recent SVT that can be successfully validated and meets the governing the electronic signature verification process. This parameter
requirement of the relying party.</t> <bcp14>MUST</bcp14> be present.
<t>Verify the integrity of the signature and the Signed Bytes of the target el </dd>
ectronic signature using the sig_ref claim.</t>
<t>Verify that the Signed Data reference in the original electronic signature
matches the reference values in the sig_data_ref claim.</t>
<t>Verify the integrity of referenced Signed Data using provided hash values i
n the sig_data_ref claim.</t>
<t>Obtain the verified certificates supporting the asserted electronic signatu
re verification through the signer_cert_ref claim.</t>
<t>Verify that signature validation policy results satisfy the requirements of
the relying party.</t>
<t>Verify that verified time results satisfy the context for the use of the si
gned document.</t>
</list></t>
<t>After successfully performing these steps, signature validity is established <dt>"res":
as well as </dt>
the trusted signer certificate binding the identity of the signer to the electro <dd>A String data type that contains the result of the electronic signature
nic verification process. The value <bcp14>MUST</bcp14> be one of "PASSED",
signature.</t> "FAILED", or "INDETERMINATE" as defined by <xref
target="ETSI319102-1"/>. This parameter <bcp14>MUST</bcp14> be present.
</dd>
</section> <dt>"msg":
<section anchor="iana"><name>IANA Considerations</name> </dt>
<dd>A String data type that contains a message describing the
result. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
</dd>
<section anchor="claim-names-reg"><name>Claim Names Registration</name> <dt>"ext":
</dt>
<dd>A MAP&lt;String&gt; data type that provides additional claims related to
the target signature. Extension claims are added at the discretion of the
SVT issuer; however, extension claims <bcp14>MUST</bcp14> follow any
conventions defined in a profile of this specification (see <xref
target="profiles"/>). Inclusion of this parameter is
<bcp14>OPTIONAL</bcp14>.
</dd>
</dl>
<t>This section registers the "sig_val_claims" claim name in the IANA "JSON Web </section>
Token Claims" registry established by Section 10.1 in <xref target="RFC7519"/>.< <section anchor="timever-obj-class">
/t> <name>TimeValidation Claims Object Class</name>
<t>The time_val parameter in the Signature object class uses the TimeV
alidation object
class. The TimeValidation claims object provides information about the result of
validating evidence of time asserting that the target signature existed at a par
ticular
time in the past. Evidence of time is typically a timestamp according to <xref t
arget="RFC3161"/>, but other types of evidence may be used such as a previously
issued SVT for this signature. The TimeValidation claims object contains the fol
lowing parameters:</t>
<section anchor="clname-reg-contents"><name>Registry Contents</name> <dl>
<dt>"time":
</dt>
<dd>A NumericDate data type that contains the verified time. This parameter
<bcp14>MUST</bcp14> be present.
</dd>
<t><list style="symbols"> <dt>"type":
<t>Claim Name: "sig_val_claims"</t> </dt>
<t>Claim Description: Signature Validation Token</t> <dd>A StringOrURI data type that contains an identifier of the type of
<t>Change Controller: IESG</t> evidence of time. This parameter <bcp14>MUST</bcp14> be present.
<t>Specification Document(s): <xref target="sigvalidation-obj-class"/> of {thi </dd>
s document}</t>
</list></t>
<t>NOTE to RFC editor: Please replace {this document} with its assigned RFC numb <dt>"iss":
er.</t> </dt>
<dd>A StringOrURI data type that contains an identifier of the entity that
issued the evidence of time. This parameter <bcp14>MUST</bcp14> be present.
</dd>
</section> <dt>"id":
</section> </dt>
<section anchor="iana-header-params"><name>Header Parameter Names Registration</ <dd>A String data type that contains an unique identifier assigned to the
name> evidence of time. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
</dd>
<t>This section registers the "svt" Header Parameter in the IANA "JSON Web Signa <dt>"hash":
ture and Encryption Header Parameters" registry established by <xref target="RFC </dt>
7515"/>.</t> <dd>A Base64Binary data type that contains the hash value of the validated
evidence of time. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
</dd>
<section anchor="iana-header-params-reg"><name>Registry Contents</name> <dt>"val":
</dt>
<dd>An [Object&lt;PolicyValidation&gt;] data type that contains an array of
results of the time evidence validation according to defined validation
procedures. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
</dd>
<t><list style="symbols"> <dt>"ext":
<t>Header Parameter Name: "svt"</t> </dt>
<t>Header Parameter Description: Signature Validation Token</t> <dd>A MAP&lt;String&gt; data type that provides additional claims related to
<t>Header Parameter Usage Location(s): JWS</t> the target signature. Extension claims are added at the discretion of the
<t>Change Controller: IESG</t> SVT issuer; however, extension claims <bcp14>MUST</bcp14> follow any
<t>Specification Document(s): <xref target="svt-header"/> of {this document}</ conventions defined in a profile of this specification (see <xref
t> target="profiles"/>). Inclusion of this parameter is
</list></t> <bcp14>OPTIONAL</bcp14>.
</dd>
<t>NOTE to RFC editor: Please replace {this document} with its assigned RFC numb er.</t> </dl>
</section> </section>
</section>
</section>
<section anchor="seccons"><name>Security Considerations</name>
<section anchor="seccon-lvl-of-reliance"><name>Level of reliance</name> <section anchor="certref-obj-class">
<name>CertReference Claims Object Class</name>
<t>The signer_cert_ref parameter in the Signature object class uses th
e CertReference object
class. The CertReference object references a single X.509 certificate or a X.509
certification path either by providing the certificate data or by providing hash
references for certificates that can be located in the target electronic signatu
re, and
it contains the following parameters:</t>
<t>An SVT allows a signature verifier to still validate the original signature u <dl>
sing
the original signature data and to use the information in the SVT selectively to
either just confirm the validity and integrity of the original data, such as con
firming the integrity of signed data or the validity of the signer's certificate
etc.</t>
<t>Another way to use an SVT is to completely rely on the validation conclusion <dt>"type":
provided </dt>
by the SVT and to omit re-validation of the original signature value and origina <dd>A StringOrURI data type that contains an identifier of the type of
l reference. The type identifier <bcp14>MUST</bcp14> be one of the
certificate status checking data.</t> identifiers defined below, an identifier specified by the selected profile,
or a URI identifier. This parameter <bcp14>MUST</bcp14> be present.
</dd>
<t>This choice is a decision made by the verifier according to its own policy an <dt>"ref":
d risk assessment.</t> </dt>
<dd>A [String] data type that contains an array of string parameters
according to conventions defined by the type identifier. At least one
parameter <bcp14>MUST</bcp14> be present.
</dd>
<t>However, even when relying on the SVT validation conclusion of an SVT it is v </dl>
ital to still verify that
the present SVT is correctly associated with the document and signature that is
being validated by
validating the hashed reference data in the SVT of the signature, signing certif
icate chain,
signed data and the signed bytes.</t>
</section> <t>The following type identifiers are defined:</t>
<section anchor="seccon-aging-algos"><name>Aging algorithms</name>
<t>Even if the SVT provides protection against algorithms becoming weakened or b roken over time, this protection is only valid for as long as the algorithms use d to sign the SVT are still considered secure. It is advisable to re-issue SVT i n cases where an algorithm protecting the SVT is getting close to its end of lif e.</t> <dl>
<t>One way to increase the resistance of algorithms becoming insecure, is to iss <dt>"chain":
ue multiple SVT for the same signature with different algorithms and key lengths </dt>
where one algorithm could still be secure even if the corresponding algorithm u <dd>The ref contains an array of Base64-encoded X.509 certificates <xref
sed in the alternative SVT is broken.</t> target="RFC5280"/>. The certificates <bcp14>MUST</bcp14> be provided in the
order starting with the end entity certificate. Any following certificate
must be able to validate the signature on the previous certificate in the
array.
</dd>
</section> <dt>"chain_hash":
</section> </dt>
<dd>The ref contains an array of one or more Base64-encoded hash values
where each hash value is a hash over a X.509 certificate <xref
target="RFC5280"/> used to validate the signature. The certificates
<bcp14>MUST</bcp14> be provided in the order starting with the end entity
certificate. Any following certificate must be able to validate the
signature on the previous certificate in the array. This option <bcp14>MUST
NOT</bcp14> be used unless all hashed certificates are present in the target
electronic signature.
</dd>
</dl>
</middle> <t>Note: All certificates referenced using the identifiers above are X
.509 certificates.
Profiles of this specification <bcp14>MAY</bcp14> define alternative types of pu
blic key containers;
however, a major function of these referenced certificates is not just to refere
nce
the public key but also to provide the subject name of the signer. It is therefo
re
important for the full function of an SVT that the referenced public key contain
er also
provides the means to identify the signer.</t>
</section>
<section anchor="svt-jose-header">
<name>SVT JOSE Header</name>
<t>The SVT JWT <bcp14>MUST</bcp14> contain the following JSON Object S
igning and Encryption (JOSE) header parameters in accordance with
<xref target="RFC7519" sectionFormat="of" section="5"/>:</t>
<back> <dl>
<references title='Normative References'> <dt>"typ":
</dt>
<dd>This parameter <bcp14>MUST</bcp14> have the string value "JWT" (upper
case).
</dd>
&RFC2119; <dt>"alg":
&RFC3125; </dt>
&RFC3161; <dd>This parameter identifies the algorithm used to sign the SVT JWT. The
&RFC3647; algorithm identifier <bcp14>MUST</bcp14> be specified in <xref
&RFC5035; target="RFC7518"/> or the IANA "JSON Web Signature and Encryption Algorithms"
&RFC8174; registry <xref target="IANA-JOSE-REG"/>. The specified signature hash
&RFC5280; algorithm <bcp14>MUST</bcp14> be identical to the hash algorithm specified in
&RFC5652; the hash_algo parameter of the SigValidation object within the sig_val_claims
&RFC6931; claim.
&RFC7515; </dd>
&RFC7518;
&RFC7519;
<reference anchor="ETSI319102-1" >
<front>
<title>ETSI - Electronic Signatures and Infrastructures (ESI); Procedures fo
r Creation and Validation of AdES Digital Signatures; Part 1: Creation and Valid
ation</title>
<author >
<organization>ETSI</organization>
</author>
<date year="2016" month="May"/>
</front>
<seriesInfo name="ETSI" value="EN 319 102-1 v1.1.1"/>
</reference>
<reference anchor="XMLDSIG11" >
<front>
<title>XML Signature Syntax and Processing Version 1.1</title>
<author initials="D." surname="Eastlake" fullname="Donald Eastlake">
<organization></organization>
</author>
<author initials="J." surname="Reagle" fullname="Joseph Reagle">
<organization></organization>
</author>
<author initials="D." surname="Solo" fullname="David Solo">
<organization></organization>
</author>
<author initials="F." surname="Hirsch" fullname="Frederick Hirsch">
<organization></organization>
</author>
<author initials="M." surname="Nystrom" fullname="Magnus Nystrom">
<organization></organization>
</author>
<author initials="T." surname="Roessler" fullname="Thomas Roessler">
<organization></organization>
</author>
<author initials="K." surname="Yiu" fullname="Kelvin Yiu">
<organization></organization>
</author>
<date year="2013" month="April" day="11"/>
</front>
<seriesInfo name="W3C" value="Proposed Recommendation"/>
</reference>
<reference anchor="ISOPDF2" >
<front>
<title>Document management -- Portable document format -- Part 2: PDF 2.0</t
itle>
<author >
<organization>ISO</organization>
</author>
<date year="2017" month="July"/>
</front>
<seriesInfo name="ISO" value="32000-2"/>
</reference>
<reference anchor="XADES" >
<front>
<title>Electronic Signatures and Infrastructures (ESI); XAdES digital signat
ures; Part 1: Building blocks and XAdES baseline signatures</title>
<author >
<organization>ETSI</organization>
</author>
<date year="2016" month="April"/>
</front>
<seriesInfo name="ETSI" value="EN 319 132-1 v1.1.1"/>
</reference>
<reference anchor="PADES" >
<front>
<title>Electronic Signatures and Infrastructures (ESI); PAdES digital signat
ures; Part 1: Building blocks and PAdES baseline signatures</title>
<author >
<organization>ETSI</organization>
</author>
<date year="2016" month="April"/>
</front>
<seriesInfo name="ETSI" value="EN 319 142-1 v1.1.1"/>
</reference>
<reference anchor="CADES" >
<front>
<title>Electronic Signatures and Infrastructures (ESI); CAdES digital signat
ures; Part 1: Building blocks and CAdES baseline signatures</title>
<author >
<organization>ETSI</organization>
</author>
<date year="2016" month="April"/>
</front>
<seriesInfo name="ETSI" value="EN 319 122-1 v1.1.1"/>
</reference>
</references> </dl>
<references title='Informative References'> <t>The SVT header <bcp14>MUST</bcp14> contain a public key or a refere
nce to a public key used to verify the signature on the SVT in accordance with <
xref target="RFC7515"/>. Each profile, as discussed in <xref target="profiles"/>
, <bcp14>MUST</bcp14> define the requirements for how the key or key reference i
s included in the header.</t>
</section>
</section>
</section>
&RFC8610; <section anchor="profiles">
<name>Profiles</name>
<t>Each signed document and signature type will have to define the precise
content and
use of several claims in the SVT.</t>
<t>At a minimum, each profile <bcp14>MUST</bcp14> define:</t>
<ul spacing="normal">
<li>The identifier of the profile</li>
<li>How to reference the Signed Data content of the signed document</li>
<li>How to reference the target electronic signature and the Signed Byte
s of the signature</li>
<li>How to reference certificates supporting each electronic signature</
li>
<li>How to include public keys or references to public keys in the SVT</
li>
<li>Whether each electronic signature is supported by a single SVT, or o
ne SVT may support multiple electronic signatures of the same document</li>
</ul>
<t>A profile <bcp14>MAY</bcp14> also define:</t>
<ul spacing="normal">
<li>Explicit information on how to perform signature validation based on
an SVT</li>
<li>How to attach an SVT to an electronic signature or signed document</
li>
</ul>
<section anchor="defined-profiles">
<name>Defined Profiles</name>
<t>The following profiles are defined in appendixes of this document:</t
>
</references> <dl>
<dt> <xref target="appendix-xml-profile"/>:
</dt>
<dd>XML Signature Profile
</dd>
<section anchor="appendix-xml-profile"><name>Appendix: XML signature profile</na <dt><xref target="appendix-pdf-profile"/>:
me> </dt>
<dd>PDF Signature Profile
</dd>
<t>This appendix defines a profile for implementing SVT with a signed XML docume <dt><xref target="appendix-jws-profile"/>:
nt, and defines the following aspects of SVT usage:</t> </dt>
<dd>JWS Profile
</dd>
</dl>
<t><list style="symbols"> <t>Other documents <bcp14>MAY</bcp14> define other profiles that <bcp14>
<t>How to include reference data related to XML signatures and XML documents i MAY</bcp14> complement, amend, or supersede these profiles.</t>
n an SVT.</t> </section>
<t>How to add an SVT token to a XML signature.</t> </section>
</list></t> <section anchor="signature-verification-with-a-svt">
<name>Signature Verification with an SVT</name>
<t>Signature verification based on an SVT <bcp14>MUST</bcp14> follow these
steps:</t>
<ol spacing="normal" type="1"><li>Locate all available SVTs available for
the signed document that are relevant for the target electronic signature.</li>
<li>Select the most recent SVT that can be successfully validated and me
ets the requirement of the relying party.</li>
<li>Verify the integrity of the signature and the Signed Bytes of the ta
rget electronic signature using the sig_ref claim.</li>
<li>Verify that the Signed Data reference in the original electronic sig
nature matches the reference values in the sig_data_ref claim.</li>
<li>Verify the integrity of referenced Signed Data using provided hash v
alues in the sig_data_ref claim.</li>
<li>Obtain the verified certificates supporting the asserted electronic
signature verification through the signer_cert_ref claim.</li>
<li>Verify that signature validation policy results satisfy the requirem
ents of the relying party.</li>
<li>Verify that verified time results satisfy the context for the use of
the signed document.</li>
</ol>
<t>After successfully performing these steps, signature validity is establ
ished as well as
the trusted signer certificate binding the identity of the signer to the electro
nic
signature.</t>
</section>
<section anchor="iana">
<name>IANA Considerations</name>
<section anchor="claim-names-reg">
<name>Claim Names Registration</name>
<t>IANA has registered the "sig_val_claims" claim name in the "JSON Web
Token Claims" registry established by <xref target="RFC7519" sectionFormat="of"
section="10.1"/>.</t>
<section anchor="clname-reg-contents">
<name>Registry Contents</name>
<t>XML documents can have any number of signature elements, signing an arbitrary number of fragments of XML documents. The actual signature element may be inclu ded in the signed XML document (enveloped), include the signed data (enveloping) or may be separate from the signed content (detached).</t> <dl>
<t>To provide a generic solution for any type of XML signature an SVT is added t <dt>Claim Name:
o each XML signature element within the XML signature &lt;ds:Object&gt; element. </dt>
</t> <dd>sig_val_claims
</dd>
<section anchor="notation"><name>Notation</name> <dt>Claim Description:
</dt>
<dd>Signature Validation Token
</dd>
<section anchor="ref-to-xml-elements"><name>References to XML Elements from XML <dt>Change Controller:
Schemas</name> </dt>
<dd>IESG
</dd>
<t>When referring to elements from the W3C XML Signature namespace <dt>Specification Document(s):
(http://www.w3.org/2000/09/xmldsig#) the following syntax is used:</t> </dt>
<dd><xref target="sigvalidation-obj-class"/> of RFC 9321
</dd>
<t><list style="symbols"> </dl>
<t>&lt;ds:Signature&gt;</t>
</list></t>
<t>When referring to elements from the ETSI XAdES XML Signature namespace </section>
(http://uri.etsi.org/01903/v1.3.2#) the following syntax is used:</t> </section>
<section anchor="iana-header-params">
<name>Header Parameter Names Registration</name>
<t>IANA has registered the "svt" Header Parameter in the "JSON Web Signa
ture and Encryption Header Parameters" registry established by <xref target="RFC
7515"/>.</t>
<section anchor="iana-header-params-reg">
<name>Registry Contents</name>
<t><list style="symbols"> <dl>
<t>&lt;xades:CertDigest&gt;</t> <dt>Header Parameter Name:
</list></t> </dt>
<dd>svt
</dd>
<t>When referring to elements defined in this specification <dt>Header Parameter Description:
(http://id.swedenconnect.se/svt/1.0/sig-prop/ns) the following syntax is used:</ </dt>
t> <dd> Signature Validation Token
</dd>
<t><list style="symbols"> <dt>Header Parameter Usage Location(s):
<t>&lt;svt:Element&gt;</t> </dt>
</list></t> <dd>JWS
</dd>
</section> <dt>Change Controller:
</section> </dt>
<section anchor="svt-in-xml"><name>SVT in XML Documents</name> <dd>IESG
</dd>
<t>When SVT is provided for XML signatures then one SVT MUST be provided for eac <dt>Specification Document(s):
h XML signature.</t> </dt>
<dd><xref target="svt-header"/> of RFC 9321
</dd>
</dl>
<t>An SVT embedded within the XML signature element MUST be placed in a &lt;svt </section>
:SignatureValidationToken&gt; element as defined in <xref target="signaturevalid </section>
ationtoken-signature-property"/>.</t> </section>
<section anchor="signaturevalidationtoken-signature-property"><name>SignatureVal <section anchor="seccons">
idationToken Signature Property</name> <name>Security Considerations</name>
<section anchor="seccon-lvl-of-reliance">
<name>Level of Reliance</name>
<t>The &lt;svt:SignatureValidationToken&gt; element MUST be placed in a &lt;ds:S <t>An SVT allows a signature verifier to still validate the original sig
ignatureProperty&gt; element in accordance with <xref target="XMLDSIG11"/>. The nature using
&lt;ds:SignatureProperty&gt; element MUST be placed inside a &lt;ds:SignaturePro the original signature data and to use the information in the SVT selectively to
perties&gt; element inside a &lt;ds:Object&gt; element inside a &lt;ds:Signature confirm the validity and integrity of the original data, such as confirming the
&gt; element.</t> integrity of Signed Data or the validity of the signer's certificate, etc.</t>
<t>Another way to use an SVT is to completely rely on the validation con
clusion provided
by the SVT and to omit revalidation of the original signature value and original
certificate status checking data.</t>
<t>This choice is a decision made by the verifier according to its own p
olicy and risk assessment.</t>
<t>However, even when relying on the SVT validation conclusion of an SVT
, it is vital to still verify that
the present SVT is correctly associated with the document and signature that is
being validated by
validating the hashed reference data in the SVT of the signature, signing certif
icate chain,
Signed Data, and the Signed Bytes.</t>
</section>
<section anchor="seccon-aging-algos">
<name>Aging Algorithms</name>
<t>Even if the SVT provides protection against algorithms becoming weake
ned or broken over time, this protection is only valid for as long as the algori
thms used to sign the SVT are still considered secure. It is advisable to reissu
e SVTs in cases where an algorithm protecting the SVT is getting close to its en
d of life.</t>
<t>One way to increase the resistance of algorithms becoming insecure, i
s to issue multiple SVTs for the same signature with different algorithms and ke
y lengths where one algorithm could still be secure even if the corresponding al
gorithm used in the alternative SVT is broken.</t>
</section>
</section>
<t>Note: <xref target="XMLDSIG11"/> requires the Target attribute to be present in &lt;ds:SignatureProperty&gt;, referencing the signature targeted by this sign ature property. If an SVT is added to a signature that do not have an Id attribu te, implementations SHOULD add an Id attribute to the &lt;ds:Signature&gt; eleme nt and reference that Id in the Target attribute. This Id attribute and Target a ttribute value matching is required by the <xref target="XMLDSIG11"/> standard, but it is redundant in the context of SVT validation as the SVT already contains information that uniquely identifies the target signature. Validation applicati ons SHOULD not reject an SVT token because of Id and Target attribute mismatch, and MUST rely on matching against signature using signed information in the SVT itself.</t> </middle>
<t>The &lt;svt:SignatureValidationToken&gt; element is defined by the following XML Schema:</t> <back>
<figure><artwork><![CDATA[ <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
125.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
161.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
647.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
035.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
652.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
515.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
518.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
519.xml"/>
<reference anchor="IANA-JOSE-REG" target="https://www.iana.org/assignments/jose/
">
<front>
<title>JSON Object Signing and Encryption (JOSE)</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="ETSI319102-1">
<front>
<title>Electronic Signatures and Infrastructures (ESI); Procedures f
or Creation and Validation of AdES Digital Signatures; Part 1: Creation and Vali
dation</title>
<author>
<organization>ETSI</organization>
</author>
<date year="2016" month="May"/>
</front>
<seriesInfo name="ETSI EN" value="319 102-1"/>
<refcontent>v1.1.1</refcontent>
</reference>
<reference anchor="XMLDSIG11">
<front>
<title>XML Signature Syntax and Processing Version 1.1</title>
<author initials="D." surname="Eastlake 3rd" fullname="Donald Eastla
ke 3rd">
<organization/>
</author>
<author initials="J." surname="Reagle" fullname="Joseph Reagle">
<organization/>
</author>
<author initials="D." surname="Solo" fullname="David Solo">
<organization/>
</author>
<author initials="F." surname="Hirsch" fullname="Frederick Hirsch">
<organization/>
</author>
<author initials="M." surname="Nystrom" fullname="Magnus Nystrom">
<organization/>
</author>
<author initials="T." surname="Roessler" fullname="Thomas Roessler">
<organization/>
</author>
<author initials="K." surname="Yiu" fullname="Kelvin Yiu">
<organization/>
</author>
<date year="2013" month="April"/>
</front>
<seriesInfo name="W3C" value="Proposed Recommendation"/>
<annotation>Latest version available at <eref target="https://www.w3.org/TR/xmld
sig-core1/"/>.</annotation>
</reference>
<reference anchor="ISOPDF2">
<front>
<title>Document management -- Portable document format -- Part 2: PD
F 2.0</title>
<author>
<organization>ISO</organization>
</author>
<date year="2020" month="December"/>
</front>
<seriesInfo name="ISO" value="32000-2:2020"/>
</reference>
<reference anchor="XADES">
<front>
<title>Electronic Signatures and Infrastructures (ESI); XAdES digita
l signatures; Part 1: Building blocks and XAdES baseline signatures</title>
<author>
<organization>ETSI</organization>
</author>
<date year="2016" month="April"/>
</front>
<seriesInfo name="ETSI EN" value="319 132-1"/>
<refcontent>v1.1.1</refcontent>
</reference>
<reference anchor="PADES">
<front>
<title>Electronic Signatures and Infrastructures (ESI); PAdES digita
l signatures; Part 1: Building blocks and PAdES baseline signatures</title>
<author>
<organization>ETSI</organization>
</author>
<date year="2016" month="April"/>
</front>
<seriesInfo name="ETSI EN" value="319 142-1"/>
<refcontent>v1.1.1</refcontent>
</reference>
<reference anchor="CADES">
<front>
<title>Electronic Signatures and Infrastructures (ESI); CAdES digita
l signatures; Part 1: Building blocks and CAdES baseline signatures</title>
<author>
<organization>ETSI</organization>
</author>
<date year="2016" month="April"/>
</front>
<seriesInfo name="ETSI EN" value="319 122-1"/>
<refcontent>v1.1.1</refcontent>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
610.xml"/>
</references>
</references>
<section anchor="appendix-xml-profile">
<name>XML Signature Profile</name>
<t>This appendix defines a profile for implementing SVTs with a signed XML
document and defines the following aspects of SVT usage:</t>
<ul spacing="normal">
<li>How to include reference data related to XML signatures and XML docu
ments in an SVT</li>
<li>How to add an SVT token to an XML signature</li>
</ul>
<t>XML documents can have any number of signature elements, signing an arb
itrary number of fragments of XML documents. The actual signature element may be
included in the signed XML document (enveloped), include the Signed Data (envel
oping), or may be separate from the signed content (detached).</t>
<t>To provide a generic solution for any type of XML signature, an SVT is
added to each XML signature element within the XML signature &lt;ds:Object&gt; e
lement.</t>
<section anchor="notation">
<name>Notation</name>
<section anchor="ref-to-xml-elements">
<name>References to XML Elements from XML Schemas</name>
<t>When referring to elements from the W3C XML Signature namespace
(<eref target="https://www.w3.org/2000/09/xmldsig#"/>), the following syntax is
used:</t>
<ul spacing="normal">
<li>&lt;ds:Signature&gt;</li>
</ul>
<t>When referring to elements from the ETSI XAdES XML Signature namesp
ace
(<eref target="https://uri.etsi.org/01903/v1.3.2#"/>), the following syntax is u
sed:</t>
<ul spacing="normal">
<li>&lt;xades:CertDigest&gt;</li>
</ul>
<t>When referring to elements defined in this specification
(<eref target="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"/>), the
following syntax is used:</t>
<ul spacing="normal">
<li>&lt;svt:Element&gt;</li>
</ul>
</section>
</section>
<section anchor="svt-in-xml">
<name>SVT in XML Documents</name>
<t>When SVTs are provided for XML signatures, then one SVT <bcp14>MUST</
bcp14> be provided for each XML signature.</t>
<t>An SVT embedded within the XML signature element <bcp14>MUST</bcp14>
be placed in a &lt;svt:SignatureValidationToken&gt; element as defined in <xref
target="signaturevalidationtoken-signature-property"/>.</t>
<section anchor="signaturevalidationtoken-signature-property">
<name>SignatureValidationToken Signature Property</name>
<t>The &lt;svt:SignatureValidationToken&gt; element <bcp14>MUST</bcp14
> be placed in a &lt;ds:SignatureProperty&gt; element in accordance with <xref t
arget="XMLDSIG11"/>. The &lt;ds:SignatureProperty&gt; element <bcp14>MUST</bcp14
> be placed inside a &lt;ds:SignatureProperties&gt; element inside a &lt;ds:Obje
ct&gt; element inside a &lt;ds:Signature&gt; element.</t>
<t>Note: <xref target="XMLDSIG11"/> requires the Target attribute to b
e present in &lt;ds:SignatureProperty&gt;, referencing the signature targeted by
this signature property. If an SVT is added to a signature that does not have a
n Id attribute, implementations <bcp14>SHOULD</bcp14> add an Id attribute to the
&lt;ds:Signature&gt; element and reference that Id in the Target attribute. Thi
s Id attribute and Target attribute value matching is required by the <xref targ
et="XMLDSIG11"/> standard, but it is redundant in the context of SVT validation
as the SVT already contains information that uniquely identifies the target sign
ature. Validation applications <bcp14>SHOULD NOT</bcp14> reject an SVT token bec
ause of Id and Target attribute mismatch and <bcp14>MUST</bcp14> rely on matchin
g against a signature using signed information in the SVT itself.</t>
<t>The &lt;svt:SignatureValidationToken&gt; element is defined by the
following XML Schema:</t>
<sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns" targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"
xmlns:svt="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"> xmlns:svt="http://id.swedenconnect.se/svt/1.0/sig-prop/ns">
<xs:element name="SignatureValidationToken" <xs:element name="SignatureValidationToken"
type="svt:SignatureValidationTokenType" /> type="svt:SignatureValidationTokenType" />
<xs:complexType name="SignatureValidationTokenType"> <xs:complexType name="SignatureValidationTokenType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
]]></artwork></figure> ]]></sourcecode>
<t>The SVT token <bcp14>MUST</bcp14> be included as a string represent
<t>The SVT token MUST be included as a string representation of the SVT JWT. Not ation of the SVT JWT. Note that this is the string representation of the JWT wit
e that this is the string representation of the JWT without further encoding. Th hout further encoding. The SVT <bcp14>MUST NOT</bcp14> be represented by the Bas
e SVT MUST NOT be represented by the Base64 encoded bytes of the JWT string.</t> e64-encoded bytes of the JWT string.</t>
<t>Example:</t>
<t>Example:</t> <sourcecode type="xml"><![CDATA[
<figure><artwork><![CDATA[
<ds:Signature Id="MySignatureId"> <ds:Signature Id="MySignatureId">
... ...
<ds:Object> <ds:Object>
<ds:SignatureProperties> <ds:SignatureProperties>
<ds:SignatureProperty Target="#MySignatureId"> <ds:SignatureProperty Target="#MySignatureId">
<svt:SignatureValidationToken> <svt:SignatureValidationToken>
eyJ0eXAiOiJKV1QiLCJhb...2aNZ eyJ0eXAiOiJKV1QiLCJhb...2aNZ
</svt:SignatureValidationToken> </svt:SignatureValidationToken>
</ds:SignatureProperty> </ds:SignatureProperty>
</ds:SignatureProperties> </ds:SignatureProperties>
</ds:Object> </ds:Object>
</ds:Signature> </ds:Signature>
]]></artwork></figure> ]]></sourcecode>
</section>
</section> <section anchor="xml-multiple-svt-tokens">
<section anchor="xml-multiple-svt-tokens"><name>Multiple SVT in an XML signature <name>Multiple SVTs in an XML Signature</name>
</name> <t>If a new SVT is stored in a signature that already contains a previ
ously issued SVT, implementations can choose either to replace the existing SVT
<t>If a new SVT is stored in a signature which already contains a previously iss or to store the new SVT in addition to the existing SVT.</t>
ued SVT, implementations can choose to either replace the existing SVT or to sto <t>If the new SVT is stored in addition to the old SVT, it <bcp14>SHOU
re the new SVT in addition to the existing SVT.</t> LD</bcp14> be stored in a new &lt;ds:SignatureProperty&gt; element inside the ex
isting &lt;ds:SignatureProperties&gt; element where the old SVT is located.</t>
<t>If the new SVT is stored in addition to the old SVT, it SHOULD be stored in a <t>For interoperability robustness, signature validation applications
new &lt;ds:SignatureProperty&gt; element inside the existing &lt;ds:SignaturePr <bcp14>MUST</bcp14> be able to handle signatures where the new SVT is located in
operties&gt; element where the old SVT is located.</t> a new &lt;ds:Object&gt; element.</t>
</section>
<t>For interoperability robustness, signature validation applications MUST be ab </section>
le to handle signatures where the new SVT is located in a new &lt;ds:Object&gt; <section anchor="xml-svt-claims">
element.</t> <name>XML Signature SVT Claims</name>
<section anchor="xml-profile-identifier">
</section> <name>XML Profile Identifier</name>
</section> <t>When this profile is used, the SigValidation object <bcp14>MUST</bc
<section anchor="xml-svt-claims"><name>XML signature SVT Claims</name> p14> contain a "profile" claim with the value "XML".</t>
</section>
<section anchor="xml-profile-identifier"><name>XML Profile Identifier</name> <section anchor="xml-signature-reference-data">
<name>XML Signature Reference Data</name>
<t>When this profile is used the SigValidation object MUST contain a "profile" c <t>The SVT Signature object <bcp14>MUST</bcp14> contain a "sig_ref" cl
laim with the value "XML".</t> aim (SigReference object) with the following elements:</t>
</section>
<section anchor="xml-signature-reference-data"><name>XML Signature Reference Dat
a</name>
<t>The SVT Signature object MUST contain a "sig_ref" claim (SigReference object)
with the following elements:</t>
<t><list style="symbols">
<t>"id" -- The Id-attribute of the XML signature, if present.</t>
<t>"sig_hash" -- The hash over the signature value bytes.</t>
<t>"sb_hash" -- The hash over the canonicalized &lt;ds:SignedInfo&gt; element
(the bytes the XML signature algorithm has signed to generated the signature val
ue).</t>
</list></t>
</section>
<section anchor="xml-signed-data-reference"><name>XML Signed Data Reference Data
</name>
<t>The SVT Signature object MUST contain one instance of the "sig_data" claim (S
ignedData object) for each &lt;ds:Reference&gt; element in the &lt;ds:SignedInfo
&gt; element. The "sig_data" claim MUST contain the following elements:</t>
<t><list style="symbols">
<t>"ref" -- The value of the URI attribute of the corresponding &lt;ds:Referen
ce&gt; element.</t>
<t>"hash" -- The hash of all bytes identified corresponding &lt;ds:Reference&g
t; element after applying all identified canonicalization and transformation alg
orithms. These are the same bytes that is hashed by the hash value in the &lt;ds
:DigestValue&gt; element inside the &lt;ds:Reference&gt; element.</t>
</list></t>
</section>
<section anchor="xml-signer-certificate-references"><name>XML Signer Certificate
References</name>
<t>The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReferenc
e object). The "type" parameter of the "signer_cert_ref" claim MUST be either "c
hain" or "chain_hash".</t>
<t><list style="symbols">
<t>The "chain" type MUST be used when signature validation was performed using
one or more certificates where some or all of the certificates in the chain are
not present in the target signature.</t>
<t>The "chain_hash" type MUST be used when signature validation was performed
using one or more certificates where all of the certificates are present in the
target signature.</t>
</list></t>
</section>
</section>
<section anchor="xml-jose-header"><name>JOSE Header</name>
<section anchor="xml-svt-signing-key-reference"><name>SVT Signing Key Reference<
/name>
<t>The SVT JOSE header for XML signatures must contain one of the following head
er parameters in accordance with <xref target="RFC7515"/>, for storing a referen
ce to the public key used to verify the signature on the SVT:</t>
<t><list style="symbols">
<t>"x5c" -- Holds an X.509 certificate <xref target="RFC5280"/> or a chain of
certificates. The certificate holding the public key that verifies the signature
on the SVT MUST be the first certificate in the chain.</t>
<t>"kid" -- A key identifier holding the Base64 encoded hash value of the cert
ificate that can verify the signature on the SVT. The hash algorithm MUST be the
same hash algorithm used when signing the SVT as specified by the <spanx style=
"verb">alg</spanx> header parameter.</t>
</list></t>
</section>
</section>
</section>
<section anchor="appendix-pdf-profile"><name>Appendix: PDF signature profile</na
me>
<t>This appendix defines a profile for implementing SVT with a signed PDF docume
nt, and defines the following aspects of SVT usage:</t>
<t><list style="symbols">
<t>How to include reference data related to PDF signatures and PDF documents i
n an SVT.</t>
<t>How to add an SVT token to a PDF document.</t>
</list></t>
<t>PDF document signatures are added as incremental updates to the signed PDF do
cument and signs all data of the PDF document up until the current signature. Wh
en more than one signature is added to a PDF document the previous signature is
signed by the next signature and can not be updated with additional data after t
his event.</t>
<t>To minimize the impact on PDF documents with multiple signatures and to stay
backwards compatible with PDF software that do not understand SVT, PDF documents
add one SVT token for all signatures of the PDF as an extension to a document t
imestamp added to the signed PDF as an incremental update. This SVT covers all s
ignatures of the signed PDF.</t>
<section anchor="svt-in-pdf"><name>SVT in PDF Documents</name>
<t>The SVT for a signed PDF document MAY provide signature validation informatio
n about any of the present signatures in the PDF. The SVT MUST contain a separat
e "sig" claim (Signature object) for each signature on the PDF that is covered b
y the SVT.</t>
<t>An SVT added to a signed PDF document MUST be added to a document timestamp a
ccordance with ISO 32000-2:2017 <xref target="ISOPDF2"/>.</t>
<t>The document timestamp contains an <xref target="RFC3161"/> timestamp token (
TSTInfo) in EncapsulatedContentInfo of the CMS signature. The SVT MUST be added
to the timestamp token (TSTInfo) as an Extension object as defined in <xref tar
get="svt-extension-to-timestamps"/>.</t>
<section anchor="svt-extension-to-timestamps"><name>SVT Extension to Timestamp T
okens</name>
<t>The SVT extension is an Extension suitable to be included in TSTInfo as defin
ed by <xref target="RFC3161"/>.</t>
<t>The SVT extension is identified by the Object Identifier (OID) 1.2.752.201.5.
2</t>
<t>Editors note: This is the current used OID. Consider assigning an IETF extens
ion OID.</t>
<t>This extension data (OCTET STRING) holds the bytes of SVT JWT, represented as
a UTF-8 encoded string.</t>
<t>This extension MUST NOT be marked critical.</t>
<t>Note: Extensions in timestamp tokens according to <xref target="RFC3161"/> ar
e imported from the definition of the X.509 certificate extensions defined in <x
ref target="RFC5280"/>.</t>
</section>
</section>
<section anchor="pdf-svt-claims"><name>PDF signature SVT Claims</name>
<section anchor="pdf-profile-identifier"><name>PDF Profile Identifier</name>
<t>When this profile is used the SigValidation object MUST contain a "profile" c
laim with the value "PDF".</t>
</section>
<section anchor="pdf-signature-reference-data"><name>PDF Signature Reference Dat
a</name>
<t>The SVT Signature object MUST contain a "sig_ref" claim (SigReference object)
with the following elements:</t>
<t><list style="symbols">
<t>"id" -- Absent or a Null value.</t>
<t>"sig_hash" -- The hash over the signature value bytes.</t>
<t>"sb_hash" -- The hash over the DER encoded SignedAttributes in SignerInfo.<
/t>
</list></t>
</section> <dl>
<section anchor="pdf-signed-data-reference"><name>PDF Signed Data Reference Data
</name>
<t>The SVT Signature object MUST contain one instance of the "sig_data" claim (S <dt>"id":
ignedData object) with the following elements:</t> </dt>
<dd>The Id-attribute of the XML signature, if present.
</dd>
<t><list style="symbols"> <dt>"sig_hash":
<t>"ref" -- The string representation of the ByteRange value of the PDF signat </dt>
ure dictionary of the target signature. This is a sequence of integers separated <dd>The hash over the signature value bytes.
by space where each integer pair specifies the start index and length of a byte </dd>
range.</t>
<t>"hash" -- The hash of all bytes identified by the ByteRange value. This is
the concatenation of all byte ranges identified by the ByteRange value.</t>
</list></t>
</section> <dt>"sb_hash":
<section anchor="pdf-signer-certificate-references"><name>PDF Signer Certificate </dt>
References</name> <dd>The hash over the canonicalized &lt;ds:SignedInfo&gt; element
(the bytes the XML signature algorithm has signed to generate the
signature value).
</dd>
<t>The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReferenc e object). The "type" parameter of the "signer_cert_ref" claim MUST be either "c hain" or "chain_hash".</t> </dl>
<t><list style="symbols"> </section>
<t>The "chain" type MUST be used when signature validation was performed using <section anchor="xml-signed-data-reference">
one or more certificates where some or all of the certificates in the chain are <name>XML Signed Data Reference Data</name>
not present in the target signature.</t> <t>The SVT Signature object <bcp14>MUST</bcp14> contain one instance o
<t>The "chain_hash" type MUST be used when signature validation was performed f the "sig_data" claim (SignedData object) for each &lt;ds:Reference&gt; element
using one or more certificates where all of the certificates are present in the in the &lt;ds:SignedInfo&gt; element. The "sig_data" claim <bcp14>MUST</bcp14>
target signature.</t> contain the following elements:</t>
</list></t>
<t>Note: The referenced signer certificate MUST match any certificates reference d using ESSCertID or ESSCertIDv2 from <xref target="RFC5035"/>.</t> <dl>
</section> <dt>"ref":
</section> </dt>
<section anchor="pdf-jose-header"><name>JOSE Header</name> <dd>The value of the URI attribute of the corresponding &lt;ds:Reference&gt;
element.
</dd>
<section anchor="pdf-svt-signing-key-reference"><name>SVT Signing Key Reference< <dt>"hash":
/name> </dt>
<dd>The hash of all bytes that were identified by the corresponding &lt;ds:Refer
ence&gt;
element after applying all identified canonicalization and transformation
algorithms. These are the same bytes that are hashed by the hash value in the
&lt;ds:DigestValue&gt; element inside the &lt;ds:Reference&gt; element.
</dd>
<t>The SVT JOSE header must contain one of the following header parameters in ac cordance with <xref target="RFC7515"/>, for storing a reference to the public ke y used to verify the signature on the SVT:</t> </dl>
<t><list style="symbols"> </section>
<t>"x5c" -- Holds an X.509 certificate <xref target="RFC5280"/> or a chain of <section anchor="xml-signer-certificate-references">
certificates. The certificate holding the public key that verifies the signature <name>XML Signer Certificate References</name>
on the SVT MUST be the first certificate in the chain.</t> <t>The SVT Signature object <bcp14>MUST</bcp14> contain a "signer_cert
<t>"kid" -- A key identifier holding the Base64 encoded hash value of the cert _ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref
ificate that can verify the signature on the SVT. The hash algorithm MUST be the " claim <bcp14>MUST</bcp14> be either "chain" or "chain_hash".</t>
same hash algorithm used when signing the SVT as specified by the <spanx style= <ul spacing="normal">
"verb">alg</spanx> header parameter. The referenced certificate SHOULD be the sa <li>The "chain" type <bcp14>MUST</bcp14> be used when signature vali
me certificate that was used to sign the document timestamp that contains the SV dation was performed using one or more certificates where some or all of the cer
T.</t> tificates in the chain are not present in the target signature.</li>
</list></t> <li>The "chain_hash" type <bcp14>MUST</bcp14> be used when signature
validation was performed using one or more certificates where all of the certif
icates are present in the target signature.</li>
</ul>
</section>
</section>
<section anchor="xml-jose-header">
<name>JOSE Header</name>
<section anchor="xml-svt-signing-key-reference">
<name>SVT Signing Key Reference</name>
<t>The SVT JOSE header for XML signatures must contain one of the foll
owing header parameters in accordance with <xref target="RFC7515"/> for storing
a reference to the public key used to verify the signature on the SVT:</t>
</section> <dl>
</section>
</section>
<section anchor="appendix-jws-profile"><name>Appendix: JWS Profile</name>
<t>This appendix defines a profile for implementing SVT with a JWS signed payloa <dt>"x5c":
d according to <xref target="RFC7515"/>, and defines the following aspects of SV </dt>
T usage:</t> <dd>Holds an X.509 certificate <xref target="RFC5280"/> or a chain
of certificates. The certificate holding the public key that
verifies the signature on the SVT <bcp14>MUST</bcp14> be the first
certificate in the chain.
</dd>
<t><list style="symbols"> <dt>"kid":
<t>How to include reference data related to JWS signatures in an SVT.</t> </dt>
<t>How to add an SVT token to JWS signatures.</t> <dd> A key identifier holding the Base64-encoded hash value of the
</list></t> certificate that can verify the signature on the SVT. The hash
algorithm <bcp14>MUST</bcp14> be the same hash algorithm used when
signing the SVT as specified by the "<tt>alg</tt>" Header Parameter.
</dd>
<t>A JWS may have one or more signatures depending on its serialization format, signing the same payload data. A JWS either contains the data to be signed (enve loping) or may sign any externally associated payload data (detached).</t> </dl>
<t>To provide a generic solution for JWS, an SVT is added to each present signat </section>
ure as a JWS Unprotected Header. If a JWS includes multiple signatures, then eac </section>
h signature includes its own SVT.</t> </section>
<section anchor="appendix-pdf-profile">
<name>PDF Signature Profile</name>
<t>This appendix defines a profile for implementing SVTs with a signed PDF
document, and it defines the following aspects of SVT usage:</t>
<ul spacing="normal">
<li>How to include reference data related to PDF signatures and PDF docu
ments in an SVT.</li>
<li>How to add an SVT token to a PDF document.</li>
</ul>
<t>PDF document signatures are added as incremental updates to the signed
PDF document and signs all data of the PDF document up until the current signatu
re. When more than one signature is added to a PDF document the previous signatu
re is signed by the next signature and can not be updated with additional data a
fter this event.</t>
<t>To minimize the impact on PDF documents with multiple signatures and to
stay backwards compatible with PDF software that does not understand SVTs, PDF
documents add one SVT token for all signatures of the PDF as an extension to a d
ocument timestamp added to the signed PDF as an incremental update. This SVT cov
ers all signatures of the signed PDF.</t>
<section anchor="svt-in-pdf">
<name>SVTs in PDF Documents</name>
<t>The SVT for a signed PDF document <bcp14>MAY</bcp14> provide signatur
e validation information about any of the present signatures in the PDF. The SVT
<bcp14>MUST</bcp14> contain a separate "sig" claim (Signature object) for each
signature on the PDF that is covered by the SVT.</t>
<t>An SVT added to a signed PDF document <bcp14>MUST</bcp14> be added to
a document timestamp in accordance with ISO 32000-2:2020 <xref target="ISOPDF2"
/>.</t>
<t>The document timestamp contains an <xref target="RFC3161"/> timestamp
token (TSTInfo) in EncapsulatedContentInfo of the CMS signature. The SVT <bcp14
>MUST</bcp14> be added to the timestamp token (TSTInfo) as an Extension object a
s defined in <xref target="svt-extension-to-timestamps"/>.</t>
<section anchor="svt-extension-to-timestamps">
<name>SVT Extension to Timestamp Tokens</name>
<t>The SVT extension is an Extension suitable to be included in TSTInf
o as defined by <xref target="RFC3161"/>.</t>
<t>The SVT extension is identified by the Object Identifier (OID) 1.2.
752.201.5.2.</t>
<section anchor="svt-in-jws"><name>SVT in JWS</name> <t>This extension data (OCTET STRING) holds the bytes of SVT JWT, repr
esented as a UTF-8-encoded string.</t>
<t>This extension <bcp14>MUST NOT</bcp14> be marked critical.</t>
<t>Note: Extensions in timestamp tokens according to <xref target="RFC
3161"/> are imported from the definition of the X.509 certificate extensions def
ined in <xref target="RFC5280"/>.</t>
</section>
</section>
<section anchor="pdf-svt-claims">
<name>PDF Signature SVT Claims</name>
<section anchor="pdf-profile-identifier">
<name>PDF Profile Identifier</name>
<t>When this profile is used, the SigValidation object <bcp14>MUST</bc
p14> contain a "profile" claim with the value "PDF".</t>
</section>
<section anchor="pdf-signature-reference-data">
<name>PDF Signature Reference Data</name>
<t>The SVT Signature object <bcp14>MUST</bcp14> contain a "sig_ref" cl
aim (SigReference object) with the following elements:</t>
<t>An SVT token MAY be added to any signature of a JWS to support validation of <dl>
that signature. If more than one signature is present then each present SVT MUST <dt>"id":
provide information exclusively related to one associated signature and MUST NO </dt>
T include information about any other signature in the JWS.</t> <dd>Absent or a Null value.
</dd>
<t>Each SVT is stored in its associated signature's "svt" header as defined in < <dt>"sig_hash":
xref target="svt-header"/>.</t> </dt>
<dd>The hash over the signature value bytes.
</dd>
<section anchor="svt-header"><name>"svt" Header Parameter</name> <dt>"sb_hash":
</dt>
<dd>The hash over the DER-encoded SignedAttributes in SignerInfo.
</dd>
<t>The "svt" (Signature Validation Token) Header Parameter is used to contain an array of SVT tokens to support validation of the associated signature. Each SVT token in the array has the format of a JWT as defined in <xref target="RFC7519" /> and is stored using its natural string representation without further wrappin g or encoding.</t> </dl>
<t>The "svt" Header Parameter, when used, MUST be included as a JWS Unprotected </section>
Header.</t> <section anchor="pdf-signed-data-reference">
<name>PDF Signed Data Reference Data</name>
<t>The SVT Signature object <bcp14>MUST</bcp14> contain one instance o
f the "sig_data" claim (SignedData object) with the following elements:</t>
<t>Note: JWS Unprotected Header is not supported with JWS Compact Serialization. <dl>
A consequence of adding an SVT token to a JWS is therefore that JWS JSON Serial <dt>"ref":
ization MUST be used, either in the form of general JWS JSON Serialization (for </dt>
one or more signatures) or in the form of flattened JWS JSON Serialization (opti <dd>The string representation of the ByteRange value of the PDF
onally used when only one signature is present in the JWS).</t> signature dictionary of the target signature. This is a sequence
of integers separated by space where each integer pair specifies
the start index and length of a byte range.
</dd>
</section> <dt>"hash":
<section anchor="jws-multiple-svt-tokens"><name>Multiple SVT in a JWS signature< </dt>
/name> <dd> The hash of all bytes identified by the ByteRange value. This
is the concatenation of all byte ranges identified by the
ByteRange value.
</dd>
<t>If a new SVT is stored in a signature which already contains a previously iss ued SVT, implementations can choose to either replace the existing SVT or to sto re the new SVT in addition to the existing SVT.</t> </dl>
<t>If a JWS signature already contains an array of SVTs and a new SVT is to be a </section>
dded, then the new SVT MUST be added to the array of SVT tokens in the existing <section anchor="pdf-signer-certificate-references">
"svt" Header Parameter.</t> <name>PDF Signer Certificate References</name>
<t>The SVT Signature object <bcp14>MUST</bcp14> contain a "signer_cert
_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref
" claim <bcp14>MUST</bcp14> be either "chain" or "chain_hash".</t>
<ul spacing="normal">
<li>The "chain" type <bcp14>MUST</bcp14> be used when signature vali
dation was performed using one or more certificates where some or all of the cer
tificates in the chain are not present in the target signature.</li>
<li>The "chain_hash" type <bcp14>MUST</bcp14> be used when signature
validation was performed using one or more certificates where all of the certif
icates are present in the target signature.</li>
</ul>
<t>Note: The referenced signer certificate <bcp14>MUST</bcp14> match a
ny certificates referenced using ESSCertID or ESSCertIDv2 from <xref target="RFC
5035"/>.</t>
</section>
</section>
<section anchor="pdf-jose-header">
<name>JOSE Header</name>
<section anchor="pdf-svt-signing-key-reference">
<name>SVT Signing Key Reference</name>
<t>The SVT JOSE header must contain one of the following header parame
ters in accordance with <xref target="RFC7515"/> for storing a reference to the
public key used to verify the signature on the SVT:</t>
</section> <dl>
</section> <dt>"x5c":
<section anchor="jws-svt-claims"><name>JWS signature SVT Claims</name> </dt>
<dd>Holds an X.509 certificate <xref target="RFC5280"/> or a chain
of certificates. The certificate holding the public key that
verifies the signature on the SVT <bcp14>MUST</bcp14> be the first
certificate in the chain.
</dd>
<section anchor="jws-profile-identifier"><name>JWS Profile Identifier</name> <dt>"kid":
</dt>
<dd>A key identifier holding the Base64-encoded hash value of the
certificate that can verify the signature on the SVT. The hash
algorithm <bcp14>MUST</bcp14> be the same hash algorithm used when
signing the SVT as specified by the "<tt>alg</tt>" Header
Parameter. The referenced certificate <bcp14>SHOULD</bcp14> be the
same certificate that was used to sign the document timestamp that
contains the SVT.
</dd>
</dl>
<t>When this profile is used the SigValidation object MUST contain a "profile" c </section>
laim with the value "JWS".</t> </section>
</section>
<section anchor="appendix-jws-profile">
<name>JWS Profile</name>
<t>This appendix defines a profile for implementing SVTs with a JWS signed
payload according to <xref target="RFC7515"/>, and it defines the following asp
ects of SVT usage:</t>
<ul spacing="normal">
<li>How to include reference data related to JWS signatures in an SVT.</
li>
<li>How to add an SVT token to JWS signatures.</li>
</ul>
<t>A JWS may have one or more signatures, depending on its serialization f
ormat, signing the same payload data. A JWS either contains the data to be signe
d (enveloping) or may sign any externally associated payload data (detached).</t
>
<t>To provide a generic solution for JWS, an SVT is added to each present
signature as a JWS Unprotected Header. If a JWS includes multiple signatures, th
en each signature includes its own SVT.</t>
<section anchor="svt-in-jws">
<name>SVT in JWS</name>
<t>An SVT token <bcp14>MAY</bcp14> be added to any signature of a JWS to
support validation of that signature. If more than one signature is present, th
en each present SVT <bcp14>MUST</bcp14> provide information exclusively related
to one associated signature and <bcp14>MUST NOT</bcp14> include information abou
t any other signature in the JWS.</t>
<t>Each SVT is stored in its associated signature's "svt" header as defi
ned in <xref target="svt-header"/>.</t>
<section anchor="svt-header">
<name>"svt" Header Parameter</name>
<t>The "svt" (Signature Validation Token) Header Parameter is used to
contain an array of SVT tokens to support validation of the associated signature
. Each SVT token in the array has the format of a JWT as defined in <xref target
="RFC7519"/> and is stored using its natural string representation without furth
er wrapping or encoding.</t>
<t>The "svt" Header Parameter, when used, <bcp14>MUST</bcp14> be inclu
ded as a JWS Unprotected Header.</t>
<t>Note: A JWS Unprotected Header is not supported with JWS Compact Se
rialization. A consequence of adding an SVT token to a JWS is therefore that JWS
JSON Serialization <bcp14>MUST</bcp14> be used either in the form of general JW
S JSON Serialization (for one or more signatures) or in the form of flattened JW
S JSON Serialization (optionally used when only one signature is present in the
JWS).</t>
</section>
<section anchor="jws-multiple-svt-tokens">
<name>Multiple SVTs in a JWS Signature</name>
<t>If a new SVT is stored in a signature that already contains a previ
ously issued SVT, implementations can choose either to replace the existing SVT
or to store the new SVT in addition to the existing SVT.</t>
<t>If a JWS signature already contains an array of SVTs and a new SVT
is to be added, then the new SVT <bcp14>MUST</bcp14> be added to the array of SV
T tokens in the existing "svt" Header Parameter.</t>
</section>
</section>
<section anchor="jws-svt-claims">
<name>JWS Signature SVT Claims</name>
<section anchor="jws-profile-identifier">
<name>JWS Profile Identifier</name>
<t>When this profile is used, the SigValidation object <bcp14>MUST</bc
p14> contain a "profile" claim with the value "JWS".</t>
</section>
<section anchor="jws-signature-reference-data">
<name>JWS Signature Reference Data</name>
<t>The SVT Signature object <bcp14>MUST</bcp14> contain a "sig_ref" cl
aim (SigReference object) with the following elements:</t>
</section> <dl>
<section anchor="jws-signature-reference-data"><name>JWS Signature Reference Dat
a</name>
<t>The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) <dt>"sig_hash":
with the following elements:</t> </dt>
<dd>The hash over the associated signature value (the bytes of the
base64url-decoded signature parameter).
</dd>
<t><list style="symbols"> <dt>"sb_hash":
<t>"sig_hash" -- The hash over the associated signature value (the bytes of th </dt>
e base64url-decoded signature parameter).</t> <dd>The hash over all bytes signed by the associated signature
<t>"sb_hash" -- The hash over all bytes signed by the associated signature (th (the JWS Signing Input according to <xref target="RFC7515"/>).
e JWS Signing Input according to <xref target="RFC7515"/>).</t> </dd>
</list></t>
</section> </dl>
<section anchor="jws-signed-data-reference"><name>JWS Signed Data Reference Data
</name>
<t>The SVT Signature object MUST contain one instance of the "sig_data" claim (S </section>
ignedData object) with the following elements:</t> <section anchor="jws-signed-data-reference">
<name>JWS Signed Data Reference Data</name>
<t>The SVT Signature object <bcp14>MUST</bcp14> contain one instance o
f the "sig_data" claim (SignedData object) with the following elements:</t>
<t><list style="symbols"> <dl>
<t>"ref" -- This parameter MUST hold one of the following thee possible values
. <list style="numbers">
<t>The explicit string value "payload" if the signed JWS Payload is embedd
ed in a "payload" member of the JWS.</t>
<t>The explicit string value "detached" if the JWS signs detached payload
data without explicit reference.</t>
<t>A URI that can be used to identify or fetch the detached signed data. T
he means to determine the URI for the detached signed data is outside the scope
of this specification.</t>
</list></t>
<t>"hash" -- The hash over the JWS Payload data bytes (not its base64url-encod
ed string representation).</t>
</list></t>
</section> <dt>"ref":
<section anchor="jws-signer-certificate-references"><name>JWS Signer Certificate </dt>
References</name> <dd>
<t>This parameter <bcp14>MUST</bcp14> hold one of the
following three possible values: </t>
<ol spacing="normal" type="1"><li>The explicit string value
"payload" if the signed JWS Payload is embedded in a "payload"
member of the JWS.</li>
<li>The explicit string value "detached" if the JWS signs
detached payload data without explicit reference.</li>
<li>A URI that can be used to identify or fetch the detached
Signed Data. The means to determine the URI for the detached
Signed Data is outside the scope of this specification.</li>
</ol>
</dd>
<t>The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReferenc <dt>"hash":
e object). The "type" parameter of the "signer_cert_ref" claim MUST be either "c </dt>
hain" or "chain_hash".</t> <dd>The hash over the JWS Payload data bytes (not its
base64url-encoded string representation).
</dd>
<t><list style="symbols"> </dl>
<t>The "chain" type MUST be used when signature validation was performed using
one or more certificates where some or all of the certificates in the chain are
not present in the target signature.</t>
<t>The "chain_hash" type MUST be used when signature validation was performed
using one or more certificates where all of the certificates are present in the
target signature JOSE header using the "x5c" Header Parameter.</t>
</list></t>
</section> </section>
</section> <section anchor="jws-signer-certificate-references">
<section anchor="jws-svt-jose-header"><name>SVT JOSE Header</name> <name>JWS Signer Certificate References</name>
<t>The SVT Signature object <bcp14>MUST</bcp14> contain a "signer_cert
<section anchor="jws-svt-signing-key-reference"><name>SVT Signing Key Reference< _ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref
/name> " claim <bcp14>MUST</bcp14> be either "chain" or "chain_hash".</t>
<ul spacing="normal">
<t>The SVT JOSE header must contain one of the following header parameters in ac <li>The "chain" type <bcp14>MUST</bcp14> be used when signature vali
cordance with <xref target="RFC7515"/>, for storing a reference to the public ke dation was performed using one or more certificates where some or all of the cer
y used to verify the signature on the SVT:</t> tificates in the chain are not present in the target signature.</li>
<li>The "chain_hash" type <bcp14>MUST</bcp14> be used when signature
validation was performed using one or more certificates where all of the certif
icates are present in the target signature JOSE header using the "x5c" Header Pa
rameter.</li>
</ul>
</section>
</section>
<section anchor="jws-svt-jose-header">
<name>SVT JOSE Header</name>
<section anchor="jws-svt-signing-key-reference">
<name>SVT Signing Key Reference</name>
<t>The SVT JOSE header must contain one of the following header
parameters in accordance with <xref target="RFC7515"/> for storing
a reference to the public key used to verify the signature on the
SVT:</t>
<t><list style="symbols"> <dl>
<t>"x5c" -- Holds an X.509 certificate <xref target="RFC5280"/> or a chain of <dt>"x5c":
certificates. The certificate holding the public key that verifies the signature </dt>
on the SVT MUST be the first certificate in the chain.</t> <dd>Holds an X.509 certificate <xref target="RFC5280"/> or a chain
<t>"kid" -- A key identifier holding the Base64 encoded hash value of the cert of certificates. The certificate holding the public key that
ificate that can verify the signature on the SVT. The hash algorithm MUST be the verifies the signature on the SVT <bcp14>MUST</bcp14> be the first
same hash algorithm used when signing the SVT as specified by the <spanx style= certificate in the chain.
"verb">alg</spanx> header parameter.</t> </dd>
</list></t>
</section> <dt>"kid":
</section> </dt>
</section> <dd>A key identifier holding the Base64-encoded hash value of the
<section anchor="schema-appendix"><name>Appendix: Schemas</name> certificate that can verify the signature on the SVT. The hash
algorithm <bcp14>MUST</bcp14> be the same hash algorithm used when
signing the SVT as specified by the "<tt>alg</tt>" Header Parameter.
</dd>
<section anchor="concise-data-definition-language-cddl"><name>Concise Data Defin ition Language (CDDL)</name> </dl>
<t>The following informative CDDL <xref target="RFC8610"/> express the structure </section>
of an SVT token:</t> </section>
</section>
<figure><artwork><![CDATA[ <section anchor="schema-appendix">
<name>Schemas</name>
<section anchor="concise-data-definition-language-cddl">
<name>Concise Data Definition Language (CDDL)</name>
<t>The following informative CDDL <xref target="RFC8610"/> expresses the
structure of an SVT token:</t>
<sourcecode type="cddl"><![CDATA[
svt = { svt = {
jti: text jti: text
iss: text iss: text
iat: uint iat: uint
? aud: text / [* text] ? aud: text / [* text]
? exp: uint ? exp: uint
sig_val_claims: SigValClaims sig_val_claims: SigValClaims
} }
SigValClaims = { SigValClaims = {
skipping to change at line 1020 skipping to change at line 1463
? hash: binary-value / null ? hash: binary-value / null
? val: [* PolicyValidation] ? val: [* PolicyValidation]
? ext: Extension ? ext: Extension
} }
Extension = { Extension = {
+ text => text + text => text
} / null } / null
binary-value = text ; base64 classic with padding binary-value = text ; base64 classic with padding
]]></artwork></figure> ]]></sourcecode>
</section>
</section> <section anchor="json-schema">
<section anchor="json-schema"><name>JSON Schema</name> <name>JSON Schema</name>
<t>The following informative JSON schema describes the syntax of the SVT
<t>The following informative JSON schema describes the syntax of the SVT token p token payload.</t>
ayload.</t> <sourcecode type="json"><![CDATA[
<figure><artwork><![CDATA[
{ {
"$schema": "https://json-schema.org/draft/2020-12/schema", "$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Signature Validation Token JSON Schema", "title": "Signature Validation Token JSON Schema",
"description": "Schema defining the payload format for SVT", "description": "Schema defining the payload format for SVTs",
"type": "object", "type": "object",
"required": [ "required": [
"jti", "jti",
"iss", "iss",
"iat", "iat",
"sig_val_claims" "sig_val_claims"
], ],
"properties": { "properties": {
"jti": { "jti": {
"description": "JWT ID", "description": "JWT ID",
skipping to change at line 1299 skipping to change at line 1740
"Extension": { "Extension": {
"description": "Extension map", "description": "Extension map",
"type": ["object","null"], "type": ["object","null"],
"required": [], "required": [],
"additionalProperties": { "additionalProperties": {
"type": "string" "type": "string"
} }
} }
} }
} }
]]></artwork></figure> ]]></sourcecode>
</section>
</section> </section>
</section> <section anchor="appendix-examples">
<section anchor="appendix-examples"><name>Appendix: Examples</name> <name>Examples</name>
<t>The following example illustrates a basic SVT according to this specifi
<t>The following example illustrates a basic SVT according to this specification cation
issued for a signed PDF document.</t> issued for a signed PDF document.</t>
<t>Note: Line breaks in the decoded example are inserted for readability.
<t>Note: Line breaks in the decoded example are inserted for readablilty. Line Line
breaks are not allowed in valid JSON data.</t> breaks are not allowed in valid JSON data.</t>
<t>Signature validation token JWT:</t>
<t>Signature validation token JWT:</t> <sourcecode><![CDATA[
<figure><artwork><![CDATA[
eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG
QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9 QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9
PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l
eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv
bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx
Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6 Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6
eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi
Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv
bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp
Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht
skipping to change at line 1352 skipping to change at line 1789
aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu
YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX
mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVN mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVN
n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_ n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_
3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM 3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM
rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk
kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY
Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A
qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc
Cr0hUK_kvREqjD2Z Cr0hUK_kvREqjD2Z
]]></artwork></figure> ]]></sourcecode>
<t>Decoded JWT Header:</t>
<t>Decoded JWT Header:</t> <sourcecode><![CDATA[
<figure><artwork><![CDATA[
{ {
"kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov "kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov
1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==", 1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==",
"typ":"JWT", "typ":"JWT",
"alg":"RS512" "alg":"RS512"
} }
]]></artwork></figure> ]]></sourcecode>
<t>Decoded JWT Claims:</t>
<t>Decoded JWT Claims:</t> <sourcecode><![CDATA[
<figure><artwork><![CDATA[
{ {
"aud" : "http://example.com/audience1", "aud" : "http://example.com/audience1",
"iss" : "https://swedenconnect.se/validator", "iss" : "https://swedenconnect.se/validator",
"iat" : 1603458421, "iat" : 1603458421,
"jti" : "4d1396f1ff728f40d52403b61c574486", "jti" : "4d1396f1ff728f40d52403b61c574486",
"sig_val_claims" : { "sig_val_claims" : {
"sig" : [ { "sig" : [ {
"ext" : null, "ext" : null,
"sig_val" : [ { "sig_val" : [ {
"msg" : "OK", "msg" : "OK",
skipping to change at line 1416 skipping to change at line 1849
pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw==" pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw=="
} ], } ],
"time_val" : [ ] "time_val" : [ ]
} ], } ],
"ext" : null, "ext" : null,
"ver" : "1.0", "ver" : "1.0",
"profile" : "XML", "profile" : "XML",
"hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512" "hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512"
} }
} }
]]></artwork></figure> ]]></sourcecode>
</section>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIACq3gmIAA+19aVfrSLLgd/0KHe47b+6dxsYLe7/qHsAGzGLAK1DdUyNL
MhbIkq8kG0yd+377REQuypRlA7duVfecqeqlsKTMjIyMPSMjC4WCkXiJ7+6b
be8hsJJp5Jo9y/ccK/HCwOyET25gOKEdWGP4xomsYVKIrSBx4zgMCvEsKZR2
DfgYXlZKlUqhtFUo7xg2PHgIo/m+6QXD0Iing7EXx9BhZz5x8aHjTlz4vyAx
DG8S7ZtJNI2TSqm0V6oYVuRaAI5rTyMvmRtP7vw5jJx9swGjRoGbFGoIhWHE
iRU4v1h+GECXQWhMvH3z5yS01804jJLIHcbw13yMf/zTMKxpMgqjfcMsGCb8
4wUxjFE022Iu9JTNsp24QyvIvAqjBwChFru22Q79KWInNg8O6Z01GETubOE1
vYsBEjfZN4/DKH4KvOAhHswDs+G4vF8b5rhvXkwDh/0MHYBgrVKpmjulNf5o
GiSIy3adfrtjy/P3oeP4f1mWVYAhi3Y4NrSZtYrmaTiNfXeuzKs1jWPtMc2p
5z14vkT3unlxcaRNSn+vzWmrvG3CYgRuPPN83zVboeUokzqF5XLCYN3sHShz
q5TKOyV9Yt22OrERg/B/zXBgObsgjMZAkzMXltBsHR9VyuU9/me1XNmSf26X
xZ/bmzv8z61SVXywW97ZFE8ruyXx5/ZWhf+5vVcVPexslbfSP3fTP2ngeqfd
qJb3yqVKgRqYJmekNXxjFsy679pJFAaenfJWbALNAiUPIwuQOLXZs8/1duPL
X83rKLRdh54Mw8g8Aj4gJsQmCk+GQ/PAqbfNGuAnsXylc+jCihKzvL+sLSMo
yQqmJAIEmX4LVi5vAyuzxXYjz42Rj0ULmuAaTrRpAgZMQoE5KxfhPzjC7eVF
rd04KWfQAo8VIdOeB4n1QvDRvEE8BA9mz41QTJi8pyysBf5vTuW1olkHPPrW
kytfMFKvhYHlO9m3meZnRbPlWg9+tvFZGLuTkf5ucWRg8zA7qjXzHPVFptUx
cKUXxfYo0+44ch3Asv2kv860viyazTlQDXCD3vzSegimceZlpnEH5hoCkn03
yrTujMKxFWffZpqfF807b5ppee76My+QLyTpVAulzUK5vIx6+tUjJB5Y9Qkg
2gE8A4OPQR1IEm20r65rxxWdfGqhPYWvEnNsBdaDS38WCuY1yHprAMLHEe+H
JCnoHXJDZd+EzsxKsbSU+mE8fQY7hdLOMvDhYwS/CtqqVKgQvR/U6u2MCPgo
798SSzucpeMclj6cer6DPDLwQ/uJdcZaDazY9b3AVZp9jNE338voVZ3Rr3/A
xK+/a+LXf/DEN/WJH/2AiR9918SP/uCJV9SJG/iproZ3t8ugRI0CcJs1gEla
NlhmCi5SAM2RNXNNy/S9sZcA2/ve0I0nYGc9e8nIhA8m0MhMQjMZuYDVsWtO
ALzQgd/AzfBwDmZlYA5cc8b0GfSBGHFcMAvHgAwHG8NrxAHIAc8ugmxzV9i1
5ud2r/PFcNwhtQZRloy82ERAvKFnsy8nUQhCHcB38V+B7TJ4rBiQl8QELMED
Fg9qZisw3JzZc1B6HRMG4F065mAO+CDTF+dCS0cm2PPIs0fKEFZiWOYEqMKz
p74Vpd2azyC546mN6nM49f25ihvbBrMZyQfQIuY4SU0M6tSGESycOOC7aB4E
c3M4pY5nmr1BU86bl8mXJIZP46FHczJEWxyazxrXOJwC2mCEwGVLZflxKOGl
L2H6Dx4o7vyhwsjAjwAtoe3RFAXz4CzYirlxkcaLp5NJiMjL6ynGpT66bK+j
pbJuoHZAQjprXzWlFomLjKjHnuOAEWB8QvcjCh1gYsTJr588/Pnto7QeuQ8W
W5RnoFGiajNL1cZbVH2JWBwCp4FLAdrwyTU90IohoMjxhkOkEeIj0WEuQcZm
OHMjvu7gm5juizWegCSDaZsdTpKS3dGQHOD6ZckdfyvYB5M+QHoSS4/DudH/
AJKfDnwYHnw5ZIAgBEqYgbGPirv45oBEH4gUkgoCcRkuAHRMLeQAG01f7Ctn
nAP/AVlsNI7NacxQyz6nDnOpbmwBxYYmeJkPgK8BTTEG7gWTDeSnjZ8w8cSg
A5worINAYwfwGtxQXCGtKwkbEmQcDpNn8H2BWAaRhYIZIW670cwD9gauQSa3
orm6tBk8WNoAae9LAaQRGKvgkkkRByIF5Q9oG4231s2ro/Y1yWpAAv4+al3A
/4eMkMAhH0+QcVDW2SNYDRcAiRWAuTgBgs/FtRfgakDHhiTOdcKhOwPSZ8uL
pA4YjT2g1jkiEf4IwXnAeeJAoDOGhHBDoQ/UMBbMCrnDQxvRhx59AiWOp+DB
2kAeRv3FiwkPFFkAPsUAAscE4o/8OmZy/forGX3fvqFEHXowNnpsIE4MhcPg
I+EJffu2zppf8+bXOc1REKXNjV9/5XYwNkYsUAdHvIOjnA5ApukdcNcWPuNC
RlC9+5K4yFCCKhBDQINc8SzId0NRK4yW7DBOEH/4JZEHIBXMeJAgLygaWEde
MAv9GWAiBlGFiIVZqNpBbWyNMRoQY58IXERqQNAjfG/JpYjcWciVMz5fVxaa
5sLIkDBmRfbIgwHVF5w+c82CJDULzNVmQQJiF8YwhPZOYVBIfcIcWwQa0OgF
E9KAqIVdUO2IGClPWQN4DsLbwLXMqDqFyQP2C/UfV1apdaHaDKZqM+QqgVXm
Q75tolkVRq5VYaZWhSa4EUjw99SPL7vtDjK9P3VQYLhg5BrC2tNEcAIrL/VJ
Ou913sjMabRgK4JhIr5A8FWthSDm9ZT9bgLoVR8YEwsEi7J+jOMqu6Vv34rG
4nQP7pjRo09ZXWYuqRRbj5bAnISgPueCBRiSYIKwGu6Eub8anOxrBRr2N4bE
4G9cdSEIPJB/rhSXpKtXYUYfM8U2H1H2rCAbBDkbvFzZQrQYV8yIluYwgaAT
nKEYw9YPMUrNVOwYfOz15VZp5Bbeb5jClA5iMRmBV8Hii9xthgNkDvxsFIXT
B1jQCagy0r9cARlSAZFYz5Mt66gIYTwmc5EZuGmAK0Z2Dww38S3bFTERRjyp
ajMYFQpTjZSLPi7aESaaoeokfI9JhAGo6KKBs3ZCcxQ+u6ixyezF3iZhgsYq
aWxQzx56jKY7HJKLh+sm1bjUAPAl2FRTTht8OQzCjdAsBFEhC5EiUblsdu1R
4H2dusvRZ3hkhegUSBoDxvPYEuYIHJOxgGtFABQg64HM0Shjhy36qYLQuFuC
1Au8Da1Xab0i6SkgKHyLkOqWpINBBcCcryNOUcLQLCVkzjShD8xFWhHAynUM
hH6EAQUfMSSQbJpEoE+BK8CS5yo2NanJUeXOLZrJQ669cREsaTeT5FD8+yJ4
VuTNrJtjYA8PoMfBY9VkMWA5QqCeyHwgcz1S7DbVewFTNOCgh1PfweYTctpS
0crw3mofGMpU1tHmcQFChzoQ9iLiBrjS970JYNoEY3/GDVILbYJI+/rrFIh4
OjZia+guhnVSPDHpAPwBrGA9gCQA8W45M5wLOaa4gFMyjybAVRHZTHY0B5EL
xDEnOKyJNfB8YCp0d4+nERLFOjPmFhQ2YtFyHPyfh0SAGwaAXcNjThSXrFOK
vg9h+XOWWDFpddMR3VrhVMDvdeQq6acU0WmuoYXgsc2yXz+BvRB/Y+SFniBu
68XmGloBa+vs32bziv5u1W+6jVa9hn+3Tw8uLuQf4ov26VX3At4b/K+05dHV
5WW9WWON4amZeQRqeI2t4trVdadx1Ty4WBNWnpFyeuRyz9vDfUcQMITXGOzC
2I68AbMMD4+u/zMYxJO/ljeZlsNtKaFuca/p2zcDHVY2Xhj4c5P9JM8fhA2I
EuwHuBiXFWkGnA60ykCkBiYyO/EjCCkJGUoEWrrQ98Nnj8vomDz3NmPVGtrL
hQKZhWQ72+hQCSWrWBfLYlUkFM1kPmECxnC/TtGOxuF1yYgOPz5FV0qxy3C2
IOJBBaFgDnigjEARFhY3OAi9gcNELj4ieRCHY1Tj5GMKu9/jj3EfKSXJdU1O
wwBC+jJh6OMEueyLUUcB/RMYw8h6oEAPSHMb448gXVBaEY40cU4AIcAID/YD
Ptk68wk8ZV4KivHZ2uE8cVsWOMBriHBrjAEd08uELgzHI/CQX3CYs35b73oa
AFAhomdizf3QYnM0Pw+YEsBA8PbmNAKtgZ8BMXwpKnSAMMScEGIWHyC/gmIl
ACm+hQml6/KMymxkxSOuDjle2ZyMFVKNoB+jU8hXTUwCbRFlTIVA180B2l5G
ZpFSs99NrBQybjPH6UrF5meE9IuIQ6m0DzbyM8htRjbZmJKisogrUXwyHMDr
gFmBmeXHQCETEHxdgMiQa0C3vsKYbOgGjIQcxVyyBsUY2W6F5thrC2zU6q2C
WGLWzUGSgHyZJuQ3812DfOLgagRajlzLYbpC0InBqJymvhAOJvGE29tkkPd5
RA3lCkoSohMyZEncZdxgtlS6BGMq0OASjFAy9KIY4ywweESqYEUc/tdP8SwB
xfBp5VfH00AEXzHvZMh/Qru3QvxkKPOwoObXxiy6RitOnrMhQw5IitIzzncz
FMuK6U/LRKIrCJSh5qaRQNElo/nKGEHqwg+8wFkSGECDWHmhhgWYGJQ6QuPb
TPAgG7Pl7MPEcZEpGwtVS0xOBHNNUGfM9QCbvu+RNZUNYfOCT8CpbqlXpcb4
+Yeo5NAtg669RHWRmS0UPkTWZASrofAymZkx81p4xI7s+yR2/eFCPKAorVwQ
/57LgjEwc0AZroBwi1Ilq8oRdExkQCiXOEgbH4D4Rj/ERJpK0uARx/gSZ1JR
2xQ/FmJQX9OVjXN9eSbgATNKMC+mhSX3I5fCcbE51LLztE+iXwyByK6F+7sQ
oM5CQ70dBJzt0o02LQwtnPzFaD8DzHXWczYIiDQVwKkB+Bq4fKKFEpWRIKeE
nYeLdck7QNR2KI3eRRy9a1ZZoBF/FDPV5woE+RSgJQgAknNNIYJVs1ARrw9B
Pia2BiCWz0bZG0gdQcsbk+0v/NfcyAAtFWezIXNKuLNA6oPbjdzhGMzTsIfO
Z7iJnLgP4NsQDx3OuXAVmy0pw5PWIVDQEYGxXNxCBkeKGdkyhMclQZF3B9IF
HX51e5JbU2CxDjAZhRwxPh4IFQqzyE0f92XiRSg/oLerCXOpfPAgB3NTdMv8
WO7I7nNAcW8ODRfN/mC+IDnM6MMHDkGPXiDZmoHqN6JwilCp4cqsVpU8uYop
yph+fEtXE+djRZHHtLrFNj777kCozLM+qExd9QuDYY8Mhk8wOplZmM4Za8MU
nISPxD0DMjBtnygIR2NBF7QwuPyEAdgC62TALD/snzk2CW0ggClL0MrRSU+z
d4z+2AYkBdytaOABMUVzhk3wQ3ggijcA2p0yQXRIZvShh3b4B8aA56ylKSw4
NKlh3MgizTVgHeJUiukkrqJuq/G9M+FfoKoLTOxn6TqJNALuSoMlyiac3aMF
8xvoxh5ZmLsBLPt5bX/ti9h0xiEI9A+DvBI26hLzeXGfMrfbYDoe4Bag3q1Z
rRQAE0IVerwHNq/Pwygcm4XK/66WEXz8d6HM3KGLcBntLBlne/Md42xX2Tjb
VTFOE0yfyLNrKHc/MhxT9m+tJLf6eR/k0GLICiwfBKi8t1MqlMrw306ptE//
vTe7nSOwQRLPZ3pFchw+R+2wwfZYYZpsg853rYnolnFGGMKzIH82A/5Snw4I
SN+zAXsMXahYoikJ0qHlx4zhrgaPIKr/00/+euSDsvzPh+SvOMQBGySkt+Yo
ZOlPlpAf/DmZmza2e2OT7nPsuoBIRTpRR9++sdW6tCYIAc4mHwCS25jrWGBT
mVjg1CgRX/bUI3pPYdMxTbjibj/4wky16jFLDgeTDgQJdpkPibkICcaO6Clz
3BACHJN1xywSEkjp9KSAUoxYKW9XOH1Fsm2osUfrDJZHvBT7oBDjr1MEaQCi
5clN4sy8//Ezg/Ef/8QTASzFgEk7Dl5bkdMxM1n+8XNKOrXQPrXiEWJsaRf8
G47HmHMpYCzFRoA/iYSVcBX2McA/uZaAj4l2RLSXGsn1V8Jj7L1sTY24ylyh
sEHlmkeMyDVtyug1Vd0UI+WcxsKJ2DJVr7oOxb0a0p6PiccmzDGaLjaLrSC5
rWFPjdoa5iihlYi2DptybugApbjZoLZKfDW114XLg7tCwMc4wghW3gEKGaPL
xwCRGE9zQ8xyZZeE7zTQxS+uQQ4O3BRygewCWmKmOmOmc3OmHZhrDdz9iT4w
b0Uea7o54+wxGZ1udOIoPLbKCIcHruWmmZSXXH1icA+DxhRZHdNsnxUPUPS4
DCtiXgpWWFr0gaanViDFMQ+S78CLEAwyOLqYveWxDVP0zNjm2xvTYJCkM7Gm
DpuJkCG0wCAF0tnQptPbq38wdTz0iD5E98iOFm/IP/Z0uYOgAwSUlZcSBAgx
/mPOQgrcO4qAKyaesJaFv2LWMTKtkBMmEIj2FHEJHsDHwN+0UW4+ROF0Qn4e
PvIwuMt23sZjdEXZHr3lhBMZCFtoATw9ZIIFZyAFnExZBb5EKNjGGnuE2S0C
lnx8824CwK7lsKwrDVlMwGOM0/ansRIhUVaHYxmZgfswYvOGCAJo7r2kXUcH
jgtfIMnfg8BjkbWHj3m6nCe27DCmRtEX8og9mTqQZu6pCcKL8gNRD/QSY4Tc
IjNexJPSiREokjCFOofu/NAG6UukQKvddimDjqcQUFuwUkBlu6BD8lZkAXtv
LAzI8F9gfX/hOorWKFXhoBJTXUimT2bNpFWZGzzlnbJ8KY5JFnKQGag8o0Fd
5LNOX7RkaQzLZE8GdiF+miEm0h8EqzOu8hLBKEQGHB9h+ljAkqUAQgxrLuRK
wXRwV9wMKLMC/DPKpaT0DnrC4hAxHvSj5It1tjvGdjMsyqaPDUUBiW0032Ob
x3NCG5nk0r6OZEScSDBmoWdJram5aIh8BAaFaQ1pU15mfvHUfRyeHAwxuCUH
4LZrgBkJSrKBMZ08RJYjxgvcZwa8koLAdqlzEhBSM0uxrxitmeRmoG3lPaTr
UgCrsECOBDexMgsubSsMr8Vik0k9isc6py6IinLeGtz8wR3eaZyAp8Z6F4kE
+T0KstcNOrmRyIIiM+Y955h10q4SfDBjB+s4YaUbkkTzJM3p8zQuyBssse2F
sS1FFBPxa+ViaY3YXqSlrrDBFmAk/4ZMQNGamIpJL4rBYRow5RIwlOA2E9Ks
8GEEUyNegzmTBDSJSeihbuWpafk22VKc0Hxwp/EXJDU2ozx7QuhptmjYQAne
yXRzyu5w00+458YTcKXqR2rEQVTtz8FCyZQNFOCp1W/fKFjJOmkcNA+4zMMI
VKoAFhfzXfMHzhAGlya9mUzmLlgGIw/ezM3bf033H/JPJmSsg9RtEk4c2ihi
DVcrCBl0HwpjDCCTwl3ZOgtYGoAWeZcEKqyl2EUkJe4CSMD7uNdpYU50sPg6
F6NAnQyji+5/Bo/yCJKSw8NJXTMlhNUoyV7wAwpax0mTtx0vtiNX3YpKueGv
IplvXeEf3hFNg7EeMZjKkQpFpvxLvS8Ly/CPYgzHZA0NjR51k0L3pLnTvCjl
2fs8Cb+YjrFcqGuCX1tTgwv9Ts67lCgXlyk3G1Ej0wxx8lSa92kEVGCRO8wx
s1oibWKllSWTKzS2VX0WyjLDHLpkIWPoTQnyCw6bwpcVJa6D0UUN0EWhoofF
uYhQckIAxWoiiNyZ1HdP+Qzy058WeDkD2CquZnudv6AdlLcQR/B85UqoM1m2
kUtJK3LnSVkzZqKl53netVObbnuuRMo7VxgPWyws7jV5nrqh/+6VxcSHWM8M
0nZ33zjnmFnOLCir1hJN1/wJoefzXdMhv0wDX0xQBs6yzIVmgtj25R6DErNV
PE8uzCYw1Y/IU1UTHVz/KE20KCK+Vy01/p9SS6mQWKqZJL/muh8oNPIUVEbB
LCinrHTK6KcF4SWXUhX0QiikJ27kyIa+B6N5g6skB6NPTc5QPJeKyfBlXiB5
5k1gSzWR8YO60HNWxbxV9lSMbMAZG3EpHX+Es3BByconQLRd5qXgKG6BqeNn
WRLa9J3iefAjYNEyS9+G7x2QCYMuq2WXm3augxCv5iNpanwPMy3R+Fmbb4ld
sJK1Vulb5STjcosGtIFIbV3CVuRD+36a1otJq7n2z/eamdKyeYu3VIMyZTJx
vpGahZGekJ1NpP6tVskHaV53zHVQfyhkSPYL1kg+zbPIPQC0LGD1cSJfYgep
FL7MVMol7/S0vjjlNmQJJ8LFkWdhVXONVMiQVAib4wfpEBq9ucun9bS4N8d3
RR5waWVOzJvJkGra7psUGLnxu7hFx96H4RBqU40TQT9r1wftNjv5cnzQuIC/
kOXWGs1avVNvXTaaB536mrrpP8CTo2p1M7bj9eY0x/HDO4XCGE8IPbjiKI3A
Opv7n7brv8R21V2aJYII/QyYx4IYkp7Sh+VQZthFKZT5QLdC3yuK1KIDWh4u
pd6yZF2RxJZrkGr+l3KqfoUHVs+Oox6owjMIomJGznYjljH89o3Ox7D9HEqE
pH1a0StuvoiCDunuCvDjzMP6iXNxqBXJUO6PafrpDdy+TwLTzN7aeNW6Eqnb
6kbXasFCHb1bzOv2vLBQecZadvHfNT4mk/y24dkWvdiFpnWhx98FzbvdmsV8
lKx3swjAh4TvbzOt9Ixz3A1YgOYjwPyOkaeEi7gUQvX4eV78Kbv3y0NRf2q2
P1izMd2mRV2XqDaMlYKzkmdhawHdD2s4ffBFBZf3XnX/ZG7NbXGrtKef3MIt
d3psLIZ6YUk80h1gz6WnUCjjW+lCuGDaR8ikhgIC6g+1DpSpHvXAjJJEJIGu
dIrIuDfebdz/QLEv58JQTo+X7KzylkrOVmoYY07MemakNNNXHLajqbMYNJLs
OlsmfTP3nX7DUE9ye6fk4rmVKTp1GZXHiMKj1RGTiZ2vgrajrWSmHyZV+Fi0
tvYIs0T4CXWcZ+5EMocrFhgg1gruZA6nifpCaqoap1HABa5cYjGzj7JKmJp2
hKpWj6qxuohycir7jLE4Dx6UEOXH8guzhdww5NaZ1gWHiSZdlLiRobqVCFKz
DDPI0pILKNeGNrgV/evJAB9VW7NyBIxaQWjp0T6uSX4/9P+B+GdsyTbXTFGQ
QtrZ08CnEIbvizPy2nyRyDlHvEMapolkvl7BUq1FkJ6M0rgJs9ZouEWWKBrX
XFUuUaiYvslYESZCJWfoTJT0MJRSjZzmYMi/GlLRg/tuPWLmmDiOzSRm7Kpw
a/PhVQAeca3odC//jM4yp8PxegBYf0k5FkcLOWVaUSQIpTujIgU9EWVxDCwH
GCUWr3lECgZT9VVo+Rk06e0pcOdNnkAypJGFLTDxksKvMhs3c4iaBbVhkLOr
dt08ZafzWWb/Yxi7BXZeX0nsx1QzLf9QV43UDT/kr8h1T5ifWD2GGMlo81IK
WwiSkrsqVCqTKYu6R2ahq4fjKLV+zfw8nUwwBxEkDDs5Y/kPOf1kMqAWk58Q
O9KChJ55InV6wnFRJafqVTkTtctSnWSekzzAmNpiVC8xoLPiiA2l8GdLJEX9
42dWGIfE6z/+yYBJx9M2YNVULgEagxbTabl1nflOA128ZzlkKc7SXZXFQKuS
E7YkE1VQD6cMjYAslZjJBMkkCiivczYnFoQnpQgt0JtWSoIlrEu7B2OK4DxM
xRkh1YpfZ8ByQcS48OvUi1xWkwV5FyQOveDw47+U3YRYVARJ0UtIoFoTUgT+
+kkOaRh1keHlqhW91AJHzHB59kjAz9zUoxPqg9KuRc0btGZ5eS5RWkY/icMO
HatIYbOmUM3YC7zxdMwH2Ben63Mi1KwpMd4p4iRUVzLdkquxLQpZj0fKI6VQ
ZH4f4Vu6SmaF5u3+6eUHFnrXVIGSnELmiD4YFtDSuxGVElNapSxlfXdMfalh
vmD2Ry75QDmDpXl+HCiZ5cePMmCFQBjrmXchKotR2Tp+Dl4WLFtSYpkjCNWW
sgQHKTWIipAKEdTF8Uk1pgn/HTGM8EIG+emO6YmhQKKAY9JKEsSB0H3h0iK8
vGKeTjWfeCkv15G8lbX5BaOptj4ux8EEr/rxXhSDRHRM8/31V4t/UXgZ+wXe
DSgsKvTER9O/mzhD9Tssr5P73eNzrH531m/L74wrWlRZ7ls1i1jIVc6H7AR8
ndZaBNlGN1YQsqawJIB2l1tBol226I1WkYIdIoSVUIvXaBs76lJa6fEEHlBh
Q8WJO0FfuVw0L0KWGoYbw7LuM5XRS38KgygrAtnRBdp09t2ZajqtNl8reHzE
ZyUdXVb8CSQk9ijNK1FBcEmJeipv4iZxVgEIztGqz8CI1SLDY86Gt66zVsmr
VXIutbdFLo5QtZvK0NxuVOWumjjJnZxVtewpwcYV8xZNubum6HyZxSDA2FqO
AcWMVSFjU5I+mOoXrhpou2heDaQlKoP2y6Q5GXy0kbIkrVunblH6NLWZ0wib
gGBHx3iuwOO7tyJWyyq+zhftiSX0tKsPoW1N5HZK6vUlZRCu/vNV7QEditFo
n0tvjjHBwuvZyeGK4rHiGOvseqwam0z7ILdJrTvtatE5rXwRsyaSjH8iw/85
mScktsiqPhIFO0X5Rs8KLFali0KoZtPCSincnuYFkD/R6hXQU4sLkfvwjVcv
5CfI5TEsRvprul0rDpORn6ceZFjLlCg54p/LAw4qpkCJCyeoXCqW88uXSC/g
SJQpQdDprD90WhDFSwB80ywo891fgFn5oEb72eRxrLxPj1rQgS4aPsICeNG+
2ai3T+hdW3PYxcVHn+Mv+1jNYMkJpm/k8Gn6FaBvXnXquNwwf9MFugphnGsM
6bmiPnC2DVNOvOgWo2lszKpOMFOA+7PX0ovJpQQkF+7oFsjhid8ihlmytth3
Ph0s9fSy7VdQiV4FbxlVLE6D03UhHw/7bCJ5r99LHzlNu5QwccEL3xMpgDlj
LKejt6hologgxB9FOGgO8VsEF2ULkATWWGLi5ULczgDy2iNXU3xQ8Gd+IRwW
xAv4XpzDFBXrshqHibs48VjBhpXl50hXGkteOqIiG3QnarBqpyRSP5ntAXgw
C6yZZ/CNGAqAUV1ksN/l1idV1Q+cRWtGguBQsUyxyc87kBJebSZ0EN/U0cbQ
NEDmRIGb2KivAmb5PltzMce0RjY/u+YDNdKZAzohrm7g0tZfKHfmhMFhKOft
OPLCMZWGzVSmXoL1NBVYvDRUyPH0LAZ0sUa92A4XFXPtUejZPM6NdScIrjHQ
vDy0KAhE2x9BCsaSa+K8PB7h9uInMm/imOt2eegWryZhh76FcaHES/JRk4Yg
WQ33GRVVTYk0tUgMHnaIhVFNpcgisLKxXHr23gDarV0S1+Dn3wcuj+2llyIo
qTEiSEUVCYRRSsSk0HbW1l6Xdda0i4BwE4NdzSEIUtjkMhM1YU7SJ/Pggcr8
pDE6ye4WvingGwrgIK69dBNaxmR5IVTajhcltdPeqKYb7TS4eOzaJbeNlVIz
lYtm2EZy2hNuBATCX8mrLmkt3iakRTipyBkt6cKdQSJubTkzLxabF7wwnQy1
USXd9KB0GlkUQCoV7KAvcGrYqR8f753ghExO6pAK5NHVC67gbnHXDreLYw9P
yrPcizzUiXp461wWMEDVgu2pe4nWW0p6y4vfIUFgVA+vCUpGYqZ60TtWx51h
ER1JVpTPVQiB+AErLDgaEbElEZs7ykYHx5YspYe3fA0s+wn1k4hV7OtFpmW8
5tdPubEKLm/EO3liOc1tQNzIMgsIp7gULS2ciiPqBbRFN/pWAD/aTydjoZMp
Ggb7OSGzDAcrmSB6AW0aSh1cqdNXVOJHGCoXwSPkHIoha10BMvV+0PtnN6Hh
BRtp2bI0rY4hJE5liFZQJ22SVuuGH9ogfA+BVZde6FmkyWVjxTk4Nz+7ASjs
cOI6X9YlFlXPjgpv84+w0jZtvbL+5clgKsWmNBLx2M+Oi/E36Bu1U7q9ZQHb
Bpg3Z8b82mgmaQBhInlBJ8VUI7MsHazIj4E9/SsxfWULQf8AM4qceJ9nSmFS
kShcTRK5ySuVAcWLomXfhImshl6x07ovgvY4d7rlFyaKd8r++gkzapKQmEWs
9TdecJroM+I619X6QHD71SNTvzGYfMoJGJ7G51GSTPY3Np6fn4vP1WIYPWzg
bawbpb0NGMmBWf7j05cM27CCWuKKFmIYgQQ5BOLhfdApV4G9BSQYvEU3iT0C
s1TeK1U3ZuVitVh5N4hYNSvexzyhmvcAPsybYK6siicB85xi/OxiPlsYBHiI
PXY3wC3YKBdLG4BClG6TjSB+L5TQdJ+TAgPQ4FugHpVPlw6IqHDmBUgWghqy
V2Py69RUOZXgdyIKv5BbgA0WGaEo/QMXRAkxzFKWEDwju0Ynh+eoyRnKlU6d
NvLZVBZaqOQox0jtQZKhBfmCkA0LPJeu6LKBFFq75m3UA+/vGIEF7j80oTyU
ZJlHQKM1zN0wVG7FY9L7XV0twBAz+bmksefGGUj07xcl3/IuM/KRpW1o8xDR
Rp7UziLMlijkz6upKrkhq2a8LlW3EosWdjz1rFbyUG0U6oKqY+RoCSvrDjgh
pWVwBW02nBTg9UxNqFjUquNWgPqtCCauQhqvg5VuWsLwDamMs+jiWTjaINjB
AlqZb0ixdLJRY7EMMqFNXyRRDIplmjDnS5Rdlik7IsTL7Ss10zctKm/5YDw7
8zQrS6sOj9NjydeYh69nRSym4CrhH7p9ytZRjmsUuZQQoNlfYJpbPPzccPLx
M/ZiQg4zJ4mBhOMukSb8peweCLdflgQ4WFH94neIEm8h6TBVLantAGrlv//7
v43/+juoCFGK6CeqLiQvOvlprds5Luyu/f1vxn+9xPsxtTPh+yDef4l/Wsu1
EcobMAYbgl2YzcE6hknW3KEF/sxPa1/BlKR9APYJW7GmUOyy53fqT9YJgwte
f7j53zAEjTMUGEQT46e1Zche4zd5o/X409qqZcHKtGvmhuyf3xxGBWtXj0Et
/0YDEepJWPCQ6d/4+ASxzAnH3cyf1vBbyi5ak19tqJ/xLjfy+qSnCogANvuQ
FvNvRC4yH4ZxiEzUEcY/K0C2rPKolpiEMl7s9KUXrqxsiylc4tILWf+eE2t6
vYeaVJgpMISd5NQTj9UBYlHVty7vayZGUSUvyIOf1i7n8nfDIXwXi0XEo9R9
HNv5ulMuUJ6W4pLmp7VPi6PwZqsIL/2M/ePOz0ru7YF35Z2d98o33sXR2WgA
0Fas5n3a48Z7uvyvjTx4BV0tnyq9E2jRP+SkhTbZpRruYE6ybkL++gk9HREV
KaCZS6SITg9qZVnPzmN34gpbSomWsBt4s+plycmuRT2NLrc9CnkEiAeeRcCe
9vzEJccUy+Ox8TASty4+y7nxsyRyr1BpV6TZaA20+WSa8gp/dGUlV2roMivz
x27eaU/GIilUAvROAzAt2y0qDnqxOLwAEzoO2VVk1FhUSIzCwTROAjde3KLN
UdhC3oh43gi0rnpLqlo6XEGccoBCw0Sub45OlU5z2IssHY3kh1TH9ia5y67k
0YBokOll7GseoSqkeWff5I1QzCGjdp6IcS5LVszkHq7xhmJLVwaoeV4pwLRW
TMFLZVd6FIayF/iUpBeTFn3AcIySQJv2sAQgntAhAPrcXiyK8iUFMzVKhFdN
nu6a56yJrPyGU0hNLS6itaVZxxCleqCDYMAAu+wjTb/X7XyGJREix5aDVQ31
28gUhmCXkml88BkbML2y6AOn4dNRWjMLSJmCVCx+uAjnl6Khr6RIPVm6lq5D
y5eu5rsXEv1/tFdFrFpmEWB/6try4hxyZWV8gGNHr8Kl+KsZX2YRg0yXLwy6
IntbJyEiQr6M2klIujIjS1F6eHsV8IxQcqiEVQNhSy7Z3PlAz6K8q7iwB7tT
O0qpj0tF3OmJrCBWDmWnVVozlxHSdoGgR7ZLxfeguEmkHlnRlodFw3r4ZpmS
eANfGtFGdBRPbGApcU6FbqOCssmVkm/8QUGk5jtJos07CPiFE1tCtvpC2viy
voQm4vp/jXbjWN2H9HTRmrzRS7yniLNoS+Je3qO0oPm0S7W4z6geR9ISxZje
Y/WJIyIfQd3aORHugNPZMCQPdH3zD9QoAT51ClxG/s7zWAb/8vM/WnbVp8yh
ECQu/VCIODzS5psi5+5ckaWpluebJoUnd54rStVTIzkB1THPR5CClU8qFVzv
OXGiptGss3q8CbtMJnPigPayP3zmgMnMly2bhNopq6UcvHFWjZW9JzqCOWnH
o7LH1OQtMxnw1ITAeCl0ksoIb3TlZc7ZMoIEKXXtidsPBzRG5o4MAcXSk3w5
VGfKNNs38FhMFcLiURYph/OqFufdpUZXFGdPvv4faPh/FmiGZf6kO6vaZah5
O6tqdvcP2VnFEf+YnVX9old59+v37Kyq7QCF6k9tiPS4fsz29MkZ9M3pxGFH
tbXrmrVuRIpInFYL4wSmfTadKFdI2dMo0kAomuQsLKmtnIlAa/3y3BZ2IlNr
ITNEuKv0ooYnEWqkd1QOKN4nTpoBoxRAYCknZLeQI4MpAwnbe6WTN2Aps/yp
8QSr7AOj6CtF/cn8hsyiktOMO7+W/fRs4S3mGJkChYKeH7UkSgiHybOVCbdT
+X8KRDOfWB8VaUFscTFiGHKFqUCgLBIrlZ3G2QjLKYbTEjNiDTK0wNov0g0P
wbMC2zM6c5oLQ9pVUdvww75zNvyAtRX1RFPLpUw8bSF2yHO1ds6lzoFMcRM6
WAGXC2KEU4/EpXaZ3MJHo0rzJFRrTnEkFqQsTkGYsJlScSxoIlIV9S2ZhcmL
MEL6Wd6KZrRwo31lVnEXvFDZr5TKO6AP4RF0XKEtxY6aG5b2op4qVysPpV8w
KvzcaXfQD/qCmKwHtjWJpyT1eISWrr7m6MdbrxXx0MloSo0Ul4/DKDMtT8KN
aX1rlSeySvrHXAPZZZzupcLwdZVHOnJYih4KCl3WT0qyKad5GfjiqZeIwE8m
4YTPaaHGmkR3cckAio/F6YgXLVGiOJ+vGrUvZrlYKe5sVYqw8sWtYsUw6pSy
Swev3X3GzDyGLSQ46XZoXJTJuDxvl6fhNOqdYwUc/JJr4/QhS4m5OurUwVjt
tBrNky/8tq80yMC16Vm/s64FvCkYT1s40tKRwe3MMGrMfGxFT+hzgoGCLqfc
jpUrwZhdp6t4eY0tlM/szDgmEYj8DlonT43uLxqcbjpi9joGXpGCJKJu72jR
OrR0FqJ1ymk2PVqn2EV/dLQOYBLROgRvRbSOpvTvFq07YHfxkbppyov7ft+Q
XK3eknTN4kgHIrRDFMpCDigXRPRMYHZp9Ezg9l8QPXsT02pQa+UuGR7Fa9GR
Bc2l0bnE8SgFF3MAl5SILkqZhpr761TUDeN3BcZSnZPopI1btQyKuNEV79GU
jozY48Mb0T0w017I1mPZqayeKV3vGyH0Hw22ie09ffZFXTKHAQqWIL0LkffE
hnxPfxlKWhHSksT0Z0jrz5DWbwxpNbmRoZVSYeuoaUyCn9WWp4pwK4ve1Ntt
JJ9GDeGWP2YVpqSZmi1VxdmtTEwNqftjMTWhiz8SU/szgPZnAO0PCKBlOUuF
Pt1PlyAsTE697gXBYBbuojO4WK2Tua1q9E6poaDG7NRKC78tZocDcK94Ys39
0HLyr+MkZvk9Y3kCkDSC8K7Ind6Mqn3gIzwnQJmWqiBWunfcCb+1El0/PHUO
1JjuqLFox7pGRbTYAkd07s1kY3EVqa0kqxtIrinHbt5JBqIOcXVexK4XUk6Z
qYN99EQDALa+9PDCQsSGeYc4mW7ATzvB50y8swRXeslXMc4L1C251k20EKf8
OInLyBV2K+NVQNbpCVOeVMZuv02DM8FcFRcCMmQ1XiQme8zR0q8TGa6KnQrE
pFNRTwOS9BF4V0Ni7gudNZzxo5qCpOloVbqcekxVOtmCNZbE2Ii2VITy3LS2
KHW0kA/EjwQvDPs/Yn7mm0u8hbR55Ywyt2yXnBFnC6YVVWNfKvG77CnrLzlH
zVM5KY1b9SJCQQTxquXNRzGvjZXSkVp2kJItmPxChAsq6ixgRFYxYCeGJZKZ
xYR4ptGW3q+eTU98jkBKk9BRUhVV/GVRtM6UGWJpfUl+5RKmFVZi/mtRIzAt
xUTqAD8+ClmEvq0KRBR1eKhS8fww9s8iV5mdFBIUSolAxoL4lKoJaP1qJras
oCsTOqIxjsSSYfxlXXwWl/gtivkvyg2dorchsGdCp1KX9afc9ZbaE/KO7lx5
kXLll+KS3EVdUwELoQ7//yR1MTv5RaB1tud3yqo4YLqU1ADXNCoUucHuPEHC
F0qCmM923MXRYNYiibh2C5FE1VbTIomKtfZHRxIBJhFJRPBWRBJpSv82kcQ3
woS5WpVNWcm34/phQO7JNPILjssD3+l+uFjyL28FGdMwk75dmgvKZy4NpPvb
CCao0JdY1jKjTzRZGpMUq/TvHZPMKXeKScC5Ljv8wluB4pg2c1mlrCKekSgz
R8wV9fn0QqncNl4Tx9L5ohAPcrMZ9zTEKUTOLKLR2BUnnVNjyjQrK0cU9rcc
UsgHNBrYK91iF9pf9peWRcfRqkV+sbVauU3YQ2mh28gcuuJ2QDkOny3zQhBm
WSHXQZyPRQlN7F5eqZXTmIouTBOZvxfb4WTJzQBLI7CCJ1XUU9+MWz6jnYGm
UsqG+v5Txmj6khFXq4Kqkhv+DKr+GVT9LUFVLcyYFiVkYbx862Cx2rQwCj4W
CBWt/gyE/hkI/TcLhGYyCdMyE+wQYEGEHHmRwjCgcs1kNNTSDf0LK3iYYjW1
z0e12sWXbB1bGfaYuSZ+wMhhd7uM5ACqM8IrANhGYTS1ZdRHcTv5mTxgIvMn
81fQrI+Jt2/ioWL4Gzyg9G8r2TenXoB//920pg57Y26YP/9P+uuf9AIGlZ/F
WvHBfW6TMz/A+EbVZOVvPvoMa8LxEbl1Ln/LkuTyCQywb/78l1Q9CRgSJceC
j8RJgw3D7ex97bZh/lxUF5U9Z25O/Sf7TlVR+/rFOOnUqY/svU4MSHEN3T7i
T7/cbMUsUuHHJvJ34Ca5EMHU9/nYiKt9rK5pRfMCcRG+GOQ95+jJ3g/L+qfJ
KfhfbGvoKp41Q2W1L1XwhqbJRK+AGUY20MnC9Z2sm0noy9GBlPfl/ZDYpbgg
ciN7PyShZRw/ZPGSh9LMrXJs2DVcmzVJxmwyOSyRh/y/56BJfStWPJ8oFgE0
0qwtBhzDmvnT3xgU30TnhjbiT+wr9Z+/ciOS3fkE8p7U2ISFosS5UR7TIRG1
StjQZ/wYO78ZU+gLVnJFOaPMwlvcui8yefMrnXJd+w/WBeCaTprH+xsbj3EY
FNhjOgjvRNYw2aiUKqVCubLBv19nzRMv8XGh0sPfC5FTdUKimZOWtqTGYhoo
dYVK5LY4D3KifoepyHHRcoWWzJ4VT0U9B3jzszwKvAbylH9AP4F+tJ9Wov6M
F8q1muY/efcTeVQUBvhVH0B9kDdFjM82aspI2jT4OXf58lsG3rd6Z/erfVfv
MP139e6YB8myAXh+TP4IoKjeHOFg6ngovJYM8LP2lN7wOa0vvqG42Zr2/J+Z
br3EHRNSsyj6ljsD0KhvzqD+MvF4LVsqB/05dsHCdTDcgkLZnYT26Mt34S9D
kW8B0s5zR3jbJcNrTCTf5jKTfDtbIDd6LOJ5Oa+k8ZD3EpOoVy7ZEt7T4Ml7
kYeiHqsQkgMHfb2MbcQ/31bM+70gNLRotrkcbd8NUYru98J0qtvg3VbjR8KD
K/zuBZIVR9PNkLdgYWy/5CPJ8Lmv6ZP/wEAH9PNp4z9AD21INlqc3ZIZUi9j
L2jwscrvQgvYCO9GS2qIjK3Jsqlm5iHb5KyS9iQD3Fp6OOZaZb2h5ceuoXcB
TVd+Dq8RFn2eqaBa289Mf7VgekMypSH8HAStqe7Fsg+00NeyTkC4ZjD6zyyY
b4isFNCldLlctktzfwkZ5NFz2maxSR4968j6EJAiPruKKd/Huu/hXT5ZU+fe
jDuVz8fLGPkNTl6KL412PoYyPfkx+ugCa07gR1YYKfk7KFCxLvjVF3/UOqdz
zrpwf8Aai6DB+1GGDq6CrX8BmnQXexmS3oWAfx99tQDd+zSW1mxNk4q/gxqi
cEsu4w1kKEb55/tUCHX0bnI85ecO9HgtxSzepMylThf7jLnq+CGLc7xbCg1+
wxy4uqE7m/5VE/AWPdylsKcStFF7h5QXHrAEfQ1jTWv/zIFsJXt8J3csaNGF
ef5GLllmY/0Q7viQEm5l94yUjeb3EtY76eVj1K4aVMsESh4wv4XKfzgt6ebJ
Dxa11DoP0UgAv5WIOGjv1fa8DPvHbLl3rpwbTMckDFhYf10N6udJhGUoefds
jvJm8T6O+O1WzPuQQp++g6Txn+81BH84NywYrj+YISahv4Qf4t/MD9j3uwmI
TVTZcP7BkjRaBmYeMCuclx/GmXx7bF1sjq1ntsbey6bjeHm4bGFil26MJ1Z+
hBGRB8u/rc3/PayXcYZ+tCbCfctcv3GZisLtnd+sothu6TuppafeW/km4S/s
Tch/8v3j79KWie4jYzw8zLULNdA+Jiry9tGWAsY21ORxcgTvd4HpA44DxRFc
PLxD98a+W6Iucv3vYqVKn0wF88Ow/WjP7EORmt6HtcK/LKL1/6PkTgfLTOkD
M0kJT8j3PMLTpHzm1RLAF3C8SiIouOF/fjO+8QQQJWONF21fuDvdZc9Nz/en
dIMqHZcFxvBsliOn5unnXOnDj9UsLaglT19dYCL2IHKtJ5lGK84gCBioIE7A
b3LGHvFoDF6b6uPdItiBwTsQqbd09SbLaWd35VF+CL+JMddEY+krZ/0OT5Vz
52eR1b/BCvDX9/2ts/PXm9dmfRLeBffj1slW6d6/ty9eR/NOdXTaLN1HTuB/
vesm/fb4uG93/RPjxh/NrOP78KbfLd8/xZt3/a2Z83jcaT4+bNqPzsXd+Dg+
r9xX7JPjxmU/3LT6Z0Gzc9a6CZ5eusf1PeO63YgbQWvLPmpsN54mt70j+A2N
7ufw2z/rNDv1eSMoFQHSkcMgDZ3T1vOV/zy7PdrzDffkOLFPXvyLcXM26D3P
7m57T1a/N72rdF8a3rNn3TZfG4+hZ522Svbp5TY0si+qzep9v+UPoI0xGG/5
d9WbqV3pwYv70eDEf7q7bc1sDyHxRw5Adtm5e758vSlf1W7ml23oNGhNsNPm
yc2Lcfn6VLl/PB7fP9rzq5O70uXJTfny8eb5stKoXPYvy83Xm9JV7Q7L679a
fWfowPRuK834ru8nNkwTVwFe2N6Vn+w0xr1NHHEQ9OLB0bNnV/zgFqGCZ/1q
7A1umwGO3CnF2KHvnt54xtV4qzw4eQZEnvk2Ie7wsFtuHrcQmcHhDBs3xqOS
c3rA5l/xny6CpThoVpzj5xmOjKBe3EIHJ/6jC8h1Ti8B2cnEhfeXtbo37JVg
gObEuC/vze/7d94VSAsCuTIa2ZUHXK6tu0rvpvf0cuaOW492Pd5qlvz7TmV0
0u7fvQyCp+pVd5QY7W7TAxLabvd7Vmd8NnHHu1X7yTlzSqOrzuPhdr/ud9xu
cmo9NSuD8d60UzlutSr3lzCdm8vqfd1w6o3Nq1P/olt2/P6JvUeENfafaO37
N0nz9XLrquY/NmGdLmt3r83Hy8pdv1G+79hl+AuW8eSu2uzYpeajTUt15++F
d7fNEDu4Ge/d9B5btzel+pZdOj6764++tl+PG3f9ybgVjCbnpeNt4+a1dd4q
t8rQ/1bvtWn1KpNH96lV6/XONu9PLrf6/V7pvjsq3QEz9ca94L56uNmuh9Um
Um25XjXa9c2X+3rrCbC91b51gutOyRu2GQ0Mxr05EI1vB62hPe6NG4+THVzu
ew/oYt54Oa8cj4z2GEZ4dWAlXo6745de69g/tnrdUv/Jt6zjm1LX71Wsrt/q
B72LZmX3pVW6v7jrtW66nfut80qyaSA2O0GrbgeHZbtXr/RP7udW6WHLKfv1
9mvLdzuHW81jZ9556s0HgUDyQ6lbb23ePfYso10pb172e91u9bgCM7xvvY6C
y1fAfa13DrL46Ly0FbS6o5NepxXcvfolu2s/WxWnYVWASl6BEjunk6h36lSd
27Mzq3Z/f9U9Ht37k3u7fzl3/YO5Xe/O7VqrhbiBVarf185qzdvm0WXdv+72
e02jN946vhknzWavDqvwVBl0zxqdwKnedc5Krj9q2vPk0qn27u9Kez3HP4zs
wD/tPh6OunV7s/PqT4127+B1cHJWbT4lX7ud47B1Um5br/fbN6+jzcvx5On+
tbTX8EtMap10kcQfrZPjyYDTiwHiipgCeAIFyei2ypcJ2JctXeiRZDo5frVI
7N0/tqqH153KHcjHl0ejewpSpuvg3B5bla3LVqm12fUvy9aj8+o8lUp3t4fP
l08Ppct+q97qviSXT81tQF+33zmYD8YtH+jg/tYa+1PnpNy6fLUr7f7LXa++
d2g/Xr64t5N7N2hy4nqRRNTwmiC9WyA/SsAL/fpLs9N7uuqcefePIEpekS/q
r3fjRvXu8a5y2bkBKQGsRNJasvpFd5wEd35YMbogIAbjUa/52Dzr9OPnVsXv
3fsgXEqtrlO99/t9v3TfO46ckuO3g+Nas3u2DQvWvzo5a90Fh75xfwwf9pzz
7unoxXkKn7v+02bzZFQddIC9gWHuXw8b9tMxaC3nwsEVCcoO0EPJ6pd9lJcG
Ccxyee8WGOj+dlQChpk6/ZcYPqrc3zYA3MbLxeMBEtGzPd4bA+Z9XJl+vXyJ
q2PQ8hzvgT5wZlKB1Cb2RRnkYNWpXgT268UYxB78vnw8eL7soUxsgfwcJYOT
3tS4mzdfrRPortPwhrelYsc5PQob3fb9Y+X1stE8f9ipb24Wdnv1X8ZnX7c7
J+Wr8Po5uGvHv4zm3cH01hhHF2eT6dPuSWvrLgoc92pqX3fvDp6vX06TX4bb
u2eNm/lxxytZD1d7vbPHoNzauX6sniXb/ZO9yR3wQrB1cVqolcfWS61cvn95
Gdh37ukgjhOn0p5XppdW9dCZwM8T53o+bo/t7ZOXu63pWXhRKmzNnsNfjKpf
2DwcVC+OOt705e7aHr8m541BbV4Z1R/Oqqcv5fPN0+NS+/QhqDaCyddDd1Yd
jSvti2cQcVuHR5dGNH8+PBid3tW3r07qJevqbPspOdjqXpceG43TofW855Wf
G95ZctqxTqazZN5vXzxt2fFoPA32Tp+cJ+Op1TnY2Rq8Tr+WGnOn9HVU2ilF
B7snj24h3uw8b768JsnDOQDSfprNd4Ot46+z174T389s/+ikMr4z7vaiy5fR
LzvbpZ3mrf1iPR5cb85rV+F5M94KxnvVne6FW5odNXetnX4nOp4CWz5G853T
0WvrcvNo68D4+jKoXR3eXl/Mw8to82uwedE6Ozp9uXIv7rfD6vRhVru66sfz
x6eq63vzw+fadPfr2elOdzz37IuXmm0cRaVR9/yXp1mr/vWxVrln5mmNm3+Y
zspODu2n6cR0ymR/7coNGn/ZrG6ejQazYS1Ihr1/bOxGVy8nO8cw20frvHdm
9b42jg9vw1FvdOBuDc93rSCcpUZxub29uxvtnA8s/y/D2cQ6LT/ueoOHrcrN
4bx8ffPTT2TUo4UNwwEo7KflP8DPVnurXFkT5rQKLzvmoMKLqakmz3ze39jg
Nm3RDscbFs9ILbO+MXggvsQc6YW7uLi5Gkb8e3BW4fvydqm6ubW7WSnTU0wU
xl42nXJ1b3tYHg53KrvDzZKzVdksVQfbZXtrZ3Nzd5v1kUn8NIWTwSrOgmci
nQ7y8+AJujLCW5G5HdqXPLKIQFydq3nPOT3w8KqZJv0rbzAKrKBu2fVkAATA
UGCXo28s+pRJXJg8eS8bpbJwkL6l8a/0MLaWbp0erobx57Z73btovDr25Hxv
p3F3NTpuDMvBfGfvdNw4GrR7rw33vjnwXsOd6KTxvMQTP202S6+3jfb8/OTx
aBaEwZV1czK82LiuzmrJ4e7u/Lzdd28fOOFxODxGPJ5T2Knu7e7Z20O7tF2F
/1iDLXdnqzosl4Y7sKDbO1qC+SAF/jC87m32jw724oOGNXo8L59aj8PjF+8v
B69Hm2cnnemwutcHe/fRfq0ddVsv+dA79t6dm7inif1y0nMfHiYvp2c7Wxv2
zc5ps+zUHODvxjPCLjCs4lc/56nhmT/52Vwr/8WyztzkYSdy/XrL79bu6l53
875xP+pstrozr3FzPz3fCcsnx+dW5/pme/6XPEifXjaum0ktmky/3mzfDqOn
073nu9r5pjsvzTf7UbMeBc8ahtN/1kab17WXwdb9+fil7HbaX2e92d3J7kO1
Gpe2zl6fD//SfKifHnc3H+y95OtJ6enhNBeCIZgz4cXrU+f5eRo1Rtt3ewfW
8P7uq115va5M6pXJ5s0yCGpO5WgrPiw1rm7cy15QP3y63LrZ6+9tjw9Pm89g
Diavt5fxXy6ep3f2VXd2/RTlQTA/aZWs65Pdq72gcV31B8/b54835VFt3Hra
fj3afak8OrhSagyYn9Ldzx7hWVjKNFcvy/IiO06lQ0mEx/bJ5OpquOv59nVS
KZ/ARO2T4OKk9gKi9HEnnl1uWpNJ5XQTaKl+Ma4cvdo5M3M7d6UKaPuzYf/R
C5LxTXUHHLrbztVBVC3PX+9eY40C86D7RDcXF8plq7y15exVBsOtrR1gn3J1
MNgZbG+XN3d27KGTO4nz1tPD4H77eiMYdberjcun0onXHXY3ap3nmXvnJe7N
0/OJe/b1aOvwtdPs7Q5uBjmTmLhOpzPtn12/fJ2dlVp3u5uj5/GOe7fxUDqN
Dq7ch/NnZRKKoJJZYYR5tq8i3y/KVspWR7Dxikr+SFbC2GfXXfHHaRq3Im2z
t1SWNvEmaxC+n+KRReovjSj9X64MXzS09wAA
</rfc> </rfc>
 End of changes. 198 change blocks. 
1501 lines changed or deleted 1415 lines changed or added

This html diff was produced by rfcdiff 1.48.