lamps

Summary

The LAMPS working group meeting covered a wide range of topics, including updates on several RFCs, discussion of ML-CHEM and ML-DSA certificate formats, composite signatures and KEMs, CMS security considerations, and adoption calls for new drafts. Key discussions focused on the validation of external MU in FIPS 140-3, the consistency of private key formats for composite signatures, and the use of the ID data content type in CMS.

Key Discussion Points

ML-CHEM and ML-DSA Certs: Discussion focused on consistency checks and language regarding implementation requirements ("should" vs. "must"). No major objections were raised, but some participants suggested clarifications for security implications. The use of public key derivation from the private key was also discussed but ultimately rejected for inclusion. The validity of external MU with FIPS 140-3 was debated, with differing opinions and ongoing clarifications from NIST.
CSR Attestation and Freshness: Updates were provided on the dependencies between CSR attestation and freshness drafts.
Composite Signatures and KEMs: New combinations were added. A static prefix was added and the ASN.1 sequence wrapping removed. The need for a four-byte length prefix was questioned for public keys and signatures but retained for private key consistency across the documents. The simplification of the Chem Combiner by using only HKDF extract was highlighted. The possibility of removing hash composites was discussed.
CMS Security Considerations: The discussion centered around ensuring the security levels of various components in CMS align (e.g., digest strength matching key strength). The group explored the impacts of strict alignment.
CMC biz: Updates were provided. It was noted a follow-on draft for PQ algorithms will be published separately.
Private Key Statement Attestation: Readyness for working group last call was discussed.
CMS Khyber: An updated version with intermediate values was about to be posted. Again discussion of security level alignment.

Decisions and Action Items

ML-CHEM/DSA Certs: Authors to incorporate minor textual tweaks based on discussion.
MLDSA Certs: Determine and post text for consistency check language.
Composite Signatures: Authors to review whether a consistent private key format can be profiled and enforced for new composite signatures. Drop the variable length format keys, if that can be profiled. Authors to investigate the CMS stuff, and if CMS part takes months and months, pure algorithm can get split up into its own document.
CMS Khyber: Update and re-post the document with alignment suggestions.
SLHDSC in X.509: Ready to go to IESG, unless people have additional comments.
E-Content Type Usage For CMS Sign Data: Pursue a BCP outlining best practices and guidance on the use (or avoidance) of the ID data content type, taking into account feedback on updating the S-MIME spec. Authors to move forward in writing the BCP.
Dual Usage: Need slides. Joe to send the slides
Action: Authors to post the last revisions and solicit feedback.

Next Steps

The group will continue discussions on the mailing list, particularly regarding the alignment of security levels in CMS and the use of private key formats.
Authors are expected to post updated drafts incorporating the feedback received.
A call for adoption for the dual usage will be scheduled once the slides and draft can be reviewed.
Follow-up slides for Friday's session.

Session Date/Time: 21 Mar 2025 02:30

lamps

Summary

This meeting covered several topics including a CAA Security Tag proposal, content types for private key information, and a discovery extension for X.509 certificates. The CAA Security Tag proposal sparked a detailed discussion regarding its potential benefits and how it could improve security. Assignment of content types was straightforward. The discovery extension raised interesting points regarding its purpose, security implications, and potential for future enhancements.

Key Discussion Points

CAA Security Tag:
- Henry Burgly presented a draft defining a new CAA tag named "security" to enhance domain control validation against network attackers.
- The tag is designed to enforce specific security requirements before a CA issues a certificate.
- Discussion involved the advantages of a declarative security approach versus existing methods, addressing the complexities of validating domain ownership across different CAs and DNS setups.
- Concerns were raised about potential deployment issues and the need for CAs to validate DNSSEC.
PKCS#8 Content Types:
- Joe Madow presented a straightforward draft assigning content types for single private key info and encrypted private key info.
- This addresses the need for CMS content types to wrap existing PKCS#8 formatted keys.
Discovery Extension:
- The session discussed an X.509 extension to facilitate the discovery of related certificates.
- Use cases included linking signing and encryption certificates, bridging between different cryptographic algorithms (e.g., RSA and post-quantum), and certificate renewal.
- Questions arose regarding the intended consumers, the applicability to WebPKI, and potential security concerns with relying solely on URIs for discovery.
- There was also a discussion about adding a "purpose" field to the extension to specify the intended relationship between certificates.

Decisions and Action Items

CAA Security Tag: Henry Burgly will start a thread on the mailing list to solicit updates and recommendations before a call for adoption.
PKCS#8 Content Types: No objections were raised and it was decided to move forward with a call for adoption.
Discovery Extension: Despite some reservations, a call for adoption will be issued. Post-adoption bike shedding and discussion will commence regarding extension purposes and potential improvements to the ASN.1.

Next Steps

Henry Burgly to start mailing list thread for the CAA security tag draft.
Issue calls for adoption for the PKCS#8 content types and Discovery Extension drafts.
Discuss design options for the discovery extension on the mailing list, particularly regarding the addition of a "purpose" field.