LAMPS WG at Virtual Interim on 28 January 2021 Minutes: Rich Salz AGENDA Since the LAMPS WG needs to re-charter to take on draft-dkg-lamps-e2e-mail-guidance, this seems like a good time to ask what other topics the group might want to tackle. Some have expressed interest in topics related to the transition to PQ cryptographic algorithms. This virtual interim on that will help determine what, if anything, should be included in the LAMPS WG re-charter. 1) Agenda Bash 2) Position Presentations a) Russ Housley b) Max Pala c) Mike Ounsworth d) Antonio Vaira e) Tadahiko Ito 3) Open Discussion 4) Wrap Up MINUTES 1) Agenda bash: No agenda changes were requested. 2) Position Presentations a) Position Presentations by Russ Housley. (https://datatracker.ietf.org/meeting/interim-2021-lamps-01/materials/slides-interim-2021-lamps-01-sessa-position-presentation-by-russ-housley-00) Goal is to deploy PQC before a large quantum-computer comes. Assumption is we will mix the traditional and PQC algorithms during the transition. There are two approaches: 1) one certificate with two public keys and two signatures, or 2) two certificates each with one public key and one signature. For encryption, protocols should use a symmetric key that is derived from both key the traditional public key and the PQC public key. For one certificate, need to think about corner cases such as "jumbo" certificates, what if one signature fails but the other one is okay? For two certificates, avoids the concerns with "jumbo" certificates, but protocol changes are needed to carry the certificate. Two certificates are bigger because there is some dupplication of subject identity, issuer identity, and other metadata. Russ recommends the two certificate approach. Mentioned that the SHA-1 deprecation was estimated for five years, but took ten years. Scott Fluhrer: For validating, need to reject if anything in the one certificate approach is bad, otherwise the attacker only needs to break one part. Tim Hollebeek: Need to think about CA validating the subject identity separate from the relying party validating received certificates. Mike Ounsworth: Agrees with Russ that this is tractable, but need to warn about foot-guns. Hendrick Brockhaus: For two certificates, are there two different keys? Russ: Yes. An existing problem. Same issue to support RSA and ECDSA. Mike O: We should discuss "n" vs 2 key pairs. If one side does not trust the PQ scheme the other is using; then 2 key pairs sufficient for PQ transition. Will we need to support identities and crypto operations involving 3+ key pairs? b) Position Presentations by Max Pala. (https://datatracker.ietf.org/meeting/interim-2021-lamps-01/materials/slides-interim-2021-lamps-01-sessa-position-presentation-by-max-pala-00) Need a solution when the lifetime is 20 years; 100s of millions of devices. No rapid deployment. DOCSIS is the protocol. Also need to address firmware upgrade. They prefer one certificate with multiple algorithms. Easier to deploy over time, and simpler conceptually (just one identity). Another drawback of two certificates is doubling some work such as OCSP queries. Mike O: I want to point out that what Max is proposing to do for DOCSIS enables RSA-only devices to understand the composite structure, but they only validate the RSA component. This is an interesting use of composite, but not the general algorithm we are proposing to become the standard. As Scott said, the fool-proof solution requires that all of the sinatures must be valid. Max: In response to a question from Sean, it’s not necessarily the case that two certificates with same subject are the same entity; it depends on policy. c) Position Presentations by Mike Ounsworth. (https://datatracker.ietf.org/meeting/interim-2021-lamps-01/materials/slides-interim-2021-lamps-01-sessa-position-presentation-by-mike-ounsworth-00) A composite signature (separate from composite certs). Proposing charter changes to add hybrid key establishment and dual signature. Using definitions for these terms from NIST. Concern about stripping a signature (CMS fixed via an extension in RFC 5752). Bigger attack surface two certificates (two certificate chains) twice as much to attack. The only way to get strong crypto is dual signatures throughout the certificate chain. Two certificates are more complex for users, deployment, management. The concern with "jumbo" certificates is mainly about mixing keyUsage. We can put public keys with the same usage into a single certificate. And if you've got PQ, adding RSA or ECDSA is a small delta. d) Position Presentations by Antonio Vaira. (https://datatracker.ietf.org/meeting/interim-2021-lamps-01/materials/slides-interim-2021-lamps-01-sessa-position-presentation-by-antonio-vaira-00) Particularly interested in software update. Has long-lived products. Stateful hash-based signatures (HBS) are good for this use-case. Questions for the WG: RFC for using XMSS to CMS? What about SPHINCS+? Does it make sense to put stateful HBS into a root certificate? Russ: XMSS is in scope under the existing LAMPS WG charter. Quynh: NIST is thinking to standardize SPHINCS+ after Round Three. (However, this statement is not a promise.) e) Position Presentations by Tadahiko Ito. (https://datatracker.ietf.org/meeting/interim-2021-lamps-01/materials/slides-interim-2021-lamps-01-sessa-position-presentation-by-tadahiko-ito-00) Large hashing not practical on an HSM. Hashing for signing not always separable. Maybe pre-hash can be used to provide a solution. Worked example of PDF document with multiple signatures. Scott F: Alternative way to address the hashing problem is to pass the hash state to the HSM so that the HSM can resume the hash calculation. This approach seems like it would work with DILITHIUM. Russ: Scott's proposal is to change the API of the HSM to pass the hash state instead of the completed hash of the to-be-signed data. Ito-san: can we work on consensus for that API? Russ: Suggest CFRG as a better place for that work. 3) Open Discussion. Russ: Several people are in favor of composite signatures; is anyone opposed? Please speak up. Max: In response to the question raised by Russ, the signature is more important for now. Once we have that, would be open to a standard mechanism for key exchange. Mike O: I proposed wording for key exchange, that is not my area, but I think we should look at it. Russ: Does Mike's proposed charter text capture the work that we want to do? Will discuss it the mail list. Will use the NIST definitions for hybrid key exchange and dual signatures. Michael Richardson: What about RFC 5280 updates? Tim H: We can clarify any document changes on the mail list. Scott: I think ANSI X9 might be doing something about OIDs. Tim H: ANSI X9.F1 is interested in transitioning. Russ: We came to conclusion quickly, let's discuss on the mail list, and once we reach consensus on the charter text we can send it to the Security ADs. 4) Wrap Up: no other business.