## Bug #5037

### Incorrect encoding for ECDSA certificates

0%

**Description**

As specified in NDN Certificate Format 2.0:

By default, the content of a certificate is the public key encoded in X509PublicKey format.

As specified in RFC5280 section 4.1.2.7:

This field is used to carry the public key and identify the algorithm with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The algorithm is identified using the AlgorithmIdentifier structure specified in Section 4.1.1.2.

As specified in RFC5280 section 4.1.1.2:

The signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign this certificate. RFC3279, RFC4055, and RFC4491 list supported signature algorithms, but other signature algorithms MAY also be supported.

For Elliptic Curve algorithms, the format is specified in RFC5480 Elliptic Curve Cryptography Subject Public Key Information, which *updates* RFC3279.

As specified in section 2.1.1:

The parameter for id-ecPublicKey is as follows and MUST always be

present:

ECParameters ::= CHOICE { namedCurve OBJECT IDENTIFIER -- implicitCurve NULL -- specifiedCurve SpecifiedECDomain }

specifiedCurve, which is of type SpecifiedECDomain type (defined in X9.62), allows all of the elliptic curve domain parameters to be explicitly specified. This choice MUST NOT be used.

However, ndn-cxx is using *specifiedCurve* in ECDSA certificates.

Steps to reproduce:

`ndnsec key-gen -te /K`

`ndnsec cert-dump -pi /K`

- Copy the "public key bits" and paste into an online decoder.
- Inspect decoding results

Expected: fourth line shows an OBJECT IDENTIFIER that matches a namedCurve.

Actual: fourth line shows a SEQUENCE.