Como dice 5.1 (redactado y énfasis añadido):
digestAlgorithms ... está destinado a enumerar los
algoritmos de compendio de mensajes empleados por todos los firmantes, en cualquier
orden, para facilitar la verificación de la firma de un paso.
Las implementaciones PUEDEN no validar firmas que usan un resumen
Algoritmo que no está incluido en este conjunto. ...
En otras palabras, un receptor / verificador puede comenzar desde el principio del mensaje y:
-
lee digestAlgorithms y configura contextos para esos algoritmos
-
lee encapContentInfo y ejecuta los datos, que pueden ser bastante grandes dependiendo del resumen (s) por ejemplo. 2 ^ 64 para SHA-1, a través del algoritmo de resumen, o algoritmos en paralelo, y al mismo tiempo también almacenan y / o procesan y / o transmiten los datos como se desee; o si está "separado", obtenga los datos de otro lugar y ejecútelos de manera similar a través de los resúmenes (s) y tal vez otro uso.
-
lea certificates y crls si está presente y manténgalos a mano si lo desea y no es demasiado grande y no está duplicando los datos disponibles localmente; puede descartarlos si lo desea, condicionado a poder recuperarlos si y cuando sea necesario, usar cosas como LDAP o AIA (incluido el OCSP)
-
lee signerInfos y para cada uno (de interés) selecciona el resumen correcto ya calculado y lo utiliza, más el signedAttrs si se usa, para verificar el signature , sin volver a los datos
Aunque no está tan claramente establecido, esta es también la razón por la que muchas (¡no todas!) en CMS se especifican como BER, que puede, a elección del remitente, usar codificación de longitud indefinida, en lugar de DER , que no puede.