**Session Date/Time:** 27 Jul 2022 14:00

# lamps

## Summary

The lamps working group session at IETF 114 covered a range of topics, including updates on documents in the IESG and RFC Editor queues, progress on CMP bis documents, and discussions around new proposals for EST, 3GPP Network Function Types, Key Attestation, and Post-Quantum Cryptography (PQC) for KEMs, signatures, and composite certificates. A key theme throughout the session was the alignment with NIST's PQC standardization efforts and the IETF's approach to integrating these new algorithms into existing PKIX standards. Discussions also focused on the balance between flexibility and interoperability in new specifications, particularly concerning parameterization and composite key structures.

## Key Discussion Points

*   **CMP Updates and Bis Documents**:
    *   `draft-ietf-lamps-cmp-algorithms` has passed IESG review and is in the RFC Editor's queue.
    *   `draft-ietf-lamps-cmp-updates` was not approved by the IESG due to its "old text/new text" style. The IESG requested a full `4210bis` document. The authors proposed also creating a `6712bis` document.
    *   The creation of `4210bis` and `6712bis` raises concerns about reopening fundamental protocol design decisions and needing input from original authors (from 2005) to ensure it's an adaptation, not a redesign.
    *   IPR considerations for the `bis` documents were discussed, and it was confirmed that rights from original authors for the *updates* were obtained, implying similar confirmation might be needed for the full `bis` documents.
    *   The responsible AD suggested clarifying "hot spots" in security considerations and thoroughly documenting existing interoperable implementations to manage the scope of IESG review.
*   **EST CSR Attributes (`draft-ietf-lamps-rfc7030-bis`)**:
    *   Clarification needed for CSR attributes, particularly Subject Alternative Name (SAN), which RFC 7030 was vague about.
    *   The proposed solution involves using an `extensionRequest` within the CSR to include the desired `extension` with its critical bit, OID, and value.
    *   Discussion covered the use of UTF-8 in DirectoryString and the need for examples not in UTF-8.
*   **3GPP Network Function Types (`draft-ietf-lamps-3gpp-network-function-type-certs`)**:
    *   A new certificate extension is proposed to include 3GPP Network Function (NF) types for 5G systems.
    *   The types are restricted to ASCII strings (with underscore) and a length limit of 32 characters, making them concise for certificates.
    *   This is intended to address a current gap in 3GPP specifications.
*   **Key Attestation (`draft-ietf-lamps-attestation-for-cert-req`)**:
    *   A mechanism to convey verifiable key attestations (e.g., from hardware) to CAs via certificate requests (SCEP, CMC, EST, CRMF).
    *   The draft proposes using the WebAuthn attestation statement format and requires a new IANA registry for attestation statement formats not specifically defined in WebAuthn.
    *   Discussions included coordinating with W3C, the distinction between "hardware" vs. "software" attestation, and the balance between specific attestation formats (WebAuthn) and broader, more mature identity assurance frameworks (ETSI, NIST 800-63).
    *   The scope and complexity of the attestation statements and their impact on relying parties were highlighted.
*   **Post-Quantum KEMs (`draft-ietf-lamps-pq-kem-for-x509`)**:
    *   This draft aims to specify how to incorporate NIST-selected Post-Quantum Key Encapsulation Mechanism (KEM) public keys (specifically Kyber) into X.509 certificates.
    *   The approach emphasizes using OIDs per security level (as determined by NIST) with no explicit parameters encoded within the OID, aiming for a "clean slate" to avoid past implementation complexities.
    *   Key usage for KEMs (distinct from key transport or key agreement) was discussed, with a proposed consistent choice.
*   **Post-Quantum Signatures (`draft-ietf-lamps-pq-sig-for-x509`)**:
    *   Focuses on defining algorithm identifiers and data structures for NIST-selected PQC signature algorithms (starting with Dilithium) in X.509.
    *   Similar to KEMs, the goal is a clean, concise specification with no parameters in the OID, following NIST's security level designations.
    *   A significant discussion point was whether to have one document per signature algorithm or a single document for all. The working group strongly favored *one document per algorithm* to manage complexity and accommodate future NIST selections.
*   **Composite Cryptography (Keys, Signatures, KEMs)**:
    *   `draft-ietf-lamps-composite-pki-keys` and `draft-ietf-lamps-composite-pki-signatures` define methods for combining traditional and PQC algorithms in certificates and signatures.
    *   The motivation is to provide a standardized approach for hybrid deployments, acknowledging that a commercial need exists even if universal deployment is debated.
    *   Concerns were raised about the complexity and flexibility offered (e.g., "and/or/k-of-n" modes), potentially leading to interoperability issues ("big parking lot" analogy).
    *   Running code and hackathon plans were presented.
    *   `draft-ietf-lamps-composite-pki-kem` for composite KEMs introduces new cryptographic primitives for transformations (key trans to KEM, key agree to KEM) and combiners, which are acknowledged to be cryptographically complex and require significant review.
*   **PQC Key Serialization (`draft-osborne-lamps-pqc-key-serialization`)**:
    *   This draft aims to provide general guidance on how to serialize and identify PQC keys, drawing lessons from past crypto issues.
    *   It initially contained all NIST finalists but will be updated to focus on the selected algorithms (including Sphincs+).
    *   Discussion points include ASN.1 syntax, partially populated keys, and the trade-offs of complexity in serialization versus higher layers.
    *   The general approach appeared to be at odds with the working group's preference for separate documents per algorithm, and the author expressed willingness to restructure the document accordingly.

## Decisions and Action Items

*   **CMP Updates**:
    *   **Decision**: The working group will proceed with creating `4210bis` and `6712bis` documents as requested by the IESG.
    *   **Action Item**: Hendrick and co-authors will prepare `00` (original), `01` (updates), and `02` (fixes) versions. They will seek input from original authors on design decisions.
    *   **Action Item**: The IPR status regarding original authors' rights for the `bis` documents needs to be formally confirmed and documented on the mailing list.
    *   **Action Item**: Roman (AD) will review `draft-ietf-lamps-cmp-profile` in the next 1-2 weeks post-IETF.
*   **EST CSR Attributes (`draft-ietf-lamps-rfc7030-bis`)**:
    *   **Decision**: Call for adoption will be sent to the mailing list.
    *   **Action Item**: Russ will verify the draft's scope against the working group charter.
    *   **Action Item**: Reviewers are encouraged to provide examples, especially those not using UTF-8 for SAN.
*   **3GPP Network Function Types (`draft-ietf-lamps-3gpp-network-function-type-certs`)**:
    *   **Decision**: Call for adoption will be sent to the mailing list.
*   **Key Attestation (`draft-ietf-lamps-attestation-for-cert-req`)**:
    *   **Decision**: Call for adoption will be sent to the mailing list.
    *   **Action Item**: The draft will be updated to define a new IANA registry for attestation statement formats.
    *   **Action Item**: Further discussion on the mailing list regarding the "Hardware vs. Software" attestation bit and the scope of attestation formats.
    *   **Action Item**: The chairs will add this document to the related document list.
*   **Post-Quantum KEMs (`draft-ietf-lamps-pq-kem-for-x509`)**:
    *   **Decision**: Call for adoption will be sent to the mailing list.
    *   **Action Item**: The draft will include placeholders (TBDs) for NIST-defined OIDs and security levels, awaiting NIST's final selections.
*   **Post-Quantum Signatures (`draft-ietf-lamps-pq-sig-for-x509`)**:
    *   **Decision**: The working group adopted the approach of having *one document per signature algorithm*.
    *   **Decision**: Call for adoption for the *Dilithium* signature document (`draft-ietf-lamps-pq-sig-for-x509`) will be sent to the mailing list.
*   **Composite Cryptography (Keys, Signatures)**:
    *   **Decision**: Calls for adoption for `draft-ietf-lamps-composite-pki-keys` and `draft-ietf-lamps-composite-pki-signatures` are deferred due to objections and ongoing technical discussions, particularly regarding the flexibility of "and/or/k-of-n" structures and the perceived complexity for implementers.
    *   **Action Item**: Further technical discussion on the mailing list regarding the scope and specific structures for composite keys and signatures.
*   **PQC Key Serialization (`draft-osborne-lamps-pqc-key-serialization`)**:
    *   **Action Item**: The author will restructure the draft to align with the "one document per algorithm" approach, creating separate documents for each NIST-selected algorithm.
    *   **Action Item**: Discussion needed on the mailing list regarding potential overlap and integration of private key format definitions with other PQC drafts.
*   **General PQC Strategy**:
    *   **Decision**: The working group strategy is to adopt PQC drafts, perform administrative and editorial work, and then pause to wait for NIST's final algorithm and parameter specifications, ensuring synchronization and timely completion.

## Next Steps

*   **Mailing List Discussions**:
    *   Continued debate on the scope and design of the CMP `bis` documents.
    *   Technical discussions on the composite cryptography drafts (keys, signatures, KEMs) including the "and/or/k-of-n" problem statement and cryptographic complexities of KEM combiners.
    *   PQC key serialization draft restructuring and integration with other PQC drafts.
*   **Draft Updates**:
    *   DKG will update Header Protection and End-to-End Mail Guidance drafts.
    *   Mike Osborne will update the PQC key serialization draft(s) based on NIST's selections and the "one document per algorithm" decision.
*   **IETF 115 Hackathon**:
    *   Entrust (Mike Ellsworth and John Gray) will volunteer to demonstrate and test composite signatures and KEMs, as well as general PQ X.509, CRLs, and S/MIME. Michael Richardson expressed interest in testing enrollment protocols.
*   **AD Reviews**: Roman (AD) will review `draft-ietf-lamps-cmp-profile`.