sequoia-sq

Author SHA1 Message Date

Author	SHA1	Message	Date
Justus Winter	dc24306af1	Emit partial TPKs as revocation certificates. - When emitting revocation certificates, emit the revocation signature with enough context so that it is a well-formed TPK, i.e. include the primary key, the component to be revoked (if revoking a user ID or subkey), and the revocation signature. - Having a partial TPK instead of a bare revocation makes handling it much easier, as it can be stored and transported like any cert. It also gives the recipient of the certificate more context, and simplifies merging it into a database of certs. - Previously, there was a bug in sq where we would emit secret key material when emitting revocation certificates. The reason for that was that the certificate was first converted to a packet stream, and then each packet serialized. In contrast, if a Cert is serialized, no secrets are emitted unless the programmer opts in. In a way, this is the more comprehensive fix for the problem, as it leverages sequoia-openpgp's mechanisms to protect secret key material. - See #160.	2023-12-11 15:48:06 +01:00
Justus Winter	8216857de2	Strip secret key material from emitted revocation certificates. - When doing a userid, subkey, or third-party certificate revocation, with the cert given to --certificate-file containing secret key material, we previously emitted a revocation certificate containing secret key material. - This patch changes that in a straight-forward way that is easy to backport to prior versions. A more comprehensive fix will follow. - Fixes #160.	2023-12-11 15:40:31 +01:00
David Runge	82a866c18d	Consolidate `sq revoke` commands as `sq key` subcommands - Move the `sq revoke certificate`, `sq revoke subkey` and `sq revoke userid` subcommands below the `sq key` namespace as `sq key revoke`, `sq key subkey revoke` and `sq key userid revoke` (respectively). This consolidates commands relevant to key management below `sq key`, which is in line with already existing subcommands (e.g. `sq key generate`, `sq key subkey add` or `sq key userid add`). - Replace the use of a common `revoke()` with `CertificateRevocation`, `SubkeyRevocation` and `UserIDRevocation` to reduce complexity and allow for easier per target (i.e., certificate, subkey or userid) command modification. - Allow specifying an output file using `--output`/ `-o` for all revocation subcommands (i.e., `sq key revoke`, `sq key subkey revoke`, `sq key userid revoke`). If unspecified, output goes to stdout as before. - Add common test facilities to create a default certificate in a temporary directory. - Add common test function to compare a set of notations with those in a `Signature`. - Replace the integration tests which used to test a combined `sq revoke` subcommand with integration tests for `sq key subkey revoke`, `sq key userid revoke` and `sq key revoke` using direct and third party revocation. Fixes #93	2023-07-03 16:04:51 +02:00

Justus Winter

dc24306af1

Emit partial TPKs as revocation certificates.

- When emitting revocation certificates, emit the revocation
    signature with enough context so that it is a well-formed TPK,
    i.e. include the primary key, the component to be revoked (if
    revoking a user ID or subkey), and the revocation signature.

  - Having a partial TPK instead of a bare revocation makes handling
    it much easier, as it can be stored and transported like any
    cert.  It also gives the recipient of the certificate more
    context, and simplifies merging it into a database of certs.

  - Previously, there was a bug in sq where we would emit secret key
    material when emitting revocation certificates.  The reason for
    that was that the certificate was first converted to a packet
    stream, and then each packet serialized.  In contrast, if a
    Cert is serialized, no secrets are emitted unless the
    programmer opts in.  In a way, this is the more comprehensive fix
    for the problem, as it leverages sequoia-openpgp's mechanisms to
    protect secret key material.

  - See #160.

2023-12-11 15:48:06 +01:00

Justus Winter

8216857de2

Strip secret key material from emitted revocation certificates.

- When doing a userid, subkey, or third-party certificate
    revocation, with the cert given to --certificate-file containing
    secret key material, we previously emitted a revocation
    certificate containing secret key material.

  - This patch changes that in a straight-forward way that is easy to
    backport to prior versions.  A more comprehensive fix will follow.

  - Fixes #160.

2023-12-11 15:40:31 +01:00

David Runge

82a866c18d

Consolidate sq revoke commands as sq key subcommands

- Move the `sq revoke certificate`, `sq revoke subkey` and `sq revoke
  userid` subcommands below the `sq key` namespace as `sq key revoke`,
  `sq key subkey revoke` and `sq key userid revoke` (respectively). This
  consolidates commands relevant to key management below `sq key`, which
  is in line with already existing subcommands (e.g. `sq key generate`,
  `sq key subkey add` or `sq key userid add`).
- Replace the use of a common `revoke()` with `CertificateRevocation`,
  `SubkeyRevocation` and `UserIDRevocation` to reduce complexity and
  allow for easier per target (i.e., certificate, subkey or userid)
  command modification.
- Allow specifying an output file using `--output`/ `-o` for all
  revocation subcommands (i.e., `sq key revoke`, `sq key subkey revoke`,
  `sq key userid revoke`). If unspecified, output goes to stdout as
  before.
- Add common test facilities to create a default certificate in a
  temporary directory.
- Add common test function to compare a set of notations with those in
  a `Signature`.
- Replace the integration tests which used to test a combined `sq
  revoke` subcommand with integration tests for `sq key subkey revoke`,
  `sq key userid revoke` and `sq key revoke` using direct and third
  party revocation.

Fixes #93

2023-07-03 16:04:51 +02:00

3 Commits