Given that it was stated that the authors believe that the document was
ready for publication, I decided to do another review pass.
1. Following the discussion in the SET WG meeting, I believe that it would
be reasonable to define some inputs for the external data fields to allow
for distinguishing between the different uses of JWT structures. Language
about different applications extending this structure would also be
reasonable.
2. I do not know if the authors looked at changing the Type3StringOrURI so
that it would explicitly tag URIs or not. I do no remember seeing any
discussions on the list but have not gone back to search
3. I find the description of Type6NumericDate to be slightly confusing as
it appears to imply that this is not using a numeric value when it does.
4. The authors need to look at their use of Type6NumericDate and determine
if this is what they really want to do. All of the examples are incorrect
because of this tag usage.
5. After the discussions in the SET group, do the authors which to
re-consider the MUST ignore statement in the first paragraph of section 3?
6. The string "6 tag value 1" is normally written as "6.1" when looking at
pretty-printed CBOR diagnostics. This would be clearer than what is
written.
7. The text should be altered to use a TBD for the CWT tag rather than
using a constant so this is highlighted.
8. The note for step 5 in section 6.1 is problematic from a number of
things. A) AEAD algorithms are required, so it is not clear that the
recommendation makes sense. B) there is a big difference between signing
and MACing in terms of the amount and type of integrity provided. Replacing
signing w/ AEAD loses a lot.
9. Step 6 in section 6.1 does not agree w/ the language in section 5. MUST
vs maybe.
10. In starting to verify the examples I ran across the following two
issues:
a) The hex string and the diagnostic notation are equivalent, but they are
not the same. Specifically, the order of claims is not the same. CBOR.ME
gives
{2: "erikw", 3: "coap://light.example.com", 4: 1444064944, 5: 1443944944, 6:
1443944944, 1: "coap://as.example.com", 7: h'0b71'}
b) The encoding of some of the claims is incorrect according to the
document. It should be
{ 1: "coap://as.example.com", 2: "erikw", 3: "coap://light.example.com", 4:
1(1444064944), 5: 1(1443944944), 6: 1(1443944944),7: h'0b71'}
Or
a7 # map(7)
01 # unsigned(1)
75 # text(21)
636f61703a2f2f61732e6578616d706c652e636f6d # "coap://as.example.com"
02 # unsigned(2)
65 # text(5)
6572696b77 # "erikw"
03 # unsigned(3)
78 18 # text(24)
636f61703a2f2f6c696768742e6578616d706c652e636f6d #
"coap://light.example.com"
04 # unsigned(4)
c1 # tag(1)
1a 5612aeb0 # unsigned(1444064944)
05 # unsigned(5)
c1 # tag(1)
1a 5610d9f0 # unsigned(1443944944)
06 # unsigned(6)
c1 # tag(1)
1a 5610d9f0 # unsigned(1443944944)
07 # unsigned(7)
42 # bytes(2)
0b71 # "\vq"
Note the additional tagging which is required.
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
