codificación de NULL opcional en DER

La información en los dos RFC citados parece un poco contradictoria con respecto al algoritmo NULL después del algoritmo.

La definición general de la estructura afirma que el atributo de parámetros es opcional, sin embargo, en el apéndice con respecto al algoritmo rsaEncryption específicamente hay esto:

-- When rsaEncryption is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.

Y algoritmos de hashing específicos similares:

-- When the following OIDs are used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.
--
md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }

Parece un poco tonto definir un campo como opcional, pero luego exige su presencia y valor. Tal vez hay otros algoritmos en los que se puede omitir el campo, pero estos algoritmos lo requieren específicamente.

El estándar parece confundirse en la sección EMSA-PKCS1-v1_5, donde habla sobre parámetros opcionales con algunos algoritmos:

-- When id-md2 and id-md5 are used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.

-- When id-sha1, id-sha256, id-sha384 and id-sha512 are used in an
-- AlgorithmIdentifier the parameters (which are optional) SHOULD
-- be omitted. However, an implementation MUST also accept
-- AlgorithmIdentifier values where the parameters are NULL.

Pero el ejemplo que sigue a este texto incluye el nulo:

sha1    HashAlgorithm ::= {
    algorithm   id-sha1,
    parameters  SHA1Parameters : NULL  -- included for compatibility
                                       -- with existing implementations
}

Todos los ejemplos de ASN.1 que miré en la documentación parecen incluir el nulo opcional obligatorio. Basado en el comportamiento de openssl (creación) y Mozilla PKIX (validación: enlace ) los nulos después de El algoritmo parece ser la interpretación generalmente aceptada de la documentación, aunque su presencia requerida podría argumentarse en función de la definición de la estructura original y la nula no parece agregar valor.

Actualización: encontré una publicación en la lista de correo de OpenSSL enlace que en realidad analiza este mismo problema, y la lógica de interpretación parece resumirse (con algo de historia) de la siguiente manera:

... declaring that in this particular case (optional parameters of
AlgorithmIdentifier) NULL is equivalent to (the same as) absent. In fact,
RFC 5754 (page 4) states that the correct encoding is omitting the empty
list altogether, but some uses defined their encoding as NULL, and it’s OK. 
It reveals some history of this duality:

The two alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax.  Later, the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory.  Because of this
history, some implementations encode parameters as a NULL element
while others omit them entirely.