See below.
Jim From: Samuel Erdtman [mailto:[email protected]] Sent: Thursday, June 22, 2017 1:40 AM To: Jim Schaad <[email protected]> Cc: [email protected]; ace <[email protected]> Subject: Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt Thanks Jim! Se comments inline On Sun, Jun 18, 2017 at 9:21 PM, Jim Schaad <[email protected] <mailto:[email protected]> > wrote: Comments on this version of the draft. Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR tag at this point In section 7.1 step 6 describes how one can add the CWT CBOR Tag to the full CWT if transport layer cannot indicate that this is a CWT. In this case you would want first the COSE tag and then the CWT tag this is described in section 6. We asked Carsten about this before we added the text so it should be okay. In section 7.2 step 6 and 7 CWT CBOR tag is not mentioned as far as I can tell. [JLS] So if an intermediary adds a layer of wrapping (i.e. encrypts it to the end point) but the original entity who signed it put the CWT tag on it, it will be and invalid CWT if the tag was not removed? Appendix A.3 - I was unable to reproduce the example. I assume that this means that a deterministic signature algorithm is not being used. While a verifier cannot tell if one is being used, the COSE document does strongly suggest that one be used. Additionally, it helps in testing if one is used so that a signature creator can be more easily tested. Correct I have not used a deterministic signing algorithm. I have used COSE-JAVA to create the examples, is it possible to configure that implementation to generate deterministic ECDSA signatures? When working with my JS implementation I have noticed that support for deterministic ECDSA implementations are hard to find. [JLS] With COSE-JAVA, if you are using anything remotely recent is deterministic, so that should not be a problem. I put this change into the sources about 8 months ago. The problem may be the same issue as for A.5 where something is different in the data to be signed. Appendix A.5 - I was unable to reproduce the example. Specially the tag value does not match with the one that I compute. That is bad. but apart from the tag it looks good? [JLS] Yes apart from the tag I matched everything – including the encryption. This bothers me if you are using the COSE-JAVA to produce the examples. I routinely run regression tests on both language libraries so they should produce the same output given the same inputs. This triggers in my mind that you might have done something odd with the external data and thus we are generating different tags. It would be something that is being done for signing and for encryption but not mac. Minor: In section 2: Is there a reason not to define CWT claim value in this section Sorry I´m not following, could you please explain a bit more`? [JLS] You thought it was reasonable to define a “CWT encoded claim key” in the terms. I was just thinking that it would be symmetric to have the values have defined here at the same time. -----Original Message----- From: Ace [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of [email protected] <mailto:[email protected]> Sent: Monday, June 5, 2017 6:27 PM To: [email protected] <mailto:[email protected]> Cc: [email protected] <mailto:[email protected]> Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments of the IETF. Title : CBOR Web Token (CWT) Authors : Michael B. Jones Erik Wahlström Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cbor-web-token-05.txt Pages : 23 Date : 2017-06-05 Abstract: CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT), but uses CBOR rather than JSON. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cbor-web-token-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> . Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Ace mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
