pub struct WorkingKey<'a> { /* private fields */ }Expand description
The key a certificate’s signature is checked with, and the parameters that are in force for it.
“If the public key algorithm parameters are absent, the working public key parameters are inherited” from the certificate above (RFC 5280 6.1.2 (c) and 6.1.4 (c)). A key written without them is not a key anything can be checked with on its own: the curve or the group it belongs to is written once, in an authority above it, and every key below stands in that same one. A verifier handed the encoding alone would have to answer that it cannot say, and a valid path would go unreported.
Where the key carries its own parameters, those are the ones in force and nothing is inherited. This is the ordinary case: a named curve, an RSA modulus, an Edwards key.
Implementations§
Source§impl<'a> WorkingKey<'a>
impl<'a> WorkingKey<'a>
Sourcepub fn standing(key: PublicKeyInfo<'a>) -> Self
pub fn standing(key: PublicKeyInfo<'a>) -> Self
A key that stands on its own, which is what a trust anchor’s is: there is nothing above it to inherit from.
Sourcepub fn key(self) -> PublicKeyInfo<'a>
pub fn key(self) -> PublicKeyInfo<'a>
The key itself, as the certificate wrote it.
Sourcepub fn parameters(self) -> Option<&'a [u8]>
pub fn parameters(self) -> Option<&'a [u8]>
The parameters in force: the key’s own where it has them, and the ones carried down from above where it does not and belongs to the same algorithm.
“If the certificate subjectPublicKey algorithm and the
working_public_key_algorithm are different, set the
working_public_key_parameters to null” (RFC 5280 6.1.4 (d)). Nothing
is carried across a change of algorithm: a curve is not a modulus,
and an authority on one algorithm certifying a key on another says
nothing about how that key is written. Handing them over anyway gives
a verifier a key described by parameters that are not its own, which
it can only refuse.
A key that writes an explicit null inherits exactly as one that omits
its parameters does. The clause opens on “an algorithm field with
null parameters or parameters are omitted” and gives the two one
rule, so a key that writes a null and names the algorithm in force
stands in what is in force, whatever a given algorithm’s own encoding
rules say about which of the two spellings it should have used. The
same tolerance is AlgorithmIdentifier::same_as, and reading a null
as a refusal here would refuse paths the profile builds.
None says the algorithm takes none, which is not the same as a key
whose parameters were inherited.