| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Because of the sorting requirement and the fact that a `KeyMgr` can have
multiple Ntor keys, the caller now explicitly extract the two Ntor keys
it wants from the `KeyMgr` and then creates a `RelayNtorKeys` object
with them.
Future changes (#2495) will move this into a view and warn if there are
more than 2 keys.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This extracts the key specifier types out of `tor-relay-crypto`, which
* makes the code layout consistent with the hidden service crates (the
key specifiers are defined in a `keys` module in `tor-hsservice`,
while the key wrapper types live in `tor-hscrypto::pk`)
* helps reduce the API surface: the key specifiers are only used in
`arti-relay`, so we can move them there and make them `pub(crate)`
instead of `pub`
|
| |
|
|
| |
Part of #2451
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is almost a full rewrite of the crypto task which was needed in
order to support our relay signing certificate to be put in the keystore
which will be needed for the offline key feature.
Instead of having rotate_key() do all the things, we now instead do two
pass:
1. Remove all expired keys and certs.
2. Generate any missing keys.
This still results in using the minimum valid_until of all our keys for
the task sleep time.
We can know cleanup the local trait used for this gymnastic and trade it
for some more KeyMgr gymnastic.
Fixes #2404
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
For relays these are pretty basic (they have no globbing components),
because relay certs don't have specifiers (their `ArtiPath`s are
identical to the `ArtiPath` of the subject key).
|
| |
|
|
|
| |
This enables the `experimental-api` feature in `tor-keymgr` because
`CertSpecifier` is experimental.
|
| |
|
|
|
|
|
| |
We need to be able to parse KeyPaths into KeyCertificateSpecifier,
and we can't do that if the signing key is part of the cert specifier
(because the signing key doesn't get encoded in the key path, unlike the
subject key, which does)
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Run maint/add_warning
|
| | |
|
| |
|
|
|
|
| |
This currently can't be used due to upstream limitations in the ssh_key
crate, which will be removed likely in the next release. In the
meantime, we can put in all the groundwork.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
|
|
|
| |
valid_until.
As per our discussion in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2577#note_3099356
|
| | |
|
| |
|
|
|
|
|
| |
This will enable us to store more than one `K_relaysign_ed` in the
keystore.
Closes #1692
|
| |
|
|
|
|
|
| |
We'll eventually need this specifier (for example, if the
`KS_relayid_ed` private key stored offline, the public part of the
keypair will be stored in the online keystore, and will be retrievable
using the new `RelayIdentityPublicKeySpecifier` specifier).
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
According to its docs, `RelayIdentityKeySpecifier` was meant to be the
key specifier for the relay identity keypair, so its role prefix should
be `KS_`.
This also renames `RelayIdentityKeySpecifier` to
`RelayIdentityKeypairSpecifier` for clarity (we're about to add another
specifier here, for the public relay identity key).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `RelaySigningKeySpecifier` is currently defined as:
```rust
#[non_exhaustive]
#[derive(Deftly, PartialEq, Debug, Constructor)]
#[derive_deftly(KeySpecifier)]
#[deftly(prefix = "relay")]
#[deftly(role = "KP_relaysign_ed")]
#[deftly(summary = "Relay medium-term signing keypair")]
/// The key sepcifier of the relay medium-term signing key (RelaySigningKeypair)
pub struct RelaySigningKeySpecifier;
```
This means there can only be a single `relaysign_ed` key with an
`ArtiPath` of the form `relay/KP_relaysign_ed`. This is a problem,
because relays storing their identity key offline will want to generate
a number of `relaysign_ed` keys ahead of time, so we need the keystores
to be able to contain multiple such keys. We will need their `ArtiPath`
to encode a variable component (for example, a timestamp).
We also need to teach `KeyMgr` to retrieve such keys (`KeyMgr::get`
should return the first key that has a valid and timely certificate).
This will involve extending the `KeySpecifier` trait with a function for
obtaining the `KeySpecifier` of the certificate of the key, if there is
one.
For now, let's comment it out and rethink its `ArtiPath` as part of
#1692.
|
| |
|
|
|
|
|
|
|
| |
This re-exports the types/traits needed by the `define_ed25519_keypair`
macro so that the macro caller doesn't need to import a bunch of extra
packages in its Cargo.toml that it doesn't use, and so that the caller
doesn't need a `use prelude::*` before invoking the macro. This makes
the macro nicer to use for the caller, and should prevent the macro from
causing "cannot find ... in this scope" errors.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
|
|
This adds a new crate called tor-relay-crypto which is responsible for
declaring the relay keys and certificate that will be used by a relay
and stored in a KeyMgr.
This is in its own crate and considered pretty low level so other crates
can use it to access the relay keys, like tor-proto, for cryptographic
actions like channel authentication or descriptor signing.
The lower level cryptographic keys are wrapped in a higher level object
in this crate, using tor-key-forge crate, so we can have proper semantic
and strong type check on those keys so they are not misused or confused
with other keys.
At this point, the key declaration might change once the KeyMgr supports
attaching a certificate to a key. We are likely going to see more code
related to certificate creation in this crate in the future.
Part of #1604
Signed-off-by: David Goulet <[email protected]>
|
