**Session Date/Time:** 26 Jul 2022 17:30

# cose

## Summary

The COSE working group discussed the status of several documents, including the Auth48 cluster, the COSE HPKE document, C509, BLS key representations, and CWT claims in COSE headers. Key technical discussions revolved around the ephemeral public key encoding format in COSE HPKE, the need for non-AEAD algorithms in `COSE_Encrypt` for specific use cases like firmware updates, and the ongoing work to represent post-quantum cryptographic algorithms within COSE structures. Decisions were made regarding the COSE HPKE key format and initiating a call for adoption for the post-quantum draft.

## Key Discussion Points

*   **Document Status Update (Auth48 Cluster, Countersign, X509, Hash Algorithms)**
    *   The cluster of four documents (Hash Algorithms, Auth48, X509, Countersign) is facing significant publication delays.
    *   The AD (Paul Wouters) expressed urgency, setting a two-week deadline for authors to finalize changes before pushing to the RFC Editor, citing long-standing external dependencies.
    *   Ben Cadeck reported Auth48 is largely complete, with minor cosmetic tweaks and pending confirmation of AEAD usage values. AD approval is needed for potential content changes made during Auth48.
    *   Marco raised a concern about an incorrect reference in section 3 of the Countersign document, which Roman will verify.

*   **COSE HPKE Document - Ephemeral Public Key Encoding**
    *   Discussion centered on the format for encoding the ephemeral public key.
    *   Two proposals: Hannes's approach uses the existing `ec2` key type with `x` and `y` coordinates, aligned with the COSE RFC. Alari's proposal uses an `OKP` key type with a new HPKE-specific value and raw data dump from the HPKE algorithm output.
    *   Consensus in the room strongly favored using the existing `ec2` key type, as it leverages an already standardized COSE key format. The `OKP` approach was seen as potentially overloading the key type and conflating application-level algorithms with key representations.
    *   The current draft already uses the `ec2` format.

*   **Non-AEAD Algorithms in `COSE_Encrypt`**
    *   **Problem:** `COSE_Encrypt` currently mandates Authenticated Encryption with Associated Data (AEAD). However, specific use cases, such as firmware updates in the SUIT working group for IoT devices, require non-AEAD modes (e.g., counter mode, CBC) for memory efficiency and to reduce flash wear cycles. Integrity is provided by separate signatures.
    *   **Proposal:** Register non-AEAD algorithms in the COSE registry with strong warnings, indicating they should only be used if integrity is guaranteed by another mechanism.
    *   **Discussion:**
        *   Cedric suggested ensuring signature verification occurs *before* decryption for structural security.
        *   Brendan Moran clarified that requiring pre-decryption integrity verification is often impractical in firmware update scenarios due to resource constraints (flash cycles, energy).
        *   Ben Cadeck noted that RFC 8152 doesn't explicitly forbid non-AEAD encryption, only discusses AEAD modes. He suggested a "how-to" section for non-authenticated modes.
        *   John Bradley recalled an explicit JOSE decision *against* non-AEAD to prevent misuse, balancing specific use cases against general security posture.
    *   **Decision:** Hannes and Russ will write a draft to propose registering these non-AEAD algorithms, making the case to the working group for adoption, potentially marking them as deprecated from the outset (similar to RSA/SHA-1).

*   **C509 Document (CBOR Encoded X.509 Certificates)**
    *   A new version has been submitted.
    *   Ongoing work includes a master's thesis on OCSP encoding in C509.
    *   Implementations are being developed (e.g., Armando Garcia from Fraunhofer).
    *   Feedback from Kerry Bonnell suggested changes to the general subtree and improvements to document structure (aligning with RFC 5280).
    *   More reviews are actively sought from the working group.

*   **BLS Key Representations (draft-ietf-cose-bls-key-representations)**
    *   This draft was recently adopted by the working group.
    *   It registers parameters for BLS (Boneh-Lynn-Shacham) curves (12-381 and 4-48-581) for both JWK and COSE key representations.
    *   BLS curves are pairing-friendly, enabling novel algorithms like aggregate signatures (used in blockchain applications, e.g., Ethereum, Filecoin) and BBS signatures (supporting selective disclosure, proof of possession).
    *   The key parameters are defined in the draft.
    *   **Next Steps:** Produce informational samples for both COSE_Key and JWK.

*   **CWT Claims in COSE Headers (draft-ietf-cose-cwt-claims-in-cose-headers)**
    *   **Rationale:** To provide a mechanism equivalent to JWT (allowing claims in the protected header) for CWT, which was not explicitly defined.
    *   **Use Cases:**
        *   **Encrypted CWTS:** Placing claims (e.g., `iss`, token validity) in an unencrypted header can aid key identification for decryption or pre-validation.
        *   **COSE Sign with Detached Payloads:** Allows describing the signer and validity information for non-CWT payloads.
    *   **Design:** A new COSE header parameter whose value is a map containing CWT claims. This handles the distinct numeric allocations of COSE header parameters and CWT claims.
    *   **Discussion:**
        *   Michael expressed strong support, noting its usefulness for binary representations in high-volume cyber-physical supply chains.
        *   Carsten questioned the clear semantics of CWT claims (e.g., `not_before`) when applied to arbitrary COSE structures that are not themselves CWTS (e.g., a signed firmware upgrade). He advocated for explicit definitions of what such claims mean in various contexts and inclusion of CDDL samples.
        *   Mike Jones agreed that the document needs to provide a deeper treatment of these questions.
    *   **Decision:** Tobias and co-authors will add CDDL samples and clarify the meaning and usage context of CWT claims when embedded in various COSE header scenarios.

*   **Post-Quantum Cryptography in COSE (draft-ietf-cose-post-quantum-signatures)**
    *   **Motivation:** To support an upgrade path for COSE and JOSE to use post-quantum resistant algorithms for key and signature representations, focusing on envelope formats.
    *   **Focus:** Key representations and signature representations (not key encapsulation/exchange at this stage).
    *   **Algorithms:** Current focus is on NIST candidates: lattice-based (Dilithium, Falcon) and hash-based (SPHINCS+).
    *   **Discussion:**
        *   John Erickson suggested waiting for NIST's final standardization before publication.
        *   Mike Perrock argued for developing drafts in parallel to address US federal executive orders for crypto agility and interoperability, but agreed final publication should await NIST's choices.
        *   Paul Wouters (AD) recommended parallel work with NIST and CFRG, and encouraged joining the dedicated PQC mailing list.
        *   John Erickson asked about hybrid systems (combining PQC with traditional crypto). Ori Steele clarified the current draft focuses on pure PQC representations as a foundational step, but hybrid approaches can be explored in parallel.
    *   **Goals:** Provide an intuitive upgrade path, ensure cryptographic agility, clarify `kty` and `alg` definitions, and reserve necessary IANA parameters.
    *   **Status:** Draft v-01 has been submitted, and feedback is welcome.
    *   **Next Steps:** Clarify `kty`/`alg` definitions, add detailed examples for Falcon and SPHINCS+, and generate test vectors.

## Decisions and Action Items

*   **COSE HPKE Ephemeral Public Key Encoding:** Consensus was reached to use the existing `ec2` key type for the ephemeral public key encoding in the COSE HPKE document. The chairs will send a note to the mailing list to confirm this consensus and invite further discussion.
*   **Non-AEAD Algorithms:** Hannes and Russ will write an Internet Draft proposing the registration of non-AEAD algorithms within the COSE registry, including appropriate warnings and a rationale for their use in specific contexts (e.g., firmware updates).
*   **CWT Claims in COSE Headers:** Tobias and co-authors will add CDDL samples to the draft and clarify the meaning and contextual usage of CWT claims when included in COSE headers for various scenarios, including detached payloads.
*   **Post-Quantum Cryptography:** The chairs will initiate a call for adoption on the mailing list for the `draft-ietf-cose-post-quantum-signatures` document.

## Next Steps

*   **Auth48 Cluster:** Authors (Ben Cadeck, Karsten, Evo) to finalize outstanding changes, especially for Auth48, within two weeks, and ensure AD approval for any content changes. Roman to double-check the Countersign reference.
*   **COSE HPKE:** Chairs to confirm consensus on `ec2` key type on the mailing list.
*   **Non-AEAD Algorithms:** Hannes and Russ to draft the document for non-AEAD algorithm registration.
*   **C509:** The working group is encouraged to provide more reviews of the `draft-ietf-cose-c509` document.
*   **BLS Key Representations:** Authors to produce informational samples for both COSE_Key and JWK formats.
*   **CWT Claims in COSE Headers:** Authors to incorporate CDDL samples and clarify claim semantics in the draft.
*   **Post-Quantum Cryptography:**
    *   Chairs to send a call for adoption to the mailing list.
    *   Authors to clarify `kty`/`alg` definitions, add detailed examples for Falcon and SPHINCS+, and produce test vectors.
    *   Working group members are encouraged to join the PQC mailing list for broader cross-WG coordination.