84   Elliptic Curves should be extended

Created: 03 Dec 2024

Status: Triage

Part: Part 5 (2023, Edition 1, IS)

Links:

Page: 31

Clause: 8.3.2.2

Paragraph: 1

Issue

Table 8 lists the curves that are mandatory or optional and paragraph 5 states "For X.509 certificate digital signature, the EC curve used shall be either scp256k1 or secp256r1". Both the table and paragraph 5 specifically exclude the use of secp384r1 and secp512r1. Without the inclusion, at a minimum, of secp384r1, this standard cannot be compliant with CNSA 2.0..

Proposal

Proposed solution:
Add both secp384r1 and secp512r1 to both Table 8 and paragraph 5 in section 8.3.2.2.
Add both secp384r1 and secp512r1 to paragraph 4 section 8.3.2.3.
Add both secp384r1 and secp512r1 to section 9.2.5.1

Discussion Created Status
That last little bit was simply pointing out that requiring digital signatures to be of particular curves, you are limiting the signing authority certificates to those curves, ie. a signing authority with a certificate created using secp384r1 cannot use that certificate for a secp256r1 based signature. In essence, this is a requirement on the type of CA certificates that are allowed. Since CNSA 1.0 requires secp384r1, no government based CA can sign a 62351-5 compliant identity certificate.
07 Dec 24 Triage
I kind of see what you mean. However, I don't think it was the intended in section 8.3.2.2 to limit the use of the curves only for key agreement. But, I am not 100% sure about this. For this I have to corroborate with the other participants of the TF that worked on the document.

That said, note that in part 5 we only have two types of certificates, (i) end-node certificates, and (ii) CA-certificates.
- CA-certificates, in their key usage field normally do not need the digitalSignature bit set. However, when I look into my CA store on my windows machine I see that there are some Root CA certificates that have this bit set.
- The end-node certificates in part 5 are only used for key agreement and therefore in those certificate the digitalSignature bit in the key usage field must not be set, only the keyAgreemnent bit.
==> So, I believe we do not have a problem in section 8.3.2.2. But, maybe DNP3 SAv6 has other requirement for the end-node certificates?

"That last part is because the EC curve for the signature must match the EC curve of the public key of the signing certificate."
I don't understand what you mean by this sentence and where that is written. Which sentence exactly. 		06 Dec 24 Triage
In section 8.3.2.2 is states, categorically, that for digital signatures the EC curve SHALL [emphasis mine] be secp256k1 or secp256r1. This wording specifically excludes all other curves.

The sentence "Additional curves may be specified in the affected protocol referencing standards" refers only to Table 8, so any additional curves added to Table 8 by such standards MAY NOT be used for digital signatures, they could be used for ECDH or as the public key for an identity certificate but MAY NOT be used as the public key for a signing certificate. That last part is because the EC curve for the signature must match the EC curve of the public key of the signing certificate.

Since CNSA 1.0 requires the use of secp384r1 or secp512r1, Table 8 should be extended to include secp384r1 and secp384r1 should be explicitly allowed for digital signatures.
06 Dec 24 Triage
My mistake. It is CNSA 1.0 that specifies secp384r1 06 Dec 24 Triage
When I look for more details on CNSA 2.0, I see that CNSA 2.0 does not mention any EC curves.
That said, I am not against adding additional curves. I guess we could also add a few other curves as well (brainpool?)

However, note that section 8.3.2.2 also says that "additional curves may be specified in the affected protocol referencing standards".
So, it is perfectly allowed for DNP3 SA6 or IEC 60870-5-7 to define additional curves and then we do not have to change anything in this document.
06 Dec 24 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 25.7.7.1