Subject: RFC3278 vs RFC3279 and draft-ietf-pkix-sha2-dsa-ecdsa-04.txt

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 4 Sep 2008 17:23:32 -0400

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 05 Sep 2008 10:57:21 -0400

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