Det vises til Difis brev av 7. juli 2009 der utkast vil versjon 2.0 av kravspesifikasjon for PKI i offentlig sektor ble sendt ut til uttalelse.
 
BankID Norge har på anmodning fra FNH og Sparebankforeningen koordinert norske bankers synspunkter på forslaget og gir med dette uttalelse på vegne av norsk banknæring.
 
Vi viser i denne sammenheng til at de fleste banker har utstedt BankID til de aller fleste av sine nettbankkunder og stadig flere tar i bruk innlogging i nettbank med BankID. Det er i dag mer enn 2,3 millioner BankID-sertifikater i markedet. BankID er meldt som kvalifisert sertifikat til Post- og teletilsynet og selvdeklarert til samme instans i sikkerhetsklasse Person-Høyt. BankID Norge er ansvarlig for drift og forvaltning av BankID på vegne av bankene som er med i BankID samarbeidet.   BankID Norge er opprettet og eies av Sparebankforeningen og Finansnæringens Hovedorganisasjon.
 
 
Med vennlig hilsen
 
 
Semming Austin
Daglig Leder
BankID Norge
 
 
Vedlegg  A. Generelle kommentarer                
B. Spørsmål stilt i høringsbrevet                 
C. Kommentarer til de enkelte punktene i spesifikasjonsutkastet

_______________
 
 
 
 A. Generelle kommentarer
Det fremgår av Difis oversendelsesbrev av kravspesifikasjonen både fastsetter felles krav til sikkerhet for PKI-løsninger til det offentlige og dessuten vil inngå i konkurransegrunnlaget for offentlige anskaffelser. For egen del antar vi likevel at det er de sikkerhetsmessige forhold som er dominerende formålet med spesifikasjonen. Vi forstår at kravspesifikasjonen har hatt slik dobbelt funksjon også tidligere, men er usikre på om dette er heldig. Vi holder det for sannsynlig at selv om forskjellige offentlige etater har behov for samme sikkerhetsnivå på sin PKI-løsning, vil det lett være forskjeller mellom disse etatene mht krav til ytelse og forretningsmessige forhold. Det vil oppfattes som ryddigere om krav av ytelsesmessige/kapasitetsmessige forhold er skilt ut og blir spesifikke for den enkelte anskaffelse.
 
Kravspesifikasjonen har en viktig rolle som grunnlaget for selvdeklarering hos Post- og teletilsynet etter forskrift 21. november 2005 om frivillige selvdeklareringsordninger. En slik selvdeklarering har betydning for om sertifikatet kan brukes i andre sammenhenger enn i offentlig forvaltning. For eksempel kreves det at en eID er selvdeklarert som Person-Høyt for at den skal kunne anvendes for legitimasjonskontroll etter hvitvaskingsloven. Etter forskrift om selvdeklarasjonsordningen må alle A-krav (absolutte) i kravspesifikasjonen være oppfylt for å kunne selvdeklareres som Person-Høyt. I høringsbrevet fremgår at utkastet til kravspesifikasjon i større grad enn tidligere inneholder "obligatoriske" krav. Vi kjenner ikke igjen begrepet "obligatoriske" krav fra kravspesifikasjonen, men antar at man her mener absolutte krav, altså A-krav. Dette innebærer i så fall at det etter revisjonen av kravspesifikasjonen vil være flere og nye krav til den som vil selvdeklarere seg hos Post- og teletilsynet. Vi savner noe mer fokus på dette forholdet i høringssaken.
 
Det forhold at kravspesifikasjonen fyller flere funksjoner uten at man tydeligere skiller mellom de forskjellige formål, kan også skape uklarheter med hensyn til krav om dokumentasjon for oppfyllelse av kravene. Det er akseptabelt at sertifikatutsteder i forbindelse med en selvdeklarering overfor Post- og teletilsynet dokumenterer at kravene er oppfylt. Derimot er mye av dokumentasjonen som kreves ifølge kravspesifikasjonen av en slik art at den ikke bør spres for vidt. Det kan for eksempel være uheldig om dokumentasjonen må utleveres bredt til offentlige etater i en anskaffelsessituasjon. I forbindelse med en anbudsprosess bør etaten som skal anskaffe en PKI-løsning derfor kunne nøye seg med at forholdet er dokumentert overfor Post- og teletilsynet.
 
Fordi kravspesifikasjonen også legger rammene for selvdeklareringsordningen er det viktig at det i forbindelse med endringer i spesifikasjonen gis overgangsregler for de som har selvdeklarert seg i henhold til den eksisterende kravspesifikasjonen. Blant annet er det vesentlig for de som har selvdeklarert seg etter eksisterende regler at de ikke må inngi en ny fullstendig selvdeklarering, men bare behøver å gi tilleggsinformasjon for eventuelle nye eller endrede krav. En slik løsning forutsetter at det er mulig å identifisere det som er revidert eller nytt i den reviderte kravspesifikasjonen.
 
I forslaget til revidert kravspesifikasjon innføres et nytt krav i punkt 4.9.2.1 og 4.9.3.1 for virksomhets- og ansattesertifikater om at utsteder skal tilbakekalle sertifikatet innen en dag etter at det skjer en endring i virksomhetens "tilstand". Vi er usikre på hva som ligger i begrepet "tilstand" - om det omfatter enhver endring, eller om det bare gjelder opphør for eksempel ved konkurs. Dette kravet antar vi både vil kunne være svært kostnadskrevende å etterleve samtidig som vi ikke kan se at dette naturlig bør høre under en sertifikatutsteders ansvarsområde å føre slik nitidig kontroll med om sertifikatinnehaver "lever" eller er "død". Det vises også til vår særlige merknad til dette punktet.
 
Vi nevner ellers en skjønnhetsplett i kravspesifikasjonen. Det synes som at man har endret omtalen av sertifikatutsteder fra "leverandør" til "sertifikatutsteder". Man har imidlertid ikke lykkes med dette alle steder, slik at en del steder i kravspesifikasjonen opererer man fortsatt med begrepet "leverandør" i sammenhenger der vi oppfatter at det menes "sertifikatutsteder". 
 
B. Spørsmål stilt i høringsbrevet
Difi har stilt åtte konkret spørsmål i høringsbrevet. Nedenfor gir vi svar på disse, eventuelt peker på hvor i vår høringsuttalelse vi har besvart spørsmålet:
 
1. Spørsmålet om åpenhet er delvis et spørsmål om forretningsmodell og delvis et spørsmål om sikkerhet. BankID er en lukket, avtalebasert PKI der Sertifikatpolicy definerer bruksområdene for BankID sertifikater. BankID sikkerhetsprotokoller er utviklet med hensyn til bruksområdet og det tilhørende trusselbildet. Bruk av BankID utenfor definert bruksområde eller uten BankID protokoller vil derfor ikke kunne gi den samme sikkerheten.
2. Det vises til våre kommentarer til kravspesifikasjonen punkt 4.2 nedenfor.
3. Det vises til våre generelle kommentarer over der vi er skeptiske til den sammenblandingen av sikkerhetsmessige krav og andre krav. Vi mener krav til oppetid ikke skal settes generelt, men settes ut fra behovet som den enkelte tjeneste har.
4. BankID samarbeidet vurderer kravene i ETSI TS 101 456 som relevante og gode.
5. Kravet om statustjeneste i form av CRL vil ikke kunne oppfylles av BankID. Årsaken er at BankID er bygget opp med OCSP som basisprotokoll for en "relying party" som vil kontrollere om et sertifikat er gyldig. Det er ikke tilrettelagt teknisk for at "relying party" skal kunne be om en CRL tilknyttet et sertifikat. Det vil heller ikke være praktisk gjennomførbart å endre løsningen, blant annet er flere BankID CRL’er så store at et CRL-basert oppslag vil være ineffektivt. Imidlertid vil det kunne legges til rette for å hente CRL’er fra arkiv ved særlige behov, for eksempel i en tvistesituasjon der gyldighet av sertifikat er sentralt.
6. Vi oppfatter dette som et fornuftig krav og som vil være med på å bevistgjøre brukeren.
7. BankID Samarbeidet er enig i intensjonen med dette kravet og at man strekker seg så langt som mulig i denne retningen, men det vil kunne være attributter som man ikke ser.
8. For sertifikatutstedere som allerede har selvdeklarert seg vil det være behov for et minimum av tid fra ny kravspesifikasjon er kjent og til man må levere tilleggsinformasjon. Hvor lang tid som er nødvendig er avhengig av kompleksiteten i det som skal leveres, herunder om man kan basere seg på allerede innlevert informasjon. Vi viser her til det som er sagt over i våre generelle kommentarer.

C. Kommentarer til de enkelte punktene i spesifikasjonsutkastet
Til de enkelte punktene i kravspesifikasjonen har vi følgende kommentarer:
 
2.2 Sikkerhetsnivåer, side 10, 2. avsnitt "Det er strengere sikkerhetskrav….."
I avsnittet henvises det til krav 7.3. Vi antar riktig henvisning er krav 7.2.
 
2.4 Forklaring til kravtabellen
Mange av punktene krever dokumentasjon fra sertifikatutsteder. Når man jobber med selvdeklarering hadde det vært oversiktlig dersom det for hvert krav i kategori-kolonnen fremgår at dokumentasjon skal leveres til PT. I tillegg kan det være hensiktsmessig med en egen kolonne "Dokumentasjon vedlagt", der sertifikatutsteder krysser av og ev legger inn henvisning til relevant vedlegg.
 
2.4 Forklaring til kravtabell s 12, "For krav merket som O (Opsjon)….."
I versjon 1.02 av kravspesifikasjon for PKI i offentlig sektor står det
"J         Ja         - betyr at kravet tilfredsstilles i en opsjon til tilbudet. Dersom opsjon utløses vil det medføre en spesifisert kostnad i tilegg til tilbudets pris. "
 
I høringsdokumentet er setningen markert med kursiv fjernet.
 
Det er etter vår mening fremdeles naturlig at opsjoner utløser spesifiserte kostnader i tillegg til tilbudets pris. Vi foreslår derfor at setningen settes inn igjen i den nye versjonen av kravspeken.
 
3.1 Begrepsavklaringer
- Registreringsenhet i Enhetsregisteret i PKI-sammenheng vil registreringsenhet kunne oppfattes som knyttet til registreringsautoritet (RA). For å øke lesbarhet foreslår vi derfor å erstatte begrepet registreringsenhet med registrert enhet.
- Sertifikatutsteder, første kolonne: Det bør legges til (CA) etter ordet sertifikatutsteder - tilsvarende slik det er gjort for "Registreringsautoritet (RA)"
 
 4.1.1.2 Sertifikat med bruksområde autentisering
Kravet er uklart formulert. Forslag til alternativ formulering: eID skal inneholde sertifikat og nøkkelpar med formål autentisering (key usage skal omfatte "digital signature")
 
4.1.3.1 Sertifikat med bruksområde elektronisk signatur

4.6.3.7 Entydig identifisering av underenhet
Kravet bør presiseres noe i forhold til utstedelse til underenheter, slik at det går klart frem hva som er kravene hvis sertifikater kun utstedes til registreringsenheter og ikke til underenheter. 
For eksempel:
 "For virksomheter registrert i Norge skal navn i sertifikatet kunne identifisere en registreringsenhet i Enhetsregisteret.
 
Dersom sertifikater utstedes til underenheter, skal på samme måte navnet i sertifikatet identifisere underenheten i Enhetsregisteret og attributtet "organisationalUnitName" i "Subject" feltet skal angi navn og ……
 
Kommentaren gjelder også for krav  4.6.3.7, som vi også foreslår formulert på samme måte Dersom sertifikat utstedes til underenheter….
 
4.2 Tilgang til sertifikatutsteders offentlige nøkler
Vi foreslår en justering av formuleringen i første setning, slik at den dekker ulike forretningsmodeller. Forslag til formulering:
Nødvendige utstedersertifikater for verifisering av utstedte sertifikater skal være tilgjengelig ved behov og skal distribueres på en sikker og tillitvekkende måte.
 
4.4.2.3 Beskyttelse av sertifikatinnehavers private nøkler
Vi ser at begrepet sikkerhetsstandard kan være vanskelig å tolke for løsninger med sentrallagrede nøkler. Vi foreslår derfor at det enten presiseres hvilke standarder som er relevante, eller at man justerer nest siste setning til :
 "Produktene skal være designet slik at de møter definerte sikkerhetskrav eller krav i en sikkerhets-standard".
 
For siste setning antar vi at hensikten med kravet var å redegjøre for revisjoner eller andre prosesser som er gjennomført. Forslag til formulering:
"Leverandøren skal fremlegge dokumentasjon på hvordan det sikres at kravene er oppfylt"
 
4.5.5 Bruk til pålogging
Vi foreslår at krav 4.5.3, 4.5.4 og 4.5.5 omformuleres slik at de fremstår som opsjonskrav.
 
For krav 4.5.5 bør det i tillegg presiseres hva som legges i "pålogging til virksomhetens IT-systemer".
 
4.6.1.4 Tekniske og organisatoriske løsninger for RA
Andre del av første setning lyder "…og hvordan disse kravene er oppfylt".
 
Vi antar hensikten er å redegjøre for revisjoner eller andre prosesser som er gjennomført og foreslår derfor at ordlyden endres til
"… og hvordan det kontrolleres at disse kravene er oppfylt"
 
4.6.2.4 Tekniske og organisatoriske løsninger for RA
Samme kommentar som under 4.6.1.4
 
4.6.3.4 Tekniske og organisatoriske løsninger for RA
Samme kommentar som under 4.6.1.4
 
4.6.3.7  Entydig identifisering av underenhet
Se kommentar til nr 4.1.3.1
 
4.8.1.6 Integrasjon med signeringsprogramvare - virksomhetssertifikater
Dette kravet bør utdypes. Er det tilgang til nøkler og bruk av nøkler som skal være åpent? Dette bør ses i lys av de begrensninger i bruksområde som fremkommer i den aktuelle sertifikatpolicy.
Vi mener at kravet slik det står nå beveger seg langt inn på området forretningsmodell og ikke har noen klar PKI-messig begrunnelse. Vi ber derfor om at dette blir et B-krav.
 
4.8.1.8  Integrasjonspakker - virksomhetssertifkater
I teksten til kravet står det "leverandøren bør" - kravet burde derfor være av typen B.
 
For øvrig gjelder samme kommentar som under 4.8.1.6, kravet går direkte inn i forretningsmodeller og bør plasseres utenfor denne kravspesifikasjonen.
 
4.8.2.2 Spesifikasjon av integransjonspakker
Det hadde blitt mer tydelig dersom man først hadde et opsjonskrav "Det skal angis om sertifikatutsteder tilbyr integrasjonspakker". Dersom man svarer ja på dette kravet, må man forholde seg til kravene nedenfor.
 
4.9.2.1 Tilbakekalling av virksomhetssertifikater
Kravet er kostnadsdrivende.  De praktiske og rettslige konsekvensene av en slik ordning er ikke utredet.
 
4.9.3.1 Tilbakekalling av ansattesertifikater
Kravet er kostnadsdrivende. De praktiske og rettslige konsekvensene av en slik ordning er ikke utredet.
 
5.2.3 Protokoll for tilbakekallingslister
Vi mener at sikkerhetsmålsetningen i innledningen kan oppfylles på andre måter enn ved CRL-tjeneste slik som spesifisert. Vi foreslår derfor at kravet justeres noe, slik at det er tilstrekkelig om aktuelle CRL’er er tilgjengelige på forespørsel. For eksempel med tillegg av følgende setning:
"For tjenester som tilbyr OCSP-grensesnitt mot katalog, skal aktuelle CRL’er kunne være tilgjengelig på forespørsel".
 
5.2.4 Begrensninger i tilgang
Vi viser til kommentaren under 5.2.3
 
5.4.1 Sertifikatkatalog over ldap
Kravet er primært relevant for krypteringssertifikater. For autentisering eller signering er det ikke behov for katalogoppslag hvis sertifikatet alltid legges ved signaturer mv.
 
PTs tolkning har tidligere vært at dette kravet gjelder kun dersom krypterings-sertifikater tilbys. Kravet foreslås derfor flyttet til kap 8, sammen med 5.4.2, 5.4.5 og 5.4.8
 
5.4.2 Skjema og søkemuligheter
Samme forslag som punkt 5.4.1
 
5.4.5 Ekstra distribusjonspunkter for katalog
Samme forslag som punkt 5.4.1
 
5.4.8 Kobling til organisasjonsnummer
Samme forslag som punkt 5.4.1
 
5.5.1 Tilgang til sertifikatstatus
Muligheten til å inngå felles avtale anser vi ikke at har noe i en selvdeklarasjon å gjøre. Dette er isteden et merkantilt forhold som bør flyttes til den enkelte anskaffelse.
Andre setning lyder "Slikt oppslag skal ikke kreve installasjon av programvare som er spesifikk for sertifikatutstederen". Vi kan ikke se den PKI-messige begrunnelsen for dette kravet. Kravet nærmer seg forretningsmodell og takseringsprinsipper og bør som sådan ikke inngå i et generelt kravdokument. Vi ber om at siste setning fjernes.
 
5.5.2 Tilgang til katalog og oppslagstjenester
Muligheten til å inngå felles avtale anser vi ikke at har noe i en selvdeklarasjon å gjøre. Dette er isteden et merkantilt forhold som bør flyttes til den enkelte anskaffelse.
 
6 Autentiseringstjenester og kanalsikkerhet
Vi ønsker at begrepet kanalsikkerhet presiseres ytterligere. Omfatter det selve autentiseringen eller også videre sesjon mot web-tjeneste?
 
Videre er det uklart om kanalsikkerhet er en forutsetning for å levere autentiseringstjenester. Dette bør presiseres tydeligere.
 
Vi foreslår at kravene i dette kapitlet utformes mer som teknologiuavhengige sikkerhetskrav, slik at det fremkommer tydeligere hva som ønskes oppnådd med kravene.
 
9.1.6 TSA s virksomhetssertifikat
Vi stiller spørsmålstegn ved om dette er et hensiktmessig krav eller om det vil redusere antall aktuelle leverandører unødig?