Re: [Ace] How to specify DTLS MTI in COAP-EST
TBH, I'm not a fan of SHOULD+, etc., and they're pretty alien to TLS, so you should just use words if you want to convey these points. With that said, I don't really understand the objective here: we're generally moving towards the CFRG curves, so what's the reasoning for the P256 MUST and why do you think that will change. -Ekr On Thu, Jun 7, 2018 at 10:41 AM, Michael Richardson wrote: > > Hannes Tschofenig wrote: > > why don't you just reference https://tools.ietf.org/html/rfc7925? > > Ignorance :-) > Thank you, I think that we will reference it then; > > Section 4.4 includes: > > At the time of writing, the > recommended curve is secp256r1, and the use of uncompressed points > follows the recommendation in CoAP. Note that standardization for > Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for > this curve will likely be required in the future. > > which is what we want to say anyway. > > > I am not a big fan of making all sorts of different crypto > > recommendations in our specs that differ slightly. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works| network > architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on > rails[ > > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
Thanks. I have no objection to this draft proceeding as-si On Wed, Mar 14, 2018 at 2:55 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > Thanks, Ekr. One more reply to your last comment the bottom of the > message… > > > > *From:* Eric Rescorla <e...@rtfm.com> > *Sent:* Wednesday, March 14, 2018 2:38 PM > *To:* Mike Jones <michael.jo...@microsoft.com> > *Cc:* The IESG <i...@ietf.org>; kathleen.moriarty.i...@gmail.com; > draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; ka...@mit.edu; > ace@ietf.org > *Subject:* Re: Eric Rescorla's No Objection on > draft-ietf-ace-cbor-web-token-13: (with COMMENT) > > > > > > > > On Wed, Mar 14, 2018 at 2:34 PM, Mike Jones <michael.jo...@microsoft.com> > wrote: > > Hi Ekr. Thanks for the review comments. Responses are inline below, > prefixed by "Mike>"... > > > -Original Message- > From: Eric Rescorla <e...@rtfm.com> > Sent: Wednesday, March 7, 2018 12:40 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; > ka...@mit.edu; ace@ietf.org > Subject: Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: > (with COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-ace-cbor-web-token-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ > > > > -- > COMMENT: > -- > >The claim values defined in this specification MUST NOT be prefixed >with any CBOR tag. For instance, while CBOR tag 1 (epoch-based date/ >time) could logically be prefixed to values of the "exp", "nbf", and >"iat" claims, this is unnecessary, since the representation of the >claim values is already specified by the claim definitions. Tagging >claim values would only take up extra space without adding >information. However, this does not prohibit future claim >definitions from requiring the use of CBOR tags for those specific >claims. > > Why do you need a MUST NOT here? This seems like not really an interop > requirement > > Mike> This requirement was added to simplify both producers and consumers > of these tokens, after a working group discussion. Not having to have code > to validate, parse and then throw away tags prefixing claims of known types > both makes representations smaller and requires less code. Since the tags > add no value for these claims, it seemed better to require that they be > omitted. > > > > Thanks. Seems reasonable. > > > > ] > > 4. Verify that the resulting COSE Header includes only parameters >and values whose syntax and semantics are both understood and >supported or that are specified as being ignored when not >understood. > > I'm surprised to find that this is not a generic 8152 processing rule. > Can you explain why this is necessary here? > > Mike> This intentionally parallels the same rule in JWT ( > https://tools.ietf.org/html/rfc7519#section-7.2, step 5). It's saying > that you have to validate that the parameters describing the parameters > describing the cryptographic operations performed. > > > > Sure. I don't think this is unreasonable, but why isn't a general rule for > COSE messages rather than just CWT? > > > > Mike> I’m sure that COSE has similar/overlapping requirements (that, or I > didn’t adequately review it at the time before it became an RFC ;-) ). As > the Brits, say, this rule is “belt and suspenders” on top of that – and > also reflects that CWT copies the syntax and semantics from JWT [RFC 7519] > wherever applicable. > > > > See you next week. > > > >-- Mike > > > > -Ekr > > > > > > > > > -- Mike > > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
On Wed, Mar 14, 2018 at 2:34 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > Hi Ekr. Thanks for the review comments. Responses are inline below, > prefixed by "Mike>"... > > -Original Message- > From: Eric Rescorla <e...@rtfm.com> > Sent: Wednesday, March 7, 2018 12:40 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; > ka...@mit.edu; ace@ietf.org > Subject: Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: > (with COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-ace-cbor-web-token-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ > > > > -- > COMMENT: > -- > >The claim values defined in this specification MUST NOT be prefixed >with any CBOR tag. For instance, while CBOR tag 1 (epoch-based date/ >time) could logically be prefixed to values of the "exp", "nbf", and >"iat" claims, this is unnecessary, since the representation of the >claim values is already specified by the claim definitions. Tagging >claim values would only take up extra space without adding >information. However, this does not prohibit future claim >definitions from requiring the use of CBOR tags for those specific >claims. > > Why do you need a MUST NOT here? This seems like not really an interop > requirement > > Mike> This requirement was added to simplify both producers and consumers > of these tokens, after a working group discussion. Not having to have code > to validate, parse and then throw away tags prefixing claims of known types > both makes representations smaller and requires less code. Since the tags > add no value for these claims, it seemed better to require that they be > omitted. > Thanks. Seems reasonable. ] > 4. Verify that the resulting COSE Header includes only parameters >and values whose syntax and semantics are both understood and >supported or that are specified as being ignored when not >understood. > > I'm surprised to find that this is not a generic 8152 processing rule. > Can you explain why this is necessary here? > > Mike> This intentionally parallels the same rule in JWT ( > https://tools.ietf.org/html/rfc7519#section-7.2, step 5). It's saying > that you have to validate that the parameters describing the parameters > describing the cryptographic operations performed. Sure. I don't think this is unreasonable, but why isn't a general rule for COSE messages rather than just CWT? -Ekr > > -- Mike > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
Eric Rescorla has entered the following ballot position for draft-ietf-ace-cbor-web-token-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ -- COMMENT: -- The claim values defined in this specification MUST NOT be prefixed with any CBOR tag. For instance, while CBOR tag 1 (epoch-based date/ time) could logically be prefixed to values of the "exp", "nbf", and "iat" claims, this is unnecessary, since the representation of the claim values is already specified by the claim definitions. Tagging claim values would only take up extra space without adding information. However, this does not prohibit future claim definitions from requiring the use of CBOR tags for those specific claims. Why do you need a MUST NOT here? This seems like not really an interop requirement 4. Verify that the resulting COSE Header includes only parameters and values whose syntax and semantics are both understood and supported or that are specified as being ignored when not understood. I'm surprised to find that this is not a generic 8152 processing rule. Can you explain why this is necessary here? ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
