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ò.