Module: enums

RFC1951

RFC1950

NIST P-256 Curve

NIST P-384 Curve

NIST P-521 Curve

SECG SECP256k1 Curve

Ed25519 - deprecated by crypto-refresh (replaced by standaone Ed25519 algo)

Curve25519 - deprecated by crypto-refresh (replaced by standaone X25519 algo)

BrainpoolP256r1 Curve

BrainpoolP384r1 Curve

BrainpoolP512r1 Curve

0x01 - Modification Detection (packets 18 and 19)

0x02 - AEAD Encrypted Data Packet (packet 20) and version 5 Symmetric-Key Encrypted Session Key Packets (packet 3)

0x04 - Version 5 Public-Key Packet format and corresponding new fingerprint format

0x01 - This key may be used to certify other keys.

0x02 - This key may be used to sign data.

0x04 - This key may be used to encrypt communications.

0x08 - This key may be used to encrypt storage.

0x10 - The private component of this key may have been split by a secret-sharing mechanism.

0x20 - This key may be used for authentication.

0x80 - The private component of this key may be in the possession of more than one person.

Binary data 'b'

Text data 't'

Utf8 data 'u'

MIME message body part 'm'

RSA (Encrypt or Sign) [HAC]

RSA (Encrypt only) [HAC]

RSA (Sign only) [HAC]

Elgamal (Encrypt only) [ELGAMAL] [HAC]

DSA (Sign only) [FIPS186] [HAC]

ECDH (Encrypt only) [RFC6637]

ECDSA (Sign only) [RFC6637]

EdDSA (Sign only) - deprecated by crypto-refresh (replaced by ed25519 identifier below) [Draft RFC]

Reserved for AEDH

Reserved for AEDSA

X25519 (Encrypt only)

X448 (Encrypt only)

Ed25519 (Sign only)

Ed448 (Sign only)

No reason specified (key revocations or cert revocations)

Key is superseded (key revocations)

Key material has been compromised (key revocations)

Key is retired and no longer used (key revocations)

User ID information is no longer valid (cert revocations)

0x00: Signature of a binary document.

0x01: Signature of a canonical text document.

Canonicalyzing the document by converting line endings.

0x02: Standalone signature.

This signature is a signature of only its own subpacket contents. It is calculated identically to a signature over a zero-lengh binary document. Note that it doesn't make sense to have a V3 standalone signature.

0x10: Generic certification of a User ID and Public-Key packet.

The issuer of this certification does not make any particular assertion as to how well the certifier has checked that the owner of the key is in fact the person described by the User ID.

0x11: Persona certification of a User ID and Public-Key packet.

The issuer of this certification has not done any verification of the claim that the owner of this key is the User ID specified.

0x12: Casual certification of a User ID and Public-Key packet.

The issuer of this certification has done some casual verification of the claim of identity.

0x13: Positive certification of a User ID and Public-Key packet.

The issuer of this certification has done substantial verification of the claim of identity.

Most OpenPGP implementations make their "key signatures" as 0x10 certifications. Some implementations can issue 0x11-0x13 certifications, but few differentiate between the types.

0x30: Certification revocation signature

This signature revokes an earlier User ID certification signature (signature class 0x10 through 0x13) or direct-key signature (0x1F). It should be issued by the same key that issued the revoked signature or an authorized revocation key. The signature is computed over the same data as the certificate that it revokes, and should have a later creation date than that certificate.

0x18: Subkey Binding Signature

This signature is a statement by the top-level signing key that indicates that it owns the subkey. This signature is calculated directly on the primary key and subkey, and not on any User ID or other packets. A signature that binds a signing subkey MUST have an Embedded Signature subpacket in this binding signature that contains a 0x19 signature made by the signing subkey on the primary key and subkey.

0x19: Primary Key Binding Signature

This signature is a statement by a signing subkey, indicating that it is owned by the primary key and subkey. This signature is calculated the same way as a 0x18 signature: directly on the primary key and subkey, and not on any User ID or other packets.

When a signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body of the key packet. (Note that this is an old-style packet header for a key packet with two-octet length.) A subkey binding signature (type 0x18) or primary key binding signature (type 0x19) then hashes the subkey using the same format as the main key (also using 0x99 as the first octet).

0x1F: Signature directly on a key

This signature is calculated directly on a key. It binds the information in the Signature subpackets to the key, and is appropriate to be used for subpackets that provide information about the key, such as the Revocation Key subpacket. It is also appropriate for statements that non-self certifiers want to make about the key itself, rather than the binding between a key and a name.

0x20: Key revocation signature

The signature is calculated directly on the key being revoked. A revoked key is not to be used. Only revocation signatures by the key being revoked, or by an authorized revocation key, should be considered valid revocation signatures.a

0x28: Subkey revocation signature

The signature is calculated directly on the subkey being revoked. A revoked subkey is not to be used. Only revocation signatures by the top-level signature key that is bound to this subkey, or by an authorized revocation key, should be considered valid revocation signatures.

Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked.

0x40: Timestamp signature. This signature is only meaningful for the timestamp contained in it.

0x50: Third-Party Confirmation signature.

This signature is a signature over some other OpenPGP Signature packet(s). It is analogous to a notary seal on the signed data. A third-party signature SHOULD include Signature Target subpacket(s) to give easy identification. Note that we really do mean SHOULD. There are plausible uses for this (such as a blind party that only sees the signature, not the key or source document) that cannot include a target subpacket.

Not implemented!