question about DigestInfo as defined in PKCS#1 v2.1

[yawnmoth]

From RFC3447#page-52:

The EMSA-PKCS1-v1_5 encoding method includes an ASN.1 value of type
DigestInfo, where the type DigestInfo has the syntax

DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithm,
digest OCTET STRING
}

digestAlgorithm identifies the hash function and shall be an
algorithm ID with an OID in the set PKCS1-v1-5DigestAlgorithms.
For
a discussion of supported hash functions, see Appendix B.1.

DigestAlgorithm ::=
AlgorithmIdentifier { {PKCS1-v1-5DigestAlgorithms} }

PKCS1-v1-5DigestAlgorithms ALGORITHM-IDENTIFIER ::= {
{ OID id-md2 PARAMETERS NULL }|
{ OID id-md5 PARAMETERS NULL }|
{ OID id-sha1 PARAMETERS NULL }|
{ OID id-sha256 PARAMETERS NULL }|
{ OID id-sha384 PARAMETERS NULL }|
{ OID id-sha512 PARAMETERS NULL }

ALGORITHM-IDENTIFIER is defined in RFC3447#page-57:

ALGORITHM-IDENTIFIER ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARAMETERS &Type] }

My question is... if PARAMETERS is optional, why require it if all
it's going to be set to is NULL? Why not define PKCS1-
v1-5DigestAlgorithms as follows?:

PKCS1-v1-5DigestAlgorithms ALGORITHM-IDENTIFIER ::= {
{ OID id-md2 }|
{ OID id-md5 }|
{ OID id-sha1 }|
{ OID id-sha256 }|
{ OID id-sha384 }|
{ OID id-sha512 }

Or better yet, why not just define it as RFC5280#section-4.1.1.2
does?:

AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }

RFC5280's definition is a lot more concise than RFC3447's.

[Thomas Pornin]

According to yawnmoth <terr...@yahoo.com>:

> My question is... if PARAMETERS is optional, why require it if all
> it's going to be set to is NULL?

It is historical. Older specification mage the parameters mandatory. For
optimal interoperability, you have to set the parameters to NULL -- but
you should also accept the absence of such parameters when verifying a
signature (I have encountered some implementations of RSA which omitted
the parameters in such a situation).

> Or better yet, why not just define it as RFC5280#section-4.1.1.2
> does?:

This uses the older ASN.1 "1988" syntax, which has been deprecated.
That syntax is simpler but contains less type information; here,
you have to resort to English text to specify what should go in
the 'parameters' field, whereas the syntax in PKCS#1 v2.1 lets the
ASN.1 compiler perform some consistency tests automatically.

--Thomas Pornin