L'estensione Key Usage , se presente, contiene l'elenco completo dei tipi di utilizzo che sono ammessi con la chiave pubblica. Quando un sistema elabora un certificato, lo fa per un determinato scopo e, pertanto, deve verificare che l'estensione Key Usage , se presente, consenta tale utilizzo. In particolare, quando un sistema analizza un certificato CA e desidera utilizzare la sua chiave pubblica per verificare la firma su un altro certificato (che la CA ha presumibilmente emesso), allora si tratta di un utilizzo del "segno di certificato"; quindi se il certificato CA contiene un'estensione Key Usage , il sistema richiederà che l'estensione contenga il flag keyCertSign .
Nulla impedisce a un'estensione Key Usage di contenere anche altri flag! La verifica è solo positiva: i sistemi verificano se la bandiera che vogliono sia effettivamente lì; non controllano mai che una bandiera che non vogliono sia assente.
Poiché una CA dovrebbe emettere certificato e CRL, dovrebbe avere, in generale, i flag keyCertSign e cRLSign . Questi due flag sono sufficienti . Se la CA non intende firmare il proprio CRL, può omettere il flag cRLSign ; tuttavia, una CA senza il flag keyCertSign ha poco senso. Si potrebbe voler includere altri flag se la chiave CA è pensata per fare anche altre cose (sebbene ciò non sia raccomandato: una regola generale è che una chiave crittografica dovrebbe essere usata solo per una cosa). Si può immaginare, ad esempio, eseguire alcuni key escrowing crittografando la chiave privata dei certificati emessi con la chiave pubblica della CA, in modo che la CA possa recuperare la chiave privata in determinate condizioni (questo non è un male idea quando la chiave dell'utente è intesa per la crittografia dei dati).
Pertanto, nulla impedisce all'estensione Key Usage di contenere altri flag. In alternativa, l'estensione Key Usage potrebbe mancare del tutto; questo è equivalente a "tutti gli usi consentiti".
La "firma CRL off-line" di Microsoft è solo un altro nome per "firma CRL". In effetti, la pagina che colleghi a questo dice:
To apply this key usage if a CA certificate is requested, type the following at a command prompt, and then press ENTER:
echo 03 02 01 06>File_Name.txt
Qui riconosciamo la codifica ASN.1 / DER di un BIT STRING di lunghezza 7 bit, con i bit 5 e 6 impostati e i bit da 0 a 4 cancellati; questa è la codifica di un'estensione Key Usage con flag keyCertSign e cRLSign . Sebbene utilizzino la propria terminologia, Microsoft in realtà si conforma allo standard per quel punto (non hanno inventato un nuovo flag di utilizzo delle chiavi non standard per la "firma CRL offline").
Tutto quanto sopra è la normale interpretazione dei certificati . Accade così che, per quanto riguarda gli standard, "certificati CA radice" non esistano . Una "root" è chiamata anchor anchor e consiste principalmente in un nome (DN) e una chiave pubblica. È Tradizionale codificare l'ancora di trust come "certificati", ovvero la sequenza di byte che seguono le regole di codifica dei certificati (tali certificati sono spesso autofirmati, perché il formato di un certificato ha un valore non opzionale slot per una "firma", quindi ci deve essere qualcosa in quello slot).
Poiché non è standard, l'interpretazione dell'estensione del certificato in una struttura simile a un certificato è aperta alle varianti locali. Alcune implementazioni interpretano l'estensione Key Usage in un certificato radice nei modi illustrati sopra. Alcuni ignorano completamente quell'estensione.
In generale, è sicuro (per l'interoperabilità) riempire i certificati CA radice con contenuti che sarebbero perfettamente validi se quel "certificato" fosse reale, invece di un comodo contenitore di codifica per un'ancora di fiducia.