Enkelt certifikatregistreringsprotokoll

  Simple Certificate Enrollment Protocol (SCEP) beskrivs av den informativa RFC 8894 . Äldre versioner av detta protokoll blev en de facto industriell standard för pragmatisk tillhandahållande av digitala certifikat mestadels för nätverksutrustning.

Protokollet har utformats för att göra begäran och utfärdandet av digitala certifikat så enkelt som möjligt för alla vanliga nätverksanvändare. Dessa processer har vanligtvis krävt intensiv input från nätverksadministratörer och har därför inte varit lämpade för storskaliga distributioner.

Popularitet

Simple Certificate Enrollment Protocol är fortfarande det mest populära och allmänt tillgängliga certifikatregistreringsprotokollet, som används av många tillverkare av nätverksutrustning och programvara som utvecklar förenklade sätt att hantera certifikat för storskalig implementering till vardagliga användare. [ citat behövs ] Det används till exempel av operativsystemet Cisco IOS ( även om Cisco nu trycker på den lite mer utvalda EST ) och iPhones för att registrera sig i företags PKI . De flesta PKI-programvara (speciellt RA-implementeringar) stöder det, inklusive Network Device Enrollment Service (NDES) för Active Directory Certificate Service och Intune .

Kritik

  • Äldre versioner av SCEP, som fortfarande används i de allra flesta implementeringar, är begränsade till att endast registrera certifikat för RSA-nycklar.
  • På grund av användningen av det självsignerade PKCS#10-formatet för Certificate Signing Requests (CSR), kan certifikat endast registreras för nycklar som stöder signering. En begränsning som delas av andra registreringsprotokoll baserade på PKCS#10 CSR:er, t.ex. EST och ACME , eller till och med det webbaserade registreringsarbetsflödet för de flesta PKI-programvara där begäranden börjar med att generera ett nyckelpar och en CSR i PKCS#10-format. CRMF-formatet, som det används av CMP och CMS, är mer flexibelt här och stöder även nycklar som endast kan användas för kryptering eller nyckelavtal. Denna distinktion är dock mestadels teoretisk eftersom i praktiken alla algoritmer som vanligtvis används med certifikat stöder signering. Till exempel ACME , som också använder PKCS#10, utfärdar TLS-certifikat som per definition måste kunna signera för TLS-handskakning.
  • Även om ursprungsbevis för certifikatregistreringsförfrågningar, dvs. autentisering av certifikatbegäraren, är det mest kritiska säkerhetskravet, krävs av pragmatiska skäl inte dess stöd strikt inom SCEP. Signaturbaserad klientautentisering med ett redan existerande certifikat skulle vara den föredragna mekanismen, men i många användningsfall är den inte möjlig eller stöds inte av de givna distributionerna. Som ett alternativ tillhandahåller SCEP bara användningen av en delad hemlighet, som bör vara klientspecifik och endast användas en gång.
  • Sekretessen för den delade hemligheten som eventuellt används för källautentisering är bräcklig eftersom den måste inkluderas i fältet 'challengePassword' i CSR, som sedan skyddas av en yttre kryptering. Det hade varit säkrare att använda en lösenordsbaserad MAC-algoritm som HMAC.
  • Att kryptera hela PKCS#10-strukturen för att skydda fältet "challengePassword" (som används för fristående källautentisering) har ytterligare en nackdel: hela CSR blir oläsligt för alla parter förutom den avsedda slutgiltiga mottagaren (CA), även om det mesta av dess innehåll inte är konfidentiellt. Så PKCS#10-strukturen kan inte kontrolleras av mellanliggande agenter som en RA.

Historia

  SCEP designades av Verisign för Cisco som ett smidigt alternativ till Certificate Management over CMS (CMC) och det mycket kraftfulla men också ganska skrymmande Certificate Management Protocol (CMP). Runt 2010 Cisco arbetet med SCEP och utvecklade istället EST . 2015 återupplivade Peter Gutmann Internet Draft på grund av SCEPs utbredda användning inom industrin och i andra standarder. Han uppdaterade utkastet med modernare algoritmer som korrigerade många problem i den ursprungliga specifikationen. I september 2020 publicerades utkastet som informativ RFC 8894 , mer än tjugo år efter starten av standardiseringsarbetet. Den nya versionen stöder även registrering av icke-RSA-certifikat (t.ex. för ECC- nycklar).

Se även

externa länkar