Cred că ați înțeles corect până acum, dar cred că pot rezuma concis.
Autoritățile de certificare, fie că este vorba de autoritatea de certificare rădăcină sau orice sub-CA sunt folosite pentru a semna alte certificate. Deci, pentru a verifica o cale de încredere către un certificat de încredere - de obicei rădăcina - li se cere să aibă o cheie publică în ele care poate fi folosită pentru verificarea certificatelor pe care le au emis. Aceasta corespunde unui extensia de utilizare a cheii care indică o astfel de utilizare:
The keyCertSign bit este afirmat când cheia publică subiect este
utilizat pentru verificarea semnăturilor pe certificatele cu cheie publică. Dacă
keyCertSign bit este afirmat, apoi bitul cA în bază
extensia constrângerilor (Secțiunea 4.2.1.9) TREBUIE de asemenea să fie afirmată.
The cRLSign bit este afirmat atunci când este utilizată cheia publică subiect
pentru verificarea semnăturilor pe listele de revocare a certificatelor (de ex.,
CRL-uri, CRL-uri delta sau ARL-uri).
De obicei, ambele utilizări ale cheilor sunt activate în același timp, deoarece autoritatea de certificare este de obicei responsabilă pentru eliberarea certificatelor, dar și pentru revocarea acestora. Aceasta corespunde utilizării cheii publice pentru verificarea semnăturii certificatelor care au fost emise de autoritatea de certificare.
Certificatele Leaf pot fi folosite pentru orice, cu excepția certificatelor de semnare (prin definiție) și a CRL-urilor (prin practica obișnuită). Asta înseamnă că utilizarea cheii poate indica orice altceva. Desigur, cel tip a perechii de chei și a cheii publice ar trebui să fie astfel încât utilizarea cheii să poată fi îndeplinită:
| Utilizarea cheii |
Pic |
Cheia publică trebuie să poată funcționa |
| semnatura digitala |
0 |
Verificarea semnăturii |
| nonRepudierea |
1 |
Verificarea semnăturii |
| keyEncipherment |
2 |
Criptare (încapsulare sau împachetare cheie) |
| cifrarea datelor |
3 |
Criptare (în mod obișnuit, încă încapsularea cheii pentru sistemele de criptare hibride) |
| KeyAgreement |
4 |
Acord cheie (de exemplu, Diffie-Hellman) |
| keyCertSign |
5 |
Verificarea semnăturii |
| cRLSign |
6 |
Verificarea semnăturii |
| EncipherOnly |
7 |
Criptare (încapsulare sau împachetare cheie) |
| descipherOnly |
8 |
Criptare (încapsulare sau împachetare cheie) |
Notă:
- În TLS 1.3, cheia frunză este utilizată exclusiv pentru autentificarea entităților, care corespunde cu
semnatura digitala.
Iată un tabel care indică modul în care anumite tipuri de chei pot fi utilizate.
| Tip cheie |
Semnătură |
Încapsulare |
Acord cheie |
| chei RSA |
da |
da |
Nu |
| Cheile DH |
Nu |
Nu |
da |
| Cheile DSA |
da |
Nu |
Nu |
| Taste EC (curbe Koblitz și Prime) |
da |
Nu |
da |
| Ed25519 și Ed448 |
da |
Nu |
Nu |
| X25519 și X448 |
Nu |
Nu |
da |
În cazul cheilor publice, acțiunile ar fi semnătură verificare și criptare pentru primele două utilizări.
Atât acordul cheie, cât și încapsularea cheii pot fi utilizate pentru stabilirea cheii. Cu toate acestea, dacă cheile fac parte dintr-un certificat persistent, atunci ele nu pot fi utilizate pentru confidențialitate, motiv pentru care acordul de cheie în, de ex. TLS 1.3 se realizează folosind chei efemere, iar cheile de semnare sunt folosite pentru autentificarea necesară a entității.
Algoritmii de acord cheie pot fi utilizați pentru a implementa schema de criptare integrată sau IES. Deci, orice pereche de chei de acord cu cheie poate fi utilizată indirect și pentru criptare.
Aceste tabele sunt conținut original; RFC-ul X.509 nu menționează în mod explicit că cheia publică ar trebui să fie compatibilă cu intenția indicată în utilizarea cheii - se pare că ar trebui să fie compatibilă.
