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/encr... [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.Compon... [distributed with her cert]: https://docs.sequoia-pgp.org/sequoia_openpgp/cert/amalgamation/struct.ValidC... [re-use of session keys]: https://docs.sequoia-pgp.org/sequoia_openpgp/serialize/stream/struct.Encrypt... [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#ex...

### 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