<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.5 (Ruby 2.6.8) --> encoding="US-ASCII"?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3125 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3125.xml">
<!ENTITY RFC3161 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3161.xml">
<!ENTITY RFC3647 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3647.xml">
<!ENTITY RFC5035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5035.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5652 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml">
<!ENTITY RFC6931 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6931.xml">
<!ENTITY RFC7515 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml">
<!ENTITY RFC7518 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml">
<!ENTITY RFC7519 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
<!ENTITY RFC8610 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-santesson-svt-08" category="info" number="9321" submissionType="independent" category="info" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">
<front>
<title>Signature Validation Token</title>
<seriesInfo name="RFC" value="9321"/>
<author initials="S." surname="Santesson" fullname="Stefan Santesson">
<organization abbrev="IDsec Solutions">IDsec Solutions AB</organization>
<address>
<postal>
<street>Forskningsbyn Ideon</street>
<city>Lund</city>
<code>223 70</code>
<country>SE</country>
<country>Sweden</country>
</postal>
<email>sts@aaa-sec.com</email>
</address>
</author>
<author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address>
<postal>
<street>516 Dranesville Road</street>
<city>Herndon, VA</city>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>US</country>
<country>United States of America</country>
</postal>
<email>housley@vigilsec.com</email>
</address>
</author>
<date year="2022" month="May" day="17"/>
<area>Security</area>
<keyword>Internet-Draft</keyword> month="October"/>
<keyword>digital signature</keyword>
<keyword>electronic signature</keyword>
<keyword>long-term archive</keyword>
<abstract>
<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)
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
a particular signature was successfully validated according to defined procedures at
a certain time. Any future validation of that electronic signature can be satisfied by
validating the SVT without any need to also validate the original electronic signature or
the associated digital certificates. The SVT supports electronic signatures in CMS, Cryptographic Message Syntax (CMS), XML,
PDF
PDF, and JSON documents.</t>
</abstract>
</front>
<middle>
<section anchor="intro"><name>Introduction</name> anchor="intro">
<name>Introduction</name>
<t>Electronic signatures have a limited lifespan regarding when they can be validated
and determined to be authentic. Many factors make it more difficult to validate
electronic signatures over time. For example:</t>
<t><list style="symbols">
<t>Trusted
<ul spacing="normal">
<li>Trusted information about the validity of the certificate containing the signer's public key is not available.</t>
<t>Trusted available.</li>
<li>Trusted information about the date and time when the signature was actually created is not available.</t>
<t>Algorithms 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 available in software libraries.</t>
<t>Services libraries.</li>
<li>Services necessary to validate the signature are no longer available at the time of validation.</t>
<t>Supporting validation.</li>
<li>Supporting evidence such as CA certification authority (CA) certificates, OCSP Online Certificate Status Protocol (OCSP) responses, CRLs, Certificate Revocation Lists (CRLs), or timestamps is not available or timestamps.</t>
</list></t> can't be validated.</li>
</ul>
<t>The challenges to validation of an electronic signature increases increase
over time, and eventually it may simply be impossible to verify the
signature with a sufficient level of assurance.</t>
<t>Existing standards, such as the ETSI XAdES <xref target="XADES"/> profile for XML
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="RFC5652"/> target="RFC5652"/>, can be used to extend the time within which a signature can be
validated at the cost of significant complexity complexity, which involves storing and
validating significant amounts of external evidence data such as revocation data,
signature time stamps stamps, and archival time stamps.</t>
<t>The Signature Validation token Token (SVT) defined in this specification takes a
trusted signature validation process as an input and preserves the validation result
for the associated signature and signed document. The SVT asserts that a particular
electronic signature was successfully validated by a trusted authority according to
defined procedures at a certain date and time. Those procedures MUST <bcp14>MUST</bcp14> include checks
that the signature match the signed document, checks that the signature can be validated by
the signing certificate certificate, and checks that the signing certificate pass certificate
path validation <xref target="RFC5280"/>.
Those procedures MAY <bcp14>MAY</bcp14> also include checks associated with a particular trust policy such as
that an acceptable certificate policy <xref target="RFC5280"/> <xref target="RFC3647"/> was used to issue the
signer's certificate and checks that an acceptable signature policy was used by
the signer <xref target="RFC3125"/>.</t>
<t>Once the SVT is issued by a trusted
authority, any future validation of that electronic signature can be satisfied by validating
the SVT, SVT without any need to also re-validate revalidate the original electronic signature.</t>
<t>As the SVT is used to preserve validation result results obtained through applying existing
standards for signature validation, it is complementary to and not a replacement for such standards,
including the ETSI standards for long term long-term validation listed above.
The SVT do however does, however, have the potentially positive effect that it may significantly reduce the need to
apply complex long-term validation and preservation techniques for signature validation
if an SVT is issued and applied to the signed document at an early stage where the signature
can be validated without support of large amounts of external evidence.
The use of SVT SVTs may therefore drastically reduce the complexity of re-validation revalidation of old
archived electronic signatures.</t>
<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
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 quantum
safe digital signature algorithm to protect against advances in computing power and
cryptanalytic capabilities. Further, the trusted authority can add additional SVTs
in the future using fresh private keys and signatures to extend the lifetime of the, the SVTs if necessary.</t>
</section>
<section anchor="defs"><name>Definitions</name>
<t>The anchor="defs">
<name>Definitions</name>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t> here.
</t>
<t>This document use the following terms:</t>
<t><list style="symbols">
<t>Signed Data -- The
<dl>
<dt>Signed Data:
</dt>
<dd>The data covered by a particular electronic signature. This is
typically equivalent to the signed content of a document, and it
represents the data that the signer intended to sign. In some cases,
such as in some XML signatures, the signed data Signed Data can be the collection
of several data fragments each referenced by the signature. In the
case of PDF, this is the data covered by the "ByteRange" parameter in
the signature dictionary. In JWS, JSON Web Signature (JWS), this is the
unencoded payload data (before base64url encoding).</t>
<t>Signed Bytes -- These encoding).
</dd>
<dt>Signed Bytes:
</dt>
<dd>These are the actual bytes of data that were hashed and signed by
the digital signature algorithm. In most cases, this is not the actual
Signed Data, Data but a collection of signature metadata that includes
references (hash) of the Signed Data as well as information about
algorithms and other data bound to a signature. In XML, this is the
canonicalized SignedInfo element. In CMS and PDF signatures, this is
the DER-encoded SignedAttributes structure. In JWS, this is the
protected header and payload data formatted according to <xref target="RFC7515"/>.</t>
</list></t>
target="RFC7515"/>.
</dd>
</dl>
<t>When these terms are used as defined in this section, they appear with a
capitalized first letter.</t>
</section>
<section anchor="svt"><name>Signature anchor="svt">
<name>Signature Validation Token</name>
<section anchor="svt-function"><name>Signature anchor="svt-function">
<name>Signature Validation Token Function</name>
<t>Signature
<t>The Signature Validation Token (SVT) is created by a trusted service to assert
evidence of successful electronic signature validation using a well-defined and
trustworthy signature validation process. The SVT binds the validation result to
the validated signature, the document signed by the signature signature, and the certificate of the signer.
This allows a relying party to verify the validity of a signed document
without having to re-validate revalidate the original signature or to re-use reuse any of its associated
cryptographic algorithms for as long as the SVT itself can be validated.
The SVT achieves this by binding the following information to
a specific electronic signature:</t>
<t><list style="symbols">
<t>A
<ul spacing="normal">
<li>A unique identification of the electronic signature.</t>
<t>The signature.</li>
<li>The data and metadata signed by the electronic signature.</t>
<t>The signature.</li>
<li>The signer's certificate that was validated as part of electronic signature verification.</t>
<t>The verification.</li>
<li>The certification path that was used to validate the signer's certificate.</t>
<t>An certificate.</li>
<li>An assertion providing evidence of that the signature was verified, verification, the date and time the verification was performed, the procedures used to verify the electronic signature, and the outcome of the verification.</t>
<t>An verification.</li>
<li>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> validation.</li>
</ul>
<t>The SVT aims to support long term long-term validation that can be further extended into the future by applying the following strategies:</t>
<t><list style="symbols">
<t>By
<ul spacing="normal">
<li>by using secure algorithms with long life exepectancy expectancy when signing the SVT.</t>
<t>By re-issuing SVT</li>
<li>by reissuing the SVT before it becomes insecure or is considered expired.</t>
<t>Optionally, expired</li>
<li>optionally, by issuing multipple SVT:s multiple SVTs with different algorithms to provide redundancy in case one algorithm is broken.</t>
</list></t> broken</li>
</ul>
</section>
<section anchor="svt-syntax"><name>Signature anchor="svt-syntax">
<name>Signature Validation Token Syntax</name>
<t>The SVT is carried in a JSON Web Token (JWT) as defined in <xref target="RFC7519"/>.</t>
<section anchor="svt-syntax-dt"><name>Data 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">
<t>String -- JSON
<dl>
<dt>String:
</dt>
<dd>JSON Data Type of string that contains an arbitrary case sensitive
case-sensitive string value.</t>
<t>Base64Binary -- JSON value.
</dd>
<dt>Base64Binary:
</dt>
<dd>JSON Data Type of string that contains of Base64 encoded a Base64-encoded byte
array of binary data.</t>
<t>StringOrURI -- JSON data.
</dd>
<dt>StringOrURI:
</dt>
<dd>JSON Data Type of string that contains an arbitrary string or an
a URI as defined in <xref target="RFC7519"/>, which REQUIRES a value containing target="RFC7519"/>. It is <bcp14>REQUIRED</bcp14> to contain the colon character (":") to be a URI.</t>
<t>URI -- JSON URI.
</dd>
<dt>URI:
</dt>
<dd>JSON Data Type of string that contains an a URI as defined in
<xref target="RFC7519"/>.</t>
<t>Integer -- JSON target="RFC7519"/>.
</dd>
<dt>Integer:
</dt>
<dd>JSON Data Type of number that contains a 32-bit signed integer value (from -2^31
-2<sup>31</sup> to 2^31-1).</t>
<t>Long -- JSON 2<sup>31</sup>-1).
</dd>
<dt>Long:
</dt>
<dd>JSON Data Type of number that contains a 64-bit signed integer value (from -2^63
-2<sup>63</sup> to 2^63-1).</t>
<t>NumericDate -- JSON 2<sup>63</sup>-1).
</dd>
<dt>NumericDate:
</dt>
<dd>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:00Z UTC until the specified
UTC date/time, ignoring leap seconds.</t>
<t>Boolean -- seconds.
</dd>
<dt>Boolean:
</dt>
<dd> JSON Data Type of boolean that contains the explicit value of true or false.</t>
<t>Object<Class> -- A
false.
</dd>
<dt>Object<Class>:
</dt>
<dd>A JSON object holding a claims object of a class defined in this
specification (see <xref target="svt-syntax-claim"/>).</t>
<t>Map<Type> -- A target="svt-syntax-claim"/>).
</dd>
<dt>Map<Type>:
</dt>
<dd>A JSON object with name-value pairs where the value is an object of the
specified Type in the notation. For example, Map<String> is a JSON
object with name value name-value pairs where all values are of type String.</t>
<t>Array -- A String.
</dd>
<dt>Array:
</dt>
<dd>A JSON array of a specific data type as defined in this section. An array
is expressed in this specification by square brackets. For example, [String]
indicates an array of String values, and [Object<DocHash>] indicates an
array of DocHash objects.</t>
<t>Null -- A objects.
</dd>
<dt>Null:
</dt>
<dd>A JSON null that represents an absent value. A claim with a null value is
equivalent with an absent claim.</t>
</list></t> claim.
</dd>
</dl>
</section>
<section anchor="svt-syntax-claim"><name>Signature anchor="svt-syntax-claim">
<name>Signature Validation Token JWT Claims</name>
<t>The SVT MUST <bcp14>MUST</bcp14> contain only JWT claims in the following list:</t>
<t><list style="symbols">
<t>jti --
<dl>
<dt>"jti":
</dt>
<dd> A String data type that is a "JWT ID" registered claim according to
<xref target="RFC7519"/>. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the
identifier holds a hexadecimal string representation of a 128-bit unsigned
integer. A An SVT MUST <bcp14>MUST</bcp14> contain one "JWT ID" claim.</t>
<t>iss -- A claim.
</dd>
<dt>"iss":
</dt>
<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 SHOULD <bcp14>SHOULD</bcp14> have the value of an a URI based
on a domain owned by the issuer. A An SVT MUST <bcp14>MUST</bcp14> contain one
"Issuer" claim.</t>
<t>iat -- A claim.
</dd>
<dt>"iat":
</dt>
<dd>A NumericDate data type that is an "Issued At" registered claim
according to <xref target="RFC7519"/>, which expresses the date and time
when this SVT was issued. A An SVT MUST <bcp14>MUST</bcp14> contain one "Issued At" claim.</t>
<t>aud -- A
claim.
</dd>
<dt>"aud":
</dt>
<dd>A [StringOrURI] data type or a StringOrURI data type that is an
"Audience" registered claim according to <xref target="RFC7519"/>. The
audience claim is an array of one or more identifiers, identifying intended
recipients of the SVT. Each identifier MAY <bcp14>MAY</bcp14> identify a single
entity, a group of entities entities, or a common policy adopted by a group of
entities. If only one value is provided provided, it MAY <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 a an SVT is OPTIONAL.</t>
<t>exp -- A
<bcp14>OPTIONAL</bcp14>.
</dd>
<dt>"exp":
</dt>
<dd>A NumericDate data type that is an "Expiration Time" registered claim
according to <xref target="RFC7519"/>, which expresses the date and time
when services and responsibilities related to this SVT is 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 a an SVT is OPTIONAL.</t>
<t>sig_val_claims -- A <bcp14>OPTIONAL</bcp14>.
</dd>
<dt>"sig_val_claims":
</dt>
<dd>An Object<SigValidation> data type that contains signature
validation claims for this SVT extending the standard registered JTW JWT claims
above. A An SVT MUST <bcp14>MUST</bcp14> contain one sig_val_claims claim.</t>
</list></t> claim.
</dd>
</dl>
<t>Note: An SVT asserts that a particular validation process was undertaken at a stated
date and
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 SVT can be
upgraded to a new SVT signed with fresh keys and algorithms.</t>
</section>
<section anchor="sigvalidation-obj-class"><name>SigValidation anchor="sigvalidation-obj-class">
<name>SigValidation Object Class</name>
<t>The sig_val_claims JWT claim uses the SigValidation object class. A SigValidation object
holds all custom claims, and a SigValidation object contains the following parameters:</t>
<t><list style="symbols">
<t>ver -- A
<dl>
<dt>"ver":
</dt>
<dd>A String data type representing the version. This parameter MUST
<bcp14>MUST</bcp14> be present, present and the version in this specification
indicated by the value "1.0".</t>
<t>profile -- A "1.0".
</dd>
<dt>"profile":
</dt>
<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 MUST <bcp14>MUST</bcp14> be present.</t>
<t>hash_algo -- A present.
</dd>
<dt>"hash_algo":
</dt>
<dd>A URI data type that identifies the hash algorithm used to compute the
hash values within the SVT. The URI identifier MUST <bcp14>MUST</bcp14> be one
defined in <xref target="RFC6931"/> target="RFC9231"/> or in the IANA registry defined by this
specification. This parameter MUST <bcp14>MUST</bcp14> be present.</t>
<t>sig -- A present.
</dd>
<dt>"sig":
</dt>
<dd>An [Object<Signature>] data type that gives information about
validated electronic signatures as an array of Signature objects. If the SVT
contains signature validation evidence for more than one signature, then each
signature is represented by a separate Signature object. At least one
Signature object MUST <bcp14>MUST</bcp14> be present.</t>
<t>ext -- A present.
</dd>
<dt>"ext":
</dt>
<dd>A Map<String> data type that provides additional claims related to
the SVT. Extension claims are added at the discretion of the SVT issuer;
however, extension claims MUST <bcp14>MUST</bcp14> follow any conventions defined
in a profile of this specification (see <xref target="profiles"/>). Inclusion
of this parameter is OPTIONAL.</t>
</list></t> <bcp14>OPTIONAL</bcp14>.
</dd>
</dl>
</section>
<section anchor="signature-obj-class"><name>Signature anchor="signature-obj-class">
<name>Signature Claims Object Class</name>
<t>The sig parameter in the SigValidation object class uses the Signature object
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">
<t>sig_ref -- A
<dl>
<dt>"sig_ref":
</dt>
<dd>An Object<SigReference> data type that contains reference
information identifying the target signature. This parameter MUST
<bcp14>MUST</bcp14> be present.</t>
<t>sig_data_ref -- A present.
</dd>
<dt>"sig_data_ref":
</dt>
<dd>An [Object<SignedDataReference>] data type that contains an array of
references to Signed Data that was signed by the target electronic
signature. At least one SignedDataReference object MUST <bcp14>MUST</bcp14> be present.</t>
<t>signer_cert_ref -- A
present.
</dd>
<dt>"signer_cert_ref":
</dt>
<dd>An Object<CertReference> data type that references the signer's
certificate and optionally reference to references a supporting certification path that
was used to verify the target electronic signature. This parameter MUST
<bcp14>MUST</bcp14> be present.</t>
<t>sig_val -- A present.
</dd>
<dt>"sig_val":
</dt>
<dd>An [Object<PolicyValidation>] data type that contains an array of
results of signature verification according to defined procedures. At least
one PolicyValidation object MUST <bcp14>MUST</bcp14> be present.</t>
<t>time_val -- A present.
</dd>
<dt>"time_val":
</dt>
<dd>An [Object<TimeValidation>] data type that contains an array of time
verification results showing that the target signature has existed at a specific date and
time in the past. Inclusion of this parameter is OPTIONAL.</t>
<t>ext -- A <bcp14>OPTIONAL</bcp14>.
</dd>
<dt>"ext":
</dt>
<dd>A MAP<String> data type that provides additional claims related to
the target signature. Extension claims are added at the discretion of the SVT Issuer;
issuer; however, extension claims MUST <bcp14>MUST</bcp14> follow any conventions
defined in a profile of this specification (see <xref
target="profiles"/>). Inclusion of this parameter is OPTIONAL.</t>
</list></t> <bcp14>OPTIONAL</bcp14>.
</dd>
</dl>
</section>
<section anchor="sigreference-obj-class"><name>SigReference anchor="sigreference-obj-class">
<name>SigReference Claims Object Class</name>
<t>The sig_ref parameter in the Signature object class uses the SigReference object
class. The SigReference object provides information used to match the Signature
claims object to a specific target electronic signature and to verify the integrity
of the target signature value and Signed Bytes, and it contains the following parameters:</t>
<t><list style="symbols">
<t>id -- A
<dl>
<dt>"id":
</dt>
<dd>A String data type that contains an identifier assigned to the target
signature. Inclusion of this parameter is OPTIONAL.</t>
<t>sig_hash -- A <bcp14>OPTIONAL</bcp14>.
</dd>
<dt>"sig_hash":
</dt>
<dd>A Base64Binary data type that contains a hash value of the target
electronic signature value. This parameter MUST <bcp14>MUST</bcp14> be present.</t>
<t>sb_hash -- A present.
</dd>
<dt>"sb_hash":
</dt>
<dd>A Base64Binary data type that contains a hash value of the Signed Bytes of
the target electronic signature. This parameter MUST <bcp14>MUST</bcp14> be present.</t>
</list></t>
present.
</dd>
</dl>
</section>
<section anchor="signeddatareference-obj-class"><name>SignedDataReference anchor="signeddatareference-obj-class">
<name>SignedDataReference Claims Object Class</name>
<t>The sig_data_ref parameter in the Signature object class uses the SignedDataReference object
class. The SignedDataReference object provides information used to verify the target electronic
signature references to Signed Data as well as to verify the integrity of all data that
is signed by the target signature, and it contains the following parameters:</t>
<t><list style="symbols">
<t>ref -- A
<dl>
<dt>"ref":
</dt>
<dd>A String data type that contains a reference identifier for the data or
data fragment covered by the target electronic signature. This parameter MUST
<bcp14>MUST</bcp14> be present.</t>
<t>hash -- A present.
</dd>
<dt>"hash":
</dt>
<dd>A Base64Binary data type that contains the hash value for the data covered
by the target electronic signature. This parameter MUST <bcp14>MUST</bcp14> be present.</t>
</list></t>
present.
</dd>
</dl>
</section>
<section anchor="policyval-obj-class"><name>PolicyValidation anchor="policyval-obj-class">
<name>PolicyValidation Claims Object Class</name>
<t>The sig_val parameter in the Signature object class uses the PolicyValidation object
class. The PolicyValidation object provides information about the result of a validation
process according to a spefific specific policy, and it contains the following parameters:</t>
<t><list style="symbols">
<t>pol -- A
<dl>
<dt>"pol":
</dt>
<dd>A StringOrURI data type that contains the identifier of the policy
governing the electronic signature verification process. This parameter MUST
<bcp14>MUST</bcp14> be present.</t>
<t>res -- A present.
</dd>
<dt>"res":
</dt>
<dd>A String data type that contains the result of the electronic signature
verification process. The value MUST <bcp14>MUST</bcp14> be one of "PASSED", "FAILED"
"FAILED", or "INDETERMINATE" as defined by <xref
target="ETSI319102-1"/>. This parameter MUST <bcp14>MUST</bcp14> be present.</t>
<t>msg -- A present.
</dd>
<dt>"msg":
</dt>
<dd>A String data type that contains a message describing the
result. Inclusion of this parameter is OPTIONAL.</t>
<t>ext -- A <bcp14>OPTIONAL</bcp14>.
</dd>
<dt>"ext":
</dt>
<dd>A MAP<String> data type that provides additional claims related to
the target signature. Extension claims are added at the discretion of the
SVT Issuer; issuer; however, extension claims MUST <bcp14>MUST</bcp14> follow any
conventions defined in a profile of this specification (see <xref
target="profiles"/>). Inclusion of this parameter is OPTIONAL.</t>
</list></t>
<bcp14>OPTIONAL</bcp14>.
</dd>
</dl>
</section>
<section anchor="timever-obj-class"><name>TimeValidation anchor="timever-obj-class">
<name>TimeValidation Claims Object Class</name>
<t>The time_val parameter in the Signature object class uses the TimeValidation object
class. The TimeValidation claims object provides information about the result of
validating evidence of time asserting that the target signature existed at a particular
date and
time in the past. Evidence of time is typically a timestamp according to <xref target="RFC3161"/> target="RFC3161"/>, but other types of evidence may be used such as a previously issued SVT for this signature. The TimeValidation claims object contains the following parameters:</t>
<t><list style="symbols">
<t>time -- A
<dl>
<dt>"time":
</dt>
<dd>A NumericDate data type that contains the verified time. This parameter MUST
<bcp14>MUST</bcp14> be present.</t>
<t>type -- A present.
</dd>
<dt>"type":
</dt>
<dd>A StringOrURI data type that contains an identifier of the type of
evidence of time. This parameter MUST <bcp14>MUST</bcp14> be present.</t>
<t>iss -- A present.
</dd>
<dt>"iss":
</dt>
<dd>A StringOrURI data type that contains an identifier of the entity that
issued the evidence of time. This parameter MUST <bcp14>MUST</bcp14> be present.</t>
<t>id -- A present.
</dd>
<dt>"id":
</dt>
<dd>A String data type that contains an unique identifier assigned to the
evidence of time. Inclusion of this parameter is OPTIONAL.</t>
<t>hash -- A <bcp14>OPTIONAL</bcp14>.
</dd>
<dt>"hash":
</dt>
<dd>A Base64Binary data type that contains the hash value of the validated
evidence of time. Inclusion of this parameter is OPTIONAL.</t>
<t>val -- A <bcp14>OPTIONAL</bcp14>.
</dd>
<dt>"val":
</dt>
<dd>An [Object<PolicyValidation>] data type that contains an array of
results of the time evidence validation according to defined validation
procedures. Inclusion of this parameter is OPTIONAL.</t>
<t>ext -- A <bcp14>OPTIONAL</bcp14>.
</dd>
<dt>"ext":
</dt>
<dd>A MAP<String> data type that provides additional claims related to
the target signature. Extension claims are added at the discretion of the
SVT Issuer; issuer; however, extension claims MUST <bcp14>MUST</bcp14> follow any
conventions defined in a profile of this specification (see <xref
target="profiles"/>). Inclusion of this parameter is OPTIONAL.</t>
</list></t>
<bcp14>OPTIONAL</bcp14>.
</dd>
</dl>
</section>
<section anchor="certref-obj-class"><name>CertReference anchor="certref-obj-class">
<name>CertReference Claims Object Class</name>
<t>The signer_cert_ref parameter in the Signature object class uses the CertReference object
class. The CertReference object references a single X.509 certificate or a X.509
certification path, path either by providing the certificate data or by providing hash
references for certificates that can be located in the target electronic signature, and
it contains the following parameters:</t>
<t><list style="symbols">
<t>type -- A
<dl>
<dt>"type":
</dt>
<dd>A StringOrURI data type that contains an identifier of the type of
reference. The type identifier MUST <bcp14>MUST</bcp14> be one of the
identifiers defined below, an identifier specified by the selected profile,
or a URI identifier. This parameter MUST <bcp14>MUST</bcp14> be present.</t>
<t>ref -- A present.
</dd>
<dt>"ref":
</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 MUST <bcp14>MUST</bcp14> be present.</t>
</list></t> present.
</dd>
</dl>
<t>The following type identifiers are defined:</t>
<t><list style="symbols">
<t>chain -- The
<dl>
<dt>"chain":
</dt>
<dd>The ref contains an array of Base64 encoded Base64-encoded X.509 certificates <xref
target="RFC5280"/>. The certificates MUST <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.</t>
<t>chain_hash -- The
array.
</dd>
<dt>"chain_hash":
</dt>
<dd>The ref contains an array of one or more Base64 encoded 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 MUST
<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 MUST NOT <bcp14>MUST
NOT</bcp14> be used unless all hashed certificates are present in the target
electronic signature.</t>
</list></t> signature.
</dd>
</dl>
<t>Note: All certificates referenced using the identifiers above are X.509 certificates.
Profiles of this specification MAY <bcp14>MAY</bcp14> define alternative types of public key containers;
however, a major function of these referenced certificates is not just to reference
the public key, key but also to provide the subject name of the signer. It is therefore
important for the full function of an SVT that the referenced public key container also
provides the means to identify of the signer.</t>
</section>
<section anchor="svt-jose-header"><name>SVT anchor="svt-jose-header">
<name>SVT JOSE Header</name>
<t>The SVT JWT MUST <bcp14>MUST</bcp14> contain the following JOSE JSON Object Signing and Encryption (JOSE) header parameters in accordance with
Section 5 of
<xref target="RFC7519"/>:</t>
<t><list style="symbols">
<t>typ -- This target="RFC7519" sectionFormat="of" section="5"/>:</t>
<dl>
<dt>"typ":
</dt>
<dd>This parameter MUST <bcp14>MUST</bcp14> have the string value "JWT" (upper case).</t>
<t>alg -- This
case).
</dd>
<dt>"alg":
</dt>
<dd>This parameter identifies the algorithm used to sign the SVT JWT. The
algorithm identifier MUST <bcp14>MUST</bcp14> be specified in <xref
target="RFC7518"/> or the IANA JSON "JSON Web Signature and Encryption Algorithms Registry [ add a ref ]. Algorithms"
registry <xref target="IANA-JOSE-REG"/>. The specified signature hash
algorithm MUST <bcp14>MUST</bcp14> be identical to the hash algorithm specified in
the hash_algo parameter of the SigValidation object within the sig_val_claims claim.</t>
</list></t>
claim.
</dd>
</dl>
<t>The SVT header MUST <bcp14>MUST</bcp14> contain a public key or a reference 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"/>, MUST <bcp14>MUST</bcp14> define the requirements for how the key or key reference is included in the header.</t>
</section>
</section>
</section>
<section anchor="profiles"><name>Profiles</name> 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>Each profile MUST as
<t>At a minimum minimum, each profile <bcp14>MUST</bcp14> define:</t>
<t><list style="symbols">
<t>The
<ul spacing="normal">
<li>The identifier of the profile.</t>
<t>How profile</li>
<li>How to reference the Signed Data content of the signed document.</t>
<t>How document</li>
<li>How to reference to the target electronic signature and the Signed Bytes of the signature.</t>
<t>How signature</li>
<li>How to reference certificates supporting each electronic siganture.</t>
<t>How signature</li>
<li>How to include public keys or references to public keys in the SVT.</t>
<t>Whether SVT</li>
<li>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> document</li>
</ul>
<t>A profile MAY <bcp14>MAY</bcp14> also define:</t>
<t><list style="symbols">
<t>Explicit
<ul spacing="normal">
<li>Explicit information on how to perform signature validation based on an SVT.</t>
<t>How SVT</li>
<li>How to attach an SVT to an electronic signature or signed document.</t>
</list></t> document</li>
</ul>
<section anchor="defined-profiles"><name>Defined anchor="defined-profiles">
<name>Defined Profiles</name>
<t>The following profiles are defined in Appendixes appendixes of this document:</t>
<t><list style="symbols">
<t><xref
<dl>
<dt> <xref target="appendix-xml-profile"/>: XML Profile</t>
<t><xref
</dt>
<dd>XML Signature Profile
</dd>
<dt><xref target="appendix-pdf-profile"/>: PDF Profile</t>
<t><xref
</dt>
<dd>PDF Signature Profile
</dd>
<dt><xref target="appendix-jws-profile"/>: JWS Profile</t>
</list></t>
</dt>
<dd>JWS Profile
</dd>
</dl>
<t>Other documents MAY <bcp14>MAY</bcp14> define other profiles that MAY <bcp14>MAY</bcp14> complement, ammend amend, or supersede these profiles.</t>
</section>
</section>
<section anchor="signature-verification-with-a-svt"><name>Signature anchor="signature-verification-with-a-svt">
<name>Signature Verification with a an SVT</name>
<t>Signature verification based on an a SVT MUST <bcp14>MUST</bcp14> follow these steps:</t>
<t><list style="numbers">
<t>Locate
<ol spacing="normal" type="1"><li>Locate all available SVTs available for the signed document that are relevant for the target electronic signature.</t>
<t>Select signature.</li>
<li>Select the most recent SVT that can be successfully validated and meets the requirement of the relying party.</t>
<t>Verify party.</li>
<li>Verify the integrity of the signature and the Signed Bytes of the target electronic signature using the sig_ref claim.</t>
<t>Verify claim.</li>
<li>Verify that the Signed Data reference in the original electronic signature matches the reference values in the sig_data_ref claim.</t>
<t>Verify claim.</li>
<li>Verify the integrity of referenced Signed Data using provided hash values in the sig_data_ref claim.</t>
<t>Obtain claim.</li>
<li>Obtain the verified certificates supporting the asserted electronic signature verification through the signer_cert_ref claim.</t>
<t>Verify claim.</li>
<li>Verify that signature validation policy results satisfy the requirements of the relying party.</t>
<t>Verify party.</li>
<li>Verify that verified time results satisfy the context for the use of the signed document.</t>
</list></t> document.</li>
</ol>
<t>After successfully performing these steps, signature validity is established as well as
the trusted signer certificate binding the identity of the signer to the electronic
signature.</t>
</section>
<section anchor="iana"><name>IANA anchor="iana">
<name>IANA Considerations</name>
<section anchor="claim-names-reg"><name>Claim anchor="claim-names-reg">
<name>Claim Names Registration</name>
<t>This section registers
<t>IANA has registered the "sig_val_claims" claim name in the IANA "JSON Web Token Claims" registry established by Section 10.1 in <xref target="RFC7519"/>.</t> target="RFC7519" sectionFormat="of" section="10.1"/>.</t>
<section anchor="clname-reg-contents"><name>Registry anchor="clname-reg-contents">
<name>Registry Contents</name>
<t><list style="symbols">
<t>Claim
<dl>
<dt>Claim Name: "sig_val_claims"</t>
<t>Claim
</dt>
<dd>sig_val_claims
</dd>
<dt>Claim Description: Signature
</dt>
<dd>Signature Validation Token</t>
<t>Change Token
</dd>
<dt>Change Controller: IESG</t>
<t>Specification
</dt>
<dd>IESG
</dd>
<dt>Specification Document(s): <xref
</dt>
<dd><xref target="sigvalidation-obj-class"/> of {this document}</t>
</list></t>
<t>NOTE to RFC editor: Please replace {this document} with its assigned RFC number.</t> 9321
</dd>
</dl>
</section>
</section>
<section anchor="iana-header-params"><name>Header anchor="iana-header-params">
<name>Header Parameter Names Registration</name>
<t>This section registers
<t>IANA has registered the "svt" Header Parameter in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by <xref target="RFC7515"/>.</t>
<section anchor="iana-header-params-reg"><name>Registry anchor="iana-header-params-reg">
<name>Registry Contents</name>
<t><list style="symbols">
<t>Header
<dl>
<dt>Header Parameter Name: "svt"</t>
<t>Header
</dt>
<dd>svt
</dd>
<dt>Header Parameter Description:
</dt>
<dd> Signature Validation Token</t>
<t>Header Token
</dd>
<dt>Header Parameter Usage Location(s): JWS</t>
<t>Change
</dt>
<dd>JWS
</dd>
<dt>Change Controller: IESG</t>
<t>Specification
</dt>
<dd>IESG
</dd>
<dt>Specification Document(s): <xref
</dt>
<dd><xref target="svt-header"/> of {this document}</t>
</list></t>
<t>NOTE to RFC editor: Please replace {this document} with its assigned RFC number.</t> 9321
</dd>
</dl>
</section>
</section>
</section>
<section anchor="seccons"><name>Security anchor="seccons">
<name>Security Considerations</name>
<section anchor="seccon-lvl-of-reliance"><name>Level anchor="seccon-lvl-of-reliance">
<name>Level of reliance</name> Reliance</name>
<t>An SVT allows a signature verifier to still validate the original signature using
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 confirming the integrity of signed data Signed Data or the validity of the signer's certificate certificate, etc.</t>
<t>Another way to use an SVT is to completely rely on the validation conclusion provided
by the SVT and to omit re-validation 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 policy and risk assessment.</t>
<t>However, even when relying on the SVT validation conclusion of an SVT 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 certificate chain,
signed data
Signed Data, and the signed bytes.</t> Signed Bytes.</t>
</section>
<section anchor="seccon-aging-algos"><name>Aging algorithms</name> anchor="seccon-aging-algos">
<name>Aging Algorithms</name>
<t>Even if the SVT provides protection against algorithms becoming weakened or broken over time, this protection is only valid for as long as the algorithms used to sign the SVT are still considered secure. It is advisable to re-issue SVT reissue SVTs in cases where an algorithm protecting the SVT is getting close to its end of life.</t>
<t>One way to increase the resistance of algorithms becoming insecure, is to issue multiple SVT SVTs for the same signature with different algorithms and key lengths where one algorithm could still be secure even if the corresponding algorithm used in the alternative SVT is broken.</t>
</section>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2119;
&RFC3125;
&RFC3161;
&RFC3647;
&RFC5035;
&RFC8174;
&RFC5280;
&RFC5652;
&RFC6931;
&RFC7515;
&RFC7518;
&RFC7519;
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3125.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3161.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3647.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5035.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.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" > anchor="ETSI319102-1">
<front>
<title>ETSI - Electronic
<title>Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation</title>
<author >
<author>
<organization>ETSI</organization>
</author>
<date year="2016" month="May"/>
</front>
<seriesInfo name="ETSI" value="EN 319 102-1 v1.1.1"/> name="ETSI EN" value="319 102-1"/>
<refcontent>v1.1.1</refcontent>
</reference>
<reference anchor="XMLDSIG11" > anchor="XMLDSIG11">
<front>
<title>XML Signature Syntax and Processing Version 1.1</title>
<author initials="D." surname="Eastlake" surname="Eastlake 3rd" fullname="Donald Eastlake">
<organization></organization> Eastlake 3rd">
<organization/>
</author>
<author initials="J." surname="Reagle" fullname="Joseph Reagle">
<organization></organization>
<organization/>
</author>
<author initials="D." surname="Solo" fullname="David Solo">
<organization></organization>
<organization/>
</author>
<author initials="F." surname="Hirsch" fullname="Frederick Hirsch">
<organization></organization>
<organization/>
</author>
<author initials="M." surname="Nystrom" fullname="Magnus Nystrom">
<organization></organization>
<organization/>
</author>
<author initials="T." surname="Roessler" fullname="Thomas Roessler">
<organization></organization>
<organization/>
</author>
<author initials="K." surname="Yiu" fullname="Kelvin Yiu">
<organization></organization>
<organization/>
</author>
<date year="2013" month="April" day="11"/> month="April"/>
</front>
<seriesInfo name="W3C" value="Proposed Recommendation"/>
<annotation>Latest version available at <eref target="https://www.w3.org/TR/xmldsig-core1/"/>.</annotation>
</reference>
<reference anchor="ISOPDF2" > anchor="ISOPDF2">
<front>
<title>Document management -- Portable document format -- Part 2: PDF 2.0</title>
<author >
<author>
<organization>ISO</organization>
</author>
<date year="2017" month="July"/> year="2020" month="December"/>
</front>
<seriesInfo name="ISO" value="32000-2"/> value="32000-2:2020"/>
</reference>
<reference anchor="XADES" > anchor="XADES">
<front>
<title>Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures</title>
<author >
<author>
<organization>ETSI</organization>
</author>
<date year="2016" month="April"/>
</front>
<seriesInfo name="ETSI" value="EN 319 132-1 v1.1.1"/> name="ETSI EN" value="319 132-1"/>
<refcontent>v1.1.1</refcontent>
</reference>
<reference anchor="PADES" > anchor="PADES">
<front>
<title>Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures</title>
<author >
<author>
<organization>ETSI</organization>
</author>
<date year="2016" month="April"/>
</front>
<seriesInfo name="ETSI" value="EN 319 142-1 v1.1.1"/> name="ETSI EN" value="319 142-1"/>
<refcontent>v1.1.1</refcontent>
</reference>
<reference anchor="CADES" > anchor="CADES">
<front>
<title>Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures</title>
<author >
<author>
<organization>ETSI</organization>
</author>
<date year="2016" month="April"/>
</front>
<seriesInfo name="ETSI" value="EN 319 122-1 v1.1.1"/> name="ETSI EN" value="319 122-1"/>
<refcontent>v1.1.1</refcontent>
</reference>
</references>
<references title='Informative References'>
&RFC8610;
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
</references>
</references>
<section anchor="appendix-xml-profile"><name>Appendix: XML signature profile</name> anchor="appendix-xml-profile">
<name>XML Signature Profile</name>
<t>This appendix defines a profile for implementing SVT SVTs with a signed XML document, document and defines the following aspects of SVT usage:</t>
<t><list style="symbols">
<t>How
<ul spacing="normal">
<li>How to include reference data related to XML signatures and XML documents in an SVT.</t>
<t>How SVT</li>
<li>How to add an SVT token to a an XML signature.</t>
</list></t> signature</li>
</ul>
<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 included in the signed XML document (enveloped), include the signed data (enveloping) Signed Data (enveloping), or may be separate from the signed content (detached).</t>
<t>To provide a generic solution for any type of XML signature signature, an SVT is added to each XML signature element within the XML signature <ds:Object> element.</t>
<section anchor="notation"><name>Notation</name> anchor="notation">
<name>Notation</name>
<section anchor="ref-to-xml-elements"><name>References 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
(http://www.w3.org/2000/09/xmldsig#)
(<eref target="https://www.w3.org/2000/09/xmldsig#"/>), the following syntax is used:</t>
<t><list style="symbols">
<t><ds:Signature></t>
</list></t>
<ul spacing="normal">
<li><ds:Signature></li>
</ul>
<t>When referring to elements from the ETSI XAdES XML Signature namespace
(http://uri.etsi.org/01903/v1.3.2#)
(<eref target="https://uri.etsi.org/01903/v1.3.2#"/>), the following syntax is used:</t>
<t><list style="symbols">
<t><xades:CertDigest></t>
</list></t>
<ul spacing="normal">
<li><xades:CertDigest></li>
</ul>
<t>When referring to elements defined in this specification
(http://id.swedenconnect.se/svt/1.0/sig-prop/ns)
(<eref target="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"/>), the following syntax is used:</t>
<t><list style="symbols">
<t><svt:Element></t>
</list></t>
<ul spacing="normal">
<li><svt:Element></li>
</ul>
</section>
</section>
<section anchor="svt-in-xml"><name>SVT anchor="svt-in-xml">
<name>SVT in XML Documents</name>
<t>When SVT is SVTs are provided for XML signatures signatures, then one SVT MUST <bcp14>MUST</bcp14> be provided for each XML signature.</t>
<t>An SVT embedded within the XML signature element MUST <bcp14>MUST</bcp14> be placed in a <svt:SignatureValidationToken> element as defined in <xref target="signaturevalidationtoken-signature-property"/>.</t>
<section anchor="signaturevalidationtoken-signature-property"><name>SignatureValidationToken anchor="signaturevalidationtoken-signature-property">
<name>SignatureValidationToken Signature Property</name>
<t>The <svt:SignatureValidationToken> element MUST <bcp14>MUST</bcp14> be placed in a <ds:SignatureProperty> element in accordance with <xref target="XMLDSIG11"/>. The <ds:SignatureProperty> element MUST <bcp14>MUST</bcp14> be placed inside a <ds:SignatureProperties> element inside a <ds:Object> element inside a <ds:Signature> element.</t>
<t>Note: <xref target="XMLDSIG11"/> requires the Target attribute to be present in <ds:SignatureProperty>, referencing the signature targeted by this signature property. If an SVT is added to a signature that do does not have an Id attribute, implementations SHOULD <bcp14>SHOULD</bcp14> add an Id attribute to the <ds:Signature> element and reference that Id in the Target attribute. This Id attribute and Target attribute 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 applications SHOULD not <bcp14>SHOULD NOT</bcp14> reject an SVT token because of Id and Target attribute mismatch, mismatch and MUST <bcp14>MUST</bcp14> rely on matching against a signature using signed information in the SVT itself.</t>
<t>The <svt:SignatureValidationToken> element is defined by the following XML Schema:</t>
<figure><artwork><![CDATA[
<sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
targetNamespace="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"
type="svt:SignatureValidationTokenType" />
<xs:complexType name="SignatureValidationTokenType">
<xs:simpleContent>
<xs:extension base="xs:string">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
]]></artwork></figure>
]]></sourcecode>
<t>The SVT token MUST <bcp14>MUST</bcp14> be included as a string representation of the SVT JWT. Note that this is the string representation of the JWT without further encoding. The SVT MUST NOT <bcp14>MUST NOT</bcp14> be represented by the Base64 encoded Base64-encoded bytes of the JWT string.</t>
<t>Example:</t>
<figure><artwork><![CDATA[
<sourcecode type="xml"><![CDATA[
<ds:Signature Id="MySignatureId">
...
<ds:Object>
<ds:SignatureProperties>
<ds:SignatureProperty Target="#MySignatureId">
<svt:SignatureValidationToken>
eyJ0eXAiOiJKV1QiLCJhb...2aNZ
</svt:SignatureValidationToken>
</ds:SignatureProperty>
</ds:SignatureProperties>
</ds:Object>
</ds:Signature>
]]></artwork></figure>
]]></sourcecode>
</section>
<section anchor="xml-multiple-svt-tokens"><name>Multiple SVT anchor="xml-multiple-svt-tokens">
<name>Multiple SVTs in an XML signature</name> Signature</name>
<t>If a new SVT is stored in a signature which that already contains a previously issued SVT, implementations can choose to either to replace the existing SVT or to store the new SVT in addition to the existing SVT.</t>
<t>If the new SVT is stored in addition to the old SVT, it SHOULD <bcp14>SHOULD</bcp14> be stored in a new <ds:SignatureProperty> element inside the existing <ds:SignatureProperties> element where the old SVT is located.</t>
<t>For interoperability robustness, signature validation applications MUST <bcp14>MUST</bcp14> be able to handle signatures where the new SVT is located in a new <ds:Object> element.</t>
</section>
</section>
<section anchor="xml-svt-claims"><name>XML signature anchor="xml-svt-claims">
<name>XML Signature SVT Claims</name>
<section anchor="xml-profile-identifier"><name>XML anchor="xml-profile-identifier">
<name>XML Profile Identifier</name>
<t>When this profile is used used, the SigValidation object MUST <bcp14>MUST</bcp14> contain a "profile" claim with the value "XML".</t>
</section>
<section anchor="xml-signature-reference-data"><name>XML anchor="xml-signature-reference-data">
<name>XML Signature Reference Data</name>
<t>The SVT Signature object MUST <bcp14>MUST</bcp14> contain a "sig_ref" claim (SigReference object) with the following elements:</t>
<t><list style="symbols">
<t>"id" -- The
<dl>
<dt>"id":
</dt>
<dd>The Id-attribute of the XML signature, if present.</t>
<t>"sig_hash" -- The present.
</dd>
<dt>"sig_hash":
</dt>
<dd>The hash over the signature value bytes.</t>
<t>"sb_hash" -- The bytes.
</dd>
<dt>"sb_hash":
</dt>
<dd>The hash over the canonicalized <ds:SignedInfo> element
(the bytes the XML signature algorithm has signed to generated generate the
signature value).</t>
</list></t> value).
</dd>
</dl>
</section>
<section anchor="xml-signed-data-reference"><name>XML anchor="xml-signed-data-reference">
<name>XML Signed Data Reference Data</name>
<t>The SVT Signature object MUST <bcp14>MUST</bcp14> contain one instance of the "sig_data" claim (SignedData object) for each <ds:Reference> element in the <ds:SignedInfo> element. The "sig_data" claim MUST <bcp14>MUST</bcp14> contain the following elements:</t>
<t><list style="symbols">
<t>"ref" -- The
<dl>
<dt>"ref":
</dt>
<dd>The value of the URI attribute of the corresponding <ds:Reference> element.</t>
<t>"hash" -- The
element.
</dd>
<dt>"hash":
</dt>
<dd>The hash of all bytes that were identified by the corresponding <ds:Reference>
element after applying all identified canonicalization and transformation
algorithms. These are the same bytes that is are hashed by the hash value in the
<ds:DigestValue> element inside the <ds:Reference> element.</t>
</list></t> element.
</dd>
</dl>
</section>
<section anchor="xml-signer-certificate-references"><name>XML anchor="xml-signer-certificate-references">
<name>XML Signer Certificate References</name>
<t>The SVT Signature object MUST <bcp14>MUST</bcp14> contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST <bcp14>MUST</bcp14> be either "chain" or "chain_hash".</t>
<t><list style="symbols">
<t>The
<ul spacing="normal">
<li>The "chain" type MUST <bcp14>MUST</bcp14> 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 signature.</li>
<li>The "chain_hash" type MUST <bcp14>MUST</bcp14> 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> signature.</li>
</ul>
</section>
</section>
<section anchor="xml-jose-header"><name>JOSE anchor="xml-jose-header">
<name>JOSE Header</name>
<section anchor="xml-svt-signing-key-reference"><name>SVT 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 header parameters in accordance with <xref target="RFC7515"/>, target="RFC7515"/> for storing a reference to the public key used to verify the signature on the SVT:</t>
<t><list style="symbols">
<t>"x5c" -- Holds
<dl>
<dt>"x5c":
</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 MUST <bcp14>MUST</bcp14> be the first
certificate in the chain.</t>
<t>"kid" -- chain.
</dd>
<dt>"kid":
</dt>
<dd> A key identifier holding the Base64 encoded Base64-encoded hash value of the
certificate that can verify the signature on the SVT. The hash
algorithm MUST <bcp14>MUST</bcp14> be the same hash algorithm used when
signing the SVT as specified by the <spanx style="verb">alg</spanx> header parameter.</t>
</list></t> "<tt>alg</tt>" Header Parameter.
</dd>
</dl>
</section>
</section>
</section>
<section anchor="appendix-pdf-profile"><name>Appendix: PDF signature profile</name> anchor="appendix-pdf-profile">
<name>PDF Signature Profile</name>
<t>This appendix defines a profile for implementing SVT SVTs with a signed PDF document, and it defines the following aspects of SVT usage:</t>
<t><list style="symbols">
<t>How
<ul spacing="normal">
<li>How to include reference data related to PDF signatures and PDF documents in an SVT.</t>
<t>How SVT.</li>
<li>How to add an SVT token to a PDF document.</t>
</list></t> 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 signature. When 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 this event.</t>
<t>To minimize the impact on PDF documents with multiple signatures and to stay backwards compatible with PDF software that do does not understand SVT, SVTs, PDF documents add one SVT token for all signatures of the PDF as an extension to a document timestamp added to the signed PDF as an incremental update. This SVT covers all signatures of the signed PDF.</t>
<section anchor="svt-in-pdf"><name>SVT anchor="svt-in-pdf">
<name>SVTs in PDF Documents</name>
<t>The SVT for a signed PDF document MAY <bcp14>MAY</bcp14> provide signature validation information about any of the present signatures in the PDF. The SVT MUST <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 MUST <bcp14>MUST</bcp14> be added to a document timestamp in accordance with ISO 32000-2:2017 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 MUST <bcp14>MUST</bcp14> be added to the timestamp token (TSTInfo) as an Extension object as defined in <xref target="svt-extension-to-timestamps"/>.</t>
<section anchor="svt-extension-to-timestamps"><name>SVT anchor="svt-extension-to-timestamps">
<name>SVT Extension to Timestamp Tokens</name>
<t>The SVT extension is an Extension suitable to be included in TSTInfo 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>
<t>Editors note: This is the current used OID. Consider assigning an IETF extension OID.</t> 1.2.752.201.5.2.</t>
<t>This extension data (OCTET STRING) holds the bytes of SVT JWT, represented as a UTF-8 encoded UTF-8-encoded string.</t>
<t>This extension MUST NOT <bcp14>MUST NOT</bcp14> be marked critical.</t>
<t>Note: Extensions in timestamp tokens according to <xref target="RFC3161"/> are imported from the definition of the X.509 certificate extensions defined in <xref target="RFC5280"/>.</t>
</section>
</section>
<section anchor="pdf-svt-claims"><name>PDF signature anchor="pdf-svt-claims">
<name>PDF Signature SVT Claims</name>
<section anchor="pdf-profile-identifier"><name>PDF anchor="pdf-profile-identifier">
<name>PDF Profile Identifier</name>
<t>When this profile is used used, the SigValidation object MUST <bcp14>MUST</bcp14> contain a "profile" claim with the value "PDF".</t>
</section>
<section anchor="pdf-signature-reference-data"><name>PDF anchor="pdf-signature-reference-data">
<name>PDF Signature Reference Data</name>
<t>The SVT Signature object MUST <bcp14>MUST</bcp14> contain a "sig_ref" claim (SigReference object) with the following elements:</t>
<t><list style="symbols">
<t>"id" -- Absent
<dl>
<dt>"id":
</dt>
<dd>Absent or a Null value.</t>
<t>"sig_hash" -- The value.
</dd>
<dt>"sig_hash":
</dt>
<dd>The hash over the signature value bytes.</t>
<t>"sb_hash" -- The bytes.
</dd>
<dt>"sb_hash":
</dt>
<dd>The hash over the DER encoded DER-encoded SignedAttributes in SignerInfo.</t>
</list></t> SignerInfo.
</dd>
</dl>
</section>
<section anchor="pdf-signed-data-reference"><name>PDF anchor="pdf-signed-data-reference">
<name>PDF Signed Data Reference Data</name>
<t>The SVT Signature object MUST <bcp14>MUST</bcp14> contain one instance of the "sig_data" claim (SignedData object) with the following elements:</t>
<t><list style="symbols">
<t>"ref" -- The
<dl>
<dt>"ref":
</dt>
<dd>The string representation of the ByteRange value of the PDF
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.</t>
<t>"hash" -- range.
</dd>
<dt>"hash":
</dt>
<dd> 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> value.
</dd>
</dl>
</section>
<section anchor="pdf-signer-certificate-references"><name>PDF anchor="pdf-signer-certificate-references">
<name>PDF Signer Certificate References</name>
<t>The SVT Signature object MUST <bcp14>MUST</bcp14> contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST <bcp14>MUST</bcp14> be either "chain" or "chain_hash".</t>
<t><list style="symbols">
<t>The
<ul spacing="normal">
<li>The "chain" type MUST <bcp14>MUST</bcp14> 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 signature.</li>
<li>The "chain_hash" type MUST <bcp14>MUST</bcp14> 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> signature.</li>
</ul>
<t>Note: The referenced signer certificate MUST <bcp14>MUST</bcp14> match any certificates referenced using ESSCertID or ESSCertIDv2 from <xref target="RFC5035"/>.</t>
</section>
</section>
<section anchor="pdf-jose-header"><name>JOSE anchor="pdf-jose-header">
<name>JOSE Header</name>
<section anchor="pdf-svt-signing-key-reference"><name>SVT anchor="pdf-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"/>, target="RFC7515"/> for storing a reference to the public key used to verify the signature on the SVT:</t>
<t><list style="symbols">
<t>"x5c" -- Holds
<dl>
<dt>"x5c":
</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 MUST <bcp14>MUST</bcp14> be the first
certificate in the chain.</t>
<t>"kid" -- A chain.
</dd>
<dt>"kid":
</dt>
<dd>A key identifier holding the Base64 encoded Base64-encoded hash value of the
certificate that can verify the signature on the SVT. The hash
algorithm MUST <bcp14>MUST</bcp14> be the same hash algorithm used when
signing the SVT as specified by the <spanx style="verb">alg</spanx> header parameter. "<tt>alg</tt>" Header
Parameter. The referenced certificate SHOULD <bcp14>SHOULD</bcp14> be the
same certificate that was used to sign the document timestamp that
contains the SVT.</t>
</list></t> SVT.
</dd>
</dl>
</section>
</section>
</section>
<section anchor="appendix-jws-profile"><name>Appendix: JWS anchor="appendix-jws-profile">
<name>JWS Profile</name>
<t>This appendix defines a profile for implementing SVT SVTs with a JWS signed payload according to <xref target="RFC7515"/>, and it defines the following aspects of SVT usage:</t>
<t><list style="symbols">
<t>How
<ul spacing="normal">
<li>How to include reference data related to JWS signatures in an SVT.</t>
<t>How SVT.</li>
<li>How to add an SVT token to JWS signatures.</t>
</list></t> signatures.</li>
</ul>
<t>A JWS may have one or more signatures signatures, depending on its serialization format, signing the same payload data. A JWS either contains the data to be signed (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, then each signature includes its own SVT.</t>
<section anchor="svt-in-jws"><name>SVT anchor="svt-in-jws">
<name>SVT in JWS</name>
<t>An SVT token MAY <bcp14>MAY</bcp14> be added to any signature of a JWS to support validation of that signature. If more than one signature is present present, then each present SVT MUST <bcp14>MUST</bcp14> provide information exclusively related to one associated signature and MUST NOT <bcp14>MUST NOT</bcp14> include information about any other signature in the JWS.</t>
<t>Each SVT is stored in its associated signature's "svt" header as defined in <xref target="svt-header"/>.</t>
<section anchor="svt-header"><name>"svt" 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 further wrapping or encoding.</t>
<t>The "svt" Header Parameter, when used, MUST <bcp14>MUST</bcp14> be included as a JWS Unprotected Header.</t>
<t>Note: A JWS Unprotected Header is not supported with JWS Compact Serialization. A consequence of adding an SVT token to a JWS is therefore that JWS JSON Serialization MUST <bcp14>MUST</bcp14> be used, used either in the form of general JWS JSON Serialization (for one or more signatures) or in the form of flattened JWS JSON Serialization (optionally used when only one signature is present in the JWS).</t>
</section>
<section anchor="jws-multiple-svt-tokens"><name>Multiple SVT anchor="jws-multiple-svt-tokens">
<name>Multiple SVTs in a JWS signature</name> Signature</name>
<t>If a new SVT is stored in a signature which that already contains a previously issued SVT, implementations can choose to 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 MUST <bcp14>MUST</bcp14> be added to the array of SVT tokens in the existing "svt" Header Parameter.</t>
</section>
</section>
<section anchor="jws-svt-claims"><name>JWS signature anchor="jws-svt-claims">
<name>JWS Signature SVT Claims</name>
<section anchor="jws-profile-identifier"><name>JWS anchor="jws-profile-identifier">
<name>JWS Profile Identifier</name>
<t>When this profile is used used, the SigValidation object MUST <bcp14>MUST</bcp14> contain a "profile" claim with the value "JWS".</t>
</section>
<section anchor="jws-signature-reference-data"><name>JWS anchor="jws-signature-reference-data">
<name>JWS Signature Reference Data</name>
<t>The SVT Signature object MUST <bcp14>MUST</bcp14> contain a "sig_ref" claim (SigReference object) with the following elements:</t>
<t><list style="symbols">
<t>"sig_hash" -- The
<dl>
<dt>"sig_hash":
</dt>
<dd>The hash over the associated signature value (the bytes of the
base64url-decoded signature parameter).</t>
<t>"sb_hash" -- The parameter).
</dd>
<dt>"sb_hash":
</dt>
<dd>The hash over all bytes signed by the associated signature
(the JWS Signing Input according to <xref target="RFC7515"/>).</t>
</list></t> target="RFC7515"/>).
</dd>
</dl>
</section>
<section anchor="jws-signed-data-reference"><name>JWS anchor="jws-signed-data-reference">
<name>JWS Signed Data Reference Data</name>
<t>The SVT Signature object MUST <bcp14>MUST</bcp14> contain one instance of the "sig_data" claim (SignedData object) with the following elements:</t>
<t><list style="symbols">
<t>"ref" -- This
<dl>
<dt>"ref":
</dt>
<dd>
<t>This parameter MUST <bcp14>MUST</bcp14> hold one of the
following thee three possible values. <list style="numbers">
<t>The 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.</t>
<t>The JWS.</li>
<li>The explicit string value "detached" if the JWS signs
detached payload data without explicit reference.</t>
<t>A reference.</li>
<li>A URI that can be used to identify or fetch the detached signed data.
Signed Data. The means to determine the URI for the detached signed data
Signed Data is outside the scope of this specification.</t>
</list></t>
<t>"hash" -- The specification.</li>
</ol>
</dd>
<dt>"hash":
</dt>
<dd>The hash over the JWS Payload data bytes (not its
base64url-encoded string representation).</t>
</list></t> representation).
</dd>
</dl>
</section>
<section anchor="jws-signer-certificate-references"><name>JWS anchor="jws-signer-certificate-references">
<name>JWS Signer Certificate References</name>
<t>The SVT Signature object MUST <bcp14>MUST</bcp14> contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST <bcp14>MUST</bcp14> be either "chain" or "chain_hash".</t>
<t><list style="symbols">
<t>The
<ul spacing="normal">
<li>The "chain" type MUST <bcp14>MUST</bcp14> 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 signature.</li>
<li>The "chain_hash" type MUST <bcp14>MUST</bcp14> 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> Parameter.</li>
</ul>
</section>
</section>
<section anchor="jws-svt-jose-header"><name>SVT anchor="jws-svt-jose-header">
<name>SVT JOSE Header</name>
<section anchor="jws-svt-signing-key-reference"><name>SVT 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"/>, target="RFC7515"/> for storing
a reference to the public key used to verify the signature on the
SVT:</t>
<t><list style="symbols">
<t>"x5c" -- Holds
<dl>
<dt>"x5c":
</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 MUST <bcp14>MUST</bcp14> be the first
certificate in the chain.</t>
<t>"kid" -- A chain.
</dd>
<dt>"kid":
</dt>
<dd>A key identifier holding the Base64 encoded Base64-encoded hash value of the
certificate that can verify the signature on the SVT. The hash
algorithm MUST <bcp14>MUST</bcp14> be the same hash algorithm used when
signing the SVT as specified by the <spanx style="verb">alg</spanx> header parameter.</t>
</list></t> "<tt>alg</tt>" Header Parameter.
</dd>
</dl>
</section>
</section>
</section>
<section anchor="schema-appendix"><name>Appendix: Schemas</name> anchor="schema-appendix">
<name>Schemas</name>
<section anchor="concise-data-definition-language-cddl"><name>Concise anchor="concise-data-definition-language-cddl">
<name>Concise Data Definition Language (CDDL)</name>
<t>The following informative CDDL <xref target="RFC8610"/> express expresses the structure of an SVT token:</t>
<figure><artwork><![CDATA[
<sourcecode type="cddl"><![CDATA[
svt = {
jti: text
iss: text
iat: uint
? aud: text / [* text]
? exp: uint
sig_val_claims: SigValClaims
}
SigValClaims = {
ver: text
profile: text
hash_algo: text
sig: [+ Signature]
? ext: Extension
}
Signature = {
sig_ref: SigReference
sig_data_ref: [+ SignedDataReference]
signer_cert_ref: CertReference
sig_val: [+ PolicyValidation]
? time_val: [* TimeValidation]
? ext: Extension
}
SigReference = {
? id: text / null
sig_hash: binary-value
sb_hash: binary-value
}
SignedDataReference = {
ref: text
hash: binary-value
}
CertReference = {
type: "chain" / "chain_hash"
ref: [+ text]
}
PolicyValidation = {
pol: text
res: "PASSED" / "FAILED" / "INDETERMINATE"
? msg: text / null
? ext: Extension
}
TimeValidation = {
"time": uint
type: text
iss: text
? id: text / null
? hash: binary-value / null
? val: [* PolicyValidation]
? ext: Extension
}
Extension = {
+ text => text
} / null
binary-value = text ; base64 classic with padding
]]></artwork></figure>
]]></sourcecode>
</section>
<section anchor="json-schema"><name>JSON anchor="json-schema">
<name>JSON Schema</name>
<t>The following informative JSON schema describes the syntax of the SVT token payload.</t>
<figure><artwork><![CDATA[
<sourcecode type="json"><![CDATA[
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Signature Validation Token JSON Schema",
"description": "Schema defining the payload format for SVT", SVTs",
"type": "object",
"required": [
"jti",
"iss",
"iat",
"sig_val_claims"
],
"properties": {
"jti": {
"description": "JWT ID",
"type": "string"
},
"iss": {
"description": "Issuer",
"type": "string"
},
"iat": {
"description": "Issued At",
"type": "integer"
},
"aud": {
"description": "Audience",
"type": [
"string",
"array"
],
"items": {"type": "string"}
},
"exp": {
"description": "Expiration time (seconds since epoch)",
"type": "integer"
},
"sig_val_claims": {
"description": "Signature validation claims",
"type": "object",
"required": [
"ver",
"profile",
"hash_algo",
"sig"
],
"properties": {
"ver": {
"description": "Version",
"type": "string"
},
"profile": {
"description": "Implementation profile",
"type": "string"
},
"hash_algo": {
"description": "Hash algorithm URI",
"type": "string"
},
"sig": {
"description": "Validated signatures",
"type": "array",
"items": {
"$ref": "#/$def/Signature"
},
"minItems": 1
},
"ext": {
"description": "Extension map",
"$ref": "#/$def/Extension"
}
},
"additionalProperties": false
}
},
"additionalProperties": false,
"$def": {
"Signature":{
"type": "object",
"required": [
"sig_ref",
"sig_data_ref",
"signer_cert_ref",
"sig_val"
],
"properties": {
"sig_ref": {
"description": "Signature Reference",
"$ref": "#/$def/SigReference"
},
"sig_data_ref": {
"description": "Signed data array",
"type": "array",
"items": {
"$ref" : "#/$def/SignedDataReference"
},
"minItems": 1
},
"signer_cert_ref": {
"description": "Signer certificate reference",
"$ref": "#/$def/CertReference"
},
"sig_val": {
"description": "Signature validation results",
"type": "array",
"items": {
"$ref": "#/$def/PolicyValidation"
},
"minItems": 1
},
"time_val": {
"description": "Time validations",
"type": "array",
"items": {
"$ref": "#/$def/TimeValidation"
}
},
"ext": {
"description": "Extension map",
"$ref": "#/$def/Extension"
}
},
"additionalProperties": false
},
"SigReference":{
"type": "object",
"required": [
"sig_hash",
"sb_hash"
],
"properties": {
"sig_hash": {
"description": "Hash of the signature value",
"type": "string",
"format": "base64"
},
"sb_hash": {
"description": "Hash of the Signed Bytes",
"type": "string",
"format": "base64"
},
"id": {
"description": "Signature ID reference",
"type": ["string","null"]
}
},
"additionalProperties": false
},
"SignedDataReference": {
"type": "object",
"required": [
"ref",
"hash"
],
"properties": {
"ref": {
"description": "Reference to the signed data",
"type": "string"
},
"hash": {
"description": "Signed data hash",
"type": "string",
"format": "base64"
}
},
"additionalProperties": false
},
"CertReference":{
"type": "object",
"required": [
"type",
"ref"
],
"properties": {
"type": {
"description": "Type of certificate reference",
"type": "string",
"enum": ["chain","chain_hash"]
},
"ref": {
"description": "Certificate reference data",
"type": "array",
"items": {
"type": "string",
"format": "base64"
},
"minItems": 1
}
},
"additionalProperties": false
},
"PolicyValidation":{
"type": "object",
"required": [
"pol",
"res"
],
"properties": {
"pol": {
"description": "Policy identifier",
"type": "string"
},
"res": {
"description": "Signature validation result",
"type": "string",
"enum": ["PASSED","FAILED","INDETERMINATE"]
},
"msg": {
"description": "Message",
"type": ["string","null"]
},
"ext": {
"description": "Extension map",
"$ref": "#/$def/Extension"
}
},
"additionalProperties": false
},
"TimeValidation":{
"type": "object",
"required": [
"time",
"type",
"iss"
],
"properties": {
"time": {
"description": "Verified time",
"type": "integer"
},
"type": {
"description": "Type of time validation proof",
"type": "string"
},
"iss": {
"description": "Issuer of the time proof",
"type": "string"
},
"id": {
"description": "Time evidence identifier",
"type": ["string","null"]
},
"hash": {
"description": "Hash of time evidence",
"type": ["string","null"],
"format": "base64"
},
"val": {
"description": "Validation result",
"type": "array",
"items": {
"$ref": "#/$def/PolicyValidation"
}
},
"ext": {
"description": "Extension map",
"$ref": "#/$def/Extension"
}
},
"additionalProperties": false
},
"Extension": {
"description": "Extension map",
"type": ["object","null"],
"required": [],
"additionalProperties": {
"type": "string"
}
}
}
}
]]></artwork></figure>
]]></sourcecode>
</section>
</section>
<section anchor="appendix-examples"><name>Appendix: Examples</name> anchor="appendix-examples">
<name>Examples</name>
<t>The following example illustrates a basic SVT according to this specification
issued for a signed PDF document.</t>
<t>Note: Line breaks in the decoded example are inserted for readablilty. readability. Line
breaks are not allowed in valid JSON data.</t>
<t>Signature validation token JWT:</t>
<figure><artwork><![CDATA[
<sourcecode><![CDATA[
eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG
QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9
PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l
eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv
bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx
Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6
eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi
Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv
bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp
Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht
SUNiU1Z6SWVaTmJpem83ckdJd0hOTjB6WElTeUtHakN2bm9uT2FRR2ZMXC9QM3ZE
dEI4OHlLU1dlWGc9PSIsImlkIjoiaWQtNzM5ODljNmZjMDYzNjM2YWI1ZTc1M2Yx
MGY3NTc0NjciLCJzYl9oYXNoIjoiQm9QVjRXQ0E5c0FJYWhqSzFIYWpmRnhpK0F6
QzRKR1R1ZjM5VzNaV2pjekRDVVJ4ZGM5WWV0ZUh0Y3hHVmVnZ3B4SEo3NVwvY1E3
SE4xZERkbGl5SXdnPT0ifSwic2lnbmVyX2NlcnRfcmVmIjp7InJlZiI6WyIxK2Fh
SmV0ZzdyZWxFUmxVRFlFaVU0WklaaFQ0UlV2aUlRWnVLN28xR0ZLYVRQUTZ5K2t4
XC9QTnREcnB1cVE2WGZya0g5d1lESzRleTB5NFdyTkVybnc9PSIsImg0UER4YjVa
S214MWVUU3F2VnZZRzhnMzNzMDVKendCK05nRUhGVTRnYzl0cUcwa2dIa2Y2VzNv
THprVHd3dXJJaDZZOUFhZlpZcWMyelAycEUycDRRPT0iLCJEZDJDNXNCMElPUWVN
Vm5FQmtNNVE5Vzk2bUJITnd3YTJ0elhNcytMd3VZY09VdlBrcnlHUjBhUEc4Tzlu
SVAzbGJ3NktqUTFoRG1SazZ6Qzh4MmpkZz09Il0sInR5cGUiOiJjaGFpbl9oYXNo
In0sInNpZ19kYXRhX3JlZiI6W3sicmVmIjoiIiwiaGFzaCI6IkZjR3BPT2Y4aWxj
UHQyMUdEZDJjR25MR0R4UlM1ajdzdk00YXBwMkg0MWRERUxtMkN6Y2VUWTAybmRl
SmZXamludG1RMzc2SWxYVE9BcjMxeXpZenNnPT0ifSx7InJlZiI6IiN4YWRlcy0x
MWExNTVkOTJiZjU1Nzc0NjEzYmI3YjY2MTQ3N2NmZCIsImhhc2giOiJLUmtnYlo2
UFwvbmhVNjNJTWswR2lVZlVcL0RUd3ZlWWl0ZVFrd0dlSnFDNUJ6VE5WOGJRYnBl
ZFRUdVdKUHhxdkowUlk4NGh3bTdlWVwvZzBIckFPZWdLdz09In1dLCJ0aW1lX3Zh
bCI6W119XSwiZXh0IjpudWxsLCJ2ZXIiOiIxLjAiLCJwcm9maWxlIjoiWE1MIiwi
aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu
YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX
mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVN
n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_
3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM
rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk
kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY
Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A
qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc
Cr0hUK_kvREqjD2Z
]]></artwork></figure>
]]></sourcecode>
<t>Decoded JWT Header:</t>
<figure><artwork><![CDATA[
<sourcecode><![CDATA[
{
"kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov
1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==",
"typ":"JWT",
"alg":"RS512"
}
]]></artwork></figure>
]]></sourcecode>
<t>Decoded JWT Claims:</t>
<figure><artwork><![CDATA[
<sourcecode><![CDATA[
{
"aud" : "http://example.com/audience1",
"iss" : "https://swedenconnect.se/validator",
"iat" : 1603458421,
"jti" : "4d1396f1ff728f40d52403b61c574486",
"sig_val_claims" : {
"sig" : [ {
"ext" : null,
"sig_val" : [ {
"msg" : "OK",
"ext" : null,
"res" : "PASSED",
"pol" : "http://id.swedenconnect.se/svt/sigval-policy/
ts-pkix/01"
} ],
"sig_ref" : {
"sig_hash" : "ycePVLIzdcpK97IYOhFIf1ny79HmICbSVzIeZNbizo7rGIw
HNN0zXISyKGjCvnonOaQGfL/P3vDtB88yKSWeXg==",
"id" : "id-73989c6fc063636ab5e753f10f757467",
"sb_hash" : "BoPV4WCA9sAIahjK1HajfFxi+AzC4JGTuf39W3ZWjczDCURx
dc9YeteHtcxGVeggpxHJ75/cQ7HN1dDdliyIwg=="
},
"signer_cert_ref" : {
"ref" : [ "1+aaJetg7relERlUDYEiU4ZIZhT4RUviIQZuK7o1GFKaTPQ6y+
kx/PNtDrpuqQ6XfrkH9wYDK4ey0y4WrNErnw==",
"h4PDxb5ZKmx1eTSqvVvYG8g33s05JzwB+NgEHFU4gc9tqG0kgH
kf6W3oLzkTwwurIh6Y9AafZYqc2zP2pE2p4Q==",
"Dd2C5sB0IOQeMVnEBkM5Q9W96mBHNwwa2tzXMs+LwuYcOUvPkr
yGR0aPG8O9nIP3lbw6KjQ1hDmRk6zC8x2jdg==" ],
"type" : "chain_hash"
},
"sig_data_ref" : [ {
"ref" : "",
"hash" : "FcGpOOf8ilcPt21GDd2cGnLGDxRS5j7svM4app2H41dDELm2Czc
eTY02ndeJfWjintmQ376IlXTOAr31yzYzsg=="
}, {
"ref" : "#xades-11a155d92bf55774613bb7b661477cfd",
"hash" : "KRkgbZ6P/nhU63IMk0GiUfU/DTwveYiteQkwGeJqC5BzTNV8bQb
pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw=="
} ],
"time_val" : [ ]
} ],
"ext" : null,
"ver" : "1.0",
"profile" : "XML",
"hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512"
}
}
]]></artwork></figure>
]]></sourcecode>
</section>
</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>