Ändringar i utfärdande av HCC Funktion

Ändringar i utfärdande av HCC Funktion

Varför? I WebTrust-revisionen har SITHS fått följande anmärkningar som måste åtgärdas om vi ska följa det globala regelverket: Efter 2017-01-01 får inga giltiga certifikat använda HASHalgoritmen SHA-1 på grund av risken för kollisioner. Risken innebär att två olika certifikat kan se likadana ut elektroniskt Detta skulle kunna utnyttjas för att tillverka ett förfalskat certifikat Sannolikheten för att risken inträffar ökar i och med att datorer blir allt kraftfullare och lättare kan räkna ut dessa kollisioner. Endast mottagaren av certifikatet ska hantera den privata nyckeln. PKCS#12 bör inte användas längre

Vad? Nedstängning av SITHS Type 2 CA v1, då den: Utfärdar certifikat med SHA-1 Tillåter PKCS#12

Konsekvenser av att SITHS Type 2 CA v1 tas bort SHA-1 ersätts med SHA-512 PKCS#12 upphör endast PKCS#10 blir kvar Skillnader och likheter mellan PKCS#10 och PKCS#12

Vad är ett certifikat?

Ett certifikat består av två delar En publik del med information om innehavaren Innehåller också en publik nyckel En privat del som består av den privata nyckeln. Vilken endast innehavaren av certifikatet ska känna till. Attribut Serienummer Subjekt/Certifikatobjekt Publik Nyckel Utfärdare Giltig från Giltig till Med mera Slumpmässigt unikt värde Namn, HSA-id, e-post etc Matematiskt beräknad sträng SITHS Type 2 CA v1 Ex. 2013-01-01 Ex. 2017-12-01 UPN, e-post etc.

Identifiering med certifikat Tjänsten och nyckelinnehavaren utbyter sina publika nycklar Tjänsten krypterar information med innehavarens publika nyckel och skickar tillbaka till innehavaren Innehavaren dekrypterar informationen med hjälp av sin privata nyckel Innehavaren krypterar informationen med tjänstens publika nyckel och skickar tillbaka till tjänsten som dekrypterar den.?????? Hemligt Hemligt?????? Hemligt

Skillnader och likheter mellan PKCS#10 och PKCS#12

PKCS#12 - Distribution PKCS#12 kan ses som en zip-fil innehållande: Den privata nyckeln Certifikatet med den publika nyckeln Nackdelen är att den privata nyckeln hanteras av andra personer än den som förvaltar systemet den ska till: Skapas av CA:n Skickas till xra Skickas till Systemförvaltare RA/ORA SITHS CA Installeras på server Systemförvaltare

Vad är en CSR-fil En CSR-fil kan ses som en undertecknad beställning/förstadie av ett certifikat. CSR-filen innehåller samma publika nyckel som sedan används i certifikatet För att beräkna den publika nyckeln måste man använda den privata nyckeln CA:n tar den publika nyckeln från CSR-filen och skapar ett certifikat. Den publika nyckel som används i ett Certifikat passar alltså bara ihop med just den CSR-fil och privata nyckel som skapades i samband med beställningen CSR skapas mha. privat nyckel CSR skickas via xra till CA CSR En publik nyckel hänger matematisk ihop med en privat nyckel. CA skapar certifkatet med samma publika nyckel

PKCS#10 - Distribution PKCS#10 är en standard för hur begäran om att signera ett certifikat (CSR-fil) ska se ut. Nyckelinnehavaren skapar en privat nyckel och en CSR inklusive publik nyckel CSR ges till xra xra skickar publik nyckel till CA CA signerar certifikatet inklusive den publika nyckeln xra skickar tillbaka certifikatet till nyckelinnehavaren CSR RA/ORA CSR SITHS CA Installeras på server Systemförvaltare CSR

Skillnader mellan PKCS#10 och #12 P10 och P12 är olika beställningsmetoder inte olika typer av certifikat. P10 SITHS Admin skapar bara certifikatet baserat på den CSR-fil organisationen laddar upp. Den privata nyckeln behöver aldrig lämna den egna organisationen. P12 SITHS Admin skapar den privata nyckeln och paketerar den tillsammans med certifikatet. P10 har ingen säkerhetskod som skickas med krypterad e-post P10 Ansvaret för den privata nyckeln hamnar helt hos beställare/nyckelinnehavare P10 Beställaren har själv möjlighet att packa ihop certifikat och privat nyckel till PKCS#12/PFX eller annat format vid flytt.

Likheter mellan PKCS#10 och #12 Certifikatet och dess struktur är i sig likadant Pga. att vi stänger av Type 2 ändras dock: Utfärdaren till Type 3 HASH-algoritmen från SHA-1 till SHA-512 Det är fortfarande HSA-katalogen som bestämmer innehållet i certifikatets subjekt Andra exempel då SITHS använder PKCS#10 Då SITHS-kort skapas skickas en CSR enligt PKCS#10 från Gemalto till SITHS CA. Detta eftersom den privata nyckeln ligger på kortet och är skyddad av pin-koderna

Hur ser en PKCS#12 fil ut Privat nyckel Certifikat Publik nyckel

Ändrad rutin för domänvalidering

Varför? I WebTrust-revisionen har SITHS fått följande anmärkningar som måste åtgärdas om vi ska följa det globala regelverket: Vi får inte lita på inskickat material vid domänvalidering, ex. fakturaunderlag, utdrag från IIS och delegationsordning Domänvalidering måste göras enligt någon av de i WebTrust-regelverket godkända metoderna. E-postadress som skrivs i certifikatet måste kontrolleras Vi måste validera landskoden som skrivs i certifikatet Vi måste ha möjlighet att svartlista domännamn Övriga ändringar Avregistrering av validerade domännamn Om det går att lägga till bör det gå att ta bort.

Vad? Förändrad domänvalideringsrutin Blanketterna: Fullmakt och Anmälan uppdateras för att stämma med ändringarna i rutinen.

Förändrad domänvalideringsrutin Ni skickar bara in blanketten, Anmälan om domän- och e-postvalidering Validering utförs genom motringning eller mail för att kontrollera att ägaren av domännamn/e-postadress godkänner att SITHScertifikat får utfärdas. Om domännamnet ägs av annan organisation skickar ni fortfarande in en fullmakt från organisationen. Validering utförs genom motringning till företagsväxeln för den organisation som äger domännamnet. Vi kommer be att få tala med den som skrivit under fullmakten.

En rad per typ av validering Både anmälningsblankett och fullmakt uppdateras med egna rader för validering av typerna Generellt domännamn (alla subdomäner till ex. inera.se www.inera.se, mail.inera.se, test.inera.se etc.) Specifikt domännamn (specifika subdomäner till ex. inera.se bara www.inera.se och hsa.inera.se) Specifik e-postadress (specifika e-postadresser till ex. siths@inera.se och sithspolicyauthority@inera.se)

Validering av e-post Blanketten Anmälan om domän och e-postvalidering innehåller nu också fält för e-post. Om ni använder funktionscertifikat för att skicka signerade mail från exempelvis funktionsbrevlådor måste e-postadressen valideras. Validering görs genom att ett mail skickas till e-postadressen i fråga och vi förväntar oss ett svar på frågan i det mailet.

Validering av land Valideringen görs genom kontroll av att organisationen som äger domännamnet är registrerat i Sverige.

Spärr av domännamn Det finns nu ett formulär kallat Spärr av domännamn på www.inera.se under Regler, rutiner, processer Här kan en organisation ansöka om att SITHS-certifikat inte ska få utfärdas på ett domännamn som de äger Validering av ägarskap kommer att utföras på samma sätt (e-post eller motringning) som när ett tillägg av domännamn görs. Leder också till avregistrering av validering och spärr av eventuella utgivna certifikat för spärrade domännamn.

Avregistrering av validering Tillägg av möjlighet att avregistrera domänvalideringar Medför att samtliga utfärdade certifikat för domännamnen revokeras om de utfärdats av den organisation där domänvalideringen avregistreras. Fullmakt