[−][src]Trait sequoia_openpgp::cert::Preferences

pub trait Preferences<'a>: Sealed {
    pub fn preferred_symmetric_algorithms(
        &self
    ) -> Option<&'a [SymmetricAlgorithm]>;
    pub fn preferred_hash_algorithms(&self) -> Option<&'a [HashAlgorithm]>;
    pub fn preferred_compression_algorithms(
        &self
    ) -> Option<&'a [CompressionAlgorithm]>;
    pub fn preferred_aead_algorithms(&self) -> Option<&'a [AEADAlgorithm]>;
    pub fn key_server_preferences(&self) -> Option<KeyServerPreferences>;
    pub fn preferred_key_server(&self) -> Option<&'a [u8]>;
    pub fn features(&self) -> Option<Features>;
}

Returns the certificate holder's preferences.

OpenPGP provides a mechanism for a certificate holder to transmit information about communication preferences, and key management to communication partners in an asynchronous manner. This information is attached to the certificate itself. Specifically, the different types of information are stored as signature subpackets in the User IDs' self signatures, and in the certificate's direct key signature.

OpenPGP allows the certificate holder to specify different information depending on the way the certificate is addressed. When addressed by User ID, that User ID's self signature is first checked for the subpacket in question. If the subpacket is not present or the certificate is addressed is some other way, for instance, by its fingerprint, then the primary User ID's self signature is checked. If the subpacket is also not there, then the direct key signature is checked. This policy and its justification are described in Section 5.2.3.3 of RFC 4880.

Note: User IDs may be stripped. For instance, the WKD standard requires User IDs that are unrelated to the WKD's domain be stripped from the certificate prior to publication. As such, any User ID may be considered the primary User ID. Consequently, if any User ID includes a particular subpacket, then all User IDs should include it. Furthermore, RFC 4880bis allows certificates without any User ID packets. To handle this case, certificates should also create a direct key signature with this information.

Algorithm Preferences

Algorithms are ordered with the most preferred algorithm first. According to RFC 4880, if an algorithm is not listed, then the implementation should assume that it is not supported by the certificate holder's software.

Examples

use sequoia_openpgp as openpgp;
use openpgp::cert::prelude::*;
use sequoia_openpgp::policy::StandardPolicy;

let p = &StandardPolicy::new();

match cert.with_policy(p, None)?.primary_userid()?.preferred_symmetric_algorithms() {
    Some(algos) => {
        println!("Certificate Holder's preferred symmetric algorithms:");
        for (i, algo) in algos.iter().enumerate() {
            println!("{}. {}", i, algo);
        }
    }
    None => {
        println!("Certificate Holder did not specify any preferred \
                  symmetric algorithms, or the subpacket is missing.");
    }
}

Sealed trait

This trait is sealed and cannot be implemented for types outside this crate. Therefore it can be extended in a non-breaking way. If you want to implement the trait inside the crate you also need to implement the seal::Sealed marker trait.