Felhatalmazáson alapuló hitelesítő adatok TLS

Lezárás a TLS a kapcsolathoz egy tanúsítvány privát kulcsa szükséges. Ennek eredményeként a privát kulcsot minden egyes szolgáltatás által használt szerveren tárolni kell. A magánkulcs titkának védelme kiemelten fontos a nyilvános kulcsú infrastruktúra sémának zökkenőmentes működéséhez. A privát kulccsal rendelkező entitás a tanúsítvány érvényességének hátralévő idejében végrehajthat „man-in-the-middle” támadásokat. Általában, ha egy támadó feltör egy privát kulcsot, a kulcshoz tartozó tanúsítványt általában visszavonják, és újat adnak ki. A több szervert használó vállalkozásoknak azonban, mint a Facebook ill

” a szerverekhez, jelezve, hogy jogosultak rá megszünteti a TLS kapcsolat.

„Egy korlátozott delegálási mechanizmus, amely lehetővé teszi a TLS egyenrangú, hogy kiadja saját hitelesítő adatait egy külső CA által kiadott tanúsítvány keretein belül. Ezek a hitelesítő adatok csak azt teszik lehetővé, hogy a megbízás címzettje olyan nevek nevében beszéljen, amelyeket a CA engedélyezett."

A delegált hitelesítési adatok a biztonság növelése érdekében készültek. Ezért rendelkeznek bizonyos tulajdonságokkal, az IEFT-tervezetben meghatározottak szerint.

• A delegált hitelesítő adatok maximális érvényességi ideje hét (7) nap minimalizálja a kitettséget, ha a magánkulcs veszélybe kerül. A rövid érvényességi idő nem jelenti azt, hogy a delegált hitelesítő adatok biztonságát félvállról kellene venni. A végfelhasználói tanúsítvány privát kulcsának védelmére hozott intézkedéseknek a DC-k védelmére is vonatkozniuk kell. Ide tartoznak többek között a fájlrendszer-vezérlők, a fizikai biztonság és a hardveres biztonsági modulok. Ezenkívül a delegált hitelesítő adatokat csak olyan felek között szabad használni, amelyek bizalmi kapcsolatban állnak egymással.
• A delegált hitelesítő adatok kriptográfiailag kötött a végfelhasználói tanúsítványhoz. Pontosabban, a végentitás-tanúsítvány privát kulcsa a DC aláírásának kiszámítására szolgál a hitelesítő adatok által meghatározott algoritmus segítségével. Az aláírás gyakorlatilag a DC-t a végentitás tanúsítványának nevéhez köti.
• A delegált hitelesítési adatokat az ügyfél adja ki, ami sokkal egyszerűbb, mint egy hitelesítésszolgáltató által aláírt tanúsítvány létrehozása. Az ügyfél által kiadott tanúsítványok abban is segítenek, hogy a szolgáltatás működjön, még akkor is, ha a CA-nak leállása van. Ezenkívül a szervezetek kísérletezhetnek a CA által hivatalosan nem támogatott algoritmusokkal anélkül, hogy veszélyeztetnék a végfelhasználói tanúsítvány biztonságát. 
• A delegált hitelesítő adatok definíció szerint rövid ideig érvényesek. A delegált hitelesítő adatok élettartamának beállításakor a kiszolgálóknak figyelembe kell venniük az ügyfél óraeltolódását, hogy elkerüljék a tanúsítványok elutasítását. Az ügyfélóra torzítása az eredeti tanúsítvány esetében is fontos, de kulcsfontosságú a rövid élettartamú delegált privát kulcs szempontjából. A kliens óraeltolódását az érvényességi időszak elején és végén egyaránt figyelembe kell venni.
• A delegált hitelesítő adatokhoz nincs visszavonási mechanizmus. Az érvényességi idő lejárta után érvénytelenné válnak. A végentitás-tanúsítvány privát kulcsának visszavonása (amely a delegált hitelesítő adatok aláírására szolgál) azonban implicit módon visszavonja a delegált hitelesítő adatot. 
• A delegált hitelesítő adatok felhasználásra készültek TLS 1.3 vagy későbbi. Ismert sebezhetőség, amikor TLS Az 1.2-es szerverek támogatják az RSA-kulcscserét, lehetővé téve RSA-aláírás hamisítását tetszőleges üzeneten keresztül. Tegyük fel, hogy egy támadó képes aláírást hamisítani. Ebben az esetben létrehozhatnak hamisított delegált hitelesítő adatokat a végentitás tanúsítványának teljes érvényességi időszakára. Ez a biztonsági rés nem található meg a megvalósításban TLS 1.3 vagy újabb. Ezenkívül a biztonsági rés nem érinti az elliptikus görbe titkosítással rendelkező tanúsítványokat, amelyek SSL.com biztosít. 
• A szervezetek használhatják a meglévő automatizált kiadási API-kat, például az ACME-t a delegált hitelesítő adatok kézbesítésére. Ebben az esetben csak a CA által támogatott algoritmusokat használjuk, de ez a gyakorlat csökkenti a kulcsfontosságú kompromisszumok lehetőségét. SSL.com támogatja ezt a gyakorlatot. 
• A delegált hitelesítő adatok nem használhatók fel újra több környezetben. A kibocsátó felek az aláírást a tervezett szerepkörhöz (ügyfél vagy kiszolgáló) egyedi környezeti karakterlánc használatával számítják ki, így lehetetlenné teszi ugyanazon delegált hitelesítő adatok használatát az ügyfél- és a kiszolgáló hitelesítéshez. 

az ECDSA-t használja a megvalósításához PKI felajánlotta ügyfelek, ügyfeleink által kibocsátott delegált hitelesítő adatok nincsenek kitéve az aláírás-hamisítási támadásoknak, a fent leírtak szerint.