LAMPS Session Minutes

Summary

The LAMPS session covered significant progress on multiple documents, including composite signatures moving to publication, discussions on composite KEMs, and updates to CMC and EST protocols. Key decisions included the adoption of AES-GCM for CMC BIS, deprecation of the Chameleon draft in favor of Certificate Discovery, and the settling of X-wing labels for CKEMs. Several new drafts, including MAC Addresses in X.509, EST Renewal Information, and CMS BCP, are entering or are in the process of working group adoption. Discussions also began on a potential EST BIS document and early adoption of a draft for FNDSA.

Key Discussion Points

RFC Production: Noted significant number of RFCs published and documents in the RFC Editor queue since the last IETF.
CMS BIS:
- Addressing IESG comments, notably the inclusion of AuthEnvelopedData as a primary mechanism, affecting many parts of the document.
- Discussion and consensus to recommend AES-GCM for new algorithm requirements.
- Updates to references (RFC6402, RFC2797), security considerations for file-based (read access) and mail-based (EnvelopedData/SMTP over TLS) scenarios, and HTTP/TCP pipelining requirements.
- Acknowledged challenges with SMTP over TLS and invited further review.
- Post-Quantum (PQ) crypto for CMP will be addressed in future updates, not the current BIS.
CRL Validation: Received short review, an update to the draft is planned.
Nonces and Freshness (CMC/EST Attestation):
- Draft now includes new authors and significant updates for EST (request/response examples) and CMC (generic nonce requests using PQI data with a control message and signed data with id-data).
- Introduced a new feature for optional payloads in nonce requests for key attestation.
- The draft's progression is dependent on the "CSR attestation" draft (currently in "penalty box"). Siemens is working on implementations.
Certificate Discovery:
- Reorganized ASN.1 structure and introduced a 'byLocalPolicy' option.
- Discussion concluded that the "Chameleon" draft, which aimed to encode certificate differences, is no longer needed due to the capabilities of Certificate Discovery.
CAA Security:
- No textual changes to the draft; focus on deployment progress for the new security CAA tag.
- Discussion covered secure CA retrieval via DNSSEC (mandated by CA/Browser Forum from March next year) and secure channels to authoritative name servers (long-term, early deployment by Let's Encrypt).
- Four cryptographic domain control validation methods were presented: HTTP over TLS, ACME Known Account Specifier, Secure DNS record change, and Private Key Control.
- Concerns raised regarding the feasibility of full-chain secure DNS channels in the near term and the need for a registry of validation types not tied to ACME.
- Bob Beck and Aaron noted parallel work on proof of key ownership in ACME.
Composites (Signatures & KEMs):
- Composite Signatures: The draft achieved Working Group Last Call (WGLC) and has received OID assignments. It is being submitted to the IESG for publication.
- Composite KEMs (CKEMs): Extensive debate over the "X-wing" labels used in the KDF was settled, accepting the existing, albeit problematic, string due to existing implementations and prior comprehensive discussions.
- Proposal to include the public key in the private key encoding for CKEMs (specifically for ECDH/RSA components) due to challenges in deriving public keys from private keys in certain HSM/API contexts. This point remains contentious, with calls for simplicity and strict consistency checks.
- New "Use in CMS" drafts for composite signatures and KEMs will be created, considered adopted by the chairs.
- Hackathon results showed strong interoperability for composite signatures, with ongoing work for CKEMs.
MAC Addresses in X.509:
- Recently adopted draft to standardize encoding of MAC addresses (EUI-48/64) in X.509 certificates using a new OtherName and OID.
- Discussion on the use case for name constraints for MAC addresses, particularly for CAs issuing to manufacturers.
- Questions raised about how 5280 validation rules for name constraints would apply.
CMS BCP (Best Current Practices):
- Draft proposes best practices for CMS signed data to mitigate remove/add signed attribute attacks.
- Key proposal is to restrict usage of the ID-data content type, potentially by defining a new ID-MIME-data OID for new uses.
EST Renewal Information:
- New draft to allow CAs to inform clients about certificate renewal schedules and staggering, similar to ACME ARI.
- Proposed a new EST endpoint renewal-info/{certID}.
EST BIS (Proposal):
- Proposal to undertake a BIS (revision) of RFC 7030 (EST) in the future (e.g., next year) to address TLS 1.2 limitations, add TLS 1.3/QUIC support, and potentially revisit CSR usage.
- The Area Director confirmed "Maintenance of EST" is within the LAMPS charter.
FNDSA (Forensic Non-Deterministic Signature Algorithm):
- Sean Turner is preparing a placeholder draft for FNDSA, aiming for early adoption similar to MLDSA, to be ready once NIST FIPS is published and OIDs are assigned.
- Concerns raised regarding floating-point operations and potential side-channel attack considerations for FNDSA implementations.

Decisions and Action Items

Decision: The proposal for including Richardson's slide (7D-30 bis) was accepted and added to the agenda.
Decision: For the CMS BIS document, AES-GCM will be used for new algorithm requirements.
Decision: The working group will not continue with the "Chameleon" draft, favoring Certificate Discovery.
Decision: The "X-wing" labels for Composite KEMs will remain as they are, acknowledging existing implementations and prior debate.
Action Item: For Composite KEMs, Mike to write security considerations around consistency checks for private keys.
Action Item: Further discussion on the Composite KEMs private key format will be taken to the mailing list.
Decision: New drafts detailing "Use in CMS" for composite signatures and KEMs are considered adopted by the chairs.
Action Item: For MAC Addresses in X.509, clarify the applicability of RFC 5280 name constraint rules, especially regarding leaf-only vs. full-chain validation.
Decision: The Call for Adoption for the CMS BCP draft is open until October 13th. Working group feedback is requested.
Decision: A Call for Adoption for the EST Renewal Information draft will be issued in the next week or two.
Action Item: The working group will discuss the scope and participation for a potential EST BIS document on the mailing list.
Decision: The working group will consider early adoption of a FNDSA draft.
Action Item: Ensure the FNDSA draft adequately addresses security considerations related to floating-point operations and side-channels.

Next Steps

CMS BIS: Seek implementer feedback, especially regarding AuthEnvelopedData and potential breaking changes.
Nonces and Freshness: Wait for the "CSR attestation" draft to finalize, then update this document, especially regarding the new key attestation feature. Authors to refine details for this feature.
Certificate Discovery: Produce and add sample implementations to the draft, then request Working Group Last Call (WGLC).
CAA Security: Continue implementation efforts (Open/Big, Let's Encrypt), add more details on Secure DNS record change and Private Key Control methods, and publish the academic paper. Seek further working group feedback and engage with early adopters.
MAC Addresses in X.509: Post the updated Internet Draft this week, potentially ready for WGLC after initial draft is reviewed.
CMS BCP: Working group members to provide feedback on the adoption call, particularly on "should" vs. "must" language and the approach to the ID-data OID.
EST Renewal Information: Prepare for and respond to feedback during the call for adoption.
EST BIS: Working group to engage in discussions on the mailing list regarding the scope, timing, and resources for a potential EST BIS document.
FNDSA: Continue development of the placeholder draft, addressing identified security considerations, in preparation for early adoption.

Session Date/Time: 06 Nov 2025 14:30

LAMPS

Summary

The second LAMPS session focused on a proposed Extended Key Usage (EKU) for attestation keys and a new proposal for one-time signature certificates. The discussion around the attestation EKU centered on whether the EKU mechanism is suitable for expressing constraints like "only sign evidence," given the additive nature of EKUs, with alternative suggestions of critical extensions or policy OIDs emerging. For one-time signature certificates, there was broad interest in the use case for archiving and simplified management, but a significant debate arose regarding whether the proposed document binding extension should be critical to truly enforce the "one-time" property. Additionally, an ad-hoc discussion revisited the structure of private keys for composite KEMs, where the authors stated that embedding the public key within the private key is necessary for compatibility with existing Java cryptographic libraries.

Key Discussion Points

EKU for Attestation Keys:
- Jean-Pierre-Fizier presented a draft proposing a new EKU for attestation keys, which are digital signature keys dedicated solely to signing evidence. The goal is to provide a generic EKU, separate from existing specialized OIDs (e.g., TPM, DICE).
- Proposed constraints included that the key should not sign anything other than evidence and remain under the attester's control, with the CA ensuring this.
- Concerns: Bob Beck questioned the need for a new EKU, suggesting the use of existing general OID space for post-handshake validation. Daniel Kant-Gilmore raised a significant concern that EKUs are additive per RFC 5280, making it problematic to define an EKU that prohibits other uses, potentially leading to divergent validator behaviors. Stefan Santesson (co-author of RFC 5280) clarified that the EKU framework defines what a key is for, not what it is not for.
- Alternatives: Suggestions were made to consider a novel critical extension or to pair the EKU with a policy OID, which could be asserted by the CA.
- Proof of Possession (PoP): Deb Cooley suggested that the need for a "special" PoP mechanism for attestation keys might not be necessary, as existing methods allow signing CSRs even for keys not primarily intended for signing.
One-Time Signature Certificates:
- Stefan Santesson presented a draft proposing one-time signature certificates, motivated by 15 years of experience in Sweden using dynamically generated keys and certificates for single signatures, which effectively address legal and operational requirements but face archiving challenges due to expiration.
- The proposal includes certificates that never expire (using RFC 5280's "notAfter" field), have no revocation mechanism, and feature a new extension that binds the certificate to the hash of the single signed document. The private key is immediately destroyed after use.
- Debate on Criticality: Dennis Jackson and Daniel Kant-Gilmore strongly argued that the document binding extension must be critical. They contend that if it's non-critical, verifiers unaware of the extension would treat the certificate as indefinitely valid and reusable, thus undermining the "one-time" security property and making misuse undetectable.
- Author's Perspective: Stefan Santesson argued against a mandatory critical extension, stating it would require all validation engines to update, rendering the solution impractical for widespread adoption. He proposed that the non-critical binding serves as a clear basis for repudiation if misuse occurs, leaving the ultimate reliance decision to the relying party.
- Support for Adoption: Several participants, including Tim Hollebeek, expressed strong support for the adoption of this work, citing its importance for use cases like code signing and the EU Wallet initiative, emphasizing the value of standardizing such a model regardless of the critical/non-critical decision.
Private Key Composite KEMs (Any Other Business):
- Mike Olsworth revisited the embedding of public keys within private key structures for composite KEMs, which was discussed on Tuesday.
- Problem Statement: New information indicates that embedding the public key is necessary for compatibility with existing Java cryptographic libraries (e.g., JCA, Bouncy Castle, potentially Oracle Java). Classes like ECPrivateKey and RSAPrivateKey in JCA do not consistently provide APIs to derive the public key from the private key without changes that would violate the design requirement of not forcing changes to FIPS-certified traditional modules.
- Concerns: Victor and John Gray expressed concerns about the increased size of private keys due to embedding the full post-quantum public key, noting potential impacts on storage costs, particularly in FIPS-certified or resource-constrained environments.
- Technical Detail: David Benjamin clarified that for EC keys, the public key can be derived using existing ECDH APIs, and for RSA keys using the CRT form, the public exponent is available. However, issues persist for non-CRT RSA private key formats.

Decisions and Action Items

Attestation EKU: No adoption decision was made. The authors are encouraged to incorporate the feedback received, particularly regarding the suitability of EKUs for negative constraints and exploring alternative mechanisms, and revise the draft.
One-Time Signature Certificates: No adoption decision was made. Authors are to publish the -00 draft. They will consider the feedback, especially on the critical/non-critical nature of the document binding extension, and are encouraged to include a detailed discussion in the security considerations section on the implications of both approaches. A revised draft and a call for adoption on the mailing list are expected.
Private Key Composite KEMs: A small group of experts (including David Benjamin, Scott, John Gray, Chris, Sophie, David Hook (Bouncy Castle), and Sean Mullen (Oracle)) was formed to investigate the technical feasibility and implications of deriving public keys from private keys in Java cryptographic libraries. This group will coordinate offline to clarify the constraints and inform the path forward for the composite KEM private key format.

Next Steps

Attestation EKU: Authors to revise the draft based on the session's technical input, focusing on the EKU framework and exploring whether a critical extension or policy OID might be a more suitable mechanism for the intended constraints. Close coordination with the RATS working group is anticipated.
One-Time Signature Certificates: Authors to publish the -00 draft. A revision addressing the critical vs. non-critical debate for the document binding extension, potentially with enhanced security considerations, is expected. A call for adoption on the LAMPS mailing list will follow.
Private Key Composite KEMs: The newly formed expert group will research and report on the technical realities of public key derivation from private keys in Java, aiming to provide clarity to the working group on the composite KEM private key format.