Risposta breve: la RFC (1422) menzionata da Wikipedia non è corretta. Non solo è il formato menzionato in una precedente RFC (1114), ma quella RFC fa correttamente riferimento al documento ITU che ha la descrizione originale: la versione 11/1988 di X.509, disponibile qui . Nella sezione 8.7 (c) di quel documento, si afferma che "se il valore di un tipo è il suo valore predefinito, sarà assente." Pertanto, un certificato di versione 1 è la versione predefinita e non deve essere incluso nel certificato firmato.
Risposta più lunga, con un po 'di spiegazione:
La nuova specifica X.509 (che non è in un RFC, ma il documento ITU non è liberamente disponibile) che si riferisce ai certificati a chiave pubblica è più recentemente documentata in RFC 5280. Ecco una parte della sezione 4.1, che copre il Codifica ASN.1:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
}
Version ::= INTEGER { v1(0), v2(1), v3(2) }
Due parti di questa notazione che fanno esplicito riferimento al controllo delle versioni sono il tag stesso e le sezioni issuerUniqueID, subjectUniqueID ed estensioni. Il tag di versione dice che il valore predefinito è v1, e le specifiche originali dicevano che i valori di default dovrebbero essere assenti. Quando le versioni successive di X.509 aggiungevano versioni, quelle nuove versioni non erano più predefinite e apparivano nel certificato firmato.
Sebbene sia possibile utilizzare questa nuova specifica per generare un certificato pubkey versione 1, non c'è davvero bisogno. Puoi etichettare un nuovo certificato con il tag di versione 3 (utilizzando il numero intero 2) e scegliere semplicemente di non utilizzare nessuna delle nuove sezioni.
La nuova specifica è retrocompatibile con l'originale. ASN.1 viene utilizzato per la codifica in tutte queste revisioni di certificati. ASN.1 è molto compatto e per la maggior parte si basa sul formato definito di una struttura per determinare il significato di un determinato campo. Cioè, ciò che vedi con tutta la sintassi "::=" è una definizione che segui quando analizzi il blob dei dati che ottieni. Il primo campo elencato nella sequenza TBSCertificate è la versione, che è un numero intero. Il campo successivo è serialNumber, che è anche un numero intero. Se manca il campo versione, che potrebbe essere se il certificato è una versione 1, potrebbe essere davvero difficile sapere che serialNumber non è la versione. (È possibile - e probabilmente, con i certificati CA - che il numero di serie sia un numero a una sola cifra.) Il modo per aggirare questo - che è usato nelle specifiche mostrate qui - è usare la codifica DER. Se il tag della versione è presente, viene taggato usando il tag DER "[0]." Il serialNumber non è taggato, quindi se si incontra un intero senza un tag DER, si sa che probabilmente è un certificato di versione 1. (È anche possibile che tu abbia solo un cert formattato in modo errato - guarda abbastanza certs, e troverai tutti i tipi di errori di formattazione ASN.1.)
I certificati della versione 1 non hanno nessuna delle altre sezioni contrassegnate con tag DER, ma la versione 3 certs (la versione che incontrerai più spesso su Internet) non deve includere nessuna o tutte queste sezioni. Per sapere quali, se esistono, delle sezioni sono presenti, si guardano i tag DER. La maggior parte dei certificati versione 3 avrà estensioni, ma non emittenteUniqueID o subjectUniqueID. In quei certificati, vedrai il tag [0] per la versione, 1 e [2] per subjectID di subject e issuer e [3] tag per estensioni. Molti certificati versione 3 che incontri non hanno sezioni uniqueID, quindi il tag [3] che segue immediatamente subjectPublicKeyInfo è l'indicazione che le estensioni verranno analizzate.
Non incontrerai molti certificati versione 2. Poiché X.509 e ASN.1 non sono abbastanza confusi, esiste una specifica X.509 per i certificati "attributo" - un diverso tipo di certificato che non contiene una chiave pubblica e segue un formato diverso (con campi simili in un ordine diverso) - che sono sempre etichettati come versione 2 per definizione. Vedi RFC 5755 per ulteriori informazioni e il formato, per i certificati dell'attributo.