Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-ace-chair-slides-00
TH doing introduction
PW: A bit slow in processing some ACE documents waiting for AD review.
Done now, so they're back to the authors to process.
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-ace-edhoc-profile-for-ace-00
GS presenting
GS (p3): Recap of the workflow for this ACE profile.
GS (p4): Summary of updates in the latest version.
GS (p5): Defined two new EDHOC EAD items. The first one (item A) can be
used empty or with value. Where used empty, it asks the RS receiving it
to provide Request Creation Hints information, within the same EAD item
in the follow-up EDHOC message in the session. The two instances of the
EAD item as (empty, with value) can be used in (mesage_1, message_2)
in the forward message flow, or in (message_2, message_3) in the
reverse message flow. The EAD item is critical and optional.
GS (p6): The other EAD item (item B) is always empty, and asks the
recipient EDHOC peer to provide its own authentication credential by
value in the follow-up EDHOC message that it sends. It can be used in
message_1 (to request CRED_R by value in message_2) or message_2 (to
request CRED_I by value in message_3).
GS (p7): some of these are useful for EDHOC in general, not just ACE.
MT presenting
MT (p1): Broad scope.
MT (p2): Intended to update 9200.
MT (p3): Clarifications the need for which came up in many documents,
collaborating with RFC Editor.
MT (p4): Further updates done, specificaly about error handling. Error
code for failed proof-of-possession.
MT (p5-8): Bigger update on definitions for "to_rs" and "from_rs".
Original design was not general enough. Revised semantics and
processing. "to_rs" and "from_rs" can be used to carry for instance
the nonces used in the OSCORE ACE profile.
MT (p9): Next steps: Examples of message exchanges, improvements when
updating access rights, guidelines for using anchor_cnf when issuing
access tokens for group-audiences.
MT presenting
MT (p2): About enabling new formats for public authentication
credentials in the DTLS profile (RFC 9202). CCS by value and COSE Keys
by reference. Also certificates by value or reference.
MT (p3): Recent updates: Editorial improvements, terminology. Fixing
examples and update references. Changed CBOR abbreviations.
MT (p4): Considerations about providing credentials by value or
reference (assumptions, coordination and how to choose). Security
considerations about verifying CCS and certificates.
MT (p5): Added two more examples, different credential formats and
coexisting RPK/Certificate modes
MT (p6): Overview of all options. Ref/value, cert mode/RPK mode etc.
MT (p7): Next steps: All intended content is included. Ready for WGLC.
But has two normative refs that are drafts (C509 and ace-edhoc-oscore
profile).
MT: At some point we'll have to stop this document. Chairs, AD: How
shall we proceed?
TH: My preference is to hold here. Easier to update this one if things
change.
PW: Depends on stability of doc. If we're expecting wording changes
(nothing fundamental) then I prefer to push on. If bigger changes are
expected then... Generally I prefer to push and wait at last moment
(e.g., waiting for cluster).
ED: Similar situation in ANIMA; there, progressed to almost RFC editor
(b/c then it'd be harder to push in required changes).
TH: Thanks for the input
MT: Will keep alive and revisit WGLC when those 2 drafts are more
advanced
TH: Let's get in contact afterwards. Certs one seem fine as it looks
like you use those certificates as a black box, more worried about the
other one. We'll figure out a plan
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-ace-est-oscore-00
MV presenting.
MV (p1): EST running over OSCORE.
MV (p4): Issue #69 on transporting certificates by reference. (Resolved
as with any other application of that reference type). As to
interoperabilty, this draft cover it as to during the enrollment process
(but beyond that, it's out of scope).
MV (p5): For the scope of this document, the issue was addressed also
based on updates in draft-ietf-cose-cbor-encoded-certs
MV (p6): Decisional workflow shown as a diagram.
ED: 281 or 287?
MV: follows RFC9148. 281 IIRC.
MV (p7): on #52. CDDL structure of /csrattrs (/att)
MV: WG Last Call?
TH: Any objections?
MV: We have normative ref to C509, Göran what is the status?
GS: That draft was presented in the COSE session; we completed the WGLC.
We'll submit a new version this week and that will go to the Shepherd.
CA (chat): early allocations for edhoc-oscore-profile please.
GS (chat): Yes, let's request early allocation
TH (chat): noted.
MT (post meeting): It might be worth doing early allocation also for
other codepoints than the two EDHOC EAD items. I am thinking especially
about the registrations in the JWT Confirmation Methods (see Section
14.6 of version -08) and CWT Confirmation Methods (see Section 14.7 of
version -08). That would trigger early reviews from Designated Experts,
which would make us have that content right sooner than later, therefore
helping the next procedural steps of
draft-ietf-ace-authcred-dtls-profile that depends on the present
document.