Bakgrunn

Buypass innfører Extended Key Usage (EKU) i alle virksomhetssertifikater og personsertifikater fra 1.februar 2019. Dette blir gjort for å tilfredsstille krav fra aktører som Microsoft samt følge beste praksis for digitale sertifikater i hht RFC 5280 standarden.

Vi benytter allerede EKU i TLS-sertifikater siden dette er et eksplisitt krav til denne type sertifikater. For virksomhetssertifikater og personsertifikater finnes det ikke tilsvarende krav i relevante standarder, men vi legger nå inn EKU i alle slike sertifikater.

Person- og virksomhetssertifikater utstedes gjerne i par som består av:

• autentiseringssertifikat - med bruksområde autentisering og/eller kryptering
• signeringssertifikat - med bruksområde signering (i betydning ikke-benekt)

Vi legger inn et sett med standard EKU verdier i begge sertifikater for både person- og virksomhetssertifikater. Settet med EKU-verdier vil kunne utvides ved behov. 

Dette innebærer en justering av innholdet i våre sertifikater og vi anser ikke dette for å utgjøre noen vesentlig risiko for våre kunder eller brukere av sertifikatbaserte løsninger. 

EKU for virksomhetssertifikater

Vi tar i bruk EKU = ClientAuth og SecureEmail som standardverdier både i autentisering- og signeringssertifikatet.

Dersom kunde genererer nøkkel selv vil vi bruke EKU = ClientAuth, ServerAuth og SecureEmail.

EKU for personsertifikater

Vi tar i bruk EKU = ClientAuth og SecureEmail som standardverdier både i autentisering- og signeringssertifikatet. 

Om Key Usage og Extended Key Usage (EKU) 

RFC 5280 er en standard som definerer struktur og innhold i X509-sertifikater og utgjør grunnlaget som alle andre sertifikat-standarder bygger videre på.

I flg RFC 5280 er Key Usage og EKU (Extended Key Usage) begge sertifikatutvidelser eller attributter som sier noe om hensikten med nøkkelen som sertifikatet er utstedt på. 

Key Usage

Key Usage er obligatorisk og alle sertifikater som skal være compliant med RFC 5280 må inneholde denne, 

Key Usage er kun en streng med bits og RFC 5280 definerer følgende Key Usage bits:

KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

Alle Buypass' sertifikater inneholder Key Usage, for CA-sertifikater benytter vi keyCertSign og cRLSign, mens for sluttbrukersertifikater benytter vi typisk kombinasjoner av digitalSignature, keyEncipherment og keyAgreement (for autentisering/kryptering) eller nonRepudiation (for signering).

Her ser vi eksempler på hhv autentiseringssertifikat og signeringssertifikat fra et av våre ansattkort:

EKU (Extended Key Usage)

I hht RFC 5280 er EKU optional og benyttes hovedsaklig i sluttbrukersertifikater. Dersom sertifikatet inneholder EKU, så må applikasjoner som forholder seg til sertifikatet ikke tillate at sertifikatet brukes til andre formål enn det som er angitt i EKU. Dette kan derfor begrense bruksområdet for sertifikater unødvendig i en del sammenhenger.

Hvilken som helst organisasjon kan definere "EKU verdier" i form av såkalte OID-er (Object IDentifier). EKU inneholder derfor gjerne et sett med slike OID-er som definerer hensikten med sertifikatene i mer detalj enn Key Usage gjør. 

Eksemplet under viser hht Key Usage og EKU for et TLS-sertifikat, i dette angir EKU at TLS-sertifikatet kan brukes for autentisering av klient eller server (i TLS-protokollen).

Microsoft benytter forøvrig termen Enhanced Key Usage om EKU i stedet for Extended Key Usage. 

EKU definert i RFC 5280

RFC 5280 definerer følgende EKU OID-er:

The following key usage purposes are defined:

   anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

   id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

   id-kp-codeSigning             OBJECT IDENTIFIER ::= { id-kp 3 }
   -- Signing of downloadable executable code
   -- Key usage bits that may be consistent: digitalSignature

   id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }
   -- Email protection
   -- Key usage bits that may be consistent: digitalSignature,
   -- nonRepudiation, and/or (keyEncipherment or keyAgreement)

   id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
   -- Binding the hash of an object to a time
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or nonRepudiation

   id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
   -- Signing OCSP responses
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or nonRepudiation