2 Sertifikatprofiler for norsk forvaltning

2.1 Innledning

Dette notatet er laget av PKI Consulting Services for Arbeids- og administrasjonsdepartementet. Formålet med notatet er å utarbeide et forslag til sertifikatprofiler med begrunnelser for en del av valgene.

Utredningen her gjelder bare sluttbrukersertifikater, ikke CA-sertifikater.

Sertifikatene skal bygge på X.509 v3 og profilen RFC 2459. RFC 2459 er den allment brukte standard for sertifikatprofilering. Sertifikatbruk i norsk offentlig sektor bør være i samsvar med denne. RFC 2459 er imidlertid svært bred og krever ytterligere nivåer av profilering for praktisk bruk.

I diskusjonen her er det tatt utgangspunkt i den stabile RFC 2459 fra 1999.

Kvalifiserte sertifikater (Qualified Certificates = QC) er en profil basert på RFC 2459. Det finnes en Internet Draft-spesifikasjon for QC som er skrevet med intensjon om å støtte kravene til kvalifiserte sertifikater og avanserte elektroniske signaturer som framkommer i EU-direktivet. I tillegg har det europeiske initiativet for standardisering rundt elektroniske signaturer (EESSI) gjort en del presiseringer og tilføyelser til denne. Likevel er det fortsatt behov for å gjøre flere profileringer og valg for faktisk bruk. Det er forsøkt å ta hensyn til krav og anbefalinger for kvalifiserte sertifikater i spesifikasjonene her.

I Internet Draft for Qualified Certificates er det gjort følgende tilleggsvalg og definisjoner:

• Definisjoner av navn og identitetsinformasjon for å identifisere subjekt (sertifikatinnehaver) på en mest mulig uniform måte.

• Definisjon av identitetsinformasjon for CA.

• Ytterligere definisjon av hvordan «keyUsage»-utvidelsen skal brukes.

• Struktur for lagring av biometrisk informasjon.

• Definisjon av lagring og representasjon av predefinerte erklæringer om sertifikatets bruk som kvalifisert sertifikat («qcStatements»-utvidelsen):

  • Erklæring om at sertifikatet er utstedt som kvalifisert sertifikat (enten ved å referere til en policy som klart indikerer at den er for slike, eller gjennom en eksplisitt erklæring),

  • Erklæring om begrensning i verdi for de transaksjoner som sertifikatet kan brukes til (gjennom en erklæring og angivelse av et beløp),

  • Erklæring om hvor lenge registreringsinformasjon om innehaver vil bli arkivert.

qcStatements er en privat utvidelse («extension») som stammer fra det kvalifiserte sertifikatet, og benyttes for å understreke overfor brukeren at det her handler om et kvalifisert sertifikat. Et standardforslag til tekst for en egenerklæring om at man har med et kvalifisert sertifikat å gjøre, finnes i ETSI's draft standard for «Qualified Certificate Profile». Det er ennå usikkert i hvilken grad dette kommer til å bli presentert for brukeren gjennom standard programvare. Man har foreløpig for liten erfaring med utvidelser for kvalifiserte sertifikater til å kunne gjøre seg opp noen mening om hvordan disse brukes av andre sertifikatutstedere.

Alle referanser forutsetter at navn på utsteder og innehaver skal kodes som sekvenser av navneattributter. Når sekvensen av attributter utgjør et unikt navn, er dette et DN (Distinguished Name). Alle navn må være unike innenfor en kontekst gitt av sertifikatutsteder og bruksområde.

Navn på utstedere og sertifikatinnehavere bør skrives i et alfabet som minimum inneholder norske tegn, fortrinnsvis som en UTF8-string, fordi RFC 2459 setter dette som et krav til alle sertifikater som utstedes etter 31.12.2003.

Det er også et poeng at informasjonen som står i commonName og organizationName-attributtene er umiddelbart gjenkjennbar for brukerne, fordi denne informasjonen kan vises fram av de fleste klientprogrammer. Det er høyst variabelt i hvilken grad f.eks. e-postklienter er i stand til å vise annen sertifikatinformasjon.

Attributtet «SerialNumber» står ikke listet opp eksplisitt blant attributtene som foreslås brukt i navnene på utstedere og sertifikatinnehavere i RFC 2459. Imidlertid er «SerialNumber» tatt med i anbefalingen av profil for kvalifiserte sertifikater og i den nye draft-profilen som IETF nå har utarbeidet og som på sikt skal erstatte RFC 2459. Det anbefales derfor å benytte «SerialNumber» i stedet for alternativet «dnQualifier» til å lagre unik identifikasjon. Merk også at «SerialNumber» tillater bruk av andre tegn enn tall, slik at sekvenser med bruk av bokstaver, bindestreker eller blanke som skilletegn er fullt ut akseptable.

Ikke alle nettlesere presenterer feltet CertificatePolicies for brukeren. Det bør derfor vurderes om man gjør som svenskene og legger et lesbart navn for policyen til, bakerst i commonName i issuer-feltet.

Det er gjort forsøk på å begrense mengden informasjon som skal inn i sertifikatene, bl.a. med tanke på at plassen i smartkort vil være begrenset.

Det er ikke tatt stilling til valg av nøkkellengder eller til hvordan data om sertifikatinnehaver initielt blir identifisert og registrert. Sertifikatene er også forsøkt beskrevet uavhengig av valg av lagringsmedium for nøklene.

Det er ikke tatt stilling til hvilke data om sertifikatinnehavere som skal lagres i kataloger. Katalogene kan bestå både av offentlig lesbar informasjon og av informasjon som det ikke gis leseaksess til ved alle katalogoppslag.

Det er satt opp forslag til følgende fire typer av sertifikater:

• Ansattsertifikat,

• Virksomhetssertifikat,

• Offentlig personsertifikat,

• Profesjonssertifikat.

Rene autorisasjonssertifikater og rollesertifikater (attributtsertifikater) beskrives ikke i dette notatet.

Det anbefales ikke å gjøre som danskene foreslår, å innføre en ny privat utvidelse i sertifikatene som eksplisitt sier om det er et personsertifikat, ansattsertifikat, virksomhetssertifikat eller profesjonssertifikat. Dette betyr at det må være mulig algoritmisk (i programvare) å finne ut hva slags sertifikat en står overfor. (En øvelse for å verifisere dette er gjort for FSP-1-sertifikattyper tidligere.) I praksis kan dette gjennomføres ved f.eks. å ha de obligatoriske elementene i subject-navnet i forskjellige, forhåndsbestemte rekkefølger.

I tabellene benyttes følgende forkortelser i kolonnen «Forekomst»:

I tabellene benyttes følgende forkortelser i kolonnen «Må sjekkes»:

2.2 Ansattsertifikat

Ansattsertifikatet skal baseres på RFC 2459 og spesifikasjonene for kvalifiserte sertifikater. I tillegg har Forvaltningsnettsamarbeidet spesifisert krav til og innhold i ansattsertifikater gjennom FSP-1 sertifikatpolicy.

Ansattsertifikatet er et personlig sertifikat for ansatte i en bedrift eller en etat. Ansattsertifikatet er et identitetssertifikat. Det er spesifisert uavhengig av valgt lagringsmedium for nøkler.

Ansattsertifikat inneholder ikke personens fødselsnummer eller annen informasjon som gjør vedkommende unikt definert på nasjonal basis. Hovedkravet her er i stedet at personen skal være entydig identifiserbar innenfor den virksomheten hvor vedkommende er ansatt.

Det foreslås at Elektronisk Ansatt-ID kan bestå av tre sertifikater:

• Sertifikat for ikke-benekting (elektronisk signatur) med non-repudiation-biten satt i keyUsage-feltet

• Sertifikat for autentisering med authentication-biten satt i keyUsage-feltet

• Kryptering og transport av sesjonsnøkler med bitene keyEncipherment og/eller dataEnciphermentsatt i keyUsage-feltet.

Anvendelse av tre sertifikater kan være vanskelig for enkelte typer programvare, spesielt på klientsiden, men også på sertifikatutstedersiden.

Det er med rette stilt spørsmål ved innehavers bruk av ansattsertifikatet i privat sammenheng. Det antas at ansattsertifikatet og de tilhørende nøklene er så nøye knyttet til ansettelsesforholdet at de ikke bør benyttes til rent privat bruk. Dette gjelder alle typer nøkler, men særlig for krypteringsnøkler og kryptering/dekryptering som privatperson.

Det er ikke obligatorisk å oppgi i sertifikatet hvilken underenhet (organizationUnit) en ansatt tilhører. Dermed reduseres risikoen for at sertifikatet vil måtte utstedes på nytt ved endringer i organisasjonsstrukturen.

Det foreslåtte ansattsertifikatet skiller seg fra forslaget i FSP-1 ved at den ansattes fullstendige navn slik dette er registrert i folkeregisteret, er fjernet fra subjectAltName. Det bør ikke være nødvendig å ha med mellomnavn som aldri brukes etc. i et ansattsertifikat.

Et annet avvik fra FSP-1 er at attributtet SerialNumber brukes i subject til å angi intern informasjon som skal sørge for unik identifikasjon av sertifikatinnehaver. Dette nummeret bør holdes unikt og konstant, i den forstand at det knyttes til en og bare en ansatt, det kan følge den ansatte gjennom forskjellige roller og stillinger, og det vil ikke bli brukt om igjen hvis den ansatte forlater virksomheten.

2.3 Virksomhetssertifikat

Virksomhetssertifikatet skal baseres på RFC 2459.

Virksomhetsssertifikatet skal sikre kommunikasjon til og fra virksomheter og organisasjonsenheter.

Virksomhetssertifikatet er spesifisert uavhengig av valgt lagringsmedium for nøkler.

Det er ikke knyttet noe personinformasjon eller personidentifikasjon til virksomhetssertifikatet. Det er således ingen personvernhensyn som må avklares.

Eksempler på bruk av virksomhetssertifikat er at en bedrift eller institusjon mottar kryptert e-post, eller at det foretas en toveis autentisering mellom en klient og virksomheten, f.eks. mellom en skatteyter og skatteetaten. Det kan også tenkes situasjoner der en ansatt i en virksomhet vil signere meldinger med en nøkkel som tilhører virksomheten. I slike tilfeller vil knytting mellom den ansatte som har signert, og meldingen eller dokumentet, være at vedkommendes navn framgår av det signerte innholdet.

Elektronisk virksomhets-ID kan bestå av opptil tre sertifikater.

• Sertifikat for ikke-benekting (elektronisk signatur) med non-repudiation-biten satt i keyUsage-feltet

• Sertifikat for autentisering med authentication-biten satt i keyUsage-feltet

• Kryptering og transport av sesjonsnøkler med bitene keyEncipherment og/eller dataEnciphermentsatt i keyUsage-feltet.

Ettersom kvalifiserte sertifikater pr. definisjon utstedes til individer, er det ikke meningsfylt å snakke om kvalifiserte virksomhetssertifikater. For helhetens skyld er imidlertid de private utvidelsene fra spesifikasjonen for kvalifiserte sertifikater tatt med også i denne tabellen.

Det foreslåtte virksomhetssertifikatet skiller seg fra forslaget i FSP-1 ved at man i subject benytter serialNumber i stedet for dnQualifier til å angi virksomhetens organisasjonsnummer. I forhold til FSP-1 foreslås det også å flytte virksomhetens fullstendige navn fra subjectAltName til organizationName-attributtet i subject, og at navn i daglig bruk flyttes fra organizationName til commonName (internt i subject).

2.4 Offentlig personsertifikat

Offentlige personsertifikater skal baseres på RFC 2459 og spesifikasjonene for kvalifiserte sertifikater. Det er et personlig identitetssertifikat.

Et offentlig personsertifikat er et sertifikat for privatpersoner til bruk blant annet mot forvaltningen. Med privatpersoner menes alle individer som enten er norske statsborgere eller bosatt i Norge og følgelig kan ha behov for å kommunisere med norske myndigheter.

Spesifikasjonen av offentlige personsertifikater er gjort uavhengig av valgt lagringsmedium for nøkler.

Forvaltningen vil kreve at man via sertifikatet skal kunne få tilgang til innehaverens fødselsnummer, fordi forvaltningen har behov for en på nasjonalt nivå unik identifikator av sertifikatinnehaver. I praksis vil dette bety at man via sertifikatet skal kunne få tilgang til innehaverens fødselsnummer. Den enkleste måten å løse dette på, vil være å ha fødselsnummeret i sertifikatene. Ettersom sertifikatinnholdet må regnes som offentlig lesbar informasjon, foreslås det i stedet å bruke en numerisk eller alfanumerisk identifikator som sikrer unikhet i «subject»-attributtet i sertifikatet, og at sertifikatutsteder blir pålagt å ha en kopling mellom denne unike verdien og fødselsnummeret. Denne unike subjekt-identifikatoren skal plasseres i attributtet serialNumber. En sertifikatinnehaver skal få tildelt et slikt entydig nummer hos hver enkelt sertifikatutsteder. Hvis en og samme sertifikatinnehaver har fått utstedt flere sertifikater hos en utsteder, skal den unike identifikatoren ha samme verdi for alle disse sertifikatene. Identifikatoren bør også beholdes uendret hvis personen f.eks. skifter navn. Identifikatorverdien skal ikke brukes om igjen hvis sertifikatinnehaver dør eller flytter ut av Norge.

Bruk av pseudonymer anbefales ikke. Hvis pseudonym skal brukes, kan det legges til som et ekstra attributt i subject-feltet. Unik subjekt-identifikator og vanlig brukt navn skal uansett finnes i sertifikatet.

Elektronisk ID for privatpersoner vil bestå av tre sertifikater. (Her avviker det fra det svenske forslaget til «Medborgarcertifikat», men er på linje med norsk arbeid i blant annet Forvaltningsnett og BankID.):

• Sertifikat for ikke-benekting (elektronisk signatur) med non-repudiation biten satt i keyUsage-feltet

• Sertifikat for autentisering med authentication biten satt i keyUsage-feltet

• Kryptering og transport av sesjonsnøkler med bitene keyEncipherment og/eller dataEnciphermentsatt i keyUsage-feltet.

Anvendelse av tre sertifikater kan være vanskelig for enkelte typer programvare, spesielt på klientsiden, men også på utstedersiden.

2.5 Profesjonssertifikat

Profesjonssertifikatet skal baseres på RFC 2459 og spesifikasjonene for kvalifiserte sertifikater. I tillegg har Forvaltningsnettsamarbeidet spesifisert krav til og innhold i profesjonssertifikater gjennom FSP-1.

Profesjonssertifikater er personlige sertifikater som knytter en person til et bestemt yrke/utdanning og til en eventuell autorisasjon eller godkjenning fra en myndighet eller en organisasjon.

Profesjonssertifikatene skal ha et unikt nummer som angir profesjonsrettigheten, samt et tittelfelt som gir en tekstlig (menneskelig lesbar) beskrivelse av profesjonen.

Et profesjonssertifikat kan betraktes som en kombinasjon av identitetssertifikat og autorisasjonssertifikat.

Profesjonssertifikatet er spesifisert uavhengig av valgt lagringsmedium for nøkler.

Profesjonssertifikatet skal inneholde et «profesjonsnummer» som definerer innehaveren unikt innenfor en nærmere angitt mengde «profesjonelle», f.eks. innenfor alt registrert helsepersonell i Norge. Profesjonssertifikatet gir således vedkommende en unik identifikasjon innenfor innehaverne av et gitt yrke, men ikke en unik identifikasjon som person hele befolkningen tatt i betraktning.

Elektronisk profesjons-ID kan bestå av tre sertifikater:

• Sertifikat for ikke-benekting (elektronisk signatur) med non-repudiation-biten satt i keyUsage-feltet

• Sertifikat for autentisering med authentication-biten satt i keyUsage-feltet

• Kryptering og transport av sesjonsnøkler med bitene keyEncipherment og/eller dataEnciphermentsatt i keyUsage-feltet.

Anvendelse av tre sertifikater kan være vanskelig for enkelte typer programvare, spesielt på klientsiden, men også på utstedersiden.

Som en del av diskusjonen rundt profesjonssertifikater bør det avklares i hvilken grad innehaveren skal ha anledning til å benytte sertifikatene og nøklene til rent privat bruk.

Som et alternativ til å definere profesjonssertifikater kan det brukes identitetssertifikater eller ansattsertifikater, og man kan i stedet lagre informasjon om innehavers profesjon og rettigheter i et sentralt, tilgjengelig register. Imidlertid må det da finnes klientprogramvare som klarer å kombinere informasjon i sertifikatene med informasjon i det andre registeret.

Det foreslåtte profesjonssertifikatet skiller seg fra forslaget i FSP-1 ved at den ansattes fullstendige navn slik dette er registrert i folkeregisteret, er fjernet fra subjectAltName. Det burde ikke være nødvendig å ha med mellomnavn som aldri brukes, etc. i et slikt sertifikat.

I stedet åpnes det for at man i feltet subjectAltName kan legge inn e-postadresse eller web-adresse til den institusjonen som har autorisert sertifikatinnehaver (f.eks. Statens helsetilsyn).

Et annet avvik fra FSP-1 er at attributtet SerialNumber brukes i subject til å angi den unike referansen (f.eks. et unikt nummer) som angir profesjonsrettighetene for innehaveren.