Dokumentpakke (ASiC)

1. Introduksjon
2. Langtidslagring
3. Manifest
4. Dokumentformater
5. MIME type
6. HTML
7. EHF
8. Sikkerhet

Introduksjon

Dokumentpakke inngår kun i DigitalPostMeldinger.

Associated Signature Container (ASiC) er et pakkeformat som er designet for å ivareta integritet til innholdet over lang tid. Kort fortalt så definerer standarden hvordan man skal sette sammen en zip fil med en filstruktur der man lager en digital signatur hver enkel fil med en kombinasjon av et digitalt fingeravtrykk av filen og et PKI sertifikat eid av en virksomheten. Dette medfører at man kan verifisere at filene kommer fra rett virksomhet, og om filene har blitt endret.

Les mer om hvordan dokumenter som sendes i Sikker digital post er beskyttet

Sikker Digital Post har definert et eget begrep Manifest som inneholder metadata relatert til hver fil.

Innhold

Begrensninger

• Dokumentpakken kan ikke overstige 30Mb
• Dokumentpakken kan inneholde et hoveddokument
• Dokumentpakken kan ha inntil 200 vedlegg
• Avsender kan ikke definere rekkefølgende på vedleggene, sorteringen av disse håndteres av postkassen.

Eksempel

• Manifest
• Full dokumentpakke

Refererte standarder

• Associated Signature Container (ASiC)
• XAdES

Langtidslagring

Associated Signature Container (ASiC) er et pakkeformat som er designet for å ivareta integritet til innholdet over lang tid.
Dette medfører at man kan verifisere at filene kommer fra rett virksomhet, og om filene har blitt endret.

Postkasseleverandørene er forpliktet til å oppbevare innholdet i Dokumentpakken så lenge innbygger ønsker.

Det betyr at følgende langtidsoppbevares i forbindelse med en sending av digital post:

• hoveddokument
• vedlegg
• Manifest
• META-INF/signatures.xml

Manifest

Attributer

Eksempel

<?xml version="1.0" encoding="UTF-8"?>
<manifest
  xmlns="http://begrep.difi.no/sdp/schema_v10"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://begrep.difi.no/sdp/schema_v10 ../xsd/sdp-manifest.xsd ">

  <mottaker>
    <person>
      <personidentifikator>17051400000</personidentifikator>
      <postkasseadresse>ola.nordmann#0ABC</postkasseadresse>
    </person>
  </mottaker>

  <avsender>
    <organisasjon authority="iso6523-actorid-upis">9908:123456789</organisasjon>
    <avsenderidentifikator>A</avsenderidentifikator>
    <fakturaReferanse>ABC barnehage</fakturaReferanse>
  </avsender>

  <hoveddokument href="vedtak_2398324.pdf" mime="application/pdf">
    <tittel lang="no">Vedtak</tittel>
  </hoveddokument>

  <vedlegg href="info.html" mime="text/html">
    <tittel lang="no">informasjon</tittel>
  </vedlegg>

  <vedlegg href="journal.txt" mime="text/plain">
    <tittel lang="no">journal</tittel>
  </vedlegg>

</manifest>

Dokumentformater

Transportinfrastrukturen som brukes for å sende DPI-meldinger kan i utgangspunktet frakte en hver filtype fra avsender til mottaker, men det er begrenset hva tjenesteleverandørene som mottar meldingene (postkasseleverandører og utskrifts- og forsendelsestjenesten) håndterer. Se oversikt over støttede MIME types i neste avsnitt.

Eksekverbare filer kan ikke sendes i Sikker digital posttjeneste.

Det utføres ingen endringer i innholdet i mottatte dokumenter. Linker, bilder eller referanser til annet innhold fjernes ikke og dokumentet blir vist i et eget vindu/frame.

Generelle regler for alle filer:

• Alle filnavn skal være UTF-8

Spesielle regler knyttet til de enkelte dokument formatene:

• HTML dokumenter
• EHF dokumenter

MIME type

Følgende mimetypes er tillatt sendt i digital post til innbygger.
Visning av blant annet PDF, DOC, ODF og OOXML krever at brukeren har installert en viewer eller et annet program som kan vise det gjeldende formatet.

Listen kan eventuelt utvides ved behov.

HTML

|---|---| | Identifikator | html | | Term          | HTML | | Definisjon    | HTML fil | | Datatype      | fil |

Dersom en melding er levert som ren HTML vil denne vises til posttmottaker uten bruk av nettlesertillegg.

Begrensninger

1. Av sikkerhetsmessige hensyn, og for å sikre korrekt visning i hele dokumentets levetid, kan dokumentet ikke inneholde referanser til eksternt innhold eller javascript.
2. Links til egne sider er unntatt og kan benyttes.
   #* Lenker må ha: target=“_blank” for å kunne være klikkbare
3. Bilder som ønskes brukt i HTML-brev skal derfor legges inn i HTML encodet etter “”data url scheme“” (RFC 2397).
   #* img src kan ikke være multiline
4. HTML-dokumenter får ikke inneholder forms av følgende årsaker:
   #* Dersom serveren, som mottar POST fra en form, ikke svarer korrekt eller ikke lengre finnes, vil dette resultere i at brukerne blir møtt med en feil som ikke kan håndteres av postkassen.
   #* Det vil ikke kunne sende med troverdige opplysninger om hvem brukeren er.
5. Det tillates ikke bruk av Flash, Java, JavaScript eller andre tredjepartsløsninger som ikke inngår i HTML-standardene.
6. hr align-attr er ikke tillatt
7. Tabeller kan benyttes
   #* td elementer kan ikke være tom

Det anbefales at HTML overholder W3C og WCAG av hensyn til tilgjengeligheten og for å sikre nettleserkompatibilitet.

Bredden i viewport som er tilgjengelig i postkasse for visning av HTML brev er i utgangspunktet 793 pixels.
Dvs. HTML dokumenter som sendes som er større enn 793 pixels vil resultere i horisontal scrolling (standard nettleser oppførsel).
Vi oppfordrer Avsendere som sender HTML dokumenter til å ikke benytte abolutte bredder i dokumentet og tilpasse bilder til å møte denne bredden.

Postkasseløsningen er reponsiv som betyr at på mobil vises HTML dokumentet som avsender har sendt helt alene.
Det anbefales alltid at det ikke benyttes en fast bredde og at innholdet tilpasser seg browserens størrelse.
Dvs. bruk av responsiv teknikker i HTML dokumentet (fra avsender) vil resultere i et mye mer brukervennlig dokument på mobile enheter.

Feilhåndtering

HTML-meldinger som ikke oppfyller disse kravene blir avvist ved mottak. Dette vil resultere i en SKAL VÆRE LINK TIL ../../meldinger/FeilMelding.md Avsendervirksomheten må korrigere meldingene og sende på nytt.

EHF

• Identifikator
  [}](
• Term
  Dokumentpakke (ASiC)
• Definisjon
  EHF faktura fil
• Datatype
  fil

Dersom en melding er levert som ren EHF vil denne vises til posttmottaker uten bruk av nettlesertillegg.
EHF filen vil konverteres til en HTML visning i henhold til Difi sin mal for visning av EHF filer til innbyggere.

Postkasseleverandøren kan ha funksjonalitet for å maskinelt behandle EHF fakturaen for videresending direkte til nettbanken til innbygger.
En slik tjeneste vil da være priset. Se prisoversikt på http://samarbeid.difi.no

Forutsetning ved sending av EHF filer

1. Det er kun støtte for å sende EHF faktura
   #* Sending av EHF kreditnota er ikke støttet i digital postkasse til innbyggere
2. Mimetype for EHF faktura skal være: “application/ehf+xml”
3. EHF filen skal alltid være hoveddokument
   #* EHF filen kan sendes som vedlegg, men da er det ikke garantert at dette vil kunne vises til innbyggere i annet enn XML format
4. Det skal kun sendes en EHF fil i en forsendelse
5. Postkasseleverandør vil kun validere EHF filen i henhold til XSD.
   #* Det er Avsender sitt ansvar at data i EHF filen er korrekt
6. Det skal ikke være embedded vedlegg i EHF filen.
   #* Eventuelle vedlegg til EHF filen skal legges som ordinære vedlegg i dokumentpakken
   #* Difi kan ikke garantere for at embedded vedlegg i EHF faktura vil vises i postkassene.

Forutsetninger for maskinell behandling av EHF fakturaen i digipost

• Det må finnes exakt en PaymentMeans.
• Det må finnes exakt en PaymentId inne i paymentMeans
• Det må finnes en PaymentMeanDueDate
• Det må finnes en PayeeFinancialAccount med ID och SchemeID
• PayeeFinancialAccount SchemeID må være IBAN
• Valutan må være NOK

Sikkerhet

• Integritet ivaretas ved at dokumentene (posten til mottaker) pakkes og signeres iht. Associated Signature Container (ASiC) fra ETSI. Dette formatet ivaretar integriteten over tid.
• Konfidensialitet fra avsender til mottaker ivaretas ved bruk av Cryptographic Message Syntax (CMS) fra IETF
• Integritetsbeskyttet Standard Business Document (SBD) fra UN/CEFACT knytter sammen den krypterte pakken med adressering, varsling og annen metadata.

En forsendelse i Sikker digital post inneholder blant annet informasjon for varsling og et hoveddokument med null eller flere vedlegg.

Her beskrives hvordan dokumenter og vedlegg som sendes i Sikker digital post er beskyttet.

Dokumentene og metadata relatert til dokumentene pakkes i en dokumentpakke som ivaretar dokumentenes integritet, samt integriteten til metadata relatert til dokumentene. Dokumentpakkens konfidensialitet ivaretas ved at dokumentpakken krypteres med en symmetrisk engangsnøkkel, og den symmetriske nøkkelen krypteres med mottakerens sertifikat som hentes fra oppslagstjenesten for kontaktinformasjon.

Standarder

Integritet

Integriteten til dokumentene skal kunne valideres mange år etter mottak, og er ivaretatt ved digitale signaturer som beskrevet nedenfor. I praksis er dette en zip-fil med en gitt struktur som inneholder en digital signatur over innholdet.

ASiC profil for dokumentpakken brukt i sikker digital post

Hoveddokumentet og vedleggene pakkes sammen i en dokumentpakke sammen med noe metadata i henhold til ASiC (ETSI TS 102 918), og videre begrenset i henhold til profilen definert i Baseline Profile (ETSI TS 103 174). Ytterlige begrensninger Baseline Profile (ETSI TS 103 174) følger nedenfor:

Signatur i dokumentpakken for sikker digital post

Dokumentpakken bør være signert av Behandlingsansvarlig, men kan signeres av Databehandler.

Signaturen skal være i henhold til XAdES (ETSI TS 101 903) med basisprofilen definert i XAdES Baseline Profile (ETSI TS 103 171) (B-Level Conformance). Ytterlige begrensninger til XAdES Baseline Profile (ETSI TS 103 171) følger nedenfor:

Konfidensialitet

Dokumentpakken krypteres til mottakers sertifikat som leveres fra oppslagstjenesten. Krypteringen skal gjøres i henhold til CMS (Cryptographic Message Syntax) med begrensninger angitt nedenfor.

CMS er BER og DER kodet ASN.1 og starter med en sekvens av ContentInfo

ContentInfo ::= SEQUENCE {
  contentType ContentType,
  content [0] EXPLICIT ANY DEFINED BY contentType 
}

Her skal følgende begrensninger gjelde:

• contentType = 1.2.840.113549.1.7.3 (id-envelopedData).
• content er EnvelopedData som beskrevet nedenfor.

EnvelopedData ::= SEQUENCE {
  version CMSVersion,
  originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  encryptedContentInfo EncryptedContentInfo,
  unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

Her skal følgende begrensninger gjelde:

• version = 0
• originatorInfo skal ikke være med
• recipientInfos skal være en mengde av nøyaktig en KeyTransRecipientInfo som beskrevet nedenfor
• encryptedContentInfo er EncryptedContentInfo som beskrevet nedenfor
• unprotectedAttrs skal ikke være med

KeyTransRecipientInfo ::= SEQUENCE {
  version CMSVersion, -- always set to 0 or 2
  rid RecipientIdentifier,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey 
}

Her skal følgende begrensninger gjelde:

• version = 0
• rid = issuerAndSerialNumber
• keyEncryptionAlgorithm er en AlgorithmIdentifier som beskrevet nedenfor
• encryptedKey den krypterte nøkkelen

AlgorithmIdentifier  ::=  SEQUENCE  {
  algorithm               OBJECT IDENTIFIER,
  parameters              ANY DEFINED BY algorithm OPTIONAL  }

Her skal følgende begrensninger gjelde:

• algorithm = 1.2.840.113549.1.1.7 (id-RSAES-OAEP) som spesifisert i RSAES-OAEP Key Transport Algorithm
• parameteres = RSAES-OAEP-params som definert nedenfor

RSAES-OAEP-params  ::=  SEQUENCE  {
  hashFunc    [0] AlgorithmIdentifier DEFAULT sha1Identifier,
  maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier,
  pSourceFunc [2] AlgorithmIdentifier DEFAULT pSpecifiedEmptyIdentifier  }

Her skal følgende begrensninger gjelde

• hashFunc = sha1Identifier
• maskGenFunc = mgf1SHA1Identifier
• pSourceFunc = pSpecifiedEmptyIdentifier

EncryptedContentInfo ::= SEQUENCE {
  contentType ContentType,
  contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
  encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL 
}

Her skal følgende begrensninger gjelde:

• contentType = 1.2.840.113549.1.7.1 (data)
• contentEncryptionAlgorithm er en AlgorithmIdentifier som beskrevet nedenfor
• encryptedContent = AES-CBC kryptert innhold med PKCS #5 padding

AlgorithmIdentifier  ::=  SEQUENCE  {
  algorithm               OBJECT IDENTIFIER,
  parameters              ANY DEFINED BY algorithm OPTIONAL  }

Her skal verdiene være i henhold til [Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax

](ietf7), med følgende begrensninger:

• algorithm = 2.16.840.1.101.3.4.1.42 (aes256-CBC)
• parameters = 16 byte IV

Ved bruk av aes256-CBC skal padding gjøres i henhold til kapittel 6.3 i CMS spesifikasjonen

Integriteten til den krypterte dokumentpakken ivaretas av Dokumentpakkefingeravtrykk som ligger i en signert melding.

Det er avsenders ansvar å generere en AES-nøkkel med tilstrekkelig tilfeldighet. Kilden bør være en sertifisert generator for tilfeldige tall (TRNG).

Mulig fremtidig utvidelse

Valg av kryptoalgoritme er begrenset til AES-CBC, men AES-GCM har også vært vurdert, og kan tas inn senere ved behov. Årsaken til ikke å ta med AES-GCM i denne omgang er at den ikke er støttet i s/mime, og dermed hindrer bruk av s/mime klienter for ende-til-ende kryptering.

Ved fremtidig støtte for AES-GCM vil følgende begrensninger gjelde:

ContentInfo vil være:

• contentType = 1.2.840.113549.1.9.16.1.23 (id-ct-authEnvelopedData) ved bruk av AES-GCM.
• content AuthEnvelopedData

AuthEnvelopedData er definert i Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type

AuthEnvelopedData ::= SEQUENCE {
  version CMSVersion,
  originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  authEncryptedContentInfo EncryptedContentInfo,
  authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
  mac MessageAuthenticationCode,
  unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL

Her skal følgende begrensninger gjelde:

• version = 0
• originatorInfo skal ikke være med
• recipientInfos skal være en mengde av nøyaktig en KeyTransRecipientInfo som beskrevet nedenfor
• authEncryptedContentInfo er EncryptedContentInfo som beskrevet nedenfor
• authAttrs skal ikke være med
• mac skal være 12 byte “authentication tag” som output av AES-GCM definert i NIST Special Publication 800-38D.
• unauthAttrs skal ikke være med

For AuthEnvelopedData (AES-GCM) skal verdiene av EncryptedContentInfo være i henhold til Using AES-CCM and AES-GCM Authenticated Encryption.

• algorithm = 2.16.840.1.101.3.4.1.46 (aes256-GCM)
• parameters = GCMParameters som beskrevet nedenfor

GCMParameters ::= SEQUENCE {
  aes-nonce        OCTET STRING, -- recommended size is 12 octets
  aes-ICVlen       AES-GCM-ICVlen DEFAULT 12 }

Her skal følgende begrensninger gjelde:

• aes-nonce = 12 byte IV/Teller
• aes-ICVlen = 12

[etsi1]http://www.etsi.org/deliver/etsi_ts/102900_102999/102918/01.03.01_60/ts_102918v010301p.pdf
[etsi2]http://www.etsi.org/deliver/etsi_ts/103100_103199/103174/02.02.01_60/ts_103174v020201p.pdf
[etsi2_9]http://www.etsi.org/deliver/etsi_ts/103100_103199/103174/02.02.01_60/ts_103174v020201p.pdf#page=9
[etsi2_11]http://www.etsi.org/deliver/etsi_ts/103100_103199/103174/02.02.01_60/ts_103174v020201p.pdf#page=11
[etsi2_12]http://www.etsi.org/deliver/etsi_ts/103100_103199/103174/02.02.01_60/ts_103174v020201p.pdf#page=12
[etsi3]http://www.etsi.org/deliver/etsi_ts%5C101900_101999%5C101903%5C01.04.02_60%5Cts_101903v010402p.pdf
[etsi4]http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf
[etsi4_8]http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf#page=8
[etsi4_10]http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf#page=10
[etsi4_11]http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf#page=11
[etsi4_12]http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf#page=12
[etsi4_13]http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf#page=13
[ietf5]http://tools.ietf.org/html/rfc5652
[ietf5_6_3]http://tools.ietf.org/html/rfc5652#section-6.3
[ietf6]http://tools.ietf.org/html/rfc3560
[ietf7]http://tools.ietf.org/html/rfc3565
[ietf8]http://tools.ietf.org/html/rfc5084
[ietf9]http://tools.ietf.org/html/rfc5083