OpenPGP Example Keys and Certificates
Mailpile ehf
Baronsstig
Iceland
bre@mailpile.is
Independent
juga@riseup.net
American Civil Liberties Union
125 Broad St.
New York, NY
10004
USA
dkg@fifthhorseman.net
int
openpgp
Internet-Draft
The OpenPGP development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of OpenPGP certificates and keys for use when generating such samples.
The OpenPGP development community, in particular the e-mail development community, benefits from sharing samples of signed and/or encrypted data. Often the exact key material used does not matter because the properties being tested pertain to implementation correctness, completeness or interoperability of the overall system. However, without access to the relevant secret key material, a sample is useless.
This document defines a small set of OpenPGP certificates and secret keys for use when generating or operating on such samples.
Samples are provided for two “personas”, Alice and Bob. Alice uses keys based on the Ed25519 elliptic curve algorithm, but Bob is a bit behind the times and has a 3072-bit RSA key.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
This document makes use of the terminology section from .
Properties:
OpenPGP Version: 4
Fingerprint: EB85 BB5F A33A 75E1 5E94 4E63 F231 550C 4F47 E38E
Primary key algorithm: Ed25519
Primary key creation date: Tue Jan 22 11:56:25 GMT 2019
Primary key capabilities: certify, sign
User ID: Alice Lovelace <alice@openpgp.example>
Symmetric algorithm preferences: AES-256, AES-192, AES-128, 3DES
Hash algorithm preferences: SHA512, SHA384, SHA256, SHA224, SHA1
Compresson algorithm preferences: ZLIB, BZip2, ZIP
Subkey algorithm: Curve25519
Subkey capabilities: encrypt
Subkey creation date: Tue Jan 22 11:56:25 GMT 2019
There are no expiration dates in the entire certificate
The secret key material is in the clear (no password)
All OpenPGP signature packets contain a hashed Issuer Fingerprint
subpacket (see
Properties:
OpenPGP Version: 4
Fingerprint: D1A6 6E1A 23B1 82C9 980F 788C FBFC C82A 015E 7330
Primary key algorithm: RSA 3072
Primary key creation date: Tue Oct 15 10:18:26 GMT 2019
Primary key capabilities: certify, sign
User ID: Bob Babbage <bob@openpgp.example>
Symmetric algorithm preferences: AES-256, AES-192, AES-128, 3DES
Hash algorithm preferences: SHA512, SHA384, SHA256, SHA224, SHA1
Compresson algorithm preferences: ZLIB, BZip2, ZIP
Subkey algorithm: RSA 3072
Subkey capabilities: encrypt
Subkey creation date: Tue Oct 15 10:18:26 GMT 2019
There are no expiration dates in the entire certificate
The secret key material is in the clear (no password)
All OpenPGP signature packets contain a hashed Issuer Fingerprint
subpacket (see
The keys presented in this document should be considered compromised and insecure, because the secret key material is published and therefore not secret.
Applications which maintain blacklists of invalid key material SHOULD include these keys in their lists.
IANA has nothing to do for this document.
[ RFC Editor: please remove this section before publication ]
This document is currently edited as markdown. Minor editorial
changes can be suggested via merge requests at
https://gitlab.com/openpgp-wg/openpgp-samples or by e-mail to the
authors. Please direct all significant commentary to the public IETF
OpenPGP mailing list: openpgp@ietf.org
The authors would like to acknowledge the help and input of the other
participants at the OpenPGP e-mail summit 2019
.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
OpenPGP Message Format
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]
OpenPGP Message Format
{ Work in progress to update the OpenPGP specification from RFC4880 } This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.
OpenPGP Email Summit 2019
Abuse-Resistant OpenPGP Keystores
OpenPGP transferable public keys are composite certificates, made up of primary keys, direct key signatures, user IDs, identity certifications ("signature packets"), subkeys, and so on. They are often assembled by merging multiple certificates that all share the same primary key, and are distributed in public keystores. Unfortunately, since many keystores permit any third-party to add a certification with any content to any OpenPGP certificate, the assembled/merged form of a certificate can become unwieldy or undistributable. Furthermore, keystores that are searched by user ID or fingerprint can be made unusable for specific searches by public submission of bogus certificates. And finally, keystores open to public submission can also face simple resource exhaustion from flooding with bogus submissions, or legal or other risks from uploads of toxic data. This draft documents techniques that an archive of OpenPGP certificates can use to mitigate the impact of these various attacks, and the implications of these concerns and mitigations for the rest of the OpenPGP ecosystem.