Markdown Version | Session Recording
Session Date/Time: 08 Nov 2022 13:00
openpgp
Summary
The openpgp working group meeting focused primarily on resolving outstanding issues from the Working Group Last Call (WGLC) for draft-ietf-openpgp-crypto-refresh-07. Key discussions included addressing conflicts with draft-kook regarding version numbers, determining the appropriate length for signature salts, handling potential aliasing between V3 and V5 signatures, and the role of context parameters in encryption and signatures. Decisions were made to adjust version numbers to avoid draft-kook conflicts and to link salt length to hash collision resistance. The meeting also touched upon IANA registry update policies and concluded with a brief, unchartered presentation on Post-Quantum (PQ) OpenPGP considerations.
Key Discussion Points
-
Working Group Last Call (WGLC) for
draft-ietf-openpgp-crypto-refresh-07- The draft
draft-ietf-openpgp-crypto-refresh-07is the basis for ongoing work. - A significant need for more in-depth reviews of the document was highlighted.
- Action Item: Rick van Rein, Robin, and Jonathan Hamill volunteered to provide reviews in the coming weeks. The co-chairs committed to setting a new WGLC deadline to encourage these reviews.
- The draft
-
Conflict with
draft-kook(RFC 4880bis)draft-kook(an individual draft) uses version 5 for new public key and signature formats, which conflicts withcrypto-refresh's use of version 5 for similar concepts.- The design team had already deconflicted other code points, but V5 key and signature formats remained a direct conflict.
- Discussion: Concerns about process, operational issues from conflicting deployments, and the difficulty of coordination with the
draft-kookauthor. There was a general consensus from a previous list discussion to avoid conflict where feasible. - Proposal: Move the
crypto-refreshdraft's version numbers for new public key format, signature format, one-pass signatures, and PKESK from V5 to V6. The SCI PD V2 would remain V2. - Decision: A poll showed strong consensus (12-13 raised hands, 0 not raised) to move these version numbers to V6.
- Action Item: Co-chair Stephen Farrell will reach out to Werner Koch (author of
draft-kook) to inquire about potential changes to his V5 definitions, acknowledging that this process will have a termination date.
-
Signature Salt Length for Post-Quantum Readiness
- Issue: Current V5 signatures use a fixed 16-octet salt. Aaron suggested increasing this, possibly making it variable, in preparation for Post-Quantum (PQ) signing schemes which may require larger salts.
- Discussion: Comparison of PQ algorithms (Dilithium, Falcon, Sphinx+), their internal salt/randomization mechanisms, and OpenPGP's one-pass signature framing. The goal is to avoid collisions and match security levels.
- Proposal (Aaron): Tie the signature salt length to the collision resistance size of the hash algorithm used (e.g., 16 octets for SHA-256, 32 octets for SHA-512).
- Decision: A poll showed strong consensus (15 raised hands, 1 not raised) for Aaron's proposal to make the salt length match the hash function's collision resistance.
- Action Item: Paul W. volunteered to create a merge request for this change.
-
V3 Signature Aliasing Prevention
- Issue: Demi-Marie OpenHour identified that a V5 signature over a message less than 4GB could be transformed into a valid V3 signature over subtly different data, potentially confusing implementations that still validate V3.
- Discussion:
crypto-refreshmandates that V3 signatures must not be validated due to known insecurities. The proposed change to the V5 trailer calculation is minor. - Proposal: Change the ordering of octets in the V5 signature trailer to prevent aliasing with V3 signatures.
- Decision: A poll showed a weaker consensus (8 raised hands, 2 not raised) to make the change, with the caveat that new information on the list could lead to reconsideration.
- Action Item: A volunteer is needed to create a merge request for this change.
-
Context Parameters for Encryption and Signatures
- Issue: Daniel Heavens proposed adding a context parameter to encryption and signatures to prevent their misuse or transplantation into unintended applications/contexts (e.g., an email signature validating in a backup application).
- Discussion: Benefits for new applications, challenges in defining a universal context for existing uses like email, and the overhead of establishing an IANA registry for context IDs.
- Decision: The working group decided to postpone detailed work on context parameters to future re-chartered work. A null context could be defined in
crypto-refreshfor now, allowing for later definition of specific contexts.
-
X-Only Representation for ECC Public Keys
- Issue: A proposal by Andrea Gypsov suggested moving from SEC1 representation to a more compact X-only representation for EC-DH and ECDSA public keys in V5 (or V6) to save space.
- Discussion: The change would lead to format differences between V4 and V5 keys for these algorithms. Concerns were raised about maintaining consistency with V4 and the lack of significant bandwidth advantage for X-only over SEC1 for elliptic curve keys.
- Decision: A poll showed strong consensus (0 raised hands, 9 not raised) to retain the SEC1 representation for V5 (or V6) EC-DH and ECDSA public keys.
-
IANA Registry Updates and Designated Experts
- Status:
crypto-refreshwill change most IANA registries to "Specification Required," meaning a Designated Expert (DE) will approve new entries. Version numbers and packet types will remain "RFC Required." - Discussion: The need for clear guidance for the DE was emphasized. Principles for guidance include ensuring specifications are open, stable, and likely to foster interoperability (e.g., not relying on ephemeral web pages or academic papers lacking implementation details). The ISG appoints DEs, but working group input on desirable qualities is crucial.
- Decision: The chairs will draft text for the IANA considerations section of the
crypto-refreshdocument, providing guidance to the Designated Expert based on the principles of openness, stability, and fostering interoperability, with reference to existing IANA Cozy/COSE registries for examples. - Action Item: Co-chairs Stephen Farrell and TKG to draft the IANA guidance text.
- Status:
-
Post-Quantum OpenPGP (Brief Introduction)
- Aaron presented a brief overview of preliminary, unchartered work on Post-Quantum (PQ) OpenPGP.
- Design Criteria: Composite multi-algorithm (Kyber, Dilithium), standalone Sphinx+, backward compatibility (via dual certificates for V4 legacy and V5/V6 PQ), and support for multiple signatures. Use of actual
X25519/X448andEd25519. - Algorithms: Kyber (KEM), Dilithium (signature), Sphinx+ (signature), with SHA-3/Shake as hash functions.
- Challenges: Adapting PQ schemes (which often expect full message input) to OpenPGP's streaming model; handling multiple signatures by clients (which often only parse the first); internal PQ algorithm specifics (e.g., Dilithium's public key prefixing).
- Next Steps: Waiting for NIST's Kyber intellectual property release, publishing a draft, developing experimental Go/OpenLPS/RMP implementations, and improving testing suites.
- A side meeting was announced for further discussion on this topic.
Decisions and Action Items
- Decision: Move the version numbers for new public key format, signature format, one-pass signatures, and PKESK in
draft-ietf-openpgp-crypto-refreshfrom V5 to V6 to avoid conflict withdraft-kook.- Action Item: Co-chair Stephen Farrell to reach out to Werner Koch regarding
draft-kook's V5 usage.
- Action Item: Co-chair Stephen Farrell to reach out to Werner Koch regarding
- Decision: The signature salt length will be tied to the collision resistance size of the hash function used (e.g., 16 octets for SHA-256 equivalent security, 32 octets for SHA-512 equivalent).
- Action Item: Paul W. to create a merge request for this change.
- Decision: Change the V5 signature trailer octet ordering to prevent aliasing with V3 signatures, pending any new information on the mailing list.
- Action Item: A volunteer is needed to create a merge request for this change.
- Decision: Postpone the definition and implementation of context parameters for encryption and signatures to future re-chartered work.
- Decision: Retain the SEC1 representation for EC-DH and ECDSA public keys in V5/V6, not moving to X-only representation.
- Decision: Chairs will draft IANA guidance text for Designated Experts, focusing on openness, stability, and fostering interoperability, drawing examples from IANA Cozy/COSE registries.
- Action Item: Co-chairs Stephen Farrell and TKG to draft the IANA guidance text.
- Action Item: Rick van Rein, Robin, and Jonathan Hamill volunteered to review
draft-ietf-openpgp-crypto-refresh-07.
Next Steps
- The Working Group Last Call for
draft-ietf-openpgp-crypto-refresh-07will be extended. Co-chairs will announce a new deadline to facilitate the committed reviews. - Following the completion of the
crypto-refreshWGLC and publication request, an interim meeting will be scheduled to discuss potential re-chartering for Post-Quantum OpenPGP work. - Aaron's Post-Quantum OpenPGP work will continue with experimental implementations and draft publication, with further discussion in a separate side meeting at IETF 118.