Come sono possibili i possibili usi per i certificati X.509 (SSL)?

X.509 "Utilizzo chiave" definisce cosa l'emittente consente di utilizzare per il certificato. Ricorda che non tutte le applicazioni seguono comunque questo requisito.

Esistono diverse estensioni che limitano l'utilizzo di un certificato. Un certificato di base, senza alcuna estensione, è considerato "idoneo per qualsiasi scopo", per quanto riguarda X.509 . Il tipo di chiave può ancora avere delle conseguenze; per esempio. una chiave RSA può funzionare sia per la crittografia asimmetrica che per le firme, ma una chiave DSA (o ECDSA), per costruzione, può essere utilizzata solo per le firme (un certificato di sola firma è comunque sufficiente per un client o server SSL, a causa di "Pacchetti di crittografia DHE").

Le estensioni standard che limitano le "capacità" per un certificato sono le due seguenti:

• Key Usage : questo è un set di bandiere che indicano operazioni di basso livello. Esistono esattamente nove flag: digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly e decipherOnly. La semantica di ogni flag è sottile e non ben definita (ad esempio la differenza tra digitalSignature e nonRepudiation è una questione di molta più speculazione dell'interoperabilità).

• Extended Key Usage : questo è un elenco aperto di "usi consentiti" che sono rappresentati come OID . Poiché virtualmente esiste un infinito di OID possibile, non può esserci un elenco esauriente di possibili utilizzi di chiavi estese. Ogni protocollo o standard che usa il certificato X.509 dovrebbe definire i propri usi di chiavi estese; per esempio. le autorità di data e ora usano 1.3.6.1.5.5.7.3.8 (vedi sezione 2.3).

Microsoft, nel proprio software CA ("Servizi certificati Active Directory") ha deciso che le estensioni standard non erano abbastanza buone, quindi hanno definito un altro chiamato Application Policies , che contiene esattamente le stesse informazioni di Extended Key Usage tranne per il fatto che il suo formato di codifica simula quello dello standard Certificate Policies estensione, il che significa che ottiene ulteriori campi di commenti opzionali, che ADCS non riempie effettivamente. Nota che ADCS anche memorizza le informazioni come un'estensione standard di Extended Key Usage , quindi l'effetto netto di questa estensione non standard è diffondere confusione.

Un'altra estensione più vecchia e non standard che tentava di trasmettere la limitazione dell'utilizzo era netscape-cert-type . Questo ci riporta al Netscape Navigator 4.0 volte, alla fine del secolo precedente. Alcuni CA includono ancora questa estensione nei loro certificati, più per motivi di tradizione che per l'effettiva interoperabilità.

Il contenuto di un'estensione è onorato solo nella misura in cui il software coinvolto lo comprende. Le estensioni possono essere contrassegnate come "critiche", il che significa che un'implementazione che non riconosce un'estensione acritica è autorizzata a ignorarlo, mentre un'estensione critica sconosciuta DEVE innescare il rifiuto incondizionato del certificato. Questa è la teoria e, ovviamente, la pratica potrebbe essere diversa. Alcune implementazioni non rispettano la bandiera di criticità. Altri ignorano l'estensione non critica anche se li riconoscono. La formulazione dello standard non è neanche chiara:

A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.

Un'implementazione potrebbe affermare di aver "elaborato" un'estensione ignorandone il contenuto, perché c'è una differenza tra riconoscere un'estensione e imporre la sua semantica. L'intera immagine è resa ancora più sfocata con alcune estensioni, in particolare CRL Distribution Points , la cui semantica dipende dal fatto che l'estensione sia stata contrassegnata come critica o meno.

Esiste un riepilogo delle estensioni utilizzate per TLS / SSL in Nota tecnica NSS: 3, di Nelson B. Bolyard .