codifica di NULL facoltativo in DER

Le informazioni nelle due RFC citate sembrano leggermente contraddittorie riguardo all'algoritmo NULL dopo.

La definizione generale della struttura afferma che l'attributo dei parametri è facoltativo, tuttavia nell'appendice relativa all'algoritmo rsaEncryption in particolare c'è questo:

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

E algoritmi di hashing altrettanto specifici:

-- 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 }

Sembra un po 'sciocco definire un campo come facoltativo, ma in seguito imporre la sua presenza e il suo valore. Forse ci sono altri algoritmi in cui il campo può essere omesso, ma questi algoritmi lo richiedono specificamente?

Lo standard sembra confondersi nella sezione EMSA-PKCS1-v1_5 dove parla di parametri opzionali con alcuni algoritmi:

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

Ma l'esempio che segue immediatamente questo testo include il null:

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

Tutti gli esempi ASN.1 che ho visto nella documentazione sembrano includere il null opzionale obbligatorio. Basato sul comportamento di openssl (creazione) e Mozilla PKIX (convalida: link ) il null dopo -algoritmo sembra essere l'interpretazione generalmente accettata della documentazione, anche se la sua presenza richiesta potrebbe essere argomentata in base alla definizione della struttura originale e il valore null non sembra aggiungere valore.

Aggiornamento: mi sono imbattuto in un post sulla mailing list OpenSSL link che in realtà discute di questo stesso problema, e la logica di interpretazione sembra riassumersi (con un po 'di storia) come segue:

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