Delegerte legitimasjon for TLS

Avslutning av a TLS tilkobling krever bruk av et sertifikats private nøkkel. Som et resultat må den private nøkkelen lagres på hver enkelt server som brukes av en tjeneste. Beskyttelsen av denne private nøkkelens hemmelighold er avgjørende for en jevn drift av et offentlig nøkkelinfrastrukturopplegg. En enhet i besittelse av den private nøkkelen kan utføre man-in-the-middle-angrep for resten av sertifikatets gyldighet. Vanligvis, når en angriper kompromitterer en privat nøkkel, tilbakekalles sertifikatet knyttet til denne nøkkelen, og en ny utstedes. Men for bedrifter som bruker flere servere, som Facebook eller

” for serverne som indikerer at de er autorisert til avslutte TLS tilkobling.

"En begrenset delegeringsmekanisme som tillater en TLS peer til å utstede sin egen legitimasjon innenfor rammen av et sertifikat utstedt av en ekstern CA. Disse legitimasjonene gjør det bare mulig for mottakeren av delegasjonen å snakke for navn som CA har autorisert."

Delegert legitimasjon er utformet med det formål å øke sikkerheten. Derfor har de visse egenskaper, som definert i IEFT-utkastet.

• Den maksimale gyldighetsperioden for en delegert legitimasjon er syv (7) dager for å minimere eksponeringen hvis den private nøkkelen kompromitteres. Den korte gyldighetsperioden betyr ikke at sikkerhet for delegert legitimasjon skal tas lett på. Tiltak som er tatt for å beskytte den private nøkkelen til endeenhetssertifikatet bør også gjelde for beskyttelse av DC-er. Disse inkluderer filsystemkontroller, fysisk sikkerhet og maskinvaresikkerhetsmoduler, blant andre. I tillegg skal delegert legitimasjon kun brukes mellom parter som deler et tillitsforhold med hverandre.
• Den delegerte legitimasjonen er kryptografisk bundet til endeenhetssertifikatet. Nærmere bestemt brukes den private nøkkelen til endeenhetssertifikatet til å beregne signaturen til DC via en algoritme spesifisert av legitimasjonen. Signaturen binder effektivt DC til navnene på endeenhetssertifikatet.
• Delegert legitimasjon utstedes av klienten, noe som er mye enklere enn å lage et sertifikat signert av en CA. Klientutstedte sertifikater er også nyttige for å holde tjenesten i gang selv om CA har nedetid. Organisasjoner kan også eksperimentere med algoritmer som ikke offisielt støttes av CA uten å kompromittere sikkerheten til endeenhetssertifikatet. 
• Delegert legitimasjon har per definisjon korte gyldighetsperioder. Når du angir levetiden til delegert legitimasjon, må servere ta hensyn til klientens klokkeskjevhet for å unngå avvisning av sertifikater. Klientklokkeskjevhet er også viktig for det originale sertifikatet, men er avgjørende for den kortvarige delegerte private nøkkelen. Klientklokkeskjevhet bør tas i betraktning både i begynnelsen og slutten av gyldighetsperioden.
• Det er ingen tilbakekallingsmekanisme for delegert legitimasjon. De blir gjort ugyldige når gyldighetsperioden utløper. Tilbakekalling av den private nøkkelen til endeenhetssertifikatet (som brukes til å signere den delegerte legitimasjonen) trekker imidlertid implisitt tilbake den delegerte legitimasjonen. 
• Delegert legitimasjon er designet for å brukes i TLS 1.3 eller senere. Det er en kjent sårbarhet når TLS 1.2-servere støtter RSA-nøkkelutveksling, som tillater smiing av en RSA-signatur over en vilkårlig melding. Anta at en angriper er i stand til å forfalske en signatur. I så fall kan de opprette forfalsket delegert legitimasjon for hele gyldighetsperioden til sluttenhetssertifikatet. Denne sårbarheten er ikke til stede i implementeringer av TLS 1.3 eller senere. Også, sårbarheten påvirker ikke sertifikater med elliptisk kurvekryptografi, som SSL.com gir. 
• Organisasjoner kan bruke eksisterende automatiserte utstedelses-APIer som ACME for å levere delegert legitimasjon. I dette tilfellet er algoritmene som brukes bare de som støttes av CA, men denne praksisen reduserer muligheten for viktige kompromisser. SSL.com støtter denne praksisen. 
• Delegert legitimasjon kan ikke gjenbrukes i flere sammenhenger. Utstedende parter beregner signaturen ved å bruke en kontekststreng som er unik for den tiltenkte rollen (klient eller server), og gjør dermed bruken av den samme delegerte legitimasjonen for klient- og serverautentisering umulig. 

bruker ECDSA for å implementere PKI tilbudt til klienter, delegert legitimasjon utstedt av våre klienter er ikke sårbare for signaturforfalskningsangrep, som beskrevet ovenfor.