In RFC5652 , Sintassi dei messaggi crittografici (CMS) , sezione < em> 5.3. SignerInfo Type , c'è un campo digestAlgorithm che ha valori come id-sha256 , id-sha1 , ecc.
Nella stessa RFC, sezione 5.1. SignedData Type c'è un campo digestAlgorithms che nel mio test generalmente ha tante voci quante sono SignerInfo .
La mia domanda è ... perché il campo digestAlgorithm viene specificato in due punti? Sembra inutilmente ridondante.
Come dice 5.1 (redatto e enfatizzato):
digestAlgorithms ... is intended to list the message digest algorithms employed by all of the signers, in any order, to facilitate one-pass signature verification. Implementations MAY fail to validate signatures that use a digest algorithm that is not included in this set. ...
In altre parole, un ricevitore / verificatore può iniziare dall'inizio del messaggio e:
leggi digestAlgorithms e configura i contesti per quegli algoritmi
leggi encapContentInfo ed esegui i dati, che possono essere abbastanza grandi a seconda del (i) digest (i) ad es. 2 ^ 64 per SHA-1, attraverso l'algoritmo di digest o algoritmi in parallelo e allo stesso tempo memorizzano e / o elaborano e / o inoltrano i dati come desiderato; o se "distaccato" ottiene i dati da qualche altra parte e, analogamente, li esegue attraverso i digest e forse altri usi.
leggono certificates e crls se presenti e li tengono a portata di mano se desiderato e non troppo grandi e non duplicano i dati già disponibili localmente; può scartarli se lo si desidera, a condizione di poterli recuperare nuovamente se e quando necessario utilizzando cose come LDAP o AIA (incluso OCSP)
leggi signerInfos e per ognuno (di interesse) seleziona il digest già calcolato e usalo, più signedAttrs se usato, per verificare signature , senza tornare ai dati
Anche se non così chiaramente dichiarato, questo è anche il motivo per cui molte (non tutte!) strutture in CMS sono specificate come BER, che a scelta del mittente può usare codifica a lunghezza indefinita, invece di DER , che non può.