**Session Date/Time:** 26 Jan 2026 11:00

# [OPENPGP](../wg/openpgp.html)

## Summary

This interim meeting focused primarily on reviewing the status of existing working group drafts to assess their readiness for Working Group Last Call (WGLC) and discussing potential new drafts for adoption. Key discussions included the progress of `draft-ietf-openpgp-nist-bp-comp`, `draft-ietf-openpgp-persistent-symmetric-keys`, and `draft-ietf-openpgp-replacement-keys`, with identified implementation issues and next steps for each. The working group indicated a strong preference for an adoption call for `draft-ietf-openpgp-hkp-v2` and a subsequent call for `draft-ietf-openpgp-grease`, while deferring `draft-ietf-openpgp-media-types`. The concept of adopting `draft-dkg-openpgp-stateless-openpgp` (SOP) as a "living" draft without an immediate RFC goal was also discussed.

## Key Discussion Points

*   **Administrivia:**
    *   The IETF Note Well was presented.
    *   The agenda focused on draft status, potential adoption calls, and IETF Shenzhen meeting plans.
*   **Status of Working Group Drafts:**
    *   **`draft-ietf-openpgp-pqc`**: Confirmed with the RFC Editor in the edit state. An editorial issue was noted via email, expected to be a minor fix.
    *   **`draft-ietf-openpgp-nist-bp-comp`**:
        *   Stavros reported two implementations: one in RNP/Botan (by Falco and Johannes) and one by Stavros himself (in an unspecified context, later clarified as Sequoia-like).
        *   Neil (Sequoia) acknowledged Stavros's changes, noting good code quality, but had not yet performed a deep review or accepted a Merge Request.
        *   A key question arose regarding test vectors and code points, specifically whether to use experimental code points for initial interoperability testing or wait for assigned 2B code points.
        *   The need for the test suite to support variant branches and experimental code points for demonstrating interop was highlighted.
    *   **`draft-ietf-openpgp-persistent-symmetric-keys`**:
        *   Daniel reported draft implementations in OpenPGP.js (his own) and rpgp (by Heiko).
        *   A small interoperability issue was identified: Daniel had omitted the cleartext symmetric algorithm ID octet in the SEIPD v1 packet for V3PKS, a field added for x25519, x448, and PQC algorithms that also needs to be in this draft. This also exposed issues in other related specifications.
        *   A question was raised about potentially using HKDF with SHA512 instead of SHA256, especially for signatures, to ensure no weakest link. This was considered a substantive issue.
        *   Daniel indicated he would mint a new draft with fixes and add test vectors once implementations interoperate.
    *   **`draft-ietf-openpgp-replacement-keys`**:
        *   Andrew reported the draft is stable with no pending changes, awaiting an implementation from Heiko (presumed in rpgp).
        *   Daniel indicated potential interest in implementing it in PGPi if time allows, stating that doing so would also constitute a different level of review.
        *   The draft is currently in a holding pattern awaiting implementations.
*   **Possible New Adoptions:**
    *   **`draft-ietf-openpgp-hkp-v2`**: Strong support for adoption was expressed by several participants (Daniel, Neil, and others). It was seen as crucial for safely deploying v6 keys and was considered a waiting adoption.
    *   **`draft-ietf-openpgp-grease`**:
        *   Andrew explained the intent for key servers to generate greasy code points when serving keys over HKPv2 to test client graceful ignorance, similar to TLS Grease.
        *   Daniel raised a point about agreeing on *how* to use Grease, e.g., only in key server responses vs. in general messages.
        *   Andrew clarified that the primary goal is to reserve a block of code points in registries for future use, with initial focus on key server usage.
    *   **`draft-ietf-openpgp-media-types`**:
        *   Andrew noted the complexity and potential for "bike-shedding" due to historical issues with PGP/MIME and the need to differentiate binary vs. ASCII formats. He expressed concern about defining things in an ad-hoc way.
        *   Daniel suggested that HKP might only need one or two specific media types, and these could potentially be defined directly within the HKP draft to avoid blocking HKP, even if it means deferring a comprehensive solution.
    *   **Stateless OpenPGP (`draft-dkg-openpgp-stateless-openpgp` - SOP)**:
        *   Daniel (as author) was open to working group adoption but questioned if it was intended to be published as an RFC, suggesting it might evolve as a "living" unpublished document for the working group's needs.
        *   Steven indicated that adopting a draft without an immediate RFC goal is process-wise possible, allowing the working group to own and maintain it as a living specification.
        *   Daniel (dkg) agreed to help with SOP editing.
    *   **External Secrets (`draft-dkg-openpgp-external-secrets`)**: Daniel (dkg) briefly mentioned this as another bite-sized draft, defining an S2K usage type for hardware tokens, but no specific action was taken.
    *   **Attested Certifications (`draft-dkg-openpgp-attested-certifications` - 1PA3PC)**:
        *   Andrew raised this long-standing draft, noting implementations in Sequoia and Hagrid (used by keys.openpgp.org).
        *   He questioned the desire for further client implementations and promotion if there wasn't broader interest.
*   **IETF Shenzhen Meeting:**
    *   A sense of those present indicated a preference *not* to have a formal working group session at IETF Shenzhen due to time zone suitability and remote participation considerations.
    *   An interim meeting (before or after IETF) was preferred.

## Decisions and Action Items

*   **`draft-ietf-openpgp-pqc`**: The identified editorial issue will be handled by Daniel, with suggested text to be provided for review via a pull request.
*   **`draft-ietf-openpgp-nist-bp-comp`**:
    *   The test suite needs to be extended to test interoperability with existing implementations (Sequoia, RNP/Botan) using experimental code points.
    *   Daniel (dkg) and Stavros will coordinate on integrating Sequoia's implementation into the test suite and generating relevant test data.
    *   Once interoperability is demonstrated and recorded, the working group will proceed with assigning non-experimental code points and then consider a Working Group Last Call (WGLC).
*   **`draft-ietf-openpgp-persistent-symmetric-keys`**:
    *   Daniel will address the identified issue of the missing symmetric algorithm ID octet and clarify the HKDF hash choice (SHA256 vs. SHA512).
    *   Once these issues are resolved and implementations interoperate, Daniel will update the Go crypto implementation and the test suite, then the draft will head towards WGLC.
*   **`draft-ietf-openpgp-hkp-v2`**: The chairs will initiate an adoption call for this draft.
*   **`draft-ietf-openpgp-grease`**: The chairs will initiate an adoption call for this draft, following the HKP adoption call.
*   **`draft-ietf-openpgp-media-types`**: No adoption call will be made at this time. The discussion on media types, especially regarding the binary vs. ASCII format differentiation, will continue in parallel with HKP requirements and potentially involve media type experts.
*   **Stateless OpenPGP (SOP)**: The chairs will poll the working group mailing list to assess if adopting `draft-dkg-openpgp-stateless-openpgp` as a working group draft, with the understanding that it may be maintained as a "living" document without an immediate goal of RFC publication, is an acceptable plan. Daniel (dkg) offered to assist with editing.
*   **Attested Certifications (`draft-dkg-openpgp-attested-certifications`)**: Andrew will start a discussion thread on the mailing list to gauge interest in further implementation and promotion of this draft.
*   **IETF Shenzhen Session**: The chairs will communicate to the mailing list that no formal working group session is planned for the upcoming IETF meeting in Shenzhen, favoring an interim meeting instead.

## Next Steps

*   Chairs to initiate adoption calls for `draft-ietf-openpgp-hkp-v2` and subsequently `draft-ietf-openpgp-grease`.
*   Chairs to send a query to the mailing list regarding the proposed approach for SOP.
*   Andrew to initiate a mailing list discussion on `draft-dkg-openpgp-attested-certifications`.
*   Implementers of `draft-ietf-openpgp-nist-bp-comp` and `draft-ietf-openpgp-persistent-symmetric-keys` to continue working on interoperability and test suite integration.
*   The working group will hold an interim meeting around the time of the IETF Shenzhen meeting instead of a formal session.