La firma del certificato è codificata nel formato ASN.1?
Sto lavorando a un diagramma per descrivere il processo di rilascio dei certificati digitali, con l'aiuto delle risposte alla mia domanda qui e qualche altra ricerca:
Ho appena letto nell'IETF che:
Il campo signatureValue contiene una firma digitale calcolata sulla ASN.1 DER codificato tbsCertificate. Il tbsCertificate codificato DER ASN.1 viene utilizzato come input per la funzione di firma. Questo valore della firma è codificato come BIT STRING e incluso nel campo della firma.
Poiché in qualche modo ho familiarità con il processo di " firma> codifica nel formato ASN.1> codifica in base64 " dal passaggio CSR, sembra diverso qui, quindi invece di questo ordine è: " codifica nel formato ASN.1> firma > codifica in base64 ?? "
ma non ha senso per me; I tre campi principali di un certificato (tbsCertificate, signatureAlgorithm, signatureValue) non dovrebbero essere codificati nel formato ASN.1 prima della codifica in Base64? quindi l'ASN.1 viene utilizzato due volte dalla CA nell'emissione dei certificati?
Quindi questo è il flusso corretto: https://i.stack.imgur.com/bJd0o.png ?
- inoltre, vorrei sapere quanto è accurato il diagramma che descrive il processo di emissione del certificato digitale?
Risposte
TLDR: Sì, tutto in una CSR o in un certificato utilizza la notazione ASN.1, ASN.1 è una descrizione dei tipi di dati.
Ci sono alcune cose da decomprimere qui, ma iniziamo con alcune definizioni:
Formati di dati utilizzati in PKI:
ASN.1 :
Questa è una notazione di sintassi o come rappresentare vari tipi di dati (interi, stringhe, byte, ecc ...). Un equivalente del linguaggio di programmazione sarebbe una struttura dati con tipi definiti. per esempio:
struct Certificate {
tbsCertificate TBSCertificateType // Another struct
signatureAlgorithm SignatureAlgorithmType // Another struct
signatureValue []byte // An array of bytes
}
DER :
La codifica DER è un modo per serializzare i dati ASN.1. L'output è un array di byte che può essere archiviato in un file, inviato sulla rete o come input per un algoritmo di firma.
PEM :
PEM è la rappresentazione in base64 dei dati DER più un'intestazione e un piè di pagina. Ciò si traduce in dati ASCII che possono essere facilmente inviati su canali solo ASCII (ad esempio: la posta elettronica non funziona in formato binario, deve essere codificato).
Ignorerò la codifica PEM perché non è strettamente necessaria qui, viene utilizzata solo per incapsulare dati binari da passare tra le parti.
Come funzionano le firme:
Gli algoritmi di firma in PKI hanno tre parametri
- l'algoritmo di firma (e parametri opzionali), ad esempio:
PKCS #1 SHA-256 With RSA Encryption - la chiave: la chiave privata del firmatario
- l'input: byte grezzi da firmare
C'è un output: la firma, che è una stringa di bit.
nota : in ASN.1, una stringa di ottetti e una stringa di bit sono due tipi diversi. Sono entrambi dati binari ma la stringa di bit può essere di qualsiasi lunghezza mentre la lunghezza di una stringa di ottetti in bit deve essere un multiplo di 8.
Firma dell'input:
Non importa quale sia l'input (certificateRequestInfo per CSR o tbsCertificate per Certificate), deve prima essere codificato in un semplice binario.
Abbiamo bisogno di uno standard per quello che è quel binario. Per fortuna ne abbiamo uno.
- Per un CSR, RFC 2986 ci dice:
The value of the certificationRequestInfo component is DER encoded, yielding an octet string - Per un certificato, RFC 5280 ci dice:
The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate.
In entrambi i casi, i dati rilevanti in formato ASN.1 devono essere codificati DER, quindi inseriti nell'algoritmo di firma. L'output (la firma) è una stringa di bit.
Cosa succede all'output:
L'output dell'algoritmo di firma viene memorizzato nel signatureValuecampo del certificato con tipo bit string. Di nuovo, questo è nella notazione ASN.1.
Una volta che tutti i campi del certificato sono stati impostati correttamente, il certificato è codificato DER.
Se necessario, i dati DER sono codificati in base64 per fornire il formato dati PEM. Ma questo non è richiesto.
Una parola di avvertimento:
Penso che tu stia cercando di ottenere troppo. Inizierei con i componenti di base del flusso CSR / certificato e mi preoccuperei dei dettagli più fini (come la codifica dei dati) in seguito.
Invece di un diagramma che contiene tutti i dettagli possibili, inizia da un livello elevato, ottieni una buona gestione del processo, quindi approfondisci i dettagli grintosi se necessario.