| |
|
| |
| | Header Protection for Cryptographically Protected E-mail |
| |
|
S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification (RFC8551) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit usability, privacy, and security guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. The Header Protection scheme defined here is also applicable to messages with PGP/MIME cryptographic protections. |
| | Guidance on End-to-End E-mail Security |
| |
|
End-to-end cryptographic protections for e-mail messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for mail user agent implementers to help mitigate those risks, and to make end-to-end e-mail simple and secure for the end user. It provides a useful set of vocabulary as well as recommendations to avoid common failures. It also identifies a number of currently unsolved usability and interoperability problems. |
| | Clarification and enhancement of RFC7030 CSR Attributes definition |
| |
| | draft-ietf-lamps-rfc7030-csrattrs-23.txt |
| | Date: |
28/06/2025 |
| | Authors: |
Michael Richardson, Owen Friel, David von Oheimb, Dan Harkins |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document updates RFC7030, Enrollment over Secure Transport (EST), clarifying how the Certificate Signiing Request (CSR) Attributes Response can be used by an EST server to specify both CSR attribute Object IDs (OID) and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. RFC9148 is derived from RFC7030, and it is also updated. RFC7030 (EST) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. As a result, there was not universal understanding of what was specified. This document clarifies the encoding rules. This document therefore also provides a new straightforward approach: using a template for CSR contents that may be partially filled in by the server. This also allows an EST server to specify a subject Distinguished Name (DN). |
| | Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) |
| |
|
The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). This document specifies the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. |
| | Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) |
| |
|
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. |
| | Use of ML-KEM in the Cryptographic Message Syntax (CMS) |
| |
| | draft-ietf-lamps-cms-kyber-11.txt |
| | Date: |
01/07/2025 |
| | Authors: |
Julien Prat, Mike Ounsworth, Daniel Van Geest |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). Three parameter sets for the ML-KEM algorithm are specified by NIST in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML-KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure. |
| | Composite ML-KEM for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-kem-07.txt |
| | Date: |
16/06/2025 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of ML-KEM [FIPS.203] in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. |
| | Use of Remote Attestation with Certification Signing Requests |
| |
| | draft-ietf-lamps-csr-attestation-20.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Mike Ounsworth, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of Evidence and Attestation Results in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This provides an elegant and automatable mechanism for transporting Evidence to a Certification Authority. Including Evidence and Attestation Results along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. |
| | Updates to Lightweight OCSP Profile for High Volume Environments |
| |
| | draft-ietf-lamps-rfc5019bis-12.txt |
| | Date: |
13/09/2024 |
| | Authors: |
Tadahiko Ito, Clint Wilson, Corey Bonnell, Sean Turner |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing. This specification obsoletes RFC 5019. The profile specified in RFC 5019 has been updated to allow and recommend the use of SHA-256 over SHA-1. |
| | Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA |
| |
| | draft-ietf-lamps-x509-slhdsa-09.txt |
| | Date: |
30/06/2025 |
| | Authors: |
Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, Stavros Kousidis |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Digital signatures are used within X.509 Public Key Infrastructure such as X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified. |
| | Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) |
| |
|
When an end entity includes attestation Evidence in a Certificate Signing Request (CSR), it may be necessary to demonstrate the freshness of the provided Evidence. Current attestation technology commonly achieves this using nonces. This document outlines the process through which nonces are supplied to the end entity by an RA/CA for inclusion in Evidence, leveraging the Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) |
| | Composite ML-DSA for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-sigs-07.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-DSA is applicable in any application that uses X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. |
| | Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax |
| |
|
This document specifies additions and amendments to RFCs 7292 and 8018. It also obsoletes the RFC 9579. It defines a way to use the Password-Based Message Authentication Code 1 (PBMAC1), defined in RFC 8018, inside the PKCS #12 syntax. The purpose of this specification is to permit the use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance. |
| | Certificate Management over CMS (CMC) |
| |
|
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: |
| | Certificate Management over CMS (CMC): Transport Protocols |
| |
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. This document obsoletes RFC 5273 and RFC 6402. |
| | Certificate Management Messages over CMS (CMC): Compliance Requirements |
| |
|
This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. This document obsoletes RFC 5274 and RFC 6402. |
| | Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined by NIST in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. |
| | An Attribute for Statement of Possession of a Private Key |
| |
|
This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate. |
| | Unsigned X.509 Certificates |
| |
|
This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate is not expected to verify the signature. As part of this, it updates RFC 5280. |
| | A Mechanism for X.509 Certificate Discovery |
| |
| | draft-ietf-lamps-certdiscovery-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Tomofumi Okubo, Corey Bonnell, John Gray, Mike Ounsworth, Joe Mandel |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether to fetch the Secondary Certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of Primary Certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. |
| | CAA Security Tag for Cryptographically-Constrained Domain Validation |
| |
| | draft-ietf-lamps-caa-security-02.txt |
| | Date: |
20/06/2025 |
| | Authors: |
Henry Birge-Lee, Grace Cimaszewski, Cyrill Kraehenbuehl, Liang Wang, Aaron Gable, Prateek Mittal |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Cryptographic domain validation procedures leverage authenticated communication channels to ensure resilience against attacks by both on-path and off-path network adversaries which attempt to tamper with communications between the Certification Authority (CA) and the network resources related to the domain contained in the certificate. Domain owners can leverage "security" Property Tags specified in CAA records (defined in [RFC8659]) with the critical flag set, to ensure that CAs perform cryptographically-constrained domain validation during their issuance procedure, hence defending against global man- in-the-middle adversaries. This document defines the syntax of the CAA security Property as well as acceptable means for cryptographically-constrained domain validation procedures. |
| | Clarification to processing Key Usage values during CRL validation |
| |
|
RFC 5280 defines the profile of X.509 certificates and certificate revocation lists (CRLs) for use in the Internet. This profile requires that certificates which certify keys for signing CRLs contain the key usage extension with the cRLSign bit asserted. Additionally, RFC 5280 defines steps for the validation of CRLs. While there is a requirement for CRL validators to verify that the cRLSign bit is asserted in the keyUsage extension of the CRL issuer's certificate, this document clarifies the requirement for relying parties to also verify the presence of the keyUsage extension in the CRL issuer's certificate. This check remediates a potential security issue that arises when relying parties accept a CRL which is signed by a certificate with no keyUsage extension, and therefore does not explicitly have the cRLSign bit asserted. |
| | PKCS #8 Private-Key Information Content Types |
| |
|
This document defines PKCS #8 content types for use with PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958. |