Sequoia PGP
Neal H. Walfield
Wiktor Kwapisiewicz
Lars Wirzenius
Justus Winter
Heiko Schaefer

November 23, 2021

1/9

Genesis

Sequoia project started in Fall 2017
Founders: Neal, Justus & Kai Michaelis
Sponsored by p≡p Foundation

2/9

Prehistory

2015: Werner Koch hires Neal, Justus & Kai
Formative period
Worked on GnuPG
Worked with developers integrating GnuPG
Worked with GnuPG users
Identified problems
Disagreements with Werner about how to proceed
Parted ways in Summer 2017

3/9

An OpenPGP Implementation for p≡p?

Not a point solution
Not an OpenPGP implementation
A project to improve the OpenPGP ecosystem
Yes, a new OpenPGP library
But also:
Improve existing tools
Develop new tools
Rethink UX paradigms

4/9

Approach

Bottom up
Avoid technical debt
Unopinionated, policy-free interfaces. . . but, secure by default
Documentation, documentation, documentation

5/9

What We’ve Done

Low-level OpenPGP library
Version 1.0 released December 2020
Lots of API documentation with examples1
Stable API
Few bugs. . . so far1

https://docs.sequoia-pgp.org/sequoia_openpgp/
6/9

What We’re Doing (1/2)

Towards day-to-day use
Public key store
Private key store
Support for hardware security modules (HSMs)

Command-line tool
sq - subcommand-style, REST-like interface, scriptablegpg chameleon - gpg CLI that uses sequoia

Strong, easy authentication with the web of trust
Beyond keysigning parties
Tools for using, creating, and managing CAs
OpenPGP CA

7/9

What We’re Doing (2/2)

Standardization WorkIETF OpenPGP Design Team
Public key store2
Web of Trust3

23

https://sequoia-pgp.gitlab.io/pgp-cert-d/
https://sequoia-pgp.gitlab.io/sequoia-wot/
8/9

Where We’re Going

Continue up the stack
Improve authentication, integrity, and confidentiality in existing tools
Develop new tools to make authentication, integrity, andconfidentiality easieremail
File Exchange
Authentication
Login to services
A cross-domain web of trust: ssh, matrix, age, etc.

Federated services
Server side infrastructure
Framework integration

9/9

Adding TPM Support to Sequoia PGP
Wiktor Kwapisiewicz <wiktor@sequoia-pgp.org>

November 23, 2021
https://wiktor.gitlab.io/tpm-openpgp/
https://gitlab.com/wiktor/tpm-openpgp

1/7

Secure private key storage

Problem: it’s hard and expensive to protect cryptographic keys
TPM to the rescue! Secure storage for your private keys that you
already have!

2/7

TPM in free/open-source software

TPMs as "treacherous computing" used for DRM(. . . ) we conclude that the ’Trusted Platform Modules’ available
for PCs are not dangerous, and there is no reason not to include one
in a computer or support it in system software. – Richard Stallman,
https: // www. gnu. org/ philosophy/ can-you-trust. html
TPM in open-source projects:
SSH authentication https://wiki.archlinux.org/title/
Trusted_Platform_Module#Securing_SSH_keys
LUKS volume decryption
https://github.com/electrickite/mkinitcpio-tpm2-encrypt
And even. . . GnuPG! https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html

3/7

TPM in Sequoia PGP: Project structure$ sq sign --signer-key wiktor.asc--private-key-store http://localhost:3000 file$ sq decrypt --recipient-key wiktor.asc--private-key-store http://localhost:3000 file

4/7

Declarative TPM$ cat key.yml
spec:
provider:tpm:
tcti: "device:/dev/tpmrm0"
handle: 0x81000027
algo:
RSA:
bits: 2048
capabilities:- sign
$ create-key -f key.yml$ echo -n foo |openssl dgst -binary -sha256 |sign-digest -f key.yml > signature
5/7

TPM: Key migration
Problem: Secure provisioning of decryption keys
Solution: TPM Duplicate + TPM Import

6/7

Thank you NLnet!

Thank you for supporting open-source!
Statistics:
declarative-tpm (tpm-openpgp): 128 commits, 37 end-to-end tests,
usage documentation
pks-tpm: 25 commits, 8 end-to-end tests, usage docsequoia-pgp+sq: 3 commits, API docs, man page,rust-tss-esapi: 22 commits, 10 merged PRs,

https://wiktor.gitlab.io/tpm-openpgp/
https://gitlab.com/wiktor/tpm-openpgp

7/7

Making sq better
Lars Wirzenius <liw@sequoia-pgp.org>

November 23, 2021
https://sequoia-pgp.org

1/9

Our dream

Sequoia is a great OpenPGP implementation
sq the obvious choice for command line use

people like using sq
Sequoia is considered when privacy, integrity or authenticity is needed

2/9Project goals

Add missing functionality to sqAdd a programmatic API using JSON
Document and verify acceptance criteria

3/9Missing functionality

sq currently implements basic functionality
example: sq can’t extend expiration
the Sequoia library supports everything (really)no good list of what’s missingbuild list of missing featurescompare sq to GnuPG
interview stakeholders

add as many features as there’s time fordocument what will remain missing for now
implement only what’s actually important for users
it is not important to have feature parity with gpg

4/9

JSON API
ideally other programs will use the Sequoia library, not sq
realistically people are going to use sq from scripts
therefore make it easy to use sq from scripts
safe
secureconvenient
future-proofed

JSON seems like a fairly obvious choice
JSON is supported by basically every language
easy to use in programsno need to parse free form text

after JSON support, other formats are easy-ish to add
YAML? TOML? S-exp?

5/9

JSON API example$ sq inspect --format=json foo.pgp{"_sq_schema": [1,0,0],"filename": "foo.pgp","file_type": "transferable-public-key","key_type": "ed25519","valid_until": 1637593318,"valid_until_iso8601": "2021-11-22T17:02:27+02:00","user_ids": ["Lars Wirzenius","<liw@sequoia-pgp.org>",],}$ sq inspect --format=json foo.pgp | jq -r .valid_until
1637593318$
6/9

JSON API, possible uses

a password manager a la pass but uses Sequoia
port pass to support sq?

cron job to find keys that will expire soon
Debian keyring maintainers could script technical checks for keys
script to find keys that have not been certified by a CA
script to find keys that aren’t strong enough anymore: too short, weakalgorithm, . . .

7/9

Acceptance criteria for sq

how do we know we’re building the right tool?
how do we know what we’ve built works after it’s changed?
communication and automation are the answer
talk to all stakeholders
agree on actual, verifiable requirements
agree on how to automate verification, when that’s possible
document agreements in a way that all stakeholders understandin CI, verify that requirements are met for every changewe’re using the Subplot tool for thisLars is biased, having co-authored Subplot

8/9

Stakeholders? User testing volunteers?

Lars will be looking for volunteers
Stakeholders
intend to use sq
want to use sq

User testinguse sq to achieve specific goals under observation, over video chat,using screen sharingis the sq command line interface OK to use?
what parts are hard or could be improved?

Look for announcements on the Sequoia project blog
https://sequoia-pgp.org/blog/

9/9

Sequoia’s GnuPG Chameleon
Justus Winter <justus@sequoia-pgp.org>

2021-11-23
https://sequoia-pgp.org/

1/7

Why reimplement GnuPG

many existing programs use GnuPG
direct invocation
GPGME
third-party libraries like GMime→ reimplement the ‘gpg‘ CLI

infeasible to port them allno migration path for users and developers

2/7

Benefits for Users

migration path to Sequoia
implemented in Rust
uses modern algorithm policies
EFAIL defense
scalable and well-documented Web of Trust implementation
scalable certificate store certd

3/7

In Scopegpg and gpgv
signing, verifying, encryption, decryption, key management
the human-readable interface
the machine-readable interface
status-fd
with-colons

reading configuration files
reading keyrings and keyboxes
using gpg-agent
reading trust-anchors from trustdb.gpg
Keyserver and WKD

4/7

Out of Scope

bug-to-bug compatibility
translations of messages and program arguments
using or reimplementing dirmngr
reimplementing gpg-agent
reimplementing scdaemon
updating the trustdb.gpg
esoteric features like server mode

5/7

Evaluation

black box testing
using gpg and gpgv as oraclecomparing machine-readable output
modulo normalizationcomparing human-readable output
edit distance <∼ 20

large-scale integration testing
rebuilding Debian packages
problems:
too coarse, e.g. boolean verification → bisimulation
old artifacts, e.g. v3 signatures in GnuPG’s test suite

6/7

How to migrate

apt install sequoia-gpg-chameleon
dpkg-diverts /bin/gpg away
update-alternatives(1) provides /bin/gpg using chameleon→ every program magically uses Sequoia

apt remove sequoia-gpg-chameleon
update-alternatives(1) provides /bin/gpg using GnuPG
dpkg-divert of /bin/gpg is undone→ every program uses GnuPG again

7/7

OpenPGP CA - a certification authority for trust
management in groups
Heiko Schäfer <heiko@schaefer.name>November 23, 2021

Heiko Schäfer <heiko@schaefer.name>https://openpgp-ca.org

1 / 10What is OpenPGP CA?

A paradigm for how to use OpenPGP in groups/organizations
Tooling to implement this paradigm
Goal: make PGP both easier and safer for users.

Heiko Schäfer <heiko@schaefer.name>https://openpgp-ca.org

2 / 10Main objective: strong authentication, but easy
Authentication, aka: being sure you’re using ‘the right key’.

Bob0x12345678

Alice(doesn't particularly
enjoy checking fingerprints)

Carol
0x87654321

Dave
0xABCDEF01
Stick figures from xkcd (CC BY-NC 2.5)

Heiko Schäfer <heiko@schaefer.name>https://openpgp-ca.org

3 / 10Authentication relying on a CA
Manual work performed by CA admin on behalf of their users.

Bob
0x12345678

Alice(relies on her CA)

Carol
0x87654321

OpenPGP CA
0xCA123456

Dave
0xABCDEF01

Stick figures from xkcd (CC BY-NC 2.5)

Heiko Schäfer <heiko@schaefer.name>https://openpgp-ca.org

4 / 10Common schemes for authentication

Central, mandatory trust anchors (e.g. TLS)
Variations of TOFU or YOLO (e.g. ssh, e2ee messengers)

Heiko Schäfer <heiko@schaefer.name>https://openpgp-ca.org

5 / 10Striking a balance

Decentralization is great.
Strong authentication is great.
Asking each user to manually authenticate all other parties, not somuch.
→ OpenPGP CA uses (machine readable) signature chains,
but keeps the decentral approach of the ‘web of trust’.

Heiko Schäfer <heiko@schaefer.name>https://openpgp-ca.org

6 / 10There’s more to OpenPGP CA, including . . .

Publishing keys, especially via WKD.
Trust for a CA can be scoped (by domain).
Federation (“bridging”) between organizations.
Integration into existing infrastructure (e.g. via restd).

Heiko Schäfer <heiko@schaefer.name>https://openpgp-ca.org

7 / 10Advantages from user perspective

Strong authentication that doesn’t require ongoing effort.
Can rely on CA(s) whose incentives are aligned with their own.
No additional software needed (OpenPGP CA populates the“web of trust”, relying on established features of theOpenPGP standard).

Heiko Schäfer <heiko@schaefer.name>https://openpgp-ca.org

8 / 10Next steps: hardened CA instances

Hardware backed CA private keys (OpenPGP card)
Split mode: online CA + protected CA

Heiko Schäfer <heiko@schaefer.name>https://openpgp-ca.org

9 / 10Thank you

In conclusion:
Maybe your organization should run an OpenPGP CA
instance?
Let’s talk! (e.g. on IRC, OFTC #sequoia or #openpgp-ca)
Thanks to NLnet and pep foundation for funding these projects

Heiko Schäfer <heiko@schaefer.name>https://openpgp-ca.org

10 / 10