Internet-Draft	S/MIME Example Keys and Certificates	December 2021
Gillmor	Expires 16 June 2022	[Page]

Workgroup:: lamps
Internet-Draft:: draft-ietf-lamps-samples-06
Published:: 13 December 2021
Intended Status:: Informational
Expires:: 16 June 2022
Author:: D.K. Gillmor, Ed.

ACLU

S/MIME Example Keys and Certificates

Abstract

The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 16 June 2022.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

▲

1. Introduction

The S/MIME ([RFC8551]) 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 ([RFC5280]) and secret keys for use when generating or operating on such samples.¶

An example RSA certification authority is supplied, and sample RSA certificates are provided for two "personas", Alice and Bob.¶

Additionally, an Ed25519 ([RFC8032]) certification authority is supplied, along with sample Ed25519 certificates for two more "personas", Carlos and Dana.¶

This document focuses narrowly on functional, well-formed identity and key material. It is a starting point that other documents can use to develop sample signed or encrypted messages, test vectors, or other artifacts for improved interoperability.¶

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Terminology

"Certification 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 [RFC5322] e-mail messages.¶

1.3. Prior Work

[RFC4134] 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 (see [RFC7468]) 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.¶

[RFC8410] includes an example X25519 certificate that is certified with Ed25519, but it appears to be self-issued, and it is not directly useful in testing an S/MIME-capable MUA.¶

2. Background

2.1. Certificate Usage

These X.509 certificates ([RFC5280]) are designed for use with S/MIME protections ([RFC8551]) for e-mail ([RFC5322]).¶

In particular, they should be usable with signed and encrypted messages, as part of test suites and interoperability frameworks.¶

All end-entity and intermediate CA certificates are marked with Certificate Policies from [TEST-POLICY] indicating that they are intended only for use in testing environments. End-entity certificates are marked with policy 2.16.840.1.101.3.2.1.48.1 and intermediate CAs are marked with policy 2.16.840.1.101.3.2.1.48.2.¶

2.2. 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.¶

2.3. 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, none of the certificates include either an OCSP indicator (see id-ad-ocsp as defined in the Authority Information Access X.509 extension in S.4.2.2.1 of [RFC5280]) or a CRL indicator (see the CRL Disttribution Points X.509 extension as defined in S.4.2.1.13 of [RFC5280]).¶

2.4. 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 either the Example RSA CA (Section 3) or the Example Ed25519 CA (Section 6) 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 ([RFC7469]) 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.¶

2.5. 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 example end-entity certificates in this document can be used with either a simple two-link certificate chain (they are directly certified by their corresponding root CA), or in a three-link chain.¶

For example, Alice's encryption certificate (Section 4.3, alice.encrypt.crt) can be validated by a peer that directly trusts the Example RSA CA's root cert (Section 3.1, ca.rsa.crt):¶

╔════════════╗  ┌───────────────────┐
║ ca.rsa.crt ╟─→│ alice.encrypt.crt │
╚════════════╝  └───────────────────┘

And it can also be validated by a peer that only directly trusts the Example Ed25519 CA's root cert (Section 6.1, ca.25519.crt), via an intermediate cross-signed CA cert (Section 3.3, ca.rsa.cross.crt):¶

╔══════════════╗  ┌──────────────────┐  ┌───────────────────┐
║ ca.25519.crt ╟─→│ ca.rsa.cross.crt ├─→│ alice.encrypt.crt │
╚══════════════╝  └──────────────────┘  └───────────────────┘

By omitting the cross-signed CA certs, it should be possible to test a "transvalid" certificate (an end-entity certificate that is supplied without its intermediate certificate) in some configurations.¶

2.6. 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 [RFC7292] objects do have simple textual passwords, because tooling for dealing with passwordless PKCS#12 objects is underdeveloped at the time of this draft.¶

2.7. Secret key origins

The secret RSA keys in this document are all deterministically derived using provable prime generation as found in [FIPS186-4], based on known seeds derived via [SHA256] from simple strings. The secret Ed25519 and X25519 keys in this document are all derived by hashing a simple string. 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 RSA seeds used are 224 bits long (the first 224 bits of the SHA-256 digest of the origin string), and are represented in hexadecimal.¶

3. Example RSA Certification Authority

The example RSA Certification Authority has the following information:¶

Name: Sample LAMPS RSA Certification Authority¶

3.1. RSA Certification Authority Root Certificate

This certificate is used to verify certificates issued by the example RSA Certification Authority.¶

3.2. RSA Certification Authority Secret Key

This secret key material is used by the example RSA Certification Authority to issue new certificates.¶

This secret key was generated using provable prime generation found in [FIPS186-4] using the seed a5c1b7847614ed661a6b0522351428b4b7f09d8ccca2d99302dd62e9. This seed is the first 224 bits of the [SHA256] digest of the string draft-lamps-sample-certs-keygen.ca.rsa.seed.¶

3.3. RSA Certification Authority Cross-signed Certificate

If an e-mail client only trusts the Ed25519 Certification Authority Root Certificate found in Section 6.1, they can use this intermediate CA certificate to verify any end entity certificate issued by the example RSA Certification Authority.¶

4. Alice's Sample Certificates

Alice has the following information:¶

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

4.1. Alice's Signature Verification End-Entity Certificate

This certificate is used for verification of signatures made by Alice.¶

4.2. 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 [FIPS186-4] using the seed 92c89d4330d3d8e31d4fde9b9d0fe6e9fc142141dd65a45e5b436f05. This seed is the first 224 bits of the [SHA256] digest of the string draft-lamps-sample-certs-keygen.alice.sign.seed.¶

4.3. Alice's Encryption End-Entity Certificate

This certificate is used to encrypt messages to Alice.¶

4.4. 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 [FIPS186-4] using the seed 1cf74849f7445f466c4272251f5f96b77fa0698b3e98b3f1ee8207bf. This seed is the first 224 bits of the [SHA256] digest of the string draft-lamps-sample-certs-keygen.alice.encrypt.seed.¶

4.5. PKCS12 Object for Alice

This PKCS12 ([RFC7292]) object contains the same information as presented in Section 4.1, Section 4.2, Section 4.3, Section 4.4, and Section 3.3.¶

It is locked with the simple five-letter password alice.¶

5. Bob's Sample

Bob has the following information:¶

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

5.1. Bob's Signature Verification End-Entity Certificate

This certificate is used for verification of signatures made by Bob.¶

5.2. 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 [FIPS186-4] using the seed f4afaacbb5473f360e06ac32e00188fe4173ae15c99bcf043a8b8f6e. This seed is the first 224 bits of the [SHA256] digest of the string draft-lamps-sample-certs-keygen.bob.sign.seed.¶

5.3. Bob's Encryption End-Entity Certificate

This certificate is used to encrypt messages to Bob.¶

5.4. 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 [FIPS186-4] using the seed 98c8998652958929e889e3419f3bfd0edfe0aca15da3060dedf8a1e8. This seed is the first 224 bits of the [SHA256] digest of the string draft-lamps-sample-certs-keygen.bob.encrypt.seed.¶

5.5. PKCS12 Object for Bob

This PKCS12 ([RFC7292]) object contains the same information as presented in Section 5.1, Section 5.2, Section 5.3, Section 5.4, and Section 3.3.¶

It is locked with the simple three-letter password bob.¶

6. Example Ed25519 Certification Authority

The example Ed25519 Certification Authority has the following information:¶

Name: Sample LAMPS Ed25519 Certification Authority¶

6.1. Ed25519 Certification Authority Root Certificate

This certificate is used to verify certificates issued by the example Ed25519 Certification Authority.¶

6.2. Ed25519 Certification Authority Secret Key

This secret key material is used by the example Ed25519 Certification Authority to issue new certificates.¶

-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIAt889xRDvxNT8ak53T7tzKuSn6CQDe8fIdjrCiSFRcp
-----END PRIVATE KEY-----

This secret key is the [SHA256] digest of the ASCII string draft-lamps-sample-certs-keygen.ca.25519.seed.¶

6.3. Ed25519 Certification Authority Cross-signed Certificate

If an e-mail client only trusts the RSA Certification Authority Root Certificate found in Section 3.1, they can use this intermediate CA certificate to verify any end entity certificate issued by the example Ed25519 Certification Authority.¶

7. Carlos's Sample Certificates

Carlos has the following information:¶

Name: Carlos Turing¶
E-mail Address: carlos@smime.example¶

7.1. Carlos's Signature Verification End-Entity Certificate

This certificate is used for verification of signatures made by Carlos.¶

7.2. Carlos's Signing Private Key Material

This private key material is used by Carlos to create signatures.¶

-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEILvvxL741LfX+Ep3Iyye3Cjr4JmONIVYhZPM4M9N1IHY
-----END PRIVATE KEY-----

This secret key is the [SHA256] digest of the ASCII string draft-lamps-sample-certs-keygen.carlos.sign.25519.seed.¶

7.3. Carlos's Encryption End-Entity Certificate

This certificate is used to encrypt messages to Carlos. It contains an SMIMECapabilities extension to indicate that Carlos's MUA expects ECDH with HKDF using SHA-256; uses AES-128 key wrap, as indicated in [RFC8418].¶

7.4. Carlos's Decryption Private Key Material

This private key material is used by Carlos to decrypt messages.¶

-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VuBCIEIIH5782H/otrhLy9Dtvzt79ffsvpcVXgdUczTdUvSQsK
-----END PRIVATE KEY-----

This secret key is the [SHA256] digest of the ASCII string draft-lamps-sample-certs-keygen.carlos.encrypt.25519.seed.¶

7.5. PKCS12 Object for Carlos

This PKCS12 ([RFC7292]) object contains the same information as presented in Section 7.1, Section 7.2, Section 7.3, Section 7.4, and Section 6.3.¶

It is locked with the simple five-letter password carlos.¶

8. Dana's Sample Certificates

Dana has the following information:¶

Name: Dana Hopper¶
E-mail Address: dna@smime.example¶

8.1. Dana's Signature Verification End-Entity Certificate

This certificate is used for verification of signatures made by Dana.¶

8.2. Dana's Signing Private Key Material

This private key material is used by Dana to create signatures.¶

-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEINZ8GPfmQh2AMp+uNIsZMbzvyTOltwvEt13usjnUaW4N
-----END PRIVATE KEY-----

This secret key is the [SHA256] digest of the ASCII string draft-lamps-sample-certs-keygen.dana.sign.25519.seed.¶

8.3. Dana's Encryption End-Entity Certificate

This certificate is used to encrypt messages to Dana. It contains an SMIMECapabilities extension to indicate that Dana's MUA expects ECDH with HKDF using SHA-256; uses AES-128 key wrap, as indicated in [RFC8418].¶

8.4. Dana's Decryption Private Key Material

This private key material is used by Dana to decrypt messages.¶

-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VuBCIEIGxZt8L7lY48OEq4gs/smQ4weDhRNMlYHG21StivPfz3
-----END PRIVATE KEY-----

This seed is the [SHA256] digest of the ASCII string draft-lamps-sample-certs-keygen.dana.encrypt.25519.seed.¶

8.5. PKCS12 Object for Dana

This PKCS12 ([RFC7292]) object contains the same information as presented in Section 8.1, Section 8.2, Section 8.3, Section 8.4, and Section 6.3.¶

It is locked with the simple four-letter password dana.¶

9. 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.¶

Any application which maintains a denylist of invalid key material SHOULD include these keys in its list.¶

10. IANA Considerations

IANA has nothing to do for this document.¶

11. 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¶

11.1. Document History

11.1.1. Substantive Changes from draft-ietf--04 to draft-ietf--05

Added outbound references for acronyms PEM, CRL, and OCSP, thanks Stewart Brant.¶

11.1.2. Substantive Changes from draft-ietf--04 to draft-ietf--05

Switch from SHA512 to SHA1 as MAC checksum in PKCS#12 objects, for interop with Keychain Access on macOS.¶

11.1.3. Substantive Changes from draft-ietf--03 to draft-ietf--04

Order subject/issuer DN components by scope.¶
Put cross-signed intermediate CA certificates into PKCS#12 instead of self-signed root CA certificates.¶

11.1.4. Substantive Changes from draft-ietf--02 to draft-ietf--03

Correct encoding of S/MIME Capabilities extension.¶
Change "Certificate Authority" to "Certification Authority".¶
Add CertificatePolicies to all intermediate and end-entity certificates.¶
Add organization and organizational unit to all certificates.¶

11.1.5. Substantive Changes from draft-ietf--01 to draft-ietf--02

Added cross-signed certificates for both CAs¶
Added S/MIME Capabilities extension for Carlos and Dana's encryption keys, indicating preferred ECDH parameters.¶
Ensure no serial numbers are negative.¶
Encode keyUsage extensions in minimum-length BIT STRINGs.¶

11.1.6. Substantive Changes from draft-ietf--00 to draft-ietf--01

Added Curve25519 sample certificates (new CA, Carlos, and Dana)¶

11.1.7. Substantive Changes from draft-dkg--05 to draft-ietf--00

WG adoption (dkg moves from Author to Editor)¶

11.1.8. Substantive Changes from draft-dkg--04 to draft-dkg--05

PEM blobs are now sourcecode, not artwork¶

11.1.9. Substantive Changes from draft-dkg--03 to draft-dkg--04

Describe deterministic key generation¶
label PEM blobs with filenames in XML¶

11.1.10. Substantive Changes from draft-dkg--02 to draft-dkg--03

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

11.1.11. Substantive Changes from draft-dkg--01 to draft-dkg--02

PKCS#12 objects are deliberately locked with simple passphrases¶

11.1.12. Substantive Changes from draft-dkg--00 to draft-dkg--01

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

12. Acknowledgements

This draft was inspired by similar work in the OpenPGP space by Bjarni Runar and juga at [I-D.bre-openpgp-samples].¶

Eric Rescorla helped spot issues with certificate formats.¶

Sean Turner pointed to [RFC4134] 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.¶

Carsten Bormann got the XML sourcecode markup working for this draft.¶

David A. Cooper identified problems with the certificates and suggested corrections.¶

Lijun Liao helped get the terminology right.¶

Stewart Brant and Roman Danyliw provided editorial suggestions.¶

13. References

13.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC5280]: Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5322]: Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC7292]: Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, <https://www.rfc-editor.org/info/rfc7292>.
[RFC8032]: Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8551]: Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.

13.2. Informative References

[FIPS186-4]: "Digital Signature Standard (DSS)", National Institute of Standards and Technology report, DOI 10.6028/nist.fips.186-4, July 2013, <https://doi.org/10.6028/nist.fips.186-4>.
[I-D.bre-openpgp-samples]: Einarsson, B. R., juga, and D. K. Gillmor, "OpenPGP Example Keys and Certificates", Work in Progress, Internet-Draft, draft-bre-openpgp-samples-01, 20 December 2019, <https://www.ietf.org/archive/id/draft-bre-openpgp-samples-01.txt>.
[RFC4134]: Hoffman, P., Ed., "Examples of S/MIME Messages", RFC 4134, DOI 10.17487/RFC4134, July 2005, <https://www.rfc-editor.org/info/rfc4134>.
[RFC7468]: Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC7469]: Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC8410]: Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, <https://www.rfc-editor.org/info/rfc8410>.
[RFC8418]: Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)", RFC 8418, DOI 10.17487/RFC8418, August 2018, <https://www.rfc-editor.org/info/rfc8418>.
[SHA256]: Dang, Q., "Secure Hash Standard", National Institute of Standards and Technology report, DOI 10.6028/nist.fips.180-4, July 2015, <https://doi.org/10.6028/nist.fips.180-4>.
[TEST-POLICY]: NIST - Computer Security Divisiion (CSD), "Test Certificate Policy to Support PKI Pilots and Testing", May 2012, <https://csrc.nist.gov/CSRC/media/Projects/Computer-Security-Objects-Register/documents/test_policy.pdf>.

Author's Address

Daniel Kahn Gillmor (editor)

American Civil Liberties Union

125 Broad St.

New York, NY, 10004

United States of America

Email: dkg@fifthhorseman.net

Document	Document type	This is an older version of an Internet-Draft that was ultimately published as RFC 9216.
	Select version	00 01 02 03 04 05 06 07 08 RFC 9216
	Compare versions
	Author	Daniel Kahn Gillmor
	Replaces	draft-dkg-lamps-samples
	RFC stream
	Other formats	txt html xml pdf bibtex bibxml
	Additional resources	Mailing list discussion