.TH SQ-KEY "1" "JANUARY 2021" "0.24.0 (SEQUOIA-OPENPGP 1.0.0)" "USER COMMANDS" 5
.SH NAME
sq\-key \- Manages keys
We use the term "key" to refer to OpenPGP keys that do contain
secrets. This subcommand provides primitives to generate and
otherwise manipulate keys.
Conversely, we use the term "certificate", or cert for short, to refer
to OpenPGP keys that do not contain secrets. See "sq keyring" for
operations on certificates.
.SH SYNOPSIS
\fBsq key\fR [FLAGS] <SUBCOMMAND>
.SH FLAGS
.TP
\fB\-h\fR, \fB\-\-help\fR
Prints help information
.SH SUBCOMMANDS
.TP
\fBhelp\fR
Prints this message or the help of the given subcommand(s)
.TP
\fBgenerate\fR
Generates a new key
Generating a key is the prerequisite to receiving encrypted messages
and creating signatures. There are a few parameters to this process,
but we provide reasonable defaults for most users.
When generating a key, we also generate a revocation certificate.
This can be used in case the key is superseded, lost, or compromised.
It is a good idea to keep a copy of this in a safe place.
After generating a key, use "sq key extract\-cert" to get the
certificate corresponding to the key. The key must be kept secure,
while the certificate should be handed out to correspondents, e.g. by
uploading it to a keyserver.
.TP
\fBextract\-cert\fR
Converts a key to a cert
After generating a key, use this command to get the certificate
corresponding to the key. The key must be kept secure, while the
certificate should be handed out to correspondents, e.g. by uploading
it to a keyserver.
.TP
\fBadopt\fR
Binds keys from one certificate to another
This command allows one to transfer primary keys and subkeys into an
existing certificate. Say you want to transition to a new
certificate, but have an authentication subkey on your current
certificate. You want to keep the authentication subkey because it
allows access to SSH servers and updating their configuration is not
feasible.
.TP
\fBattest\-certifications\fR
Attests to third\-party certifications allowing for their distribution
To prevent certificate flooding attacks, modern key servers prevent
uncontrolled distribution of third\-party certifications on
certificates. To make the key holder the sovereign over the
information over what information is distributed with the certificate,
the key holder needs to explicitly attest to third\-party
certifications.
After the attestation has been created, the certificate has to be
distributed, e.g. by uploading it to a keyserver.
.SH SEE ALSO
For the full documentation see <https://docs.sequoia\-pgp.org/sq/>.
.ad l
.nh
sq(1), sq\-armor(1), sq\-certify(1), sq\-dearmor(1), sq\-decrypt(1), sq\-encrypt(1), sq\-inspect(1), sq\-key(1), sq\-key\-adopt(1), sq\-key\-attest\-certifications(1), sq\-key\-extract\-cert(1), sq\-key\-generate(1), sq\-keyring(1), sq\-keyring\-filter(1), sq\-keyring\-join(1), sq\-keyring\-list(1), sq\-keyring\-merge(1), sq\-keyring\-split(1), sq\-keyserver(1), sq\-keyserver\-get(1), sq\-keyserver\-send(1), sq\-packet(1), sq\-sign(1), sq\-verify(1), sq\-wkd(1)
.SH AUTHORS
.P
.RS 2
.nf
Azul <azul@sequoia\-pgp.org>
Igor Matuszewski <igor@sequoia\-pgp.org>
Justus Winter <justus@sequoia\-pgp.org>
Kai Michaelis <kai@sequoia\-pgp.org>
Neal H. Walfield <neal@sequoia\-pgp.org>
Nora Widdecke <nora@sequoia\-pgp.org>
Wiktor Kwapisiewicz <wiktor@sequoia\-pgp.org>