- Announce - lists.sequoia-pgp.org

sequoia-wot v0.5.0
by Neal H. Walfield 08 Feb '23

08 Feb '23

Hi everyone, I'm pleased to announce the release of version 0.5.0 of the sequoia-wot crate. I have published sequoia-wot on crates.io: https://crates.io/crates/sequoia-wot You can also fetch 0.5.0 using the v0.5.0 tag: https://gitlab.com/sequoia-pgp/sequoia-wot/-/tags/v0.5.0 which I signed: $ git verify-tag v0.5.0 gpg: Signature made Wed Feb 08 15:55:57 2023 +01:00 gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate] gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" This release includes one significant change: certificates fetched from key servers are cached on disk in the default certificate directory. This release also includes a number of minor bug fixes. When upgrading to clap 4, the short option for `--keyring` was mistakenly changed from `-k` to `-f`. That change has been reverted. Several API warts were corrected. And, a performance bug, which impacts `sq-wot list`, was fixed. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-ipc v0.30.1
by Neal H. Walfield 02 Feb '23

02 Feb '23

Hi everyone, I'm pleased to announce the release of version 0.30.1 of the sequoia-ipc crate. I have published sequoia-ipc on crates.io: https://crates.io/crates/sequoia-ipc You can also fetch 0.30.1 using the v0.30.1 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/ipc/v0.30.1 which I signed: $ git verify-tag ipc/v0.30.1 gpg: Signature made Thu Feb 02 15:18:54 2023 +01:00 gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate] gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" This release includes a fix for the keybox parser. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-ipc v0.30.0
by Neal H. Walfield 01 Feb '23

01 Feb '23

Hi everyone, I'm pleased to announce the release of version 0.30.0 of the sequoia-ipc crate. I have published sequoia-ipc on crates.io: https://crates.io/crates/sequoia-ipc You can also fetch 0.30.0 using the v0.30.0 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/ipc/v0.30.0 which I signed: $ git verify-tag ipc/v0.30.0 gpg: Signature made Wed Feb 01 16:27:00 2023 +01:00 gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate] gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" Primary key fingerprint: 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 Subkey fingerprint: C03F A641 1B03 AE12 5764 6118 7223 B566 78E0 2528 This release includes a fix for sequoia-ipc's gpg agent support. When decrypting a message with multiple recipients (i.e., multiple PKESK packets), sequoia-ipc's state machine would sometimes become desynchronized from gpg agent's state machine, and the decryption would fail. It also includes a fix for a test failure on big endian systems, like S390. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-wot 0.4.0 & 0.4.1
by Neal H. Walfield 31 Jan '23

31 Jan '23

Hi everyone, I'm pleased to announce the release of version 0.4.0 and 0.4.1 of the sequoia-wot crate, our web of trust engine. After releasing 0.4.0, we identified an issue that prevented building 0.4.0 in a reproducible manner. I fixed that, and then immediately released 0.4.1. sequoia-wot 0.4.0 and 0.4.1 have been published on crates.io: https://crates.io/crates/sequoia-wot You can also fetch 0.4.1 using the v0.4.1 tag: https://gitlab.com/sequoia-pgp/sequoia-wot/-/tags/v0.4.1 which I signed: $ git verify-tag v0.4.1 gpg: Signature made Wed Jan 25 16:02:18 2023 GMT gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" This release includes a lot of new functionality. - sequoia-wot now supports certification networks. By default sequoia-wot works on authentication networks. An authentication network draws a distinction between two types of certifications: ones that confirm an identity should be associated with a certificate ("Alice says that this is Bob's certificate"), and ones that delegate the ability to assert identities ("Alice says that she trusts Bob when he says this is Carol's certificate"). In a certification network, all certifications delegate the ability to assert identities. This is the type of network that PGP path finding tools use, like: https://the.earth.li/~noodles/pathfind.html And the graph-paths.py tool from the Linux kernel community's wotmate: https://github.com/mricon/wotmate sq-wot exposes this functionality via the `--certification-network` option. As an example of where this is useful, let's say Sam Hartman, a previous Debian project leader, wants to authenticate a certificate for Jonathan Carter, the current Debian project leader. Unfortunately, Sam can't directly authenticate Jonathan's certificate: ``` $ sq-wot --keyring /usr/share/keyrings/debian-keyring.gpg -r 332D4CE3A2FAE5439B7E25B2283681BA6FE7F41D authenticate C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 'Jonathan Carter <jcc(a)debian.org>' No paths found. ``` Using a certification network, however, he can see that he certified Steve McIntyre's certificate, who in turn certified a different User ID on Jonathan's certificate: ``` $ sq-wot --certification-network --keyring /usr/share/keyrings/debian-keyring.gpg -r 332D4CE3A2FAE5439B7E25B2283681BA6FE7F41D authenticate C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 'Jonathan Carter <jcc(a)debian.org>' [ ] C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 Jonathan Carter <jcc(a)debian.org>: doubly authenticated (800%) Path #1 of 8, trust amount 120: ◯ 332D4CE3A2FAE5439B7E25B2283681BA6FE7F41D ("Sam Hartman <hartmans(a)debian.org>") │ certified the following certificate on 2019-06-28 ├ CEBB52301D617E910390FE16587979573442684E ("Steve McIntyre <93sam(a)debian.org>") │ certified the following certificate on 2015-08-22 ├ C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 ("Jonathan Carter <jcarter(a)linux.com>") │ certified the following binding on 2023-01-31 └ C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 "Jonathan Carter <jcc(a)debian.org>" ... ``` Sam can now reevaluate whether he is willing to consider Steve to be a trusted introducer for Jonathan. If so, he could upgrade his certification of Steve's certificate to a delegation thereby making him a trusted introducer: ``` $ sq certify --depth 1 sam.pgp steve.pgp "Steve McIntyre <93sam(a)debian.org>" ``` Sam also needs to consider whether the two User IDs on Jonathan's certificate refer to the same person. - sequoia-wot can now fetch missing certificates from key servers and WKD. The certificates are also cached locally to speed up future runs, and reduce load on the keyservers. This functionality is enabled in sq-wot by the `--network` option. It can be supplied in addition to a local keyring or alone. If a local keyring is supplied, then the certificates in the local keyring are preferred. The network backend only uses the configured keyserver if a certificate is missing. Combining this option with `--certification-network` makes sq-wot as powerful as a PGP path finding tool with access to a keyserver's database, because that's exactly what it is. - sequoia-wot understands gossip. Sometimes there are no paths from a trust root to the binding that you are trying to authenticate in the certification network. In that case, it may still be helpful to find out who has certified a particular certificate. That is, it may be helpful to listen to other's gossip. The `--gossip` option finds arbitrary paths to a particular certificate by treating all certificates as if they were trust roots albeit with zero trust. (This is similar to wotmate's graph-to-full.py.) Returning to our previous example, Sam can find out who else certified Jonathan's certificate by running: ``` $ sq-wot --gossip --keyring /usr/share/keyrings/debian-keyring.gpg authenticate C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 'Jonathan Carter <jcc(a)debian.org>' ``` - sequoia-wot includes a path validator and linter. Instead of searching for an arbitrary path in the web of trust, it is possible to validate a specific path. If the path is invalid, it is also linted: the certificates and the certifications are checked for validity (not revoked, not expired, using safe cryptography, etc.). This is particularly helpful when you think a path ought to be valid, but `sq-wot authenticate` doesn't find it. In the following example, we see that although Linus (79BE3E4300411886) certified greg k-h's certificate (38DBBDC86092693E), the path from Linus to greg k-h is not valid, because the certification uses SHA-1, which is rejected, because it is not secure: ``` $ sq-wot --keyring kernel.pgp path ABAF11C65A2970B130ABE3C479BE3E4300411886 647F28654894E3BD457199BE38DBBDC86092693E 'Greg Kroah-Hartman (Linux kernel stable release signing key) <greg(a)kroah.com>' [ ] 647F28654894E3BD457199BE38DBBDC86092693E Greg Kroah-Hartman (Linux kernel stable release signing key) <greg(a)kroah.com>: not authenticated (0%) ◯ ABAF11C65A2970B130ABE3C479BE3E4300411886 ("Linus Torvalds <torvalds(a)kernel.org>") │ No adequate certification found. │ 79BE3E4300411886 did not certify <38DBBDC86092693E, "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg(a)kroah.com>"> │ No active certifications by 79BE3E4300411886 for <38DBBDC86092693E, "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg(a)kroah.com>"> had a trust amount of at least 120 │ Certification (BA80 by 79BE3E4300411886 on 38DBBDC86092693E at 2011-10-25 19:51.53) is adequate, but it is not valid │ BA80 by 79BE3E4300411886 on 38DBBDC86092693E at 2011-10-25 19:51.53: policy violation │ Policy rejected non-revocation signature (GenericCertification) requiring collision resistance │ SHA1 is not considered secure since 2013-02-01T00:00:00Z └ 647F28654894E3BD457199BE38DBBDC86092693E "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg(a)kroah.com>" ``` The main visible, non-functional improvement in sequoia-wot is better performance. Whereas the previous versions of the sequoia-wot library parsed and validated all certificates at start up time, the library has been restructured to only fetch, parse, and validate those certificates that are actually relevant to the given operation. Scanning the keyring, parsing, and validating the relevant certificates, and authenticating a binding takes about 100 ms on my keyring: ``` $ gpg --export --export-options export-local-sigs > keyring.pgp $ ls -lh keyring.pgp -rw-r--r-- 1 us us 30M Jan 27 15:06 keyring.pgp $ sq keyring list keyring.pgp | wc -l 834 $ time sq-wot --keyring keyring.pgp -r 8F17777118A33DDA9BA48E62AACB3243630052D9 authenticate CBCD8F030588653EEDD7E2659B7DD433F254904A 'Justus Winter <justus(a)sequoia-pgp.org>' [✓] CBCD8F030588653EEDD7E2659B7DD433F254904A Justus Winter <justus(a)sequoia-pgp.org>: fully authenticated (100%) ◯ 8F17777118A33DDA9BA48E62AACB3243630052D9 ("Neal H. Walfield <neal(a)g10code.com>") │ certified the following binding on 2022-10-07 └ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <justus(a)sequoia-pgp.org>" real 0m0.107s user 0m0.056s sys 0m0.051s ``` This is about three times longer than `gpg --list-keys CBCD8F030588653EEDD7E2659B7DD433F254904A`. Unlike sq-wot, however, gpg uses a cache. Listing all authenticated bindings using `sq-wot list` takes 4.5 seconds on my test system. Running `gpg --check-trustdb` takes significantly longer: ``` $ time gpg --check-trustdb real 1m29.038s user 1m1.604s sys 0m27.420s $ time sq-wot --keyring keyring.pgp -r 8F17777118A33DDA9BA48E62AACB3243630052D9 list >/dev/null real 0m4.270s user 0m4.154s sys 0m0.116s ``` This performance improvement was achieved by restructuring how the web of trust engine fetches certificates. Instead of having to provide all of the certificates upfront, the engine looks up certificates using a storage abstraction, the new Store and Backend traits. https://docs.rs/sequoia-wot/0.4.1/sequoia_wot/store/index.html This storage abstraction can be implemented by applications to interface with their own certificate stores, e.g., an SQLite database, etc. Neal on behalf of the whole Sequoia PGP team

1 0

[Sequoia-devel] sequoia-openpgp: 1.12.0
by Neal H. Walfield 06 Jan '23

06 Jan '23

Hi everyone, I'm pleased to announce the release of version 1.1.4 of the buffered reader crate. It has been published on crates.io: https://crates.io/crates/buffered-reader You can also fetch it using the buffered-reader/v1.1.4 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/buffered-reader%2Fv1.1.4 which I signed: $ git verify-tag buffered-reader/v1.1.4 gpg: Signature made Fri Jan 6 21:40:10 2023 GMT gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" This release fixes a performance bug in the generic buffered reader (`buffered_reader::Generic`). When the amount of data that is requested (e.g., via `BufferedReader::data`) exceeds the default buffer size, exactly that amount of data was read from the underlying reader. This is problematic for two reasons. First, as users of a buffered reader often do not immediately consume the data that is read, most reads are forwarded to the underlying buffered reader. Second, most reads are for one byte. Because `buffered_reader::Generic` keeps all data in a single vec, this resulted in a lot of copying, which hurt performance. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-openpgp: 1.12.0
by Neal H. Walfield 13 Dec '22

13 Dec '22

Hi everyone, I'm pleased to announce the release of version 1.12.0 of the sequoia-openpgp crate. It has been published on crates.io: https://crates.io/crates/sequoia-openpgp You can also fetch it using the openpgp/v1.12.0 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/openpgp%2Fv1.12.0 which I signed: $ git verify-tag openpgp/v1.12.0 gpg: Signature made Tue Dec 13 16:14:59 2022 GMT gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" The main reason for this release is to fix an issue with a dependency. sequoia-openpgp v1.11.0 depended on version 0.12 or later of the base64 crate. Version 0.20 of the base64 crate was recently released with an incompatible API. This means that when an application uses sequoia-openpgp, it may try and to use version 0.20 of base64, and compilation will fail. Version 1.12.0 tightens the dependency. We expect that the next version of sequoia-openpgp will upgrade to version 0.20 of base64. This release also includes a fix for how text data is hashed [1]. When sequoia-openpgp hashes a text (signature type = "0x01: Signature of a canonical text document" [2]), it breaks the input into to blocks. Unlike for signatures over data, for signatures over text, the line endings `\n`, `\r`, and `\r\n` are canonicalized to `\r\n`. Unfortuantely, if a '\r\n' is split across two blocks, sequoia-openpgp would recognize two line endings instead of one, and hash too much data. This defect does not impact binary signatures, and in practice it is relatively uncommon as a line ending has to straddle two blocks. Nevertheless, this defect may have resulted in the creation of incorrect signatures, or correct signatures being incorrectly identified as invalid. [1] https://gitlab.com/sequoia-pgp/sequoia/-/issues/960 [2] https://www.rfc-editor.org/rfc/rfc4880#section-5.2.1 Neal on behalf of the whole Sequoia PGP team

1 0

Sequoia 1.4 released
by Justus Winter 06 Oct '21

06 Oct '21

We're happy to announce the release of version 1.4 of our low-level OpenPGP library. The most prominent change is the addition of a new cryptographic backend based on the [RustCrypto] crates. [RustCrypto]: https://github.com/RustCrypto ## Cryptographic backends Sequoia allows you to chose between several cryptographic libraries at compile time. Previously, there were two options available: - Nettle: Based on the [Nettle cryptographic library] - CNG: Using Windows' [Cryptography API: Next Generation] (only available on Windows) This release adds a third option: - RustCrypto: Cryptographic algorithms implemented in [pure Rust] This work was started by Nikhil Benesch sponsored by [Materialize] (you can [sponsor] us too!). This makes it possible to use Sequoia in environments where the other options are not available or desirable (e.g. WASM, non-Rust dependencies). The set of supported cryptographic algorithms depends on the backend, for more information please see our [status page]. [Nettle cryptographic library]: https://www.lysator.liu.se/~nisse/nettle/ [Cryptography API: Next Generation]: https://docs.microsoft.com/en-us/windows/win32/seccng/cng-portal [pure Rust]: https://github.com/RustCrypto [sponsor]: https://pep.foundation/support-pep/index.html [Materialize]: https://materialize.com/ [status page]: /status/#algorithms ## Sequoia 1.4 During the 1.x release cycle, we are adding features, fixing bugs, and improving the documentation, while keeping the API stable. Downstream users should be able to update to version 1.4 without changing their code. In December 2020, we commited to providing security fixes for and maintaining the 1.x releases for 1 year. We remain commited to that promise. ### Notable Bug Fixes - [#738]: Unbounded, attacker-controlled heap allocation during decryption of AEAD encrypted messages. [#738]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/738 - [win-crypto-ng#39]: Some DSA keys triggered a crash in the CNG backend. Sequoia now works around that problem. [win-crypto-ng#39]: https://github.com/emgre/win-crypto-ng/issues/39 ### New API The following new functions have been added: - CipherSuite::is_supported - MPI::value_padded - Preferences::policy_uri - ProtectedMPI::value_padded - TSK::eq - ValidAmalgamation::revocation_keys - ValidCert::policy_uri - ValidCert::revocation_keys

1 0

Sequoia 1.3 is released
by Justus Winter 08 Jun '21

08 Jun '21

We're happy to announce the release of version 1.3 of our low-level OpenPGP library. For those of you following along at home, you're probably asking what happened to 1.2. This past Sunday was [PGP's 30th birthday]. To celebrate *three* decades of PGP, we've decided to skip 1.2 and directly release 1.*3*. [PGP's 30th birthday]: https://philzimmermann.com/EN/essays/PGP_30th/ Sequoia PGP is the most advanced OpenPGP implementation available today. -Phil Zimmermann, Creator of PGP 30 years is a long time for a program. And indeed, today, the [original PGP implementation][broadcom-pgp] is hardly recognizable after having changed hands so many times. However, OpenPGP, the protocol that PGP used and was standardized by the IETF first in [RFC 1991] in 1996, and updated by [RFC 2440] and [RFC 4880], lives on. And, it still has one of the most flexible authentication mechanisms and PKIs. Historically, this has only been accessible to advanced users, but through our work on tools like [keys.openpgp.org] and [OpenPGP CA], we are starting to leverage its strength to bring strong and easy-to-use authentication to normal users. For this reason and others, [Phil Zimmermann], the creator of PGP, has said that "Sequoia PGP is the most advanced OpenPGP implementation available today." We're proud to have a [Champion of Freedom]'s endorsement, and will continue to innovate in this space to better protect the privacy and security of Internet users. [broadcom-pgp]: https://www.broadcom.com/products/cyber-security/information-protection/enc… [RFC 1991]: https://datatracker.ietf.org/doc/html/rfc1991 [RFC 2440]: https://datatracker.ietf.org/doc/html/rfc2440 [RFC 4880]: https://datatracker.ietf.org/doc/html/rfc4880 [Phil Zimmermann]: http://philzimmermann.com/EN/background/index.html [keys.openpgp.org]: https://keys.openpgp.org [OpenPGP CA]: https://openpgp-ca.org [Champion of Freedom]: https://epic.org/events/RELEASE-EPIC-Int%27l-Award-2015.pdf ## Sequoia 1.3 During the 1.x release cycle, we are adding features, fixing bugs, and improving the documentation, while keeping the API stable. Downstream users should be able to update to version 1.3 without changing their code. In December 2020, we commited to providing security fixes for and maintaining the 1.x releases for 1 year. We remain commited to that promise. ### Security Fixes We are not aware of any security issues in this version of Sequoia. However, if you are using Sequoia with Nettle, Sequoia's default cryptographic backend, please be aware that versions of Nettle prior to 3.7.3 have a bug, which an attacker can exploit to crash Nettle and consequently the program using Sequoia. For more details, please see [CVE-2021-3580] and Nettle's [release announcement]. [CVE-2021-3580]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3580 [release announcement]: http://lists.lysator.liu.se/pipermail/nettle-bugs/2021/009545.html ### Notable Bug Fixes - [#715]: The Windows CNG backend did not clamp Curve25519 secret key material prior to using them. This caused decryption failures when using the keys. According to the standard, Curve25519 keys must be clamped, however, some OpenPGP implementations did not do this. Rather than force the user to create new keys, the Windows CNG backend now simply clamps the keys. This also aligns the behavior of the CNG backend with the Nettle backend. [#715]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/715 - [#706]: `Cert::insert_packets` ran in quadratic time. We rewrote the deduplication code to run in `O(n * log n)` time. [#706]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/706 - [#699]: When `CertParser` encountered invalid data, it would eagerly return the error before returning the already parsed certificate. This has been fixed to first return the pending certificate and then return the error. [#699]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/699 ### Features - Sequoia now supports [first-party attestations of third-party confirmation signatures]. This lets certificate holders [attest to third-party certifications] over their certificate, and allow those certifications to be distributed by a abuse-resistant keyserver (like, for example, https://keys.openpgp.org) that preserves the holders sovereignty over the information [distributed with her cert]. - Sequoia now allows the [re-use of session keys]. This solves a long-standing problem: How do you reply to an email if you don't have the certs of each and every recipient? Previously, users had no chance but to reply in plaintext, potentially revealing sensitive information. With session key re-use, the original message's session key is used, which already has been encrypted for every recipient in the conversation. - Sequoia's [certificate builder] is now more flexible: it allows binding signatures to be customized. For example, you can add notations to it, [restricting the use of subkeys to certain domains]. [first-party attestations of third-party confirmation signatures]: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10.html… [attest to third-party certifications]: https://docs.sequoia-pgp.org/sequoia_openpgp/cert/amalgamation/struct.Compo… [distributed with her cert]: https://docs.sequoia-pgp.org/sequoia_openpgp/cert/amalgamation/struct.Valid… [re-use of session keys]: https://docs.sequoia-pgp.org/sequoia_openpgp/serialize/stream/struct.Encryp… [certificate builder]: https://docs.sequoia-pgp.org/sequoia_openpgp/cert/struct.CertBuilder.html [restricting the use of subkeys to certain domains]: https://docs.sequoia-pgp.org/sequoia_openpgp/cert/struct.CertBuilder.html#e… ### New API The following new functions have been added: - CertBuilder::add_subkey_with - CertBuilder::add_user_attribute_with - CertBuilder::add_userid_with - ComponentBundle::attestations - Encryptor::with_session_key - Signature::verify_user_attribute_attestation - Signature::verify_userid_attestation - SignatureBuilder::pre_sign - SignatureBuilder::set_attested_certifications - SignatureType::AttestationKey - SubpacketAreas::MAX_SIZE - SubpacketAreas::attested_certifications - SubpacketTag::AttestedCertifications - SubpacketValue::AttestedCertifications - UserAttributeAmalgamation::attest_certifications - UserIDAmalgamation::attest_certifications - ValidUserAttributeAmalgamation::attest_certifications - ValidUserAttributeAmalgamation::attestation_key_signatures - ValidUserAttributeAmalgamation::attested_certifications - ValidUserIDAmalgamation::attest_certifications - ValidUserIDAmalgamation::attestation_key_signatures - ValidUserIDAmalgamation::attested_certifications

1 0

2026

2025

2024

2023

2022

2021

Announce