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 (e)). 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, subject to its specific key profile. An absent PSS parameter field means unrestricted PSS usage and does not inherit restrictions (RFC4055 §3.3 case2).
“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 (e)). 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.
The generic RFC5280 transition treats explicit NULL and omitted parameters alike. A specific key profile may define absence differently, as PSS does. This projection does not validate algorithm-specific syntax: the provider also receives the original SPKI and must reject a spelling forbidden by its algorithm contract.
None means no effective parameters were supplied or inherited. It
does not itself prove that the key’s encoding is valid for its algorithm.
Sourcepub fn subject<E: Work>(
self,
certificate: &'a Certificate<'a>,
execution: &E,
) -> Result<Self>
pub fn subject<E: Work>( self, certificate: &'a Certificate<'a>, execution: &E, ) -> Result<Self>
Project the subject’s effective key using the current parameter state. This is only the RFC 5280 §6.1.4(d)–(e) state transition: it does not authenticate the certificate, bind issuer names, or establish trust. https://www.rfc-editor.org/rfc/rfc5280#section-6.1.4
A caller projecting a key from an already validated path starts at its anchor and visits the original certificates in issuer-to-subject order. Returned SPKI and parameters borrow those sources; no key catalogue, copy or repeated signature verification is needed. The current execution account pays for each transition and data-dependent OID comparison.
§Panics
Only if the internal unit-meter invariant is violated: that meter always admits local work and cannot produce a truncated transition.