Sv: Validering av filformater

Thomas Sødring tsodring at oslomet.no
Mon Dec 19 11:41:53 CET 2022


Hei,

Merk! Jeg kan ikke nok om PDF/A til å uttale med bastant. Ta det jeg sier med en
klype salt. Jeg synes spørsmålet er interessant og kaster ut mine tanker
og håper andre kan komme med innspill.

Når jeg leser om PDF/A og signaturer (overfladisk) så ville jeg trodd at dette
ikke ville være et problem. Jeg forstod det slik at signaturer dekket et sett
av innhold i dokumentet og selve signaturen ligger i en "lomme" i PDF filen.

I teorien skal det være mulig å flytte innholdet og signaturen inn i en PDF/A
fil, men kun dersom det ikke ble gjort endringer til innhold feks et problem med
en font / bilde. Det er vel avhengig av hvor mye konvertering som må skje.

En stund tilbake ble det sagt at signaturer er noe fagmiljøet ikke har tenkt over i det
hele tatt. Det er ikke sant da signaturer er noe som er beskrevet i Noark og
løsningen der er jeg delvis enig i.

Noark håndterer problemstillingen med at Noark velger at du kun skal dokumentere
hvorvidt dokumentets signatur stemte under danningen. Noark sin XML/XSD gjør
ikke plass for noe teknisk bevaring av PKI infrastrukturinformasjon.

<xs:complexType name="elektroniskSignatur">
  <xs:sequence>
    <xs:element name="elektroniskSignaturSikkerhetsnivaa" type="n5mdk:elektroniskSignaturSikkerhetsnivaa"/>
    <xs:element name="elektroniskSignaturVerifisert" type="n5mdk:elektroniskSignaturVerifisert"/>
    <xs:element name="verifisertDato" type="n5mdk:verifisertDato"/>
    <xs:element name="verifisertAv" type="n5mdk:verifisertAv"/>
  </xs:sequence>
</xs:complexType>

(ref: https://github.com/arkivverket/schemas/blob/master/N5/v5.0/arkivstruktur.xsd#L566)

Noark 5v4 hadde en restriksjon på elektroniskSignaturVerifisert som ble borte i
Noark 5v5.

<xs:restriction base="xs:string">
 <xs:enumeration value="Signatur påført, ikke verifisert"/>
 <xs:enumeration value="Signatur påført og verifisert"/>
</xs:restriction>

I teorien kan det i Noark 5v5 stå "Signatur påført, verifisert og ikke verifisert"!

Denne generelle tilnærmingen er noe jeg opplever som både positivt og negativt.
Det er positivt at Noark har valgt hvordan signaturer skal håndteres og her er
det en fiks ferdig tilnærming fagmiljøet kan diskutere for å komme fram til en
best practice. Positivt også at det er så enkelt. Men den verdien i
elektroniskSignaturVerifisert kan bli viktig senere.

Det vi tidligere har diskutert i nikita prosjektet er hvorvidt organisasjoner
burde bevare den offentlig nøkkelen som ble brukt til å verifisere signaturen,
eller ikke. Fra en etterprøvbarhetsperspektiv så er svaret til det JA. Depot
burde bevare de offentlig nøklene som er brukt. Men slik er det ikke i Noark og
den delen av en "chain-of-custody" skal bevist kastes. Jeg mistenker at grunnen
Noark gjør det slikt er fordi Noark ikke skal styre for mye dette da det kan
være noen uante kostnader her. Altså at depot ikke skal bry seg om autentisitet
på dette nivået.

Tid vil være en utfordring dersom vi bevarer slike nøkler med dokumentet. Vi må
også bevare hvilken algoritme og håpe at det fortsatt vil være en implementasjon
tilgjengelig som gjør at vi kan verifisere signaturen på en uavhengig vis.

Dette med uavhengig vis er viktig synes jeg! Jeg mistenker at Norge vil bruke
informasjonssiloer og bli mer og mer avhengig av leverandører for ting
 som verifisering av signatur. Da vil depot ha et problem dersom det er viktig å
sikre etterprøvbarheten til signaturen. Dersom etterprøvbarheten er viktig så
må depot besitte kompetanse (enkelt) og infrastruktur, noe som ikke er enkelt
om det er en proprietær tjeneste der ting er skjult.

Noark løser problemet ditt dersom du kan leve med at depot ikke trenger å
senere verifisere signaturer på PDF/A variantene. Du trenger bare å verifisere
at dokumentets signatur er gyldig og så konvertere til PDF/A.

Dersom vi ser litt mer på dette så er det vel slik at de PDF/A filer burde være
identifisert med PUID fmt/476 (2a) eller fmt/477 (2b), men det du etterspør er
egne PUID for PDF/A filer som inneholder en signatur som kan verifiseres.

https://www.nationalarchives.gov.uk/PRONOM/Format/proFormatSearch.aspx?status=detailReport&id=1263
https://www.nationalarchives.gov.uk/PRONOM/Format/proFormatSearch.aspx?status=detailReport&id=1264


fmt/276 er danningsformatet for PDF 1.7 (slik jeg forstår det) så det er ingen
forsøk på å få dette til PDF/A.

https://www.nationalarchives.gov.uk/PRONOM/Format/proFormatSearch.aspx?status=detailReport&id=1016

Jeg husker jeg snakket med en leverandør en gang om mismatch i registrerte
filformater i databasen og de fortalte at det var en nesten umulig oppgave å
vite om ting faktisk var i PDF/A. Jeg ville håpet at vi er kommet videre siden
da!

Når det gjelder spørsmål 1:

Først vil jeg trekke oppmerksomheten til en diskusjon i Noark på github

https://github.com/arkivverket/noark5-standard/pull/99#issuecomment-814962618

der det framkommer at noen depot institusjoner ikke ønsker å beholde flere
kopier av et dokument. Greit å ha en slik perspektiv i bakhodet når man
diskuterer dette.

"Vil bruk av metadatafeltene elektroniskSignatur i Noark kunne erstatte
bevaringen av en uendret versjon?"

Min forståelse er at du har et signert dokument i vanlig PDF, ikke PDF/A. Så
denne produksjonsformat PDF filen kan inneholde fonter og annet informasjon som
er lenket til operativsystemet som skapte PDF dokumentet. Dette er noe som vil
ha utfordringer når det gjelder bevaring. Når du konverterer til PDF/A blir
signaturen feil. Så du er nødt til å konvertere til PDF/A, men du mister
signaturen. Da må du ivareta signaturen på en måte. Her kan Noark sin metadata
brukes til å bekrefte at signaturen stemte. Men egentlig kan du vel bevare begge
deler, men produksjonformat PDF'n vil miste noe av nytteverdien det øyeblikket det
ikke er mulig å verifisere signaturen og dersom du er avhengig av en tjeneste
for å verifisere så vil det skje når tjenesten legges ned  / nøkler ikke er
tilgjengelig.

Merk! Jeg kan ikke nok om postens tjeneste for å vite om offentlig nøkler er fritt
tilgjengelig for nedlasting, hva skjer dersom en privatnøkkel blir lekket og det
er tilbakekalling osv.

Hva som vil gi best integritet over tid? Jeg tror etterprøvbarheten og mulighet
til å verifisere dokumentet når som helst vil være det som gir best integritet.
Dersom det ikke er mulig så vil det kanskje være en sporbar prosess på
verifikasjonen som er best. At det registreres at signaturen er verifisert,
av hvem og når. "Hvem" er vel bare et programvare.


Spørsmål 2:

Litt beslektet diskusjon fra arkade5:

https://github.com/arkivverket/arkade5/issues/97

At Pronom ikke er ønskelig i danning, det er en depot anliggende. I nikita ønsker
jeg å bruke relevant verktøy for å identifisere pronomkoder så fort som mulig.
Jo mer kontroll du har, jo bedre. Du er inn på det når du etterspør pronomkoder
for å skille signert/ ikke signert PDF/A

Jeg vet at Petter Reinholdtsen jobbet med å få sosi koder inn i pronom listen
og lagde en M701-verdikatalog for Noark 5 (Tjenestegrensesnitt)

https://gitlab.com/petterreinholdtsen/m701-noark5-katalog

Dette er vel et spørsmål som må løftes høyere. Jeg har ingen tillit at det
finnes noen hos Arkivverket som har evnen eller kunnskap til å gjøre denne
jobben så jeg er usikker hvem som er riktig instans.

Det må være mulig å gjøre dette, men er det så viktig å ha egen pronom kode for
en PDF/A som er signert? Jeg tror JA, det er veldig viktig. Det er litt som
pronomkoder for docx. Det er interessant og viktig å vite om du har
docx filer med PUID fmt/494 fordi de er kryptert!














________________________________
Fra: nikita-noark <nikita-noark-bounces at nuug.no> på vegne av Thomas Sødring via nikita-noark <nikita-noark at nuug.no>
Sendt: torsdag 15. desember 2022 09:40
Til: nikita-noark at nuug.no <nikita-noark at nuug.no>
Emne: Vs: Validering av filformater

Hei,

Denne kom i innboksen min i går kveld fra Pål Mjørlund ved Innlandet fylkesarkiv og er et tematikk som jeg synes er interessant og relevant her på listen. Jeg har litt dårlig tid med sensur akkurat nå, men tenkte å svare her og la andre kommentere dersom de ønsker det.

-- start --
Mange har nå gått over til fullelektronisk arkivering av dokumenter. I en del tilfeller gjelder dette også avtaler som har blitt sendt til digital signering. Jeg oppfatter at de fleste kommunene benytter den nasjonale fellesløsningen til dette, og at det dermed er postens signeringsportal som blir brukt for selve signeringsprosessen. Jeg antar at du har kjennskap til løsningene og teknologien, men dokumentasjon på løsningen finnes her: https://signering-docs.readthedocs.io/en/latest/index.html<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsignering-docs.readthedocs.io%2Fen%2Flatest%2Findex.html&data=05%7C01%7Ctsodring%40oslomet.no%7Cac65966482e246c1243008dade780d3a%7Cfec81f12628645508911f446fcdafa1f%7C0%7C0%7C638066905256161256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cYLBYsZydx55UDc1VEssaSQkWcPWQ%2FPmkkiBlfLf%2BnI%3D&reserved=0> . Dette betyr at det allerede finnes en del dokumenter i sak/arkivløsningene som inneholder en digital signatur (basert på PAdES og XAdES).

Jeg har gjort noen kontroller i forhold til dokumenter som har blitt arkivert med avansert digital signatur, og oppdager at disse dokumentene heller ikke validerer som godkjent arkivformat. Dette har vært kjent hos Arkivverket og det ble på et møte sagt at dersom det kun er signaturen som avviker fra PDF/A-2, så godkjennes signerte PDF-dokumenter. Dette er imidlertid ikke helt enkelt. Dokumentene som jeg finner i sak/arkivløsningen fremstår dessverre ikke som PDF/A i det hele tatt, men som PDF 1.7 (pronom: fmt/276). Dette gjelder også dokumenter som var konvertert til PDF/A før de ble sendt til signering. Jeg har ikke funnet noen egen pronom-kode som viser at dette dokumentet inneholder en digital signatur, selv om det sannsynligvis burde være mulig å identifisere signaturen inne i dokumentet.

Bekymringen min er derfor i forhold til videre håndtering av disse dokumentene. Den digitale signaturen kan kun bekreftes så lenge filen er uendret. Dersom vi produserer PDF/A av et signert dokument vil det ikke være mulig å validere signeringen lenger. Denne utfordringen kan komme i forbindelse med produksjon av arkivuttrekk, men også i konverteringsprosesser som skjer i et arkivdepot for å vedlikeholde arkivdata.

Jeg har egentlig to hovedspørsmål:

Spørsmål 1:
I Noark-løsninger kan det være flere måter å håndtere digitale signaturer. I de uttrekkene vi har mottatt, har jeg så langt ikke sett at metadatafeltet elektroniskSignatur har blitt benyttet (M507, M508, M622 og M623). I mitt hode kunne en slik kontroll være automatisert i en løsning som benytter signeringsportalen. Jeg har imidlertid ikke fått signaler om at noen løsninger støtter en slik kontroll.
Flere opererer med flere varianter (eller bruker betegnelsen «versjoner») av dokumentet – slik at løsningen kan lagre både en arkivvariant og en signert variant. Det er imidlertid ikke praktisert å ta med flere av disse variantene i uttrekk. Vi ser at behovet for flere varianter er økende, ved at du gjerne skal ha en offentlig variant (i forhold til meroffentlighet og/eller publisering på postjournal hvor vi nå får krav om PDF/UA). Vil bruk av metadatafeltene elektroniskSignatur i Noark kunne erstatte bevaringen av en uendret versjon av det signerte dokumentet og hvilken løsning vil gi best integritet over tid?

Spørsmål 2:
Vi ønsker at en dokumentanalyse basert på PRONOM skal være grunnlaget for å gjennomføre en dokumentkonvertering. Vi oppfatter at filnavn og mime-type er mer utbredt grunnlagsdata i dag. Dersom signerte dokumenter hadde hatt egne PRONOM-koder ville det vært betydelig enklere å bevare originalversjonen av et signert dokument. Har du noen formening om hvor enkelt det er å få definert de signerte PDF-dokumentene inn som egne innføringer i PRONOM-registeret, og vil det egentlig være nødvendig?



--  slutt --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nuug.no/pipermail/nikita-noark/attachments/20221219/9db4b4cc/attachment-0001.htm>


More information about the nikita-noark mailing list