Session Date/Time: 04 Nov 2025 14:30

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.

Recently Published RFCs

• draft-ietf-lamps-e2e-mail-guidance (RFC 9787)
• draft-ietf-lamps-header-protection (RFC 9788)
• draft-ietf-lamps-rfc4210bis (RFC 9810)
• draft-ietf-lamps-rfc6712bis (RFC 9811)
• draft-ietf-lamps-rfc9579bis (RFC 9879)
• draft-ietf-lamps-cms-sphincs-plus (RFC 9814)
• draft-ietf-lamps-private-key-stmt-attr (RFC 9883)
• draft-ietf-lamps-dilithium-certificates (RFC 9881)
• draft-ietf-lamps-cms-ml-dsa (RFC 9882)

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 Ounsworth 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.