Explain why the implementors section for SigningKey is empty, where
SigningKey comes from, and what it is consumed by.
Update the functions that document encodings for loading private keys so
they are more specific and concrete.
Since these are now unconditionally available on the Tls13CipherSuite,
there doesn't seem to be much point in keeping this API (which appears
be unused).
The bits and pieces we're landing for HPKE support aren't ready for
broad use yet. To avoid confusion before the 0.22 release this commit
adds a `#[doc(hidden)]` attribute to the `crypto/hpke.rs` mod.
We deprecated `ClientConfig` builder's `with_single_cert` in 0.21.4,
encouraging use of `with_client_auth_cert`. This commit removes the
deprecated fn ahead of the 0.22.0 release.
This hides a bunch of mess underlying `cargo update -Z direct-minimal-versions`:
mainly the ability to exclude workspace crates with publish=false from
version resolution (`--ignore-private` flag).
Of `-Z minimal-versions` it is said:
> Note: It is not recommended to use this feature. Because it enforces minimal
> versions for all transitive dependencies, its usefulness is limited since not
> all external dependencies declare proper lower version bounds.
`-Z direct-minimal-versions` appears to be its replacement, which means our
CI is checking things only within our control.
This was only partially ported, but built due to feature unification
from other crates in the workspace.
Unconditionally use a provider, and wrap certificate signature
operations rather than using (ring-only) `default_verify_tls12_signature`
et al.
In QUIC connections, we shouldn't offer or accept cipher suites
that have `Tls13CipherSuite::quic` as `None`. So introduce
`usable_for_protocol` on `SupportedCipherSuite`, and
use it to extend `reduce_given_version` into `reduce_given_version_and_protocol`.
The goal is to make it possible for provider-example to exist
without implementing (eg) QUIC header protection.
This introduces some knock-on requirements for other types/functions
to be the public, so `quic::Algorithm` can be implemented outside
the crate.
If we put the key derivation on "our" side of the trait, we avoid
publicising low-level key schedule functions like hkdf_expand_label
& hkdf_expand_label_aead_key, and quic::Version.
Instead we just provide the `AeadKey` and `Iv`, which makes these
interfaces very similar to those in `Tls13AeadAlgorithm`.
This commit implements the Rustls HPKE provider traits using hpke-rs[0]
with the rust-crypto backend.
Since HPKE is not yet used in Rustls (but will be for ECH support),
a unit test based on the RFC 9180 test vectors is added.
Likely in the future we will want to move this test somewhere outside of
the provider-example crate and use it to test a *ring* HPKE
implementation using the same test vector data.
[0]: https://github.com/franziskuskiefer/hpke-rs
This commit introduces a trait for a hybrid public key encryption (HPKE)
provider. HPKE is specified in RFC 9180[0], and is a pre-requisite for
implementing encrypted client hello (ECH).
Implementations of this trait can use the cryptographic provider of
their choice to provide HPKE using existing primitives from the crypto
provider.
We've tailored the HPKE trait in Rustls to just what is required for
ECH, e.g. it doesn't support modes other than the unauthenticated 'base'
mode, and it only offers the "single-shot" APIs.
[0]: https://www.rfc-editor.org/rfc/rfc9180
Dirkjan Ochtman
Jorge Aparicio
Jacob Hoffman-Andrews
Joseph Birr-Pixton
Daniel McCarney
Steve Fan