Add support for Ed25519 DNSSEC signing from RFC 8080 #458

Open
wants to merge 1 commit into
from

Projects

None yet

2 participants

@tmthrgd
Contributor
tmthrgd commented Feb 16, 2017 edited

This pull request adds support for the Ed25519 algorithm in DNSSEC from RFC 8080. RFC 8080 also specifies the use of Ed448 but there is no standard library implementation of Ed448 so it is not included, this should not be an issue as Ed25519 will always see more use than Ed448.

I'm not sure if this pull request meets the 'Depends only on the standard library.' feature listed in the README. Ed25519 support comes from a Golang sub-repositories, in particular golang.org/x/crypto/ed25519. The sub-repositories are described with:

These packages are part of the Go Project but outside the main Go tree. They are developed under looser compatibility requirements than the Go core. Install them with "go get".

Note: the examples included in the RFC are invalid and were corrected in RFC Errata Report (4935).

@tmthrgd tmthrgd Add support for Ed25519 DNSSEC signing from RFC 8080 6725276
@miekg
Owner
miekg commented Feb 16, 2017

Thank you. This is a useful addition. I'm however torn about the golang.org/x dep that it adds; yes we could vendor, use the new dep, but it has been something we managed to avoid. I think for that reason alone merging this would be impossible. Is there any chance this code will move into the std lib?

Code looks good btw.

@tmthrgd
Contributor
tmthrgd commented Feb 16, 2017

Unfortunately I don't have an easy solution for the golang.org/x dep. Some things to note though:

It's quite unfortunate that ed25519 isn't yet part of the standard library. I'm happy for this not to merged and just left open for the indefinite future until either ed25519 becomes crypto/ed25519 or some other solution is arrived at. I've really got no idea when ed25519 might become part of the standard library.

I guess other possible solutions are to simply import golang.org/x/crypto/ed25519 and consider the sub-repositories to be loosely part of the standard library or to vendor it. Neither is ideal of course.

@miekg
Owner
miekg commented Feb 17, 2017

I have no problem leaving this PR open until enough stuff sits in the standard lib.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment