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
