I do not know what implementations do, and if there are people with
shipping product, that should be the answer.
If we have the opportunity to influence how people will do it, I
prefer absent parameters when generating, but for safety being able
to validate with either absent parameters of NULL.
Russ
At 05:23 PM 9/4/2008, Turner, Sean P. wrote:
What did people do when they implemented ecdsa-with-SHA1 - did they include
NULL parameters or are they absent? PKIX said one thing and S/MIME says
something else. For hash algorithms implementations ought to accept both
NULL and absent as equivalent, but was the same done for ECDSA?
RFC3278 clause 8.1 states:
The following object identifier indicates the digital signature algorithm
used in this document:
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 signatures(4) 1 }
When the object identifier ecdsa-with-SHA1 is used within an algorithm
identifier, the associated parameters field contains NULL.
RFC3279 clause 2.2 states:
When the ecdsa-with-SHA1 algorithm identifier appears as the algorithm field
in an AlgorithmIdentifier, the encoding MUST omit the parameters field.
That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the
OBJECT IDENTIFIER ecdsa-with-SHA1.
I'd also like to know whether people followed what's in
draft-ietf-pkix-sha2-dsa-ecdsa-04.txt for ECDSA with SHA224->512 clause
3.2.1 (below) or if they put NULL parameters in:
When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or
ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as an
AlgorithmIdentifier, the encoding MUST omit the parameters field. That is,
the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OID:
ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with- SHA384 or
ecdsa-with-SHA512.
spt