|
|
| |
| 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. The Header Protection schemes described here are also applicable to messages with PGP/MIME cryptographic protections. Furthermore, this document offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. |
| 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. |
| Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP) |
|
| draft-ietf-lamps-rfc4210bis-10.txt |
| Date: |
06/05/2024 |
| Authors: |
Hendrik Brockhaus, David von Oheimb, Mike Ounsworth, John Gray |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document obsoletes RFC 4210 by including the updates specified by CMP Updates RFC 9480 Section 2 and Appendix A.2 maintaining backward compatibility with CMP version 2 wherever possible and obsoletes both documents. Updates to CMP version 2 are: improving crypto agility, extending the polling mechanism, adding new general message types, and adding extended key usages to identify special CMP server authorizations. Introducing CMP version 3 to be used only for changes to the ASN.1 syntax, which are: support of EnvelopedData instead of EncryptedValue, hashAlg for indicating a hash AlgorithmIdentifier in certConf messages, and RootCaKeyUpdateContent in ckuann messages. In addition to the changes specified in CMP Updates RFC 9480 this document adds support for management of KEM certificates. |
| Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) |
|
| draft-ietf-lamps-rfc6712bis-05.txt |
| Date: |
20/03/2024 |
| Authors: |
Hendrik Brockhaus, David von Oheimb, Mike Ounsworth, John Gray |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It includes the updates on RFC 6712 specified in CMP Updates RFC 9480 Section 3 and obsoleted both documents. These updates introduce CMP URIs using a Well-known prefix. |
| Clarification of RFC7030 CSR Attributes definition |
|
| draft-ietf-lamps-rfc7030-csrattrs-09.txt |
| Date: |
04/04/2024 |
| Authors: |
Michael Richardson, Owen Friel, David von Oheimb, Dan Harkins |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. This document updates RFC7030 (EST) and clarifies how the CSR Attributes Response can be used by an EST server to specify both CSR attribute OIDs and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. |
| Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) |
|
|
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), also known as Kyber, is a key-encapsulation mechanism (KEM). This document specifies algorithm identifiers and ASN.1 encoding format for ML-KEM in public key certificates. The encoding for public and private keys are also provided. [EDNOTE: This document is not expected to be finalized before the NIST PQC Project has standardized PQ algorithms. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] |
| Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA |
|
|
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Module-Lattice-Based Digital Signatures (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 Password Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax |
|
|
This document specifies additions and amendments to RFCs 7292 and 8018. It defines a way to use the Password Based Message Authentication Code 1, defined in RFC 8018, inside the PKCS #12 syntax. The purpose of this specification is to permit use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance. |
| Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) |
|
| draft-ietf-lamps-cms-sphincs-plus-04.txt |
| Date: |
07/05/2024 |
| Authors: |
Russ Housley, Scott Fluhrer, Panos Kampanakis, Bas Westerbaan |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
SLH-DSA is a stateless hash-based signature scheme. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. |
| Related Certificates for Use in Multiple Authentications within a Protocol |
|
|
This document defines a new CSR attribute, relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate. The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certificates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms. |
| Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS) |
|
| draft-ietf-lamps-cms-kemri-08.txt |
| Date: |
06/02/2024 |
| Authors: |
Russ Housley, John Gray, Tomofumi Okubo |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652. |
| Use of ML-KEM in the Cryptographic Message Syntax (CMS) |
|
| draft-ietf-lamps-cms-kyber-03.txt |
| Date: |
02/03/2024 |
| Authors: |
Julien Prat, Mike Ounsworth, Daniel Van Geest |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
The Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM) Algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's ML-KEM public key. Three parameters sets for the ML-KEM Algorithm are specified by NIST in [FIPS203-ipd] [EDNOTE: Change to [FIPS203] when it is published]. 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 KEMRecipientInfo as specified in [I-D.ietf-lamps-cms-kemri]. |
| Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS) |
|
|
The RSA Key Encapsulation Mechanism (RSA-KEM) Algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's RSA public key. The RSA-KEM Algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This document specifies the conventions for using the RSA-KEM Algorithm as a standalone KEM algorithm and the conventions for using the RSA-KEM Algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in RFC XXXX. This document obsoletes RFC 5990. RFC EDITOR: Please replace XXXX with the RFC number assigned to draft-ietf-lamps-cms-kemri. |
| Updates to X.509 Policy Validation |
|
|
This document updates RFC 5280 to replace the algorithm for X.509 policy validation with an equivalent, more efficient algorithm. The original algorithm built a structure which scaled exponentially in the worst case, leaving implementations vulnerable to denial-of- service attacks. |
| Composite ML-KEM for Use in the Internet X.509 Public Key Infrastructure and CMS |
|
| draft-ietf-lamps-pq-composite-kem-03.txt |
| Date: |
02/03/2024 |
| Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines Post-Quantum / Traditional composite Key Encapsulation Mechanism (KEM) algorithms suitable for use within X.509, PKIX and CMS protocols. Composite algorithms are provided which combine ML-KEM with RSA-KEM and ECDH-KEM. The provided set of composite algorithms should meet most Internet needs. This document assumes that all component algorithms are KEMs, and therefore it depends on [I-D.ietf-lamps-rfc5990bis] and [I-D.ounsworth-lamps-cms-dhkem] in order to promote RSA and ECDH respectively into KEMs. For the purpose of combining KEMs, the combiner function from [I-D.ounsworth-cfrg-kem-combiners] is used. For use within CMS, this document is intended to be coupled with the CMS KEMRecipientInfo mechanism in [I-D.housley-lamps-cms-kemri]. |
| Use of Remote Attestation with Certification Signing Requests |
|
| draft-ietf-lamps-csr-attestation-09.txt |
| Date: |
10/05/2024 |
| Authors: |
Mike Ounsworth, Hannes Tschofenig, Henk Birkholz, Monty Wiseman |
| 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 believable claims about the protections afforded to the corresponding private key, such as whether the private key resides on a hardware security module or the protection capabilities provided by the hardware. This document defines a new PKCS#10 attribute attr-evidence and CRMF extension ext-evidence that allows placing any Evidence data, in any pre-existing format, along with any certificates needed to validate it, into a PKCS#10 or CRMF CSR. Including Evidence along with a CSR can help to improve the assessment of the security posture for the private key, and the trustworthiness properties of the submitted key to the requested certificate profile. These Evidence Claims can include information about the hardware component's manufacturer, the version of installed or running firmware, the version of software installed or running in layers above the firmware, or the presence of hardware components providing specific protection capabilities or shielded locations (e.g., to protect keys). |
| Internationalized Email Addresses in X.509 Certificates |
|
| draft-ietf-lamps-rfc8398bis-05.txt |
| Date: |
13/02/2024 |
| Authors: |
Alexey Melnikov, Wei Chuang, Corey Bonnell |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address. This document updates RFC 5280 and obsoletes RFC 8398. |
| Updates to Lightweight OCSP Profile for High Volume Environments |
|
| draft-ietf-lamps-rfc5019bis-08.txt |
| Date: |
10/04/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. |
| Use of the SHA3 One-way Hash Functions in the Cryptographic Message Syntax (CMS) |
|
|
This document describes the conventions for using the one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS). The SHA3 family can be used as a message digest algorithm, as part of a signature algorithm, as part of a message authentication code, or part of a key derivation function. |
| No Revocation Available for X.509 Public Key Certificates |
|
| draft-ietf-lamps-norevavail-04.txt |
| Date: |
04/04/2024 |
| Authors: |
Russ Housley, Tomofumi Okubo, Joseph Mandel |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
X.509v3 public key certificates are profiled in RFC 5280. Short- lived certificates are seeing greater use in the Internet. The Certification Authority (CA) that issues these short-lived certificates do not publish revocation information because the certificate lifespan that is shorter than the time needed to detect, report, and distribute revocation information. Some long-lived X.509v3 public key certificates never expire, and they are never revoked. This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the certificate, and it updates the certification path validation algorithm in RFC 5280 to skip revocation checking when the noRevAvail certificate extension is present. |
| Encryption Key Derivation in the Cryptographic Message Syntax (CMS) using HKDF with SHA-256 |
|
|
This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the Cryptographic Message Syntax (CMS). The use of this mechanism provides protection against where the attacker manipulates the content-encryption algorithm identifier or the content-authenticated-encryption algorithm identifier. |
| Online Certificate Status Protocol (OCSP) Nonce Extension |
|
|
RFC 8954 imposed the size constraints on the optional Nonce extension for the Online Certificate Status Protocol (OCSP). OCSP is used for checking the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. Some environments use cryptographic algorithms that generate a Nonce value that is longer than 32 octets. This document updates the maximum allowed length of Nonce to 128 octets. This document also modifies Nonce section to clearly define the encoding format and values distinctively for an easier implementation and understanding. This document obsoletes RFC 8954 and provides updated ASN.1 modules for OCSP, updates RFC 6960. |
| X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs |
|
|
RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines Instant Messaging (IM) identity KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates |
| Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA |
|
| draft-ietf-lamps-x509-slhdsa-00.txt |
| Date: |
03/05/2024 |
| 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 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Stateless Hash-Based Digital Signature Standard (SLH-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. [EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized FIPS 205 Stateless Hash-Based Digital Signature Standard. The current FIPS draft was published August 24, 2023 for public review. Final versions are expected by April 2024. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] |
| Internet X.509 Public Key Infrastructure: Algorithm Identifiers for HSS and XMSS |
|
| draft-ietf-lamps-x509-shbs-00.txt |
| Date: |
03/05/2024 |
| Authors: |
Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, Stavros Kousidis |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document specifies algorithm identifiers and ASN.1 encoding formats for the Stateful Hash-Based Signature Schemes (S-HBS) Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT, a multi-tree variant of XMSS. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when those digital signatures are used in Internet X.509 certificates and certificate revocation lists. |
| Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) |
|
|
Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) define protocol messages for X.509v3 certificate creation and management. Both protocol provide interactions between client systems and PKI management entities, such as a Registration Authority (RA) and a Certification Authority (CA). CMP and EST allow an RA/CA to request additional information it has to provide in a certification request. When an end entity places attestation Evidence in a Certificate Signing Request (CSR) it may need to demonstrate freshness of the provided Evidence. Attestation technology today often accomplishes this task via the help of nonces. This document specifies how nonces are provided by an RA/CA to the end entity for inclusion in Evidence. |