Crates.io | openpgp-card-tools |
lib.rs | openpgp-card-tools |
version | 0.11.7 |
source | src |
created_at | 2021-11-05 22:17:43.56814 |
updated_at | 2024-10-22 04:38:56.11566 |
description | A tool for inspecting, configuring and using OpenPGP cards |
homepage | |
repository | https://codeberg.org/openpgp-card/openpgp-card-tools |
max_upload_size | |
id | 477526 |
size | 323,327 |
This crate contains the oct
tool for inspecting, configuring and using OpenPGP
cards.
One easy way to install this crate is via the "cargo" tool.
The following build dependencies are needed to build on current Fedora:
# dnf install rustc cargo pcsc-lite-devel
For current Debian, a sufficiently new Rust toolchain (rustc
and cargo
) is required (the version in Debian stable may be too old), and in addition:
# apt install pkg-config libpcsclite-dev
Afterwards, you can install this crate by running:
$ cargo install openpgp-card-tools --locked
Finally, add $HOME/.cargo/bin
to your PATH to be able to run the installed
binaries.
oct
uses the PC/SC framework. So on Linux-based systems, you need to make sure the pcscd
service is running, to be able to access your OpenPGP cards.
To generate the man pages for oct
, provide an absolute directory with the OCT_MANPAGE_OUTPUT_DIR
environment variable.
After creating the man pages below the specified directory, the application exits.
$ OCT_MANPAGE_OUTPUT_DIR=/some/directory oct
To generate the shell completions for oct
, provide an absolute directory with the OCT_COMPLETION_OUTPUT_DIR
environment variable.
After creating the shell completions below the specified directory, the application exits.
$ OCT_COMPLETION_OUTPUT_DIR=/some/directory oct
A tool to inspect, configure and use OpenPGP cards.
This tool is designed to be equally convenient for regular interactive use, as well as from scripts. To this end, all functionality of this tool is alternatively usable in a non-interactive manner (see below).
When using the tool in interactive contexts, two methods of PIN entry are supported: in most cases, PINs can (and must) be entered via the host computer. When a pin pad is available on the smartcard reader, PIN entry will be requested via this pin pad.
List idents of all currently connected cards:
$ oct list
Available OpenPGP cards:
ABCD:01234567
0007:87654321
Print status information about the data on a card. The card is implicitly selected (if exactly one card is connected):
$ oct status
OpenPGP card ABCD:01234567 (card version 3.4)
Cardholder: Alice Adams
Language preferences: 'en'
Signature key
Fingerprint: 034b348ceda2064caa2274e47563e86f5cabc2a4
Creation Time: 2022-05-21 13:15:19 UTC
Algorithm: EdDSA (Ed25519)
Signatures made: 11
Decryption key
Fingerprint: 338bee093950d831a76f0eb913d62df68c9e5176
Creation Time: 2022-05-21 13:15:19 UTC
Algorithm: ECDH (Curve25519)
Authentication key
Fingerprint: 4881a22e7ec626d1120250b0a7d7f0d50c8df719
Creation Time: 2022-05-21 13:15:19 UTC
Algorithm: EdDSA (Ed25519)
Remaining PIN attempts: User: 3, Admin: 3, Reset Code: 0
Explicitly print the status information for a specific card (this command syntax is needed, when more than one card is plugged in):
$ oct status --card ABCD:01234567
Add -v
for more verbose card status:
OpenPGP card ABCD:01234567 (card version 3.4)
Cardholder: Alice Adams
Language preferences: 'en'
Signature key
Fingerprint: 034b348ceda2064caa2274e47563e86f5cabc2a4
Creation Time: 2022-05-21 13:15:19 UTC
Algorithm: EdDSA (Ed25519)
Touch policy: Cached (features: Button)
Key Status: generated
User PIN presentation is valid for unlimited signatures
Signatures made: 11
Decryption key
Fingerprint: 338bee093950d831a76f0eb913d62df68c9e5176
Creation Time: 2022-05-21 13:15:19 UTC
Algorithm: ECDH (Curve25519)
Touch policy: Off (features: Button)
Key Status: generated
Authentication key
Fingerprint: 4881a22e7ec626d1120250b0a7d7f0d50c8df719
Creation Time: 2022-05-21 13:15:19 UTC
Algorithm: EdDSA (Ed25519)
Touch policy: Off (features: Button)
Key Status: generated
Attestation key:
Algorithm: RSA 2048 [e 17]
Touch policy: Cached (features: Button)
Remaining PIN attempts: User: 3, Admin: 3, Reset Code: 0
Key Status (#129): imported
The --public-key-material
flag additionally outputs the raw public key data for each key slot.
This command returns an OpenPGP public key representation of the keys on a card.
To bind the decryption and authentication subkeys (if any) to the signing key, the user pin needs to be provided.
$ oct pubkey
OpenPGP card ABCD:01234567
Enter User PIN:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: F9C7 97CB 1AF2 1C68 AEEC 8D4D 1002 89F5 5EF6 B2D4
Comment: Alice Adams
xjMEYkOmahYJKwYBBAHaRw8BAQdADwHIuuSgboyzgcLci8Hc0Q15YHKfDP8/CZG4
uumYosXNA2JhesLABgQTFgoAeAWCYkjTagWJAAAAAAkQEAKJ9V72stRHFAAAAAAA
HgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnifpLw5yhNlKffk7V+P9g
idnIM3j6l3k34+p7tMQmCPoCmwMWIQT5x5fLGvIcaK7sjU0QAon1Xvay1AAAhJkB
AIEhZTDuc9xARVK8ta51SOpX3mZs/UYA5a+UrB6vpmZ3AP4k14gFQ6q/cl/SOhPR
FpCAvYlqL8rb3gc2sFIZDfYUDM4zBGJDpmoWCSsGAQQB2kcPAQEHQDRodITykZoi
hIIPZcFZ2bMXvo20YEv+I1eg2kFQ2qSqwsAGBBgWCgB4BYJiSNNqBYkAAAAACRAQ
Aon1Xvay1EcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcI
5rVHhWA5cGdYlyQJYRXv4osAyFlyznFiUOATnoT6LgKbIBYhBPnHl8sa8hxoruyN
TRACifVe9rLUAADpTwD/a+AlBGryfLsqFzIhdJRpGkoOl0H+xcgk3vcaPUQq0pcA
/3TtUmaJ5w60qb/Px7/Q+MTymHH54elRY4lvwIfbvkUIzjgEYkOmahIKKwYBBAGX
VQEFAQEHQO5KBZ7cMwwjsXGOWWMqgAkCyNdw7smcx/+jBEk0m38dAwEKCcLABgQY
FgoAeAWCYkjTagWJAAAAAAkQEAKJ9V72stRHFAAAAAAAHgAgc2FsdEBub3RhdGlv
bnMuc2VxdW9pYS1wZ3Aub3Jn9IwQkbcw9W0jfrduv1q4qNhsOgJWkGTMbVyvQCug
YpcCmwwWIQT5x5fLGvIcaK7sjU0QAon1Xvay1AAAfTwBAPSQq/hGcGjAWNePHoLH
5zA/ePu1vaY1nh2dPhqtUg8+AP0TDG96MJxlM8SJUQXtQsJCAEo4qT9GnGi7MyTU
nvraDw==
=es4l
-----END PGP PUBLIC KEY BLOCK-----
You can query a specific card
$ oct pubkey --card ABCD:01234567
In the process of exporting the key material on a card as a certificate (public key), one or more User IDs can be bound to the certificate:
$ oct pubkey --userid "Alice Adams <alice@example.org>"
The result of exporting public key material from a card is only an approximation of the original public key, since some metadata is not available on OpenPGP cards. This missing metadata includes expiration dates.
Also, if your card only contains subkeys, but not the original primary key, then the exported certificate will use the signing subkey from the card as the primary key for the exported certificate.
One way to safely process this exported public key material from a card is via sq key adopt
.
You can use this approach when you have access to your private primary key material (in the following example, we
assume this key is available in key.pgp
). Then you can bind the public key material from a card to your key:
oct pubkey > public.key
sq key adopt key.pgp public.pgp
In that process, you will be able to manually set any relevant flags.
To use an OpenPGP card for ssh login authentication, a PGP authentication key needs to exist on the card.
oct ssh
then shows the ssh public key string representation of the PGP authentication
key on the card, like this:
$ oct ssh
OpenPGP card ABCD:01234567
Authentication key fingerprint:
59a5cd3ea88f8707d887eaae13545f404e11be1c
SSH public key:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAII2dcYBqMCamidT5MpE3Cl3MIKcYMBekGXbK2aaN6JaH oct:ABCD:01234567
To allow login to a remote machine, that ssh public key can be added to
.ssh/authorized_keys
on that remote machine.
In the example output above, this string is the ssh public key:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAII2dcYBqMCamidT5MpE3Cl3MIKcYMBekGXbK2aaN6JaH oct:ABCD:01234567
Print information about the capabilities of a card, including the list of supported algorithms (if the card returns that list).
Most of the output is probably not of interest to regular users.
$ oct info
OpenPGP card FFFE:12345678 (card version 2.0)
Application Identifier: D276000124 01 0200 FFFE 12345678 0000
Manufacturer [FFFE]: Range reserved for randomly assigned serial numbers.
Card Capabilities:
- command chaining
Card service data:
- Application Selection by full DF name
- EF.DIR and EF.ATR/INFO access services by the GET DATA command (BER-TLV): 010
Extended Capabilities:
- get challenge
- key import
- PW Status changeable
- algorithm attributes changeable
- KDF-DO
- maximum length of challenge: 32
- maximum length cardholder certificates: 2048
- maximum command length: 255
- maximum response length: 256
Supported algorithms:
- SIG: RSA 2048 [e 32]
- SIG: RSA 4096 [e 32]
- SIG: ECDSA (Secp256k1)
- SIG: EdDSA (Ed25519)
- SIG: EdDSA (Ed448)
- DEC: RSA 2048 [e 32]
- DEC: RSA 4096 [e 32]
- DEC: ECDSA (Secp256k1)
- DEC: ECDH (Curve25519)
- DEC: ECDH (X448)
- AUT: RSA 2048 [e 32]
- AUT: RSA 4096 [e 32]
- AUT: ECDSA (Secp256k1)
- AUT: EdDSA (Ed25519)
- AUT: EdDSA (Ed448)
Or to query a specific card:
$ oct info --card ABCD:01234567
All admin
commands need the Admin PIN. It can be provided as a file, with -P <admin-pin-file>
,
for non-interactive use (see below).
By default, the PIN must be entered interactively on the host computer, or via a pin pad if the OpenPGP card is used in a smart card reader that has a pin pad.
Cards can require confirmation by the user before cryptographic operations are performed (this confirmation feature is often implemented as a mechanical button on the card).
However, not all cards implement this feature.
Rationale: when a card requires touch confirmation, an attacker who gains control of the user's host computer cannot perform cryptographic operations on the card at will - even after they learn the user's PINs.
This feature is configured per key slot. The user can choose to require (or not require) touch confirmation separately for signing, decryption, authentication and attestation operations.
E.g., when the touch policy is set to On
for the SIG
key slot, then every signing operation requires a touch button
confirmation:
$ oct admin --card ABCD:01234567 touch --key SIG --policy On
Valid values for the key slot are: SIG
, DEC
, AUT
, ATT
(some cards only support the first three).
Available policies can include: Off
, On
, Fixed
, Cached
, CachedFixed
.
Some cards only support a subset of these.
Off
means that no touch confirmation is required.
On
means that each operation requires on touch confirmation.
The Fixed
policies are like On
, but the policies cannot be changed without performing a factory reset on the card.
With the Cached
policies, a touch confirmation is valid for multiple operations within 15 seconds.
Set the (informational) cardholder name:
$ oct admin --card ABCD:01234567 name "Alice Adams"
The URL field on OpenPGP cards is intended to point to the certificate (or "public key") the corresponds to the keys that are present on the card.
It can be set like this:
$ oct admin --card ABCD:01234567 url "https://key.url.example"
keys.openpgp.org
for the URLIf you have uploaded (or plan to upload) your certificate (your public key) to the keys.openpgp.org
keyserver,
you can point the URL field on your card there:
If the fingerprint of your certificate is 0123456789ABCDEF0123456789ABCDEF01234567
, then you can set the URL
as follows:
$ oct admin --card FFFE:12345678 url "https://keys.openpgp.org/vks/v1/by-fingerprint/0123456789ABCDEF0123456789ABCDEF01234567"
You can use any URL that serves your certificate ("public key"), including links to:
gitlab (https://gitlab.com/<username>.gpg
) or github (https://github.com/<username>.gpg
)
any other keyserver, such as https://keyserver.ubuntu.com/,
a WKD server,
a copy of your certificate on your personal website, ...
Import private key onto a card. This works if at most one (sub)key per role
(sign, decrypt, auth) exists in key.priv
:
$ oct admin --card ABCD:01234567 import key.priv
Import private key onto a card while explicitly selecting subkeys. Explicitly
specified fingerprints are necessary if more than one subkey exists
in key.priv
for any role (spaces in fingerprints are ignored).
$ oct admin --card ABCD:01234567 -P <admin-pin-file> import key.priv \
--sig-fp f290dbbf21db86343c96157b87be15b7f548d97c \
--dec-fp 3c6e08f6761389358b8d766673c7f1a9eedac360 \
--auth-fp d6aa48ef39a26f26c42d5bcbaad214d55332c838
When fingerprints are only specified for a subset of the roles, no keys will be imported for the other roles.
If the private (sub)keys in the import file are locked with a passphrase, the user is prompted to enter the passphrase. If (sub)keys are encrypted with different passphrases, the user will be prompted multiple times.
(Background: OpenPGP keys can be passphrase-protected when they are stored in files. However, to import to an OpenPGP card the keys must be provided in unencrypted form. Therefore, they need to be decrypted for import.)
For non-interactive workflows it's possible to provide the passphrase from a file:
$ oct admin --card ABCD:01234567 import --key-passphrase passphrase.txt key.priv
Note that the content of the passphrase file is used verbatim, including e.g. any trailing space or newline. One way to generate a passphrase file without a trailing newline is
$ echo -n "my passphrase" > passphrase.txt
(Be aware that executing such a command might store your passphrase in your shell history file. Make sure to take measures to avoid this, if necessary.)
This command generates new keys on an OpenPGP card. It creates the corresponding certificate ("public key") representation in an output file.
$ oct admin --card ABCD:01234567 generate --output <output-cert-file> curve25519
Note that key generation needs both the Admin PIN and the User PIN (the User PIN is needed to export the new key as a public key).
The cryptographic algorithm for the generated keys can be selected as the (optional) last parameter. In our example, we use curve25519
, which is usually what you'll want to use, if your card supports it.
Depending on the capabilities of the specific card you are using, the following algorithm names may be supported: curve25519
, rsa2048
, rsa3072
, rsa4096
, nistp256
, nistp384
, nistp521
(on modern cards, the oct info
command shows a table of algorithms that your specific device supports).
Output will look like:
Enter Admin PIN:
Enter User PIN:
Generate subkey for Signing
Generate subkey for Decryption
Generate subkey for Authentication
The <output-cert-file>
will contain the corresponding certificate ("public key").
As part of the process of generating key material on a card, one or more User IDs must be included with the exported certificate:
$ oct admin --card ABCD:01234567 generate --userid "Alice Adams <alice@example.org>" --output <output-cert-file> curve25519
This tool supports creating three different forms of OpenPGP signatures: Detached, inline and cleartext signatures.
If no input file is provided, stdin is read. By default output is emitted on stdout, but can be directed to a file using a commandline option.
$ oct sign --card ABCD:01234567 detached <input-file>
$ oct sign --card ABCD:01234567 inline <input-file>
$ oct sign --card ABCD:01234567 cleartext <input-file>
Decryption using a card (if no input file is set, stdin is read):
$ oct decrypt --card ABCD:01234567 <input-file>
OpenPGP cards use PINs (numerical passwords) to verify that a user is allowed to perform an operation.
To use cryptographic operations on a card (such as decryption or signing), the User PIN is required.
To configure a card (for example to import OpenPGP key material into the card's key slots), the Admin PIN is needed.
By default, on unconfigured (or factory reset) cards, the User PIN is typically set to 123456
,
and the Admin PIN is set to 12345678
.
When a user has entered a wrong User PIN too often, the card goes into a blocked state, in which presenting the User PIN successfully is not possible anymore. The purpose of this is to prevent attackers from trying all possible PINs (e.g. after stealing a card).
To be able to use the card again, the User PIN must be "reset".
A User PIN reset can be performed by presenting the Admin PIN.
OpenPGP cards offer an additional, optional, Resetting Code mechanism.
The resetting code may be configured on a card and used to reset the User PIN if it has been forgotten or blocked. When unblocking a card with the Resetting Code, the Admin PIN is not needed.
The Resetting Code mechanism is only useful in scenarios where a user doesn't have access to (or prefers not to use) the Admin PIN (e.g. in some corporate settings, users might not be given the Admin PIN for their cards. Instead, an admin may define a resetting code and give that code to the user).
On un-configured (or factory reset) cards, the Resetting Code is typically unset.
Setting a new User PIN requires the Admin PIN:
$ oct pin --card ABCD:01234567 set-user
This requires the (previous) Admin PIN.
$ oct pin --card ABCD:01234567 set-admin
The User PIN can be reset to a different (or the same) PIN by providing the Admin PIN. This is possible at any time, including when a wrong User PIN has been entered too often, and the card refuses to accept the User PIN anymore.
$ oct pin --card ABCD:01234567 reset-user
The resetting code is an alternative mechanism to recover from a lost or locked User PIN.
You can set the resetting code after verifying the Admin PIN. Once a resetting code is configured on your card, you can use that code to reset the User PIN without needing the Admin PIN.
$ oct pin --card ABCD:01234567 set-reset
If a resetting code is configured on a card, you can use that code to reset the User PIN:
$ oct pin --card ABCD:01234567 reset-user-rc
Enter resetting code:
Enter new User PIN:
Repeat the new User PIN:
User PIN has been set.
The "system" top level command groups commands that perform initialization and similar functionality.
A factory reset erases all data on your card, including the private key material that the card stores.
$ oct system factory-reset --card ABCD:01234567
NOTE: you do not need a PIN to reset a card!
This command is specific to the Nitrokey Start.
The Nitrokey Start OpenPGP card can present as 3 separate "virtual" OpenPGP cards, each with a set of OpenPGP keys. To select identity "1", run:
$ oct system set-identity --card ABCD:01234567 1
This command is not useful in normal operation. However, if your card has accidentally ended up in "terminated" state, you can use this command to activate the card again.
This command can only be used when exactly on card is connected to your system, and that card is in "terminated" mode. Otherwise the command prints an error and does nothing.
$ oct system activate-file
If your OpenPGP card is inserted in a card reader with a pin pad, this tool
offers you the option to use the pin pad to enter the User- or Admin PINs.
To do this, you can omit the -p
and/or -P
parameters. Then you will
be prompted to enter the user or Admin PINs where needed.
This tool is can optionally provide its output in JSON (or YAML) format. The functionality is intended for scripting use.
For all commands that return relevant output, the parameter --output-format json
chooses JSON as the output format.
For example, with the status
command:
$ oct --output-format json status
{
"schema_version": "0.9.0",
"ident": "ABCD:01234567",
"card_version": "3.4",
"cardholder_name": "Alice Adams",
"language_preferences": [],
"certificate_url": "http://alice.example/alice.pgp",
"signature_key": {
"fingerprint": "a3934505bc5111772e0b845a142cc9ab71265c00",
"creation_time": "2022-10-31 13:45:35 UTC",
"algorithm": "EdDSA (Ed25519)",
"touch_policy": "Off",
"touch_features": "Button",
"status": "generated",
"public_key_material": "ECC [EdDSA (Ed25519)], data: 3A2B88EF788FA59575E3C4DB89EE367DBD0D9E93B6CE26B7686D32E94958F32A"
},
"signature_count": 3,
"user_pin_valid_for_only_one_signature": false,
"decryption_key": {
"fingerprint": "0643f2a966054158ccfab11fc7d20dbada6484e0",
"creation_time": "2022-10-31 13:45:35 UTC",
"algorithm": "ECDH (Curve25519)",
"touch_policy": "Off",
"touch_features": "Button",
"status": "generated",
"public_key_material": "ECC [ECDH (Curve25519)], data: AF97CA49B2D89998605985AEDAA19097A0CE7E5CC681B1ABD1C8610933FDB320"
},
"authentication_key": {
"fingerprint": "2ba33b4290de337d1df854b32e20e5503abc57a9",
"creation_time": "2022-10-31 13:45:35 UTC",
"algorithm": "EdDSA (Ed25519)",
"touch_policy": "Off",
"touch_features": "Button",
"status": "generated",
"public_key_material": "ECC [EdDSA (Ed25519)], data: 80178ECE7F16ACDFDB0A645C81E72287761F03488CE3AE01F74279AA88A9018C"
},
"attestation_key": {
"fingerprint": null,
"creation_time": null,
"algorithm": "RSA 2048 [e 17]",
"touch_policy": "Off",
"touch_features": "Button",
"status": null,
"public_key_material": null
},
"user_pin_remaining_attempts": 3,
"admin_pin_remaining_attempts": 3,
"reset_code_remaining_attempts": 0
}
All commands that require PIN entry can be used non-interactively by providing PINs via files (see the section "Using file-descriptors to provide PINs" for a variation on this).
In almost all contexts, -p
is used to provide the User PIN and -P
to provide the Admin PIN
(the exception is when changing a PIN on the card, then a different parameter is used to provide the new PIN).
Examples of non-interactive use
$ oct admin --card ABCD:01234567 -P <admin-pin-file> name "Alice Adams"
$ oct admin --card ABCD:01234567 -P <admin-pin-file> import key.priv
$ oct admin --card ABCD:01234567 -P <admin-pin-file> generate -p <user-pin-file> --output <output-cert-file> curve25519
$ oct sign --card ABCD:01234567 -p <user-pin-file> detached <input-file>
$ oct sign --card ABCD:01234567 -p <user-pin-file> inline <input-file>
$ oct sign --card ABCD:01234567 -p <user-pin-file> cleartext <input-file>
Examples of non-interactive PIN management
$ oct pin --card ABCD:01234567 set-user -p <old-user-pin-file> -q <new-user-pin-file>
$ oct pin --card ABCD:01234567 set-admin -P <old-admin-pin-file> -Q <new-admin-pin-file>
$ oct pin --card ABCD:01234567 reset-user -P <admin-pin-file> -p <new-user-pin-file>
$ oct pin --card ABCD:01234567 set-reset -P <admin-pin-file> -r <resetting-code-file>
$ oct pin --card ABCD:01234567 reset-user-rc -r <resetting-code-file> -p <new-user-pin-file>
When using a shell like bash , you can pass User- and/or Admin PINs via file-descriptors (instead of from a file on disk):
$ oct sign --card ABCD:01234567 -p /dev/fd/3 detached 3<<<123456
$ oct admin --card ABCD:01234567 -P /dev/fd/3 generate -p /dev/fd/4 --output <output-cert-file> curve25519 3<<<12345678 4<<<123456
Yubico implements a proprietary extension to the OpenPGP card standard to "cryptographically certify that a certain asymmetric key has been generated on device, and not imported".
This feature is available on YubiKey 5 devices with firmware version 5.2 or newer.
"The YubiKey is preloaded with an attestation certificate and matching attestation key issued by the Yubico CA. The template and key are replaceable, which permits an individual or organization to issue attestations verifiable with their own CA if they prefer. If replaced, the Yubico template can never be restored."
This tool does not currently support replacing the attestation key on a YubiKey. It only supports use of the Yubico-provided attestation key to generate "attestation statements".
The attestation certificate on a card can be inspected as follows:
$ oct attestation cert
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
For any key slot on the card you can generate an attestation statement, if the key material in that key slot has been generated on the card.
It's not possible to generate attestation statements for key material that was imported to the card (the attestation statement certifies that the key has been generated on the card).
To generate an attestation statement, run:
$ oct attestation generate --key SIG --card 0006:01234567
Supported values for --key
are SIG
, DEC
and AUT
.
Generation of an attestation requires the User PIN. By default, it also requires touch confirmation
(the touch policy configuration for the attestation key slot is set to On
by default).
When the YubiKey generates an attestation statement, it gets stored in a cardholder certificate
data object on the card.
After an attestation statement has been generated, it can be read from the card and viewed in pem-encoded format:
$ oct attestation statement --key SIG
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
Supported values for --key
are SIG
, DEC
and AUT
.
This project is licensed under the terms of the Apache-2.0 OR MIT licenses. Contributions to this repository are automatically dual-licensed under the terms of the aforementioned licenses.
This project has been funded in part through NGI Assure, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program.
Learn more at the NLnet project page.