Innhold på denne siden:

Table of Contents

Faglig bakgrunn

I e-resept er det besluttet at Reseptformidleren skal gjennomføre en stringent kontroll av rekvirentens autorisasjon i HPR i forhold til sertifikatinformasjonen. Beslutning om dette ble først tatt av styringsrådet i juni 2007 og deretter er dette bekreftet av forskriften. De resepter som ikke oppfyller disse kravene forkastes av Reseptformidleren. Et slikt regime gjør situasjonen oversiktlig og enkel for utleverer; alle resepter i Reseptformidleren er kontrollert og akseptert (innenfor disse gitte rammer) men detaljer rundt rekvisisjonsrett (Kobling vare – rekvisisjonsrett fra HPR) sjekkes av utleverer. Det betyr at resepter blir avvist av Reseptformidleren hvis ikke rekvirentens fødselsnummer ligger korrekt i HPR og at vedkommende har autorisasjon. Utleverer har fortsatt ansvaret for at utlevering skjer på en forsvarlig måte.

...

Expand

title	Hva er OCSP...

OCSP = Online Certificate Status Protocol.

OCSP-tjeneste er en sertifikatstatus-tjeneste som sertifikatmottakere kan benytte for å sjekke revokeringsstatus for et sertifikat.

OCSP-tjeneste tilbys av sertifikatutsteder.

...

SKO blir videresendt med M1 (resepten) til utleverer i M9.4, men ikke til rekvirenter i M9.6, M6, M8, eller M15 eller til SLV DMP i M14.

Når utleverer laster ned en resept med M9.4 vil SKO mottas som en del av M1. Utleverer kan legge til grunn dokumentasjonen av utførte kontroller samt andre kontrollverdier i SKO ved utførelse av sin ekspedering.

Merk: Ved innføring av SKO forsterkes kravene til håndtering av sertifikater hos utleverer ved at utleverersystemet må kunne motta M9.4 fra Reseptformidleren inneholdende to ulike sertifikater. Eksempelvis kan SKO være signert med et gammelt virksomhetssertifikat, mens M9.4 er signert med ett nytt virksomhetssertifikat.

SKO fra Reseptformidleren blir deretter (for blå resepter) videresendt sammen med resepten i Oppgjørsmeldingen M18 fra utleverer til Helfo. Når Helfo mottar en M18 vil M18 valideres og de vedlagte M1 vil valideres. Ved at SKO fra Reseptformidleren medfølger vil kontrollen hos Helfo muliggjøres.

...

SKO omfatter informasjon om

gyldigheten av rekvirentens personlige sertifikat og tilhørende fødselsnummer som Reseptformidleren innhenter fra CA i form av et OCSP-oppslag.
resultatet av Reseptformidlerens HPR-kontroll sammen med kopi av OCSP-oppslaget for Reseptformidlerens virksomhetssertifikat
et tidsstempel på resepten, sammen med kopi av OCSP-oppslaget for Reseptformidlerens tidsstemplingssertifikat

I det videre vil hvert av disse elementene bli beskrevet.

...

Ved at Reseptformidleren gjennomfører en egen tidsstempling av resepten i SKO, basert på eget tidsstemplingssertifikat, oppnås to viktige forhold:

tidspunktet for beregning av starten av reseptens gyldighet (Utstedelsestidspunktet) fastslås autoritativt
reseptens sertifikatmessige gyldighet økes til gyldigheten for Reseptformidlerens tidsstemplingssertifikat.

I påvente av at NHN eller andre etablerer TSA tjenester, er Reseptformidleren akseptert som TSA i e-resept.

...

Tidsstempling implementeres i Reseptformidleren ved å bruke XAdES-T for tidsangivelsen.

Sertifikatet utstedes under CP for Buypass virksomhetssertifikater
E-resept/Helfo må produsere en CSR (Certificate Signing Request) som Buypass benytter for å generere det aktuelle sertifikatet
Nøkkelen skal være 2048 bits
Levetiden på sertifikatet settes lik 3 år

Reseptformidleren vil synkronisere sin klokkefunksjon mot en klokkefunksjon hos Universitetet i Oslo: (ntp.uio.no), kontrollert mot 4 andre autoritative klokkefunksjoner.

...

Dersom det viser seg at årlig fornyelse av Reseptformidlerens tidsstemplingssertifikat skaper problemer, kan det vurderes to tilnærminger:

Øke frekvens for oppdatering av Reseptformidlerens tidsstemplingssertifikat til halvårlig kvartalsvis, eller månedlig
Reseptformidleren kan utvide sin tidsstempling av de aktuelle reseptene med XAdES-A- signatur

Erfaringer med bruken av XAdES vil vurderes etter hvert og tilnærming velges i tråd med dette.

...

Bruk av standardisert format (ETSI XAdES)

[1] http://uri.etsi.org/01903/v1.3.2/ og altså ETSI TS 101 903 V1.3.2 (2006-03

...

Det har vært et viktig mål for arbeidet med SKO å finne en form på det som gjør gjenbruksverdien av SKO størst mulig for partene. Bruk av aktuelle standarder for slike objekter har derfor vært vurdert. Slike standarder er ikke i bred bruk innenfor helsesektoren i Norge i dag. E-resept vil derfor gjøre nybrottsarbeidet med bruken av slike standarder. Den standard som legges til grunn er ETSI XAdES. Det antas at vi ved å legge ETSI XAdES v1.3.2 og ETSI TS 101 903 V1.3.2 (2006-03) til grunn, kan oppnå viktige fordeler som:

Bruken av avanserte XML-signaturer er transparent og krever ikke at et nytt XML-dokument spesifiseres.
Bruken av XAdES vil minske arbeidet med å implementere og bruke SKO.
XAdES er en bæredyktig standard som forventes å bringe elektronisk samhandling og dokumenthåndtering i helse- og sosialsektoren videre.

Avanserte XML signaturer kvalifiserer en signatur i henhold til XMLDsig. Ved å utvide signaturen med tidsstempler (XAdES-T), sertifikater og sertifikatstatusinformasjon (XAdES-X-L eller -A) gjøres validering av signaturen etter lang tid mulig.

...

Kravene til sertifikater i e-resept er som følger:

1	CA sertifikater	minst 2048 bit RSA
2	Personlige kvalifiserte sertifikater	minst 1024 bit RSA
3	OCSP signeringssertifikater	minst 1024 bit RSA
4	TSA sertifikate	minst 2048 bit RSA

Nøkkelbrukutvidelser

E-resept krever nøkkelbrukutvidelser som følger:

1	OCSP signeringssertifikater	extendedKeyUsage id-pkix-ocsp-nocheck
2	TSA sertifikater	extendedKeyUsage id-kp-timeStamping

Algoritmer / styrke

E-resept krever algoritmer med styrke som følger:

1	Signering	minst SHA-256
2	OCSP signering	minst SHA-256
3	Tidsstempling	minst SHA-256

Konkrete verdier og parametre som skal brukes

...

RF skal validere virksomhetssertifikater sertifikater opp mot revokeringslister. Revokeringslister lastes ned fra sertifikattilbyder. Følgende prinsipper gjelder for dette:

RF kan akseptere meldinger opp til 12 timer etter at gyldigheten for siste CRL utløp
Det etableres en mulighet for å revokere/sperre sertifikater eller på annen måte hindre tilgang lokalt i Reseptformidleren. Dette kan benyttes hvis oppdatering av CRL ikke er tilgjengelig til å sperre utleverere på bakgrunn av manuelt innhentet informasjon.
Varslingsrutiner mellom Reseptformidleren og sertifikattilbyder etableres for å få overført revokeringsdata ved feilsituasjoner
Ved utilgjengelig OCSP-oppslag kan Reseptformidleren benytte cashet verdi som beskrevet i Håndtering av nedetid hos CA.

Eksempler

Strukturen for de ulike signaturelementer i SKO fremgår av figuren under:Image Removed

...

XMLDsig angir hvordan rekvirentens signatur generelt utvides

...

Eksempelet under viser hvordan et slikt <ds:Signature> element typisk kan se ut slik det foreligger i M1 etter rekvirentens signering:

<ds

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds

<ds:SignedInfo >

<ds

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

<ds

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds

<ds:Reference URI="">

<ds:Transforms>
<ds

<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<

</ds:

Transforms>
<ds

Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>GJunG

<ds:DigestValue>GJunG+L8z9omau5FpDL0gHmjDiU=</ds:

DigestValue>

<

</ds:

Reference>

<

</ds:>

Eksempel 2: XMLDsig med Signature

Rekvirentens signatur vil av Reseptformidleren utvides med ny informasjon i elementene <ds:Signature> , <ds:SignatureValue> og <ds:KeyInfo> , som vist i eksempelet under, slik at det entydig kan refereres til i XAdES. Attributtene kan tilføyes etter at signaturen er produsert av rekvirenten uten å bryte signature

<ds

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature">

<ds:SignedInfo>
<ds

<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

<ds

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds

<ds:Reference URI="">

<ds:Transforms>
<ds

<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<

</ds:

Transforms>
<ds

Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>ByGrS9cJoRra12hjSia5yFwzBMc

<ds:DigestValue>ByGrS9cJoRra12hjSia5yFwzBMc=</ds:

DigestValue>

<

</ds:

Reference>

<

</ds:

SignedInfo>
<ds

SignedInfo>
<ds:SignatureValue Id="SignatureValue"

>YVauwq0…aCk

>YVauwq0…aCk+Dws8=</ds:

SignatureValue>
<ds

SignatureValue>
<ds:KeyInfo Id="KeyInfo">

<

<ds:X509Data>
<ds:X509Certificate>MIID3…dAW2+</ds:

X509Data>
<ds:X509Certificate>MIID3…dAW2+<

X509Certificate>
</ds:

X509Certificate>

X509Data>

<

</ds:

X509Data>

KeyInfo>

</ds:

KeyInfo></ds:Signature>

Signature>

Eksempel 3: XMLDsig med utvidet signaturinformasjon

...

To standarder definerer tidsstempler: RFC31619 i ASN.1 og OASIS DSS10 i XML syntaks. Uansett gjelder kravene fra RFC3161 når det gjelder hva et tidsstempel inneholder og hvordan slike produseres. OASIS DSS tidsstempler er enkle å produsere med standardbiblioteker, siden de egentlig bare er XMLDSIG enveloping signaturer. Derfor vurderes OASIS DSS som enklest å implementere i e-resept, og legges til grunn.

<ds

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature"

>

<ds

<ds:

SignedInfo>
<ds

SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

<ds

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds

<ds:Reference URI="">....</ds:

Reference>

<

</ds:

SignedInfo>
<ds

SignedInfo>
<ds:SignatureValue Id="SignatureValue"

>YVauwq0…aCk

>YVauwq0…aCk+Dws8=</ds:

SignatureValue>
<ds:

SignatureValue>
<ds:KeyInfo Id="KeyInfo">....</ds:

KeyInfo>
<ds:Object>
<xades

KeyInfo>
<ds:Object>
<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#Signature">

            <xades:UnsignedProperties>
                <xades:UnsignedSignatureProperties>
                    <xades

            <xades:UnsignedProperties>
                <xades:UnsignedSignatureProperties>
                    <xades:SignatureTimeStamp Id="SignatureTimeStamp">

<xades:XMLTimeStamp>

<

</xades:

XMLTimeStamp>

<

</xades:

SignatureTimeStamp>

<

</xades:

UnsignedSignatureProperties>

<

</xades:

UnsignedProperties>

<

</xades:

QualifyingProperties>

<

</ds:

Object>

Object>
</ds:

Signature>

Eksempel 4: XAdES-T – plassering av SignatureTimeStamp

....

<dss

<dss:Timestamp xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema">

<ds

<ds:Signature Id="XMLTimeStampTokenSignature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds

<ds:

SignedInfo>

<ds

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds

<ds:Reference URI="#SignatureValue">....</ds:

Reference>ds

Reference>

<

<ds:Reference URI="#XMLTimeStampTokenKeyInfo">....</ds:

Reference>

<ds

<ds:Reference URI="#TstInfo" Type="urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken">
....

<

</ds:

Reference>

<

</ds:

SignedInfo>
<ds

SignedInfo>
<ds:SignatureValue Id="XMLTimeStampTokenSignatureValue"

>JNRFS1aj

>JNRFS1aj...KLjY=</ds:

SignatureValue>
<ds

SignatureValue>
<ds:KeyInfo Id="XMLTimeStampTokenKeyInfo">

<ds:X509Data><ds:X509Certificate>
<

<ds:X509Data><ds:X509Certificate>

<

</ds:

X509Data><

X509Data></ds:

X509Certificate>
<

X509Certificate>
</ds:

KeyInfo>
<ds

KeyInfo>
<ds:Object Id="TstInfo">

<dss

<dss:

TstInfo>

<dss:SerialNumber>1227859557799<

<dss:SerialNumber>1227859557799</dss:

SerialNumber>
<dss:CreationTime>2008

SerialNumber>
<dss:CreationTime>2008-11-28T09:05:57+01:

00<

00</dss:

CreationTime>
<dss

CreationTime>
<dss:TSA NameQualifier="CN"

Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">

CN=NAV Test

</dss:

TSA>

</dss:

TstInfo>

</ds:

Object>

</ds:

Signature>

</dss:

Timestamp>

....

Eksempel 5: XAdES-T – innhold i XMLTimeStamp

...

Elementet er en signatur av Reseptformidleren og inneholder således Reseptformidlerens sertifikat.

<ds

<ds:

Object>
<xades

Object>
<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#Signature">

                <xades:UnsignedProperties>
                    <xades:UnsignedSignatureProperties>                            <xades:CounterSignature>
                            <ds:Signature>
                                <ds:SignedInfo>
                                    <ds

<xades:UnsignedProperties>
<xades:UnsignedSignatureProperties>

                            <xades:CounterSignature>
                            <ds:Signature>
                                <ds:SignedInfo>
                                    <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds

<ds:Reference Type="http://uri.etsi.org/01903#CountersignedSignature" URI="#SignatureValue">

<ds

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>rBmeyy0stU4vxxGkabzy1XO

<ds:DigestValue>rBmeyy0stU4vxxGkabzy1XO/PXc=</ds:

DigestValue>

<

</ds:

Reference> <ds

Reference>

<ds:Reference Type="http://uri.etsi.org/01903#CountersignedSignature" URI="#KeyInfoCounterSignature">

<ds

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>somethirddigestvalue

<ds:DigestValue>somethirddigestvalue=</ds:

DigestValue>

<

</ds:

Reference>
<ds

Reference>
<ds:Reference Type="http://uri.etsi.org/01903#CountersignedSignature" URI="#HPR">

<ds

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>someotherdigestvalue

<ds:DigestValue>someotherdigestvalue=</ds:

DigestValue>

<

</ds:

Reference>

<

</ds:

SignedInfo>
<ds:SignatureValue>Szxwaa

SignedInfo>
<ds:SignatureValue>Szxwaa...=</ds:

SignatureValue>
<ds

SignatureValue>
<ds:KeyInfo Id="KeyInfoCounterSignature">

<ds:X509Certificate>MIIE3z

<ds:X509Certificate>MIIE3z...+

dwQa<

dwQa</ds:

X509Certificate>

<

</ds:

KeyInfo>

<

</ds:

Signature>

<

</xades:

CounterSignature>

<hpr

<hpr:RfHprData Id="HPR" xmlns:hpr="http://www.reseptformidleren.no/schema/rf-hpr-data">

<hpr

<hpr:HPR-

nummer>string<

nummer>string</hpr:HPR-

nummer>
<hpr

nummer>
<hpr:HPRMerknad V="token" S="0" DN="string" OT="string"/>

<hpr:Autorisasjonskode>string<

<hpr:Autorisasjonskode>string</hpr:

Autorisasjonskode>
<hpr:Rekvireringskode>string<

Autorisasjonskode>
<hpr:Rekvireringskode>string</hpr:

Rekvireringskode>

<

</hpr:

RfHprData>

<

</xades:

UnsignedSignatureProperties>

<

</xades:

UnsignedProperties>

<

</xades:

QualifyingProperties>

<

</ds:

Object>

Eksempel 6: XAdES-CounterSignature

...

Eksempel på skjema for HPR data er vist under:

<?xml version="1.0"?>

<xsd

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:rfhpr="http://www.reseptformidleren.no/schema/rf-hpr-data" targetNamespace="http://www.reseptformidleren.no/schema/rf-hpr-data" xmlns:EISI="http://www.EISI.no/xmlstds">

<xsd

<xsd:import namespace="http://www.EISI.no/xmlstds" schemaLocation="http://www.EISI.no/xmlstds/EISI.xsd"/>

<xsd

<xsd:complexType name="RfHprDataType">

<xsd:sequence>
<xsd

<xsd:sequence>
<xsd:element name="HPR-nummer" type="EISI:ST" minOccurs="1"/>

<xsd

<xsd:element name="HPRMerknad" type="EISI:CV" minOccurs="1"/>

<xsd

<xsd:element name="Autorisasjonskode" type="EISI:ST" minOccurs="0"/>

<xsd

<xsd:element name="Rekvireringskode" type="EISI:ST" minOccurs="0"/>

<

</xsd:

sequence>
<xsd

sequence>
<xsd:attribute name="Id" type="xsd:ID" use="required"/>

<

</xsd:

complexType>

Eksempel 7: HPR-data

Fra 2019/2020 vil bli tatt i bruk ny versjon av feltet "RfHprData". Ny versjon av RfHprData gir støtte for flere autorisasjoner, og rekvireringskode(r) og spesialitet(er).

...

Under <xades:CertificateValues> legges det ved

hele sertifikatkjeden for rekvirenten, dvs. rekvirentens sertifikat og CA sertifikatet for dette.

Hvis nødvendig legges det også ved

hele sertifikatkjeden for statusinformasjon (OCSP eller CRL), dersom det benyttes delegerte OCSP signeringssertifikater uten utvidelsen id-pkix-ocsp-nocheck. Sertifikater som forekommer i flere av sertifikatkjedene legges bare ved én gang.

Figur 11: Illustrasjon av sertifikatkjeden

Under <xades:RevocationValues> legges det ved

OCSP svaret for rekvirentens signeringssertifikat, inkludert fødselsnummer
OCSP svaret for TSA tidsstemplingssertifikat

<ds

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature">
...

...

<ds:Object>
<xades

<ds:Object>
<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#Signature">

            <xades:UnsignedProperties>
                <xades:UnsignedSignatureProperties>
                    <xades

            <xades:UnsignedProperties>
                <xades:UnsignedSignatureProperties>
                    <xades:SignatureTimeStamp Id="SignatureTimeStamp">

<xades:XMLTimeStamp>
<dss

<xades:XMLTimeStamp>
                            <dss:Timestamp xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema">

<

</dss:

Timestamp>

<

</xades:

XMLTimeStamp>

<

</xades:

SignatureTimeStamp>

                    <xades:CertificateValues Id="CertificateValues">
                            <xades:EncapsulatedX509Certificate>mkpUl…Pg=</xades:EncapsulatedX509Certificate>
                            <xades:EncapsulatedX509Certificate>MIIFs…8Fw=</xades:EncapsulatedX509Certificate>
                            <xades:EncapsulatedX509Certificate>MIIE9…scDe</xades:EncapsulatedX509Certificate>
                     </xades:CertificateValues>
                     <xades:RevocationValues Id="RevocationValues">
                            <xades:OCSPValues>
                                <xades:EncapsulatedOCSPValue>MIIIZA…SlSU+A==</xades:EncapsulatedOCSPValue>
                                <xades:EncapsulatedOCSPValue>MIIInIt…GDwXA==</xades:EncapsulatedOCSPValue>
                            </xades:OCSPValues>
                     </xades:RevocationValues>

<

</xades:

UnsignedSignatureProperties>

<

</xades:

UnsignedProperties>

<

</xades:

QualifyingProperties>

<

</ds:

Object>

Object>
</ds:

Signature>

Eksempel 8: XAdES Revocation values

...

Formålet med XAdES-A er å kunne holde X-L formen gyldig utover gyldighetsperioden til sertifikatene og valideringsdata i den. Bruken av XAdES-A er ikke forutsatt ved initiell implementering av SKO mellom partene i e-resept, men kan være aktuelt som en utvidelse senere.

Arkivtidstempelet signerer all XAdES-data og binder disse dermed uforanderlig til den opprinnelige signaturen.
En XAdES-A signatur rommer vilkårlig mange arkivtidsstempel. Et nytt tidsstempel forlenger dermed gyldigheten til hele signaturen.

Arkivtidstempelet produserer ved hjelp av en TSA, jf. XAdES-T. NB Dette trenger ikke være samme TSA eller samme TS sertifikat som ble benyttet i SignatureTimestamp i XAdES-T.

I e-resept kan dette anvendes for å presentere en gyldig signatur til utleverer og Helfo selv i de tilfellene der

både rekvirentens og TSAens (Reseptformidleren) sertifikater har enten gått ut på dato eller endret status.
RF skifter virksomhetssertifikat.
TSAens (Reseptformidleren) sertifikat som benyttes til SignatureTimestamp er gyldig i mindre enn ett år til.

Alle aktører kan legge til nye arkivtidsstempler ved behov over tid.

Eksempelet på neste side viser bruken av XAdES-A i XML.

<ds:Object>
<xades

<ds:Object>
<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#Signature">

            <xades:UnsignedProperties>
                <xades:UnsignedSignatureProperties>
                    <xades

<xades:UnsignedProperties>
                <xades:UnsignedSignatureProperties>
                    <xades:SignatureTimeStamp Id="SignatureTimeStamp"></xades:

SignatureTimeStamp>

<xades:CertificateValues Id="CertificateValues"

><

><!-- --

><

></xades:CertificateValues>
<xades:RevocationValues Id="RevocationValues"

><

><!-- --

><

></xades:RevocationValues>
<xades:ArchiveTimeStamp Id="ArchiveTimeStamp">

<xades:XMLTimeStamp>
<dss

<xades:XMLTimeStamp>
<dss:Timestamp xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema">

<ds

<ds:Signature Id="

XMLArchiveTimeStampTokenSignature

XMLArchiveTimeStampTokenSignature">

<ds:SignedInfo>
<ds

<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds

<ds:Reference URI="#SignatureValue"></ds:

Reference>

<ds

<ds:Reference URI="#KeyInfo"></ds:

Reference>

<ds

<ds:Reference URI="#SignatureTimeStamp"></ds:

Reference>

<ds

<ds:Reference URI="#CertificateValues"></ds:

Reference>

<ds

<ds:Reference URI="#RevocationValues"></ds:

Reference>

<ds

<ds:Reference URI="#ArchiveTstInfo" Type="urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken"

><

><!-- --

><

></ds:

Reference>

<ds

<ds:Reference URI="#XMLArchiveTimeStampTokenKeyInfo"></ds:

Reference>

<

</ds:

SignedInfo>
<ds

SignedInfo>
<ds:SignatureValue Id="XMLTimeStampTokenSignatureValue"

>JNR

>JNR...jY=</ds:

SignatureValue>
<ds

SignatureValue>
<ds:KeyInfo Id="XMLArchiveTimeStampTokenKeyInfo"></ds:

KeyInfo>
<ds

KeyInfo>
<ds:Object Id="ArchiveTstInfo">

<dss:TstInfo><

<dss:TstInfo></dss:

TstInfo>

<

</ds:

Object>

<

</ds:

Signature>

<

</dss:

Timestamp>

<

</xades:

XMLTimeStamp>

XMLTimeStamp>
</xades:ArchiveTimeStamp>

<

</xades:

UnsignedSignatureProperties>

<

</xades:

UnsignedProperties>

<

</xades:

QualifyingProperties>

<

</ds:

Object>

Eksempel 9: XAdES-A

Versions Compared

Old Version 3

New Version Current

Key

Faglig bakgrunn

Bruk av standardisert format (ETSI XAdES)

Nøkkelbrukutvidelser

Algoritmer / styrke

Konkrete verdier og parametre som skal brukes

Eksempler

Page Comparison

Versions Compared

Old Version 3

New Version Current

Key

Faglig bakgrunn

Bruk av standardisert format (ETSI XAdES)

Nøkkelbrukutvidelser

Algoritmer / styrke

Konkrete verdier og parametre som skal brukes

Eksempler