(Notes: MT, RH, CA)
TH doing introductions and agenda bashing
(none)
MT presenting.
MT (p2): Recapping the solution. One access token for operations at
broker and one for operations at the KDC.
MT (p3): Narrowed to CoAP from MQTT+CoAP by May agreement. Updates from
applying AD comments to other document also here.
MT (p4): Updates for v-01. Editorial and IANA considerations.
MT (p5): Clarified point about nonce generation when TLS is used.
Clarified randomness and length of nonces. Adding references to
Appendixes.
MT (p6): We think the document is ready for WGLC.
GS: Believe this is ready; followed that draft.
TH: Can have WGLC within next couple of weeks.
MT presenting.
MT (p2): Recap, key feature is the AS uploading the access token to the
RS on behalf of the client.
MT (p3): Updates for v-06. Editorial. CDDL model with abbreviations.
MT (p4): Elaborated on the to_rs and from_rs parameters. The AS needs
to understand the semantics of these. In case of problems: Fall back to
original workflow, AS returns access token to client.
MT (p5): Considerations about updated_rights parameters, signals
updating of access rights.
MT (p6): Further details and semantics about updated_rights parameter.
MT (p7): IANA considerations. Updates to "Parameter Usage Location",
adding as-rs request and rs-as response.
MT (p8): Reminder: We have 7 open errata for RFC9200, please review.
MT (p9): Next steps.
DR: About updated_rights parameter. Suggested it, and a ton got added.
Editorial: use forward reference to keep "upload token" section not
noisy. Question: About "RS forgets, and AS sends update". C gets error.
So, new series gets started?
MT: (agrees)
DR: What if client forgets? New token, not an update_?
MT: Nothing to update; yes.
MV presenting.
MV (p2): Today, covering 2 reviews from MT and ED.
MV (p4): MT provided 40 mostly editorial fixes, thinks document is
ready. Concrete non-applied: On normative language (input please!). MT
thinks "must" should be "MUST", but already mandating EDHOC and thus not
restate.
TH: If we mean "must" to mean "we're restating a normative requirement",
should say that explicitly in terminology.
MV: The last quoted sentence may cover your concern
TH: Doesn't work for readers; should be consistently 2119 or explain why
we do it differently
MT on chat: s/must/has to
MV: WFM.
CA on chat: Thumbs up on lower-case must when re-stating.
JR: RFC2119 update says lower-case has no special meaning. Avoiding
using must by has-to is common (???). Relying on syntax to disambiguate
is not good.
TH: That is my objection
JR: Not fine to redefine. We SHOULD NOT do that ;-)
TH: At the start of that paragraph, "The requirements here come from
EDHOC".
MV (p4): 4th paragraph.
TH: IMO that is poster child for when non-normative "must" makes sense.
MV, summarizing: So for 3rd and 4th, get away from lower-case "must" and
go with alternative wording.
TH: Got a lot of thumbs up, sounds good
ED on p4, 4th paragraph: Who issues what?
MV: Clear to me, needs clarification?
ED: Needs to be clearer, "its" can be ambigous
MV (p5): On ED's post-cutoff review.
MV (p6): just accepting ED's proposal, not controversial.
MV (p7): on "bag". is it always a bag or can be single cert? looked it
up and the response can be a single cert. still we want to get away from
the term "bag"
GS: Remnant from EST, responding with bag, is probably not right thing
to do. Should chain or single cert. Should take away bag.
ED: Depends if want to mimick what EST-COAPS has, does this allow bag?
Allows to have either one or multiple.
MV: Looking it up. The response is either a single cert or (I guess) a
bag. need to double-check
ED: If want to optimzie for constrained, chain makes sense.
MV: In case of DER encoding: Keep original semantics of EST-COAPS, but
for CBOR encoding we use chains. Works?
Someone in room: "Okay"
TH: If no more reviews come in, yes. Of course, comments can still come
any time. Once ED is happy wiht -10, do shepherd writeup.
RH presenting.
RH (p2): Overview.
RH (p3): Added requirements for the RS to support the Uri-Path-Abbrev
option defined in -core-uri-path-abbrev, for abbreviating
/.well-known/edhoc. Also expanded on using the two new EAD items
(request of other peer's credential by value and request for information
that would normally be in the Request Creation Hints response)
RH (p3): Why hint? Client may not know which AS to use yet. Combinable
with new credential-by-value item.
RH (p4): Example of full interaction where both those EAD items are
used. The client starts EDHOC with the RS without even knowing what AS
should be contacted. There's some limitations, but it works for pointing
the client to the right AS.
RH (p5): More updates, with examples for the ead_value of the new EAD
items.
RH (p6): Unlike in the DTLS profile, we forbid the AS from differing
CNFs.
RH (p7): Example work. Early allocations. Ciphersuite flexibility.
Implications of options.
CA on handling suites: Prefer not audience, but provide higher-level
information (not precisely method). Spelling out methods is problematic
anyway (see recent mail).
CA: Recent review just shortly before meeting, on list. Mostly
editorial. Selected items I'd like to bring up:
RH: On session_id, can make it more unique.
RH: On registry content, we looked at EDHOC RFC at what is shown as
examples of app profiles (appendix or main section), that's why we have
content format option and the endpoint identity.
CA: Back then, had little experience with EDHOC as it was just being
written. Now we gathered experience, let's focus on the things we
learned are relevant, not everything that was thought of as possibly
relevant back then.
MT on session ID: 2nd option from mail should work
MT: as for early alloc, would need new version with IANA considerations,
with actual values.
TH, wrapping up: ToDos