Delegerade referenser för TLS

Avsluta a TLS anslutningen kräver att ett certifikats privata nyckel används. Som ett resultat måste den privata nyckeln lagras på varje enskild server som används av en tjänst. Skyddet av denna privata nyckels sekretess är avgörande för att ett system för offentlig nyckelinfrastruktur ska fungera smidigt. En enhet som har den privata nyckeln kan utföra man-in-the-middle-attacker under återstoden av certifikatets giltighetstid. Vanligtvis, när en angripare äventyrar en privat nyckel, återkallas certifikatet som är kopplat till denna nyckel och ett nytt utfärdas. Men för företag som använder flera servrar, som Facebook eller

” för servrarna som anger att de är auktoriserade avsluta TLS anslutning.

"En begränsad delegeringsmekanism som tillåter en TLS peer att utfärda sina egna referenser inom ramen för ett certifikat utfärdat av en extern CA. Dessa referenser gör det bara möjligt för mottagaren av delegationen att tala för namn som CA har godkänt."

Delegerade inloggningsuppgifter är utformade med syftet att öka säkerheten. Därför har de vissa egenskaper, enligt definitionen i IEFT-utkastet.

• Den maximala giltighetstiden för en delegerad legitimation är sju (7) dagar för att minimera exponeringen om den privata nyckeln äventyras. Den korta giltighetstiden innebär inte att säkerheten för delegerad legitimation ska tas lätt på. Åtgärder som vidtas för att skydda den privata nyckeln för slutenhetscertifikatet bör även gälla skyddet av DC. Dessa inkluderar bland annat filsystemkontroller, fysisk säkerhet och hårdvarusäkerhetsmoduler. Dessutom bör delegerade referenser endast användas mellan parter som delar någon förtroenderelation med varandra.
• De delegerade referenserna är kryptografiskt bunden till slutenhetscertifikatet. Specifikt används den privata nyckeln för slutenhetscertifikatet för att beräkna DC:s signatur via en algoritm som specificeras av referensen. Signaturen binder effektivt DC till namnen på slutenhetscertifikatet.
• Delegerade referenser utfärdas av klienten, vilket är mycket enklare än att skapa ett certifikat signerat av en CA. Klientutfärdade certifikat är också till hjälp för att hålla tjänsten fungerande även om CA har ett stillestånd. Organisationer kan också experimentera med algoritmer som inte officiellt stöds av CA utan att äventyra säkerheten för slutenhetscertifikatet. 
• Delegerade referenser har per definition korta giltighetsperioder. När servrar ställer in livstiden för delegerade autentiseringsuppgifter måste servrar ta hänsyn till klientklockans snedställning för att undvika att certifikat avvisas. Klientens klockskevning är också viktig för det ursprungliga certifikatet men är avgörande för den kortlivade delegerade privata nyckeln. Kundens klockskevning bör beaktas både i början och slutet av giltighetsperioden.
• Det finns ingen återkallelsemekanism för delegerade autentiseringsuppgifter. De görs ogiltiga när giltighetstiden löper ut. Återkallelse av den privata nyckeln för slutenhetscertifikatet (som används för att signera de delegerade autentiseringsuppgifterna) återkallar dock implicit den delegerade autentiseringsinformationen. 
• Delegerade autentiseringsuppgifter är utformade för att användas i TLS 1.3 eller senare. Det finns en känd sårbarhet när TLS 1.2-servrar stöder utbyte av RSA-nyckel, vilket möjliggör förfalskning av en RSA-signatur över ett godtyckligt meddelande. Anta att en angripare kan förfalska en signatur. I så fall kan de skapa förfalskade delegerade autentiseringsuppgifter för hela giltighetsperioden för slutenhetscertifikatet. Denna sårbarhet finns inte i implementeringar av TLS 1.3 eller senare. Sårbarheten påverkar inte heller certifikat med elliptisk kurvkryptografi, vilket SSL.com ger. 
• Organisationer kan använda befintliga API:er för automatisk utfärdande som ACME för att leverera delegerade autentiseringsuppgifter. I det här fallet är algoritmerna som används endast de som stöds av CA, men denna praxis minskar möjligheten för viktiga kompromisser. SSL.com stöder denna praxis. 
• Delegerade autentiseringsuppgifter kan inte återanvändas i flera sammanhang. Utfärdande parter beräknar signaturen med hjälp av en kontextsträng som är unik för den avsedda rollen (klient eller server), vilket gör det omöjligt att använda samma delegerade autentisering för klient- och serverautentisering. 

använder ECDSA för att implementera PKI erbjöd sig klienter, delegerade referenser utfärdade av våra kunder är inte sårbara för signaturförfalskningsattacker, som beskrivs ovan.