S/MIME Example Keys and Certificates

Introduction The S/MIME () 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 X.509v3 certificates () and secret keys for use when generating or operating on such samples. An example certificate authority is supplied, and samples are provided for two "personas", Alice and Bob.

Requirements Language 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.

Terminology

"Certificate Authority" (or "CA") is a party capable of issuing X.509 certificates
"End-Entity" is a party that is capable of using X.509 certificates (and their corresponding secret key material)
"Mail User Agent" (or "MUA") is a program that generates or handles e-mail messages.

Prior Work contains some sample certificates, as well as messages of various S/MIME formats. That older work has unacceptably old algorithm choices that may introduce failures when testing modern systems: in 2019, some tools explicitly mark 1024-bit RSA and 1024-bit DSS as weak. This earlier document also does not use the now widely-accepted PEM encoding for the objects, and instead embeds runnable perl code to extract them from the document. It also includes examples of messages and other structures which are greater in ambition than this document intends to be. This document intends to focus specifically on identity and key material, as a starting point for other documents that can develop examples or test cases from them.

Background

Certificate Usage These X.509 certificates () are designed for use with S/MIME protections () for e-mail (). In particular, they should be usable with signed and encrypted messages.

Certificate Expiration The certificates included in this draft expire in 2052. This should be sufficiently far in the future that they will be useful for a few decades. However, when testing tools in the far future (or when playing with clock skew scenarios), care should be taken to consider the certificate validity window. Due to this lengthy expiration window, these certificates will not be particularly useful to test or evaluate the interaction between certificate expiration and protected messages.

Certificate Revocation Because these are expected to be used in test suites or examples, and we do not expect there to be online network services in these use cases, we do not expect these certificates to produce any revocation artifacts. As a result, there are no OCSP or CRL indicators in any of the certificates.

Using the CA in Test Suites To use these end-entity certificates in a piece of software (for example, in a test suite or an interoperability matrix), most tools will need to accept the example CA () as a legitimate root authority. Note that some tooling behaves differently for certificates validated by "locally-installed root CAs" than for pre-installed "system-level" root CAs). For example, many common implementations of HPKP () only applied the designed protections when dealing with a certificate issued by a pre-installed "system-level" root CA, and were disabled when dealing with a certificate issued by a "locally-installed root CA". To test some tooling specifically, it may be necessary to install the root CA as a "system-level" root CA.

Certificate Chains In most real-world examples, X.509 certificates are deployed with a chain of more than one X.509 certificate. In particular, there is typically a long-lived root CA that users' software knows about upon installation, and the end-entity certificate is issued by an intermediate CA, which is in turn issued by the root CA. The examples presented in this document use a simple two-link certificate chain, and therefore may be unsuitable for simulating some real-world deployments. In particular, testing the use of a "transvalid" certificate (an end-entity certificate that is supplied without its intermediate certificate) is not possible with the configuration here.

Passwords Each secret key presented in this draft is unprotected (it has no password). As such, the secret key objects are not suitable for verifying interoperable password protection schemes. However, the PKCS#12 objects do have simple textual passwords, because tooling for dealing with passwordless PKCS#12 objects is underdeveloped at the time of this draft.

Secret key origins The secret keys in this document are all deterministically derived using provable prime generation as found in , based on known seeds derived via from simple strings. The seeds and their derivation are included in the document for informational purposes, and to allow re-creation of the objects from appropriate tooling. All seeds used are 224 bits long (the first 224 bits of the SHA-256 digest of the origin string), and are represented in hexadecimal.

Example Certificate Authority The example Certificate Authority has the following information:

Name: Sample LAMPS Certificate Authority

Certificate Authority Certificate This cerificate is used to verify certificates issued by the example Certificate Authority.

Certificate Authority Secret Key This secret key material is used by the example Certificate Authority to issue new certificates. This secret key was generated using provable prime generation found in using the seed f05461b8dd3517a5c943dea7cea99117c87443ccf4dfb23dcb537c1d. This seed is the first 224 bits of the digest of the string draft-lamps-sample-certs-keygen.ca.seed.

Alice's Sample Certificates Alice has the following information:

Name: Alice Lovelace
E-mail Address: alice@smime.example

Alice's Signature Verification End-Entity Certificate This certificate is used for verification of signatures made by Alice.

Alice's Signing Private Key Material This private key material is used by Alice to create signatures. This secret key was generated using provable prime generation found in using the seed 92c89d4330d3d8e31d4fde9b9d0fe6e9fc142141dd65a45e5b436f05. This seed is the first 224 bits of the digest of the string draft-lamps-sample-certs-keygen.alice.sign.seed.

Alice's Encryption End-Entity Certificate This certificate is used to encrypt messages to Alice.

Alice's Decryption Private Key Material This private key material is used by Alice to decrypt messages. This secret key was generated using provable prime generation found in using the seed 1cf74849f7445f466c4272251f5f96b77fa0698b3e98b3f1ee8207bf. This seed is the first 224 bits of the digest of the string draft-lamps-sample-certs-keygen.alice.encrypt.seed.

PKCS12 Object for Alice This PKCS12 () object contains the same information as presented in , , , , and . It is locked with the simple five-letter password alice.

Bob's Sample Bob has the following information:

Name: Bob Babbage
E-mail Address: bob@smime.example

Bob's Signature Verification End-Entity Certificate This certificate is used for verification of signatures made by Bob.

Bob's Signing Private Key Material This private key material is used by Bob to create signatures. This secret key was generated using provable prime generation found in using the seed f4afaacbb5473f360e06ac32e00188fe4173ae15c99bcf043a8b8f6e. This seed is the first 224 bits of the digest of the string draft-lamps-sample-certs-keygen.bob.sign.seed.

Bob's Encryption End-Entity Certificate This certificate is used to encrypt messages to Bob.

Bob's Decryption Private Key Material This private key material is used by Bob to decrypt messages. This secret key was generated using provable prime generation found in using the seed 98c8998652958929e889e3419f3bfd0edfe0aca15da3060dedf8a1e8. This seed is the first 224 bits of the digest of the string draft-lamps-sample-certs-keygen.bob.encrypt.seed.

PKCS12 Object for Bob This PKCS12 () object contains the same information as presented in , , , , and . It is locked with the simple three-letter password bob.

Security Considerations 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 Considerations IANA has nothing to do for this document.

Document Considerations [ 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/dkg/lamps-samples or by e-mail to the author. Please direct all significant commentary to the public IETF LAMPS mailing list: spasm@ietf.org

Document History

Substantive Changes from -03 to -04

Describe deterministic key generation
label PEM blobs with filenames in XML

Substantive Changes from -02 to -03

Alice and Bob now each have two distinct certificates: one for signing, one for encryption, and public keys to match.

Substantive Changes from -01 to -02

PKCS#12 objects are deliberately locked with simple passphrases

Substantive Changes from -00 to -01

changed all three keys to use RSA instead of RSA-PSS
set keyEncipherment keyUsage flag instead of dataEncipherment in EE certs

Acknowledgements This draft was inspired by similar work in the OpenPGP space by Bjarni Runar and juga at . Eric Rescorla helped spot issues with certificate formats. Sean Turner pointed to as prior work. Deb Cooley suggested that Alice and Bob should have separate certificates for signing and encryption. Wolfgang Hommel helped to build reproducible encrypted PKCS#12 objects.