pub struct Subpacket { /* private fields */ }
Expand description
Signature subpackets.
Most of a signature’s attributes are not stored in fixed fields,
but in so-called subpackets. These subpackets are stored in a
Signature
’s so-called subpacket areas, which are effectively
small key-value stores. The keys are subpacket tags
(SubpacketTag
). The values are well-structured
(SubpacketValue
).
In addition to their key and value, subpackets also include a critical flag. When set, this flag indicates to the OpenPGP implementation that if it doesn’t understand the subpacket, it must consider the signature to be invalid. (Likewise, if it isn’t set, then it means that it is safe for the implementation to ignore the subpacket.) This enables forward compatibility with security-relevant extensions.
It is possible to control how Sequoia’s higher-level functionality
handles unknown, critical subpackets using a Policy
object.
Depending on the degree of control required, it may be sufficient
to customize a StandardPolicy
object using, for instance, the
StandardPolicy::accept_critical_subpacket
method.
The subpacket system is extensible in two ways. First, although
limited, the subpacket name space is not exhausted. So, it is
possible to introduce new packets. Second, one of the subpackets,
the Notation Data
subpacket (NotationData
), is explicitly
designed for adding arbitrary data to signatures.
Subpackets are described in Section 5.2.3.7 of RFC 9580.
Implementations§
Source§impl Subpacket
impl Subpacket
Sourcepub fn new(value: SubpacketValue, critical: bool) -> Result<Subpacket>
pub fn new(value: SubpacketValue, critical: bool) -> Result<Subpacket>
Creates a new Subpacket.
Sourcepub fn tag(&self) -> SubpacketTag
pub fn tag(&self) -> SubpacketTag
Returns the Subpacket’s tag.
Sourcepub fn value(&self) -> &SubpacketValue
pub fn value(&self) -> &SubpacketValue
Returns the Subpacket’s value.
Sourcepub fn authenticated(&self) -> bool
pub fn authenticated(&self) -> bool
Returns whether the information in this subpacket has been authenticated.
There are three ways a subpacket can be authenticated:
- It is in the hashed subpacket area and the signature has been verified.
- It is in the unhashed subpacket area and the information is self-authenticating and has been authenticated by Sequoia. This can be done for issuer information and embedded Signatures.
- The subpacket has been authenticated by the user and
marked as such using
Subpacket::set_authenticated
.
Note: The authentication is only valid in the context of the
signature the subpacket is in. If the authenticated
Subpacket
is added to a SubpacketArea
, the flag is
cleared.
Sourcepub fn set_authenticated(&self, authenticated: bool) -> bool
pub fn set_authenticated(&self, authenticated: bool) -> bool
Marks the information in this subpacket as authenticated or not.
See Subpacket::authenticated
for more information.