Loading, storing, and generating DNSSEC keys #406
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bal-e
force-pushed
the
dnssec-key
branch
2 times, most recently
from
005b7e7
to
90af63d
Compare
ximon18
added a commit
that referenced
this pull request
Oct 11, 2024
… query-zone.rs code to silence compile errors for now).
ximon18
reviewed
Oct 14, 2024
ximon18
reviewed
Oct 15, 2024
ximon18
reviewed
Oct 15, 2024
bal-e
force-pushed
the
dnssec-key
branch
2 times, most recently
from
569693a
to
f65c5cc
Compare
ximon18
reviewed
Oct 16, 2024
added 11 commits
October 24, 2024 16:13
A private key converted into a 'KeyPair' can be exported in the conventional DNS format. This is an important step in implementing 'ldns-keygen' using 'domain'. It is up to the implementation modules to provide conversion to and from 'KeyPair'; some impls (e.g. for HSMs) won't support it at all.
'Sign' is a more generic version of 'sign::key::SigningKey' that does not provide public key information. It does not try to abstract over all the functionality of a keypair, since that can depend on the underlying cryptographic implementation.
There are probably lots of bugs in this implementation, I'll add some tests soon.
Also fixes 'cargo clippy' issues, particularly with the MSRV.
I'm going to add a corresponding 'PublicKey' type, at which point it becomes important to differentiate from the generic representations and actual cryptographic implementations.
Key generation, for now, will only be provided by the OpenSSL backend (coming soon). However, generic keys (for RSA/SHA-256 or Ed25519) can be imported into the Ring backend and used freely.
The OpenSSL backend supports import from and export to generic secret keys, making the formatting and parsing machinery for them usable. The next step is to implement generation of keys.
added 2 commits
October 24, 2024 16:13
The 'Dnskey' impl of 'fmt::Display' was no longer accurate to the zone file format because 'SecAlg' now prints '<code>(<mnemonic>)'.
added 2 commits
October 25, 2024 11:59
It's a bit hacky because it relies on specific byte indices within the generated PKCS8 documents (internally, Ring basically just concatenates bytes to form the documents, and we use the same indices). However, any change to the document format should be caught by the tests here.
added 10 commits
October 25, 2024 12:50
Now that Ring and OpenSSL support all mandatory algorithms, OpenSSL is no longer required in order to provide signing functionality.
For consistency with the upcoming 'PublicKeyBytes'.
ximon18
reviewed
Nov 1, 2024
ximon18
reviewed
Nov 2, 2024
ximon18
approved these changes
Nov 5, 2024
This code is getting more eyes on it and being exercised at points of use in other work we are doing so with that combined with previous reviews I've done of this PR I'm fine to merge this. |
|
Awesome, thanks for all the reviews @ximon18! |
|
I'll leave the branch up for a bit because it could mess with other PRs iirc. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR defines an ergonomic basis for DNSSEC signing.
The following features are supported:
Cryptographic primitives are implemented using Ring or OpenSSL, at the user's choice. Note that OpenSSL supports more algorithms. For simplicity, a combined key type is provided which uses Ring where possible and falls back to OpenSSL for other algorithms.
Signatures can be created using the following algorithms:
In DNSSEC, keys are associated with important metadata, such as who they belong to and how they can be used (Zone Signing Keys sign resource records, while Key Signing Keys sign Zone Signing Keys). This implementations provides low-level or "raw" types which do not include this metadata, as well as higher-level types which do include it.
sign::generic::SecretKey: A generic representation of a secret key. It does not support any cryptographic operations itself.sign::{openssl,ring,common}::SecretKey: A secret key that supports cryptographic operations and that can be used for signing.sign::Signer: A secret key associated with important metadata.validate::RawPublicKey: A generic representation of a public key.validate::Key: A public key associated with important metadata.The actual signing functionality is provided by the
sign::SignRawtrait. This provides a synchronoussign_raw()function, which should be used for on-CPU signing operations. In the future, an asynchronous signing interface will be provided, for use with off-CPU signing operations (e.g. via HSMs).