Movatterモバイル変換

RFC 9216	S/MIME	April 2022
Gillmor	Informational	[Page]

2.Background

2.1.Certificate Usage

These X.509 certificates ([RFC5280]) are designed for use with S/MIME protections ([RFC8551]) for email ([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 document 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 Online Certificate Status Protocol (OCSP) indicator (seeid-ad-ocsp as defined in the Authority Information Access X.509 extension inSection 4.2.2.1 of [RFC5280]) or a Certificate Revocation List (CRL) indicator (see the CRL Distribution Points X.509 extension as defined inSection 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 HTTP Public Key Pinning (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 either with 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 (alice.encrypt.crt; seeSection 4.3) can be validated by a peer that directly trusts the example RSA CA's root cert (ca.rsa.crt; seeSection 3.1):¶

Figure 1:Validating Alice's encryption certificate directly when the issuing CA is a trust anchor

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

Figure 2:Validating Alice's cert from a different trust anchor via an intermediate cross-signed CA certificate

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 document is represented as a PEM-encoded PKCS #8 ([RFC5958]) object in cleartext form (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 document.¶

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 SHA-256 ([SHA]) from simple strings.The validation parameters for these derivations are stored in the objects themselves as specified in[RFC8479].¶

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 recreation 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 seeda5c1b7847614ed661a6b0522351428b4b7f09d8ccca2d99302dd62e9. This seed is the first 224 bits of the SHA-256 ([SHA]) digest of the stringdraft-lamps-sample-certs-keygen.ca.rsa.seed.¶

3.3.RSA Certification Authority Cross-Signed Certificate

If an email client only trusts the Ed25519 Certification Authority Root Certificate found inSection 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¶
Email 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 seed92c89d4330d3d8e31d4fde9b9d0fe6e9fc142141dd65a45e5b436f05. This seed is the first 224 bits of the SHA-256 ([SHA]) digest of the stringdraft-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 seed1cf74849f7445f466c4272251f5f96b77fa0698b3e98b3f1ee8207bf.This seed is the first 224 bits of the SHA-256 ([SHA]) digest of the stringdraft-lamps-sample-certs-keygen.alice.encrypt.seed.¶

4.5.PKCS #12 Object for Alice

This PKCS #12 ([RFC7292]) object contains the same information as presented in Sections3.3,4.1,4.2,4.3, and4.4.¶

It is locked with the simple five-letter passwordalice.¶

5.Bob's Sample

Bob has the following information:¶

Name:: Bob Babbage¶
Email 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 seedf4afaacbb5473f360e06ac32e00188fe4173ae15c99bcf043a8b8f6e. This seed is the first 224 bits of the SHA-256 ([SHA]) digest of the stringdraft-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 seed98c8998652958929e889e3419f3bfd0edfe0aca15da3060dedf8a1e8. This seed is the first 224 bits of the SHA-256 ([SHA]) digest of the stringdraft-lamps-sample-certs-keygen.bob.encrypt.seed.¶

5.5.PKCS #12 Object for Bob

This PKCS #12 ([RFC7292]) object contains the same information as presented in Sections3.3,5.1,5.2,5.3, and5.4.¶

It is locked with the simple three-letter passwordbob.¶

7.Carlos's Sample Certificates

Carlos has the following information:¶

Name:: Carlos Turing¶
Email 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 SHA-256 ([SHA]) digest of the ASCII stringdraft-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 MUAexpects Elliptic Curve Diffie-Hellman (ECDH) with the HMAC-based KeyDerivation Function (HKDF) using SHA-256, and that it uses the AES-128 key wrap algorithm,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 SHA-256 ([SHA]) digest of the ASCII stringdraft-lamps-sample-certs-keygen.carlos.encrypt.25519.seed.¶

7.5.PKCS #12 Object for Carlos

This PKCS #12 ([RFC7292]) object contains the same information as presented in Sections6.3,7.1,7.2,7.3, and7.4.¶

It is locked with the simple five-letter passwordcarlos.¶

8.Dana's Sample Certificates

Dana has the following information:¶

Name:: Dana Hopper¶
Email 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 SHA-256 ([SHA]) digest of the ASCII stringdraft-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, and that it uses the AES-128 key wrap algorithm, 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 SHA-256 ([SHA]) digest of the ASCII stringdraft-lamps-sample-certs-keygen.dana.encrypt.25519.seed.¶

8.5.PKCS #12 Object for Dana

This PKCS #12 ([RFC7292]) object contains the same information as presented in Sections6.3,8.1,8.2,8.3, and8.4.¶

It is locked with the simple four-letter passworddana.¶

Movatterモバイル変換

RFC 9216

S/MIME Example Keys and Certificates