**Session Date/Time:** 08 May 2023 13:00

# [ACE](../wg/ace.html)

## Summary

The ACE Working Group held an interim meeting to discuss the status of several active drafts. The primary focus of the meeting was an in-depth review of `draft-ietf-ace-est-oscore` based on feedback received. Extensive discussion took place on various technical points raised in a review, leading to several agreed-upon actions for clarifying and improving the document. Updates were also provided for `draft-ietf-ace-revoke-token-ntf`, `draft-ietf-ace-oscore-profile`, and `draft-ietf-ace-oscore-gm-admin`.

## Key Discussion Points

### Revoke Token Notification (`draft-ietf-ace-revoke-token-ntf`)

*   **Status:** An update addressing reviews from the working group last call (WGLC) has been submitted. Authors will reply to the mailing list.
*   **Next Steps:** The draft is ready for shepherd review and write-up.

### OSCORE Profile (`draft-ietf-ace-oscore-profile`)

*   **Status:** No updates from the authors in time for this interim meeting.
*   **Next Steps:** Planned updates will be worked on after the shepherd write-up for `draft-ietf-ace-revoke-token-ntf` is complete, targeting the next interim or IETF meeting.

### OSCORE GM Admin (`draft-ietf-ace-oscore-gm-admin`)

*   **Status:** Work has begun on splitting the draft. A new repository has been created on the ACE GitHub organization for the new document. Content is being pulled from the main draft.
*   **Next Steps:** Once complete, `gmn` and `gm-admin-core` will be published as version 0 drafts.

### CoAP EST OSCORE (`draft-ietf-ace-est-oscore`)

Malisa presented updates and discussed remaining comments from a review by Marco.

*   **EST Client Role in Ad-hoc Flow:**
    *   **Discussion:** The draft implicitly assumes the EST client is the Ad-hoc initiator. A question was raised about whether a reverse flow (EST client as Ad-hoc responder) could be ruled out. No use cases were identified for such a reverse flow.
    *   **Decision:** The document will explicitly specify in Section 3 that the EST client must play the role of the Ad-hoc initiator. There was a sense of those present indicating approval for this.
*   **Channel Binding with Pre-shared OSCORE Key Material:**
    *   **Discussion:** The draft specifies Ad-hoc exporter-based channel binding, mimicking RFC 9148's approach to TLS 1.3 exporter. A question arose if channel binding is possible or required when OSCORE key material is pre-shared and Ad-hoc was not executed. It was clarified that the intention to counter TLS 1.2 triple shake is from RFC 9148, not directly applicable here as Ad-hoc is used for authentication. For pre-shared OSCORE, if no interactive protocol establishes the material, channel binding might not be applicable.
    *   **Decision:** The draft will specify that Ad-hoc exporter-based channel binding is applicable only when Ad-hoc is executed and not for cases where pre-shared OSCORE context is used.
*   **Transport of PKCS#10 Request/Response in EAD Fields:**
    *   **Discussion:** A suggestion was made to transport PKCS#10 requests and responses in EAD3 and EAD4 items of Ad-hoc messages, particularly for message 4. The authors' rationale for not doing so is to maintain homogeneity with re-enrollment flows, where Ad-hoc is not required and EST payloads are carried within OSCORE-protected messages.
    *   **Action Item:** Further clarification will be provided on the mailing list regarding this choice, particularly concerning re-enrollment and potential optimizations.
*   **Mandating `osc` Attribute in Links:**
    *   **Discussion:** RFC 8613 states the `osc` attribute is optional. The question was whether it should remain optional for EST resources. An example was given where not mandating it could lead to ambiguity, e.g., accessing a resource over DTLS might signal EST CoAP-s instead of EST OSCORE.
    *   **Decision:** The `osc` attribute in links to EST resources will be mandated to explicitly signal the use of EST OSCORE. This received support from those present.
*   **Server-Side Generation of Keys (Unencrypted Private Key):**
    *   **Discussion:** Unlike RFC 9148 where the private key is encrypted, it was questioned if `draft-ietf-ace-est-oscore` could return an *unencrypted* PKCS#8 private key, given that OSCORE provides end-to-end encryption for the entire EST payload. This would open up a new content format pair.
    *   **Decision:** The draft will specify that an unencrypted PKCS#8 private key can be returned, and a new content format pair for this will be used, due to the end-to-end OSCORE protection. There was a sense of those present indicating approval.
*   **Content Format Support:**
    *   **Discussion:** The draft intends to support content formats similar to RFC 9148 but did not explicitly state this.
    *   **Decision:** The draft will explicitly state the supported content formats and include a table summarizing them, similar to Table 3 in RFC 9148.
*   **CoAP Options in Section 4.4 (Normative Language):**
    *   **Discussion:** Section 4.4 uses "it is recommended that" for several requirements (e.g., delayed responses, support for CoAP options like `oscore`, `URI-Host`, `Block1`, `Block2`, and HTTPS-to-CoAP/CoAPs translation). A reviewer suggested these should be "must" requirements. During the discussion, concerns were raised about the "restatement anti-pattern" if these were presented as new normative requirements. Instead, it was suggested they are logical consequences of using the protocol.
    *   **Decision:** The language in Section 4.4 will be rephrased to use informative language, such as "Note that...", rather than normative keywords (e.g., "must," "required"), to indicate these are natural consequences of implementing the protocol.
*   **CoAP vs. CoAPs Scheme for HTTPS Translation:**
    *   **Discussion:** A sentence stated that "EST URLs based on HTTPS are translated to co-op but with mandatory use of the co-op Oscar option." It was pointed out that the scheme is `coaps` if DTLS is also used.
    *   **Decision:** The draft will explicitly mention that if DTLS is used, the translation scheme is `coaps`.
*   **Mandating Block 1 and Block 2 (follow-up on Section 4.4):**
    *   **Discussion:** Following the decision for Section 4.4 to use informative language, the implication for `Block1` and `Block2` support was discussed. Concerns were raised about potential interoperability issues if `Block1` and `Block2` support were optional, especially when dealing with large certificates. Reference was made to RFC 9148, which *mandates* `Block1` and `Block2` for servers, and `Block2` for clients (and `Block1` for clients sending large requests).
    *   **Action Item:** Malisa will review all CoAP options and their normative requirements in RFC 9148 and ensure consistent and normative mapping for `draft-ietf-ace-est-oscore` where appropriate.
*   **Secure Association Between EST Client and CoAP-HTTP Proxy:**
    *   **Discussion:** Section 5 describes a secure association (e.g., TLS) between the EST client and a CoAP-to-HTTP proxy. A suggestion was made to also reference OSCORE as an alternative for this leg, citing an individual draft on OSCORE-capable proxies. The figure might also need clarification.
    *   **Decision:** A paragraph will be added to the text to explain that both DTLS and OSCORE can be used for establishing a secure association between the EST client and the CoAP-to-HTTP proxy.

## Decisions and Action Items

*   For `draft-ietf-ace-est-oscore`:
    *   **Decision:** Explicitly specify in Section 3 that the EST client must play the role of the Ad-hoc initiator.
    *   **Decision:** Specify that Ad-hoc exporter-based channel binding is applicable only when Ad-hoc is executed, not for pre-shared OSCORE context.
    *   **Action Item:** (Malisa) Provide clarification on the mailing list regarding why PKCS#10 requests/responses are not transported in EAD fields for homogeneity with re-enrollment.
    *   **Decision:** Mandate the `osc` attribute in links to EST resources.
    *   **Decision:** Specify that the private key can be returned as unencrypted PKCS#8 (due to OSCORE E2E protection) and define a new content format pair for it.
    *   **Decision:** Explicitly state content format support and include a summary table similar to RFC 9148 Table 3.
    *   **Decision:** Rephrase Section 4.4 to use informative language ("Note that...") rather than normative keywords for general CoAP option requirements.
    *   **Decision:** Explicitly mention that if DTLS is used, the scheme for HTTPS translation is `coaps`.
    *   **Action Item:** (Malisa) Review all CoAP options in the document, particularly `Block1` and `Block2`, and ensure their normative requirements align consistently with RFC 9148.
    *   **Decision:** Add a paragraph explaining that both DTLS and OSCORE can be used for secure association between the EST client and a CoAP-to-HTTP proxy.
    *   **Action Item:** (Malisa) Respond to Marco's review on the mailing list and release a new version of `draft-ietf-ace-est-oscore` by mid-next week incorporating these changes.
*   For `draft-ietf-ace-revoke-token-ntf`:
    *   **Action Item:** (Yoron, Shepherd) Complete the shepherd write-up within the next two weeks.

## Next Steps

*   `draft-ietf-ace-est-oscore` will see a new version addressing the discussed review comments and clarifications.
*   The shepherd write-up for `draft-ietf-ace-revoke-token-ntf` is expected to be completed soon.
*   Work on splitting `draft-ietf-ace-oscore-gm-admin` will continue, with version 0 drafts (`gmn` and `gm-admin-core`) expected for publication.
*   Discussions on `draft-ietf-ace-website-profile` will resume in the second half of May between the authors.
*   Updates for `draft-ietf-ace-oscore-profile` are planned for the next meeting or IETF.