Hi Marco, On 2021-05-22, Marco Tiloca <[email protected]> wrote:
> On 2021-05-21 15:21, Olaf Bergmann wrote: >>> a) Clarify that the elements of the structure in Figure 9 of Section >>> 3.3.2 have to follow that exact order. This ensures that the >>> result and >>> its following encoding are deterministic. This can't be taken for >>> granted from a CBOR implementation building a CBOR map. >> I do not see why we would need to mandate this order. Although this >> could help with optimized parsers, it violates Postel's theorem and >> therefore should be avoided IMO. >> >> (That we indeed might have to say in the document is whether duplicate >> keys are allowed. As we are just using data represenations from other >> sources such as COSE and the CBOR-OAuth mappings, I would expect these >> specs to define the restrictions on the deterministic CBOR; I did not >> check that, though.) > > ==>MT > I initially interpreted that, by using the elements retrieved from the > received Token, the RS had to rebuild and store exactly the same > serialization that the client will have later built and sent on the > wire as "psk_identity". > > That would have required C and RS to agree on a canonical format of > the CBOR map in Figure 9, to be sure that the "psk_identity" in > ClientKeyExchange can match with the same "psk_identity" that the RS > rebuilt and stored after receiving the Token. > > Now my RS is storing as local lookup-label only the "kid" (rather than > the whole "psk_identity" to expect on the wire). If the RS does so and > actually relies on the "kid" only as a local lookup-label, I agree > it's not necessary to have a fixed order of "kty" and "kid" into > "COSE_Key". Exactly: The kid included in cnf.COSE_Key is supposed to be the index into your lookup table to retrieve a previously uploaded access token. >>> c) In Section 3.3.2, the text before Figure 9 says: "This >>> structure then >>> is included as the only element in the "cnf" structure that is >>> used as >>> value for "psk_identity" as shown in Figure 9." >>> >>> I think it should be clarified what "is used" actually >>> means. This >>> can be either: >> Commit be8ac2c now clarifies that the serialized CBOR structure is put >> into the psk_identity (option i). > > ==>MT > I thought the CBOR serialization should refer to the most outer > structure as the one used as value of "psk_identity", i.e. the map > including the "cnf" element, also called "cnf structure". > > Then, still following the same functional approach of option (i), I > think the text should actually say: > > OLD: > The CBOR serialization of this structure then is included ... > > NEW: > This structure then is included as the only element in the `cnf` > structure, whose CBOR serialization is used as value for > `psk_identity` as shown in ... > > > Correct? To be even more clear, it would help to include after Figure > 9 also the actual serialization used in "psk_identity" for that, which > should be: > > 0xA1 08 A1 01 A2 01 04 02 48 3D027833FC6267CE > > <== Thanks. I have updated the text as suggested and included the actual serialization. (See [1]). [1] https://github.com/ace-wg/ace-dtls-profile/commit/608350c6a23a563263292d8b0f94f631a162f345) > it seems anyway possible in Californium to be compliant with the spec Good to hear that. Grüße Olaf
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
