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

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