Limited Additional Mechanisms for PKIX and SMIME (lamps) Internet Drafts


      
 Header Protection for Cryptographically Protected E-mail
 
 draft-ietf-lamps-header-protection-20.txt
 Date: 01/03/2024
 Authors: Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
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
 
 draft-ietf-lamps-e2e-mail-guidance-16.txt
 Date: 16/03/2024
 Authors: Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
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-09.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 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-08.txt
 Date: 03/03/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)
 
 draft-ietf-lamps-kyber-certificates-03.txt
 Date: 03/03/2024
 Authors: Sean Turner, Panos Kampanakis, Jake Massimo, Bas Westerbaan
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
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
 
 draft-ietf-lamps-dilithium-certificates-03.txt
 Date: 05/02/2024
 Authors: Jake Massimo, Panos Kampanakis, Sean Turner, Bas Westerbaan
 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 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
 
 draft-ietf-lamps-pkcs12-pbmac1-09.txt
 Date: 19/03/2024
 Authors: Hubert Kario
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
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-03.txt
 Date: 14/11/2023
 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
 
 draft-ietf-lamps-cert-binding-for-multi-auth-03.txt
 Date: 29/11/2023
 Authors: Alison Becker, Rebecca Guthrie, Michael Jenkins
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
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)
 
 draft-ietf-lamps-rfc5990bis-05.txt
 Date: 04/03/2024
 Authors: Russ Housley, Sean Turner
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
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 draft- ietf-lamps-cms-kemri.
 Updates to X.509 Policy Validation
 
 draft-ietf-lamps-x509-policy-graph-05.txt
 Date: 01/02/2024
 Authors: David Benjamin
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
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 Certificate Signing Requests
 
 draft-ietf-lamps-csr-attestation-08.txt
 Date: 01/03/2024
 Authors: Mike Ounsworth, Hannes Tschofenig, Henk Birkholz
 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-05.txt
 Date: 08/03/2024
 Authors: Tadahiko Ito, Clint Wilson, Corey Bonnell, Sean Turner
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
RFC 5019 defines a lightweight profile for OCSP that makes the protocol more suitable for use in high-volume environments. The lightweight profile specifies the mandatory use of SHA-1 when calculating the values of several fields in OCSP requests and responses. In recent years, weaknesses have been demonstrated with the SHA-1 algorithm. As a result, SHA-1 is increasingly falling out of use even for non-security relevant use cases. This document obsoletes the lightweight profile as specified in RFC 5019 to instead recommend the use of SHA-256 where SHA-1 was previously required. An RFC 5019-compliant OCSP client is still able to use SHA-1, but the use of SHA-1 may become obsolete in the future.
 Use of the SHA3 One-way Hash Functions in the Cryptographic Message Syntax (CMS)
 
 draft-ietf-lamps-cms-sha3-hash-02.txt
 Date: 03/03/2024
 Authors: Russ Housley
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
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-02.txt
 Date: 16/03/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.
 Encryption Key Derivation in the Cryptographic Message Syntax (CMS) using HKDF with SHA-256
 
 draft-ietf-lamps-cms-cek-hkdf-sha256-01.txt
 Date: 18/03/2024
 Authors: Russ Housley
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
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
 
 draft-ietf-lamps-ocsp-nonce-update-04.txt
 Date: 16/03/2024
 Authors: himanshu sharma
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
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 is a complete replacement for RFC 8954, obsoleting RFC 8954 and provides updated ASN.1 modules for OCSP, updating RFC 6960.


data-group-menu-data-url="/group/groupmenu.json"> Skip to main content

Limited Additional Mechanisms for PKIX and SMIME (lamps)

WG Name Limited Additional Mechanisms for PKIX and SMIME
Acronym lamps
Area Security Area (sec)
State Active
Charter charter-ietf-lamps-06 Approved
Status update Show Changed 2017-11-16
Document dependencies
Additional resources Issue tracker, Wiki, Zulip stream
Personnel Chairs Russ Housley, Tim Hollebeek
Area Director Deb Cooley
Mailing list Address spasm@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/spasm
Archive https://mailarchive.ietf.org/arch/browse/spasm/
Chat Room address https://zulip.ietf.org/#narrow/stream/lamps

Charter for Working Group

The PKIX and S/MIME Working Groups have been closed for some time. Some
updates have been proposed to the X.509 certificate documents produced
by the PKIX Working Group and the electronic mail security documents
produced by the S/MIME Working Group.

The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working
Group is chartered to make updates where there is a known constituency
interested in real deployment and there is at least one sufficiently
well specified approach to the update so that the working group can
sensibly evaluate whether to adopt a proposal.

The LAMPS WG is now tackling these topics:

  1. Specify the use of short-lived X.509 certificates for which no
    revocation information is made available by the Certification Authority.
    Short-lived certificates have a lifespan that is shorter than the time
    needed to detect, report, and distribute revocation information. As a
    result, revoking short-lived certificates is unnecessary and pointless.

  2. Update the specification for the cryptographic protection of email
    headers -- both for signatures and encryption -- to improve the
    implementation situation with respect to privacy, security, usability
    and interoperability in cryptographically-protected electronic mail.
    Most current implementations of cryptographically-protected electronic
    mail protect only the body of the message, which leaves significant
    room for attacks against otherwise-protected messages.

  3. The Certificate Management Protocol (CMP) is specified in RFC 4210,
    and it offers a vast range of certificate management options. CMP is
    currently being used in many different industrial environments, but it
    needs to be tailored to the specific needs of such machine-to-machine
    scenarios and communication among PKI management entities. The LAMPS
    WG will develop a "lightweight" profile of CMP to more efficiently
    support of these environments and better facilitate interoperable
    implementation, while preserving cryptographic algorithm agility. In
    addition, necessary updates and clarifications to CMP will be
    specified in a separate document. This work will be coordinated with
    the LWIG WG.

  4. Provide concrete guidance for implementers of email user agents to
    promote interoperability of end-to-end cryptographic protection of
    email messages. This may include guidance about the generation,
    interpretation, and handling of protected messages; management of
    the relevant certificates; documentation of how to avoid common
    failure modes; strategies for deployment in a mixed environment; as
    well as test vectors and examples that can be used by implementers
    and interoperability testing. The resulting robust consensus
    among email user agent implementers is expected to provide more
    usable and useful cryptographic security for email users.

  5. Recent progress in the development of quantum computers pose a
    threat to widely deployed public key algorithms. As a result,
    there is a need to prepare for a day when cryptosystems such as
    RSA, Diffie-Hellman, ECDSA, ECDH, and EdDSA cannot be depended
    upon in the PKIX and S/MIME protocols.

5.a. The US National Institute of Standards and Technology (NIST)
has a Post-Quantum Cryptography (PQC) effort to produce one or more
quantum-resistant public-key cryptographic algorithm standards.
The LAMPS WG will specify the use of these new PQC public key
algorithms with the PKIX certificates and the Cryptographic Message
Syntax (CMS). These specifications will use object identifiers
for the new algorithms that are assigned by NIST.

5.b. A lengthy transition from today's public key algorithms to
PQC public key algorithms is expected. Time will be needed to gain
full confidence in the new PQC public key algorithms.

5.b.i. The LAMPS WG will specify formats, identifiers, enrollment,
and operational practices for "hybrid key establishment" that
combines the shared secret values one or more traditional
key-establishment algorithm and one or more NIST PQC
key-establishment algorithm or a PQC key-establishment algorithm
vetted by the CFRG. The shared secret values will be combined using
HKDF (see RFC 5869), one of the key derivation functions in NIST
SP 800-56C, or a key derivation function vetted by the CFRG.

5.b.ii. The LAMPS WG will specify formats, identifiers, enrollment,
and operational practices for "dual signature" that combine one or
more traditional signature algorithm with one or more NIST PQC
signature algorithm or a PQC algorithm vetted by the CFRG.

In addition, the LAMPS WG may investigate other updates to documents
produced by the PKIX and S/MIME WG. The LAMPS WG may produce
clarifications where needed, but the LAMPS WG shall not adopt
anything beyond clarifications without rechartering.

Milestones

Date Milestone Associated documents
Dec 2022 Send draft for rfc6712bis to IESG for standards track publication draft-ietf-lamps-rfc6712bis
Dec 2022 Send draft for rfc4210bis to IESG for standards track publication draft-ietf-lamps-rfc4210bis
Jul 2022 End-to-end email user agent guidance sent to IESG for informational publication draft-ietf-lamps-e2e-mail-guidance
Mar 2022 Short-lived certificate conventions sent to IESG for BCP publication
Dec 2021 CMP algorithms sent to IESG for standards track publication draft-ietf-lamps-cmp-algorithms
Dec 2021 Adopt draft for dual signature in CMS
Dec 2021 Adopt draft for dual signatures in PKIX certificates
Dec 2021 Adopt draft for hybrid key establishment in CMS
Dec 2021 Adopt draft for public keys for hybrid key establishment in PKIX certificates
Dec 2021 Adopt draft for PQC signatures in CMS
Dec 2021 Lightweight CMP profile sent to IESG for informational publication draft-ietf-lamps-lightweight-cmp-profile
Dec 2021 CMP updates sent to IESG for standards track publication draft-ietf-lamps-cmp-updates
Dec 2021 Adopt draft for PQC signatures in PKIX certificates
Nov 2021 Header protection conventions sent to IESG for standards track publication draft-ietf-lamps-header-protection
Oct 2021 Adopt draft for PQC KEM algorithms in CMS
Oct 2021 Adopt draft for PQC KEM public keys in PKIX certificates
Jul 2021 Adopt a draft for short-lived certificate conventions

Done milestones

Date Milestone Associated documents
Done Adopt draft for rfc6712bis draft-ietf-lamps-rfc6712bis
Done Adopt draft for rfc4210bis draft-ietf-lamps-rfc4210bis
Done Adopt a draft for end-to-end email user agent guidance draft-ietf-lamps-e2e-mail-guidance