[Opendnssec-user] ECC algo signing in ods?

[PGNet Dev]

IANA lists "DNS Security Algorithm Numbers"

http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

where

"All algorithm numbers in this registry may be used in CERT RRs. Zone
signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG)
make use of particular subsets of these algorithms. Only algorithms
usable for zone signing may appear in DNSKEY, RRSIG, and DS RRs.
Only those usable for SIG(0) and TSIG may appear in SIG and KEY RRs."

The Zone-Signing enable algos listed are

3 DSA/SHA1
5 RSA/SHA-1
6 DSA-NSEC3-SHA1
7 RSASHA1-NSEC3-SHA1
8 RSA/SHA-256
10 RSA/SHA-512
12 GOST R 34.10-2001
13 ECDSA Curve P-256 with SHA-256
14 ECDSA Curve P-384 with SHA-384

I'm interested in use of the ECC algos, #13 & #14, for signing in ods

ods allows changing the algo

https://wiki.opendnssec.org/pages/viewpage.action?pageId=10125376#HowdoI...?-Changethesigningalgorithm

ods' defaults appear to be #8

cat kasp.xml
...
<!-- Parameters for KSK only -->
<KSK>
<Algorithm length="2048">8</Algorithm>
<Lifetime>P1Y</Lifetime>
<Repository>SoftHSM</Repository>
</KSK>

<!-- Parameters for ZSK only -->
<ZSK>
<Algorithm length="1024">8</Algorithm>
<Lifetime>P90D</Lifetime>
<Repository>SoftHSM</Repository>
<!-- <ManualRollover/> -->
</ZSK>
...

I found this thread

[Opendnssec-develop] Adding ECC to ods-signer
http://lists.opendnssec.org/pipermail/opendnssec-develop/2016-September/005437.html

"...
We would welcome this contribution. If your time permits, I see
no problem getting this into the next 2.1 release.
...
When you have something to review or submit you can push your changes
back to github and make a pull-request for it.
..."

but lost any further comment.

I've built ods from latest git

./ods-enforcer -V
opendnssec version 2.1.0-dev

checking git log, I've missed any reference to inclusion of ECC algo signing support.

What's the status of ECC support in current/latest ods?

[PGNet Dev]

Well, that version you compiled should have support! It is indeed staged
for the 2.1 release. It should be in the NEWS file in the repositories
root directory.

aha!

cat NEWS
...
UNRELEASED:
...
* OPENDNSSEC-450: Implement support for ECDSA P-256, P-384, GOST. Notice:
...


no mention of 'ecc' or 'elliptic' or 'curve', so I grep-missed it :-/

I assume that the ods algo #'s match the IANA's for the ECDSA P-256 & P-384 algos? i.e., "13" & "14"?

Note that you can not use SoftHSMv1 as it doesn't support anything other
than RSA. SoftHSMv2 does work. Let me know how it works out, you are the
first user!

yep, I already have

/usr/local/softhsm/bin/softhsm2-util --version
2.3.0rc1

we'll see how it goes.

[Yuri Schaeffer]

Post by PGNet Dev
I assume that the ods algo #'s match the IANA's for the ECDSA P-256 & P-384 algos? i.e., "13" & "14"?

Yes!

//Yuri

[PGNet Dev]

Post by PGNet Dev
I assume that the ods algo #'s match the IANA's for the ECDSA P-256 & P-384 algos? i.e., "13" & "14"?

Yes!

When switching to ECC algo, e.g. for AES-256 'equivalency' (fyi, why the keylength naming is as it is: http://crypto.stackexchange.com/questions/9901/why-is-the-p-521-elliptic-curve-not-in-suite-b-if-aes-256-is)

14 ECDSA Curve P-384 with SHA-384

what's the required form for the <Algorithm length="???"> parameter ?

kasp.xml
...
<!-- Parameters for KSK only -->
<KSK>
?? <Algorithm length="2048">8</Algorithm>
<Lifetime>P1Y</Lifetime>
<Repository>SoftHSM</Repository>
</KSK>

<!-- Parameters for ZSK only -->
<ZSK>
?? <Algorithm length="1024">8</Algorithm>
<Lifetime>P90D</Lifetime>
<Repository>SoftHSM</Repository>
<!-- <ManualRollover/> -->
</ZSK>
...


Does it need to be SPECIFIED for ods config? as key length,

<Algorithm length="384">P-384</Algorithm>

bit-depth,

<Algorithm length="256">P-384</Algorithm>

or, since it's implicit in the curve definition, not at all,

<Algorithm>P-384</Algorithm>

?

[PGNet Dev]

oops, that's of course

<Algorithm ...>14</Algorithm>

[Yuri Schaeffer]

Post by PGNet Dev
what's the required form for the <Algorithm length="???"> parameter ?

It should be a positive integer. For algorithms other than RSA the
parameter is ignored.