Hi Göran, John, Marco and Rikard, and group, I've read the ACE EDHOC OSCORE profile document preparing for this week's meeting, in different levels of detail.
Some might be clarified trivially, for some it may make sense to open an issue. If you like, I can file those not resolved in a single mail exchange in there after a first round on list. * For the code points requested in EAD items, please consider early allocation, and don't alter the values without good reason. In particular, aiocoap and Ariel OS's coapcore already use EAD 15 to trigger sending a credential by value. Those implementations use the EAD item outside of the ACE context, and it is valuable there. (Relatedly, please let me know if you need RFC7942 items). * Consistency: 3.1 lists CWT as a possible credential type prominently (1st mention), whereas the introduction just lists CCSs, *509 "or a different type". * "If the identifier specified in the "session_id" parameter of the POST request identifies multiple, ongoing token series of which C has an access token, then C MUST specify": This sounds quite hard to get right. (Not that I'd have implemented token series at all). C is a constrained device and as such may discard information it doesn't need any more. If C has discarded all but the most recent users of a given "session_id", and applied this paragraph strictly, it'd be sending a session_id without audience, but AS might still remember the other sessions and not know which one to update. Plus, issuing identitical sessioion IDs to a single client on different audiences sounds like something that only few ASs would do, and then Cs get tested against the others and suddenly things break. I think the good paths around this are either to generally ask the AS to not issue the same session_id twice to the same client on different audiences, or to generally require that the audience be sent along; the conditional / flexibility looks like an over-optimization to me. * "When later issuing further access tokens to the same pair (C, RS) using the same AUTH_CRED_RS, it is expected that the response to C includes AUTH_CRED_RS by reference." Why would the rs_cnf be transported at all? This is supposed to be used inside an EDHOC session, and that credential can't change anyway (just like the client's req_cnf cant' change). Later, it even says explicitly that there is no rs_cnf in updates. * EDHOC_Information / methods: An EDHOC_Information can indicate support for one or both flows of EDHOC. Methods 1 and 2 are directional -- but I'd suppose that any node would implement "I am signing" or "My peer is using a static key" independent of which role it has. In 4.3 and 4.4 it becomes clear that the methods only relate to the forward flow, because that's where the client has any sayin it, but it might be helpful to say "supported EDHOC methods in forward flow" in the description. * Why would an implementation require the default content format to be sent when interacting through /.well-known/edhoc in the first place? (If there's no reason to do that, coap_ct is moot). * The EDHOC transports registry and the EDHOC_Information transports parameter seem to be a limited subset of the mechanisms of transport-indication. * A lot of the language about booleans, true, false, simple values and 0xf5 after Table 1 sounds needlessly repetitive, also of things that any user of CBOR or JSON would know. Stating that they have boolean values would IMO suffice. * How are endpoint identity types supposed to be used, and why are they needed? * EAD items: I think that writing all the values down as hex encoded CBOR is more distracting than helpful, especially because those EAD items go into EDHOC as CBOR values, and not as encoded byte strings. For example, the ACCESS_TOKEN example could say: > Example: Assuming IANA label 26, used as critical label (negative), > and a token 8343a1010aa2044c53...0f6a (partly omitted for brevity): > > EAD_ACCESS_TOKEN = (-26, h'8343..0f6a') * Why is EAD_ACCESS_TOKEN only supporting the first token? If a new token coincides with the desire to update, why send it as an extra POST to /authz-info on the old context and establish a new one with EAD_SESSION_ID, when this could go in a single operation? (The way I model the EAD_ACCESS_TOKEN items in implementations is that it goes into the same place as a POST to /authz-info and then produces a reference to some key slot, so I think I'd actually have to explicitly write code to forbid accepting a session-updating token by the current wording). * 4.3 and 4.4: All that is in there seems to follow from what has been written previously, or from referenced standards. If that is so, a note (and no normative language) would help readers skip this if they can do without the illustration which these subsections provide. * Paragraphs 3-5 of 4.13 appear a bit out of context, maybe that section could be reordered to have more of a flow. * Figure 9 does not look like valid CBOR; in any case, maybe the CBOR encoding is better done in prose, eg. > In its first use (from C to RS), the item is used without a value. > In its second use (from RS to C), the value of the > EAD_REQUEST_CREATION_HINTS EAD item is the CBOR encoding of the map > defined in …. BR c -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
