Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Esko Dijk]

With "ignoring" tags I also mean that the decoder presents it to the 
application; where the application then does not do any _additional_ checks on 
tags (like e.g. their presence or absence).
Any use of, or checks on tags as needed for the application are of course to be 
done in the normal way.

In essence my comment is just to enable a way of adding of tags in the future 
onto today's-tagless-claims, without today's implementations rejecting these 
future-claims as being malformed/unexpected.  If most think that's already 
covered by the current text then I'm okay with it.

Esko

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Carsten Bormann
Sent: Monday, December 11, 2017 22:59
To: Esko Dijk <esko.d...@philips.com>
Cc: Samuel Erdtman <sam...@erdtman.se>; Mike Jones 
<michael.jo...@microsoft.com>; Benjamin Kaduk <ka...@mit.edu>; ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

On Dec 11, 2017, at 12:02, Esko Dijk <esko.d...@philips.com> wrote:
>
> given that a CBOR decoder would normally ignore tags

If you are talking about CBOR tags (I’ve lost the context of the current 
discussion):
A generic CBOR decoder would normally present those to the application.
Simply ignoring them would not be very helpful.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


The information contained in this email may be confidential and/or legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this email is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original email.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Carsten Bormann]

On Dec 11, 2017, at 12:02, Esko Dijk  wrote:
> 
> given that a CBOR decoder would normally ignore tags

If you are talking about CBOR tags (I’ve lost the context of the current 
discussion): 
A generic CBOR decoder would normally present those to the application.
Simply ignoring them would not be very helpful.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Jim Schaad]

Esko,

 

Whether a generic encode would automatically skip over tags is going to
depend on the data model presented to the user by the parser.  I have worked
with one where the tags are ignored by the data model unless the user
explicitly asks about them.  I have worked with another where the tags are
explicitly modeled in the result of the parser.   There is a node in the
resulting tree that is of node type tag with a value.

 

Consider the case of something that could be either a string or an url
encoded string.  In this case the only difference in the encoding is the tag
value.   In this case the tag is significant so should not be ignored.  

 

I agree with Mike that this additional requirement could be misleading.

 

Jim

 

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Esko Dijk
Sent: Monday, December 11, 2017 3:03 AM
To: Mike Jones <michael.jo...@microsoft.com>; Samuel Erdtman
<sam...@erdtman.se>
Cc: Benjamin Kaduk <ka...@mit.edu>; ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

 

Hello Mike,

 

My intention was to have "no extra code in recipients that verifies absence
of tags".  I did not intend to propose modification to the CBOR decoder (a
generic decoder would skip over i.e. ignore any tags already - which is the
right behavior in my view).

 

I don't see how an additional sentence in the spec "MUST ignore tags" can
possibly lead to extra code? A generic CBOR decoder will already skip over
any tags. And besides these tags are not present because the spec states
they must not be used. So there's nothing a receiver would have to do extra
or different.

The benefit then seemingly comes for free; and this benefit is the potential
usage of tags attached to existing claims, for future versions of the spec. 

 

But given that a CBOR decoder would normally ignore tags already, I'm also
fine with not changing the text if it is confusing for developers. They
might think they need to implement something while the requirement actually
asks them *not* to implement something. Most developers would not bother to
implement such extra checks anyhow.

 

thanks

Esko

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Friday, December 8, 2017 14:46
To: Esko Dijk <esko.d...@philips.com <mailto:esko.d...@philips.com> >;
Samuel Erdtman <sam...@erdtman.se <mailto:sam...@erdtman.se> >
Cc: Benjamin Kaduk <ka...@mit.edu <mailto:ka...@mit.edu> >; ace@ietf.org
<mailto:ace@ietf.org> 
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

 

Requiring extra code in recipients to ignore tags that already must not be
present would make them needlessly more complicated and hurt interop. It's
virtually certain that many implementations will not include this extra code
that should never be executed. We shouldn't put developers in the position
of deciding whether to add code for a case that already must not occur.

-- Mike

 

 

  _  

The information contained in this email may be confidential and/or legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this email is
strictly prohibited and may be unlawful. If you are not the intended
recipient, please contact the sender by return e-mail and destroy all copies
of the original email.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Esko Dijk]

Hello Mike,

My intention was to have "no extra code in recipients that verifies absence of 
tags".  I did not intend to propose modification to the CBOR decoder (a generic 
decoder would skip over i.e. ignore any tags already - which is the right 
behavior in my view).

I don't see how an additional sentence in the spec "MUST ignore tags" can 
possibly lead to extra code? A generic CBOR decoder will already skip over any 
tags. And besides these tags are not present because the spec states they must 
not be used. So there's nothing a receiver would have to do extra or different.
The benefit then seemingly comes for free; and this benefit is the potential 
usage of tags attached to existing claims, for future versions of the spec.

But given that a CBOR decoder would normally ignore tags already, I'm also fine 
with not changing the text if it is confusing for developers. They might think 
they need to implement something while the requirement actually asks them *not* 
to implement something. Most developers would not bother to implement such 
extra checks anyhow.

thanks
Esko

From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Friday, December 8, 2017 14:46
To: Esko Dijk <esko.d...@philips.com>; Samuel Erdtman <sam...@erdtman.se>
Cc: Benjamin Kaduk <ka...@mit.edu>; ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

Requiring extra code in recipients to ignore tags that already must not be 
present would make them needlessly more complicated and hurt interop. It's 
virtually certain that many implementations will not include this extra code 
that should never be executed. We shouldn't put developers in the position of 
deciding whether to add code for a case that already must not occur.
-- Mike



The information contained in this email may be confidential and/or legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this email is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original email.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Mike Jones]

Requiring extra code in recipients to ignore tags that already must not be 
present would make them needlessly more complicated and hurt interop. It's 
virtually certain that many implementations will not include this extra code 
that should never be executed. We shouldn't put developers in the position of 
deciding whether to add code for a case that already must not occur.

-- Mike

From: Ace <ace-boun...@ietf.org> on behalf of Samuel Erdtman <sam...@erdtman.se>
Sent: Friday, December 8, 2017 4:31:31 AM
To: Esko Dijk
Cc: Benjamin Kaduk; ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

thanks for persisting

See inline

On Wed, Dec 6, 2017 at 2:48 PM, Esko Dijk 
<esko.d...@philips.com<mailto:esko.d...@philips.com>> wrote:

Thanks Samuel,



I agree with your answers and proposed actions except for the below:



> I think the language in section 3 is enough to get robust implementations. 
> "all claims that are not understood by implementations MUST be ignored."



Ignoring a claim is very different from ignoring an unrecognize/unsuitable tag 
that prefixes a claim. The latter will in fact accept the claim while the 
former will reject the claim.

To get the desired robustness and future extendibility, and make tags useful 
for existing claims, an implementation must ignore the unrecognized tag – but 
not the claim. (Assuming any cases where the receiver should understand the 
claim but a future-version sender has added an additional future-version tag to 
it.)

What this can achieve is keep using ‘old’ version claims while augmenting these 
with ‘new version’ semantics by use of tags, in a future version of the 
specification.



Besides with current Section 3 & 5 language one claim parser #1 may still 
consider an “exp” claim as “understood” because it ignores any tags for it, 
while parser #2 may reject that “exp” claim because it sees a tag that is not 
1. While parser #3 may reject an “exp” claim even with a tag 1 because it 
considers it out of scope of the spec (which says sender MUST NOT use this tag 
hence any tag usage is not according to spec so not understood.).



In a way this issue is similar to the archetypical spec requirement of “sender 
MUST put 0s in this field and a receiver MUST ignore the value of this field”.  
Both are needed.

I have added created a PR with some text to make this more specific.
please have a look at https://github.com/erwah/ietf/pull/74




Best Regards

Esko



From: Samuel Erdtman [mailto:sam...@erdtman.se<mailto:sam...@erdtman.se>]
Sent: Wednesday, December 6, 2017 13:48
To: Esko Dijk <esko.d...@philips.com<mailto:esko.d...@philips.com>>
Cc: Benjamin Kaduk <ka...@mit.edu<mailto:ka...@mit.edu>>; 
ace@ietf.org<mailto:ace@ietf.org>

Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)



Thanks Esko for your review it is greatly appreciated.

see comments inline



On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk 
<esko.d...@philips.com<mailto:esko.d...@philips.com>> wrote:

Dear all,

Overall the document looks in good shape to go forward if the earlier mentioned 
issue of multiple values for "audience" (reported by Hannes) is addressed; and 
the below issue I see for Section 5. Other comments are minor.
(Btw sorry for being late responding to this WGLC.)

My review comments to specific sections:

Entire document:
Replace "binary string" by "byte string".  The latter is the name used in RFC 
7049.



Good point.

I have created a PR waiting for review by the co-authors



3.1.1 / 3.1.2 / 3.1.3
"except that the value is of type StringOrURI"
-> May be slightly confusing to readers, since JWT also has StringOrURI named 
type. So it seemingly says "don't use StringOrURI, but use StringOrURI."   This 
is most likely intended, as in "don't use JWT StringOrURI, but use our CWT 
StringOrURI". So also fine if we leave this formulation in, but it could still 
cause some confusion.



I see your point, but I don´t think it will be an issue. JWT is in JSON context 
and CWT is in CBOR context so whenever string is refereed to in CWT the reader 
should think CBOR string and vice verse for JWT.

If you don´t have a strong opinion here or a great suggestion for a new name I 
would like to keep it as it is.



3.1.4 / 3.1.5 / 3.1.6
"except that the value is of type NumericDate"
-> same comment as above.



Same as above.



5
Text states the sender MUST NOT use a tag, but future specs may introduce tags 
for claim values. Then it seems required to also include some text about how a 
receiver implementing the *current* version of CWT should handle tags for claim 
values, which may come from a sender implementing a future version of CWT.
E.g. add text "A receiver/decoder MUST ignore any Tags used for a claim value.&qu

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Esko Dijk]

Thanks Samuel,

I agree with your answers and proposed actions except for the below:

> I think the language in section 3 is enough to get robust implementations. 
> "all claims that are not understood by implementations MUST be ignored."

Ignoring a claim is very different from ignoring an unrecognize/unsuitable tag 
that prefixes a claim. The latter will in fact accept the claim while the 
former will reject the claim.
To get the desired robustness and future extendibility, and make tags useful 
for existing claims, an implementation must ignore the unrecognized tag – but 
not the claim. (Assuming any cases where the receiver should understand the 
claim but a future-version sender has added an additional future-version tag to 
it.)
What this can achieve is keep using ‘old’ version claims while augmenting these 
with ‘new version’ semantics by use of tags, in a future version of the 
specification.

Besides with current Section 3 & 5 language one claim parser #1 may still 
consider an “exp” claim as “understood” because it ignores any tags for it, 
while parser #2 may reject that “exp” claim because it sees a tag that is not 
1. While parser #3 may reject an “exp” claim even with a tag 1 because it 
considers it out of scope of the spec (which says sender MUST NOT use this tag 
hence any tag usage is not according to spec so not understood.).

In a way this issue is similar to the archetypical spec requirement of “sender 
MUST put 0s in this field and a receiver MUST ignore the value of this field”.  
Both are needed.

Best Regards
Esko

From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Wednesday, December 6, 2017 13:48
To: Esko Dijk <esko.d...@philips.com>
Cc: Benjamin Kaduk <ka...@mit.edu>; ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

Thanks Esko for your review it is greatly appreciated.

see comments inline

On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk 
<esko.d...@philips.com<mailto:esko.d...@philips.com>> wrote:
Dear all,

Overall the document looks in good shape to go forward if the earlier mentioned 
issue of multiple values for "audience" (reported by Hannes) is addressed; and 
the below issue I see for Section 5. Other comments are minor.
(Btw sorry for being late responding to this WGLC.)

My review comments to specific sections:

Entire document:
Replace "binary string" by "byte string".  The latter is the name used in RFC 
7049.

Good point.
I have created a PR waiting for review by the co-authors


3.1.1 / 3.1.2 / 3.1.3
"except that the value is of type StringOrURI"
-> May be slightly confusing to readers, since JWT also has StringOrURI named 
type. So it seemingly says "don't use StringOrURI, but use StringOrURI."   This 
is most likely intended, as in "don't use JWT StringOrURI, but use our CWT 
StringOrURI". So also fine if we leave this formulation in, but it could still 
cause some confusion.

I see your point, but I don´t think it will be an issue. JWT is in JSON context 
and CWT is in CBOR context so whenever string is refereed to in CWT the reader 
should think CBOR string and vice verse for JWT.
If you don´t have a strong opinion here or a great suggestion for a new name I 
would like to keep it as it is.


3.1.4 / 3.1.5 / 3.1.6
"except that the value is of type NumericDate"
-> same comment as above.

Same as above.


5
Text states the sender MUST NOT use a tag, but future specs may introduce tags 
for claim values. Then it seems required to also include some text about how a 
receiver implementing the *current* version of CWT should handle tags for claim 
values, which may come from a sender implementing a future version of CWT.
E.g. add text "A receiver/decoder MUST ignore any Tags used for a claim value."
That should help robustness and future extendibility. E.g. we don't want 
receivers of a CWT to go check if tags are present and reject the CWT if a Tag 
is found.

I think the language in section 3 is enough to get robust implementations. "all 
claims that are not understood by implementations MUST be ignored."


7.1
Step 5 & 6: text states "add the matching COSE CBOR tag" resp. "add the 
appropriate COSE CBOR tag"
-> could we clarify where this is added, e.g. say "prepend with the matching 
COSE CBOR tag"?

I think adding the tag in itself has this semantic. But I have created a PR 
with the change, so that my co-authors can consider it.


9.2.1
"Applications that use this media type: IoT applications sending security 
tokens over HTTP(S) and other transports"
-> can already mention CoAP/CoAPs here ?

It is not obvious that we should mention CoAP(S) here since the media type is 
for HTTP(S) and not CoAP(S) and it does state that "and other transports". For 
CoAP(S) we register the CoAP Content-Format that maps to this media type.

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Samuel Erdtman]

Thanks Esko for your review it is greatly appreciated.

see comments inline

On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk <esko.d...@philips.com> wrote:

> Dear all,
>
> Overall the document looks in good shape to go forward if the earlier
> mentioned issue of multiple values for "audience" (reported by Hannes) is
> addressed; and the below issue I see for Section 5. Other comments are
> minor.
> (Btw sorry for being late responding to this WGLC.)
>
> My review comments to specific sections:
>
> Entire document:
> Replace "binary string" by "byte string".  The latter is the name used in
> RFC 7049.
>

Good point.
I have created a PR waiting for review by the co-authors


>
> 3.1.1 / 3.1.2 / 3.1.3
> "except that the value is of type StringOrURI"
> -> May be slightly confusing to readers, since JWT also has StringOrURI
> named type. So it seemingly says "don't use StringOrURI, but use
> StringOrURI."   This is most likely intended, as in "don't use JWT
> StringOrURI, but use our CWT StringOrURI". So also fine if we leave this
> formulation in, but it could still cause some confusion.
>

I see your point, but I don´t think it will be an issue. JWT is in JSON
context and CWT is in CBOR context so whenever string is refereed to in CWT
the reader should think CBOR string and vice verse for JWT.
If you don´t have a strong opinion here or a great suggestion for a new
name I would like to keep it as it is.


>
> 3.1.4 / 3.1.5 / 3.1.6
> "except that the value is of type NumericDate"
> -> same comment as above.
>

Same as above.


> 5
> Text states the sender MUST NOT use a tag, but future specs may introduce
> tags for claim values. Then it seems required to also include some text
> about how a receiver implementing the *current* version of CWT should
> handle tags for claim values, which may come from a sender implementing a
> future version of CWT.
> E.g. add text "A receiver/decoder MUST ignore any Tags used for a claim
> value."
> That should help robustness and future extendibility. E.g. we don't want
> receivers of a CWT to go check if tags are present and reject the CWT if a
> Tag is found.
>

I think the language in section 3 is enough to get robust implementations.
"all claims that are not understood by implementations MUST be ignored."


>
> 7.1
> Step 5 & 6: text states "add the matching COSE CBOR tag" resp. "add the
> appropriate COSE CBOR tag"
> -> could we clarify where this is added, e.g. say "prepend with the
> matching COSE CBOR tag"?
>

I think adding the tag in itself has this semantic. But I have created a PR
with the change, so that my co-authors can consider it.


>
> 9.2.1
> "Applications that use this media type: IoT applications sending security
> tokens over HTTP(S) and other transports"
> -> can already mention CoAP/CoAPs here ?
>

It is not obvious that we should mention CoAP(S) here since the media type
is for HTTP(S) and not CoAP(S) and it does state that "and other
transports". For CoAP(S) we register the CoAP Content-Format that maps to
this media type.


>
> Best regards
> Esko Dijk
>
>
> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Benjamin Kaduk
> Sent: Thursday, November 23, 2017 01:31
> To: ace@ietf.org
> Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)
>
> Reminder: there is only one week left in this WGLC.
>
> -Ben
>
> On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote:
> > This message begins a working group last call for
> > draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC,
> > ending at 23:59 PST on Wednesday 29 November, 2017.
> >
> > The current (-09) version of the document is available at:
> > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 .
> >
> > Thanks,
> >
> > Ben and Jim
> >
> > ___
> > 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
>
> 
> The information contained in this email may be confidential and/or legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby
> notified that any use, forwarding, dissemination, or reproduction of this
> email is strictly prohibited and may be unlawful. If you are not the
> intended recipient, please contact the sender by return e-mail and destroy
> all copies of the original email.
>
> ___
> 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] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Esko Dijk]

Dear all,

Overall the document looks in good shape to go forward if the earlier mentioned 
issue of multiple values for "audience" (reported by Hannes) is addressed; and 
the below issue I see for Section 5. Other comments are minor.
(Btw sorry for being late responding to this WGLC.)

My review comments to specific sections:

Entire document:
Replace "binary string" by "byte string".  The latter is the name used in RFC 
7049.

3.1.1 / 3.1.2 / 3.1.3
"except that the value is of type StringOrURI"
-> May be slightly confusing to readers, since JWT also has StringOrURI named 
type. So it seemingly says "don't use StringOrURI, but use StringOrURI."   This 
is most likely intended, as in "don't use JWT StringOrURI, but use our CWT 
StringOrURI". So also fine if we leave this formulation in, but it could still 
cause some confusion.

3.1.4 / 3.1.5 / 3.1.6
"except that the value is of type NumericDate"
-> same comment as above.

5
Text states the sender MUST NOT use a tag, but future specs may introduce tags 
for claim values. Then it seems required to also include some text about how a 
receiver implementing the *current* version of CWT should handle tags for claim 
values, which may come from a sender implementing a future version of CWT.
E.g. add text "A receiver/decoder MUST ignore any Tags used for a claim value."
That should help robustness and future extendibility. E.g. we don't want 
receivers of a CWT to go check if tags are present and reject the CWT if a Tag 
is found.

7.1
Step 5 & 6: text states "add the matching COSE CBOR tag" resp. "add the 
appropriate COSE CBOR tag"
-> could we clarify where this is added, e.g. say "prepend with the matching 
COSE CBOR tag"?

9.2.1
"Applications that use this media type: IoT applications sending security 
tokens over HTTP(S) and other transports"
-> can already mention CoAP/CoAPs here ?

Best regards
Esko Dijk


-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Benjamin Kaduk
Sent: Thursday, November 23, 2017 01:31
To: ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

Reminder: there is only one week left in this WGLC.

-Ben

On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote:
> This message begins a working group last call for
> draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC,
> ending at 23:59 PST on Wednesday 29 November, 2017.
>
> The current (-09) version of the document is available at:
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 .
>
> Thanks,
>
> Ben and Jim
>
> ___
> 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


The information contained in this email may be confidential and/or legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this email is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original email.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Samuel Erdtman]

Thanks for the review Ludwig, it is really appreciated.

see inline

On Thu, Nov 23, 2017 at 10:25 AM, Ludwig Seitz  wrote:

> Hi ACE,
>
> I have only some nits on the CWT draft (see below).
>
>
> /Ludwig
>
> 
>
> I'm not sure what the RFC editors prefer as affiliation
> (I've seen both):
>
> --
> E. Wahlstroem
>
> --  OR
> E. Wahlstroem
> (no affiliation)
> --
>

I would prefere the empty space. The xml doc does not contain any text and
when submitting to http://xml2rfc.tools.ietf.org/ I get the empty line.

If co-authors agree I think we need to do something when submitting the new
draft.


>
>
> ===
> 2. Terminology
>
> In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT
> RECOMMENDED is used in the draft. What is the recommended procedure here?
> It feels like we could remove the other ones.
>
> ===
>

I agree with Carsten that the full template should be used. and I agree
with Benjamin that we should use the latest version.
I have created a PR that is waiting for review by co-authors.


>
> "CWT Claims Set
>
>   The CBOR map that ..."
>
> Why is a map called a set here? I know what is meant, but it sound really
> weird.
>

I think the is the right way to phrase it.


>
> ===
>
> Sections 3.1.*
>
> The links to sections in JWT point to sections in this draft instead
> (at least in the html-ised version of the draft).
>
> See:
> https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18
>
> for hints on how to fix this.
>

I have created a PR that is waiting for review by co-authors.


> ===
>
> Figure 1:  Perhaps indicate the CBOR major type number together with the
> "Value type" text.
>

I agree with Carsten, we have had this discussion before.

I have created a PR changing from ascii art to table (waiting for review by
co-authors)


>
> ===
>
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE SICS
> Phone +46(0)70-349 92 51
>
>
> ___
> 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] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Benjamin Kaduk]

On Thu, Nov 23, 2017 at 11:55:46AM +0100, Carsten Bormann wrote:
> Hi Ludwig,
> 
> > I'm not sure what the RFC editors prefer as affiliation
> > (I've seen both):
> > 
> > --
> > E. Wahlstroem
> > 
> > --  OR
> > E. Wahlstroem
> > (no affiliation)
> > —
> 
> I don’t know what the RFC editor prefers her, but I find “no affiliation” 
> jarring — leaving the space open is much better.

I also sometimes see "Unaffliated".

> > ===
> > 2. Terminology
> > 
> > In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT 
> > RECOMMENDED is used in the draft. What is the recommended procedure here? 
> > It feels like we could remove the other ones.
> 
> It is usual to include the whole boilerplate (obviously the corrected one, 
> with NOT RECOMMENDED included, in this case).

Right, at this point people should be citing BCP 14/RFC 8174.

-Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Carsten Bormann]

Hi Ludwig,

> I'm not sure what the RFC editors prefer as affiliation
> (I've seen both):
> 
> --
> E. Wahlstroem
> 
> --  OR
> E. Wahlstroem
> (no affiliation)
> —

I don’t know what the RFC editor prefers her, but I find “no affiliation” 
jarring — leaving the space open is much better.

> ===
> 2. Terminology
> 
> In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT 
> RECOMMENDED is used in the draft. What is the recommended procedure here? It 
> feels like we could remove the other ones.

It is usual to include the whole boilerplate (obviously the corrected one, with 
NOT RECOMMENDED included, in this case).

> ===
> 
> "CWT Claims Set
> 
>  The CBOR map that ..."
> 
> Why is a map called a set here? I know what is meant, but it sound really 
> weird.

Because a claim is a pair of map key and map value, so the whole thing is 
indeed a set of claims (with the additional restriction that a key can only be 
used once; hence we need array-valued map values).

(The term “claim" is misleading and wrong here, but that is inherited from JWT.)

> ===
> 
> Sections 3.1.*
> 
> The links to sections in JWT point to sections in this draft instead
> (at least in the html-ised version of the draft).
> 
> See:
> https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18
> 
> for hints on how to fix this.

Somewhat temporary, but a useful thing to change.

> 
> ===
> 
> Figure 1:  Perhaps indicate the CBOR major type number together with the
> "Value type" text.

Or perhaps don’t?  The major type number is something that is internal to the 
serialization; standards using RFC 7049 should not try to repeat internals of 
RFC 7049 all over the place.
I’d prefer to use the data model level names as it is specified now.

My editorial comment on this is that this should be a table, not ASCII art.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Benjamin Kaduk]

Reminder: there is only one week left in this WGLC.

-Ben

On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote:
> This message begins a working group last call for
> draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC,
> ending at 23:59 PST on Wednesday 29 November, 2017.
> 
> The current (-09) version of the document is available at:
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 .
> 
> Thanks,
> 
> Ben and Jim
> 
> ___
> 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] WGLC on draft-ietf-ace-cbor-web-token

[Benjamin Kaduk]

On Wed, Nov 01, 2017 at 06:33:59PM +0100, Carsten Bormann wrote:
> Just wondering:
> 
> Are you aware that this is a second WGLC?  You didn’t mention that.

I was aware, sorry for not mentioning it.  (The first WGLC was on the -04.)

> (And do we really need four weeks for a second WGLC?  Even factoring in the 
> IETF week?)

It spans a US holiday and an IETF meeting, so the extra time seemed warranted
given how many other distractions people may have.

-Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Carsten Bormann]

Just wondering:

Are you aware that this is a second WGLC?  You didn’t mention that.

(And do we really need four weeks for a second WGLC?  Even factoring in the 
IETF week?)

Grüße, Carsten

> On Nov 1, 2017, at 18:24, Benjamin Kaduk  wrote:
> 
> This message begins a working group last call for
> draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC,
> ending at 23:59 PST on Wednesday 29 November, 2017.
> 
> The current (-09) version of the document is available at:
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 .
> 
> Thanks,
> 
> Ben and Jim
> 
> ___
> 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

[Ace] WGLC on draft-ietf-ace-cbor-web-token

[Benjamin Kaduk]

This message begins a working group last call for
draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC,
ending at 23:59 PST on Wednesday 29 November, 2017.

The current (-09) version of the document is available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 .

Thanks,

Ben and Jim

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

I don't know that I agree with several of the statements below.  I have 
problems with the view that just doing a profile is sufficient for a very 
simple reason.  What if I am presented with a CWT that is from a different 
profile?

In your example below, if an issuer was creating a "nbf" claim in an ID Token 
profile then it is not conforming to the profile and I would not have a real 
problem with the fact that the token could not be used by an entity that did 
not understand the profile.  What happens to the space when the ID Token 
profile gets updated in five years and the "nbf" claim becomes a mandatory 
field to be included and understood?  All of a sudden there is going to be a 
large number of entities in the system that are using the token without 
enforcing all of the constraints that are considered to be of importance to the 
issuer.  This is a security problem.

There is nothing that is being placed in a CWT to identify the profile that is 
being used.  This means that if a token issuer is creating tokens that match 
different profiles and it does not use different keys for each of those 
profiles, then a token issued under one profile and with a specific set of 
assumptions about what is in the token and what it can be used for, can be 
provided to an application that is expecting the second profile and it might 
allow operations which would otherwise not be permitted.  This is a security 
issue.

Identifying the profile in the token is one possible answer, but it is one with 
lots of other problems.  Who defines and identifies the profiles?  How are they 
uniquely identified? How do you do the configuration on a small device to deal 
with company identified profiles? 

 A more generic way of allowing for identification of what is and what is not 
so important might be one way to get around some of these issue

Jim


-Original Message-
From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Tuesday, May 16, 2017 3:58 PM
To: Carsten Bormann <c...@tzi.org>
Cc: Jim Schaad <i...@augustcellars.com>; Samuel Erdtman <sam...@erdtman.se>; 
ace <Ace@ietf.org>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Profiles of CWTs will vary in which claims must be present, which are optional, 
and what the format of those claims are, when applicable.  This is just like 
JWT, where application profiles provide that information.  To make this 
concrete, OpenID Connect defines a profile of a JWT called an ID Token at 
http://openid.net/specs/openid-connect-core-1_0.html#IDToken.  Note that is 
says which claims are REQUIRED and OPTIONAL.  The profile also defines 
additional ID Token validation rules at 
http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation, which 
go beyond those in the JWT spec itself.  This is how application profiles work.

As a hypothetical example, it would be unhelpful for the ID Token profile if 
the underlying JWT spec had said that the "nbf" (not before) claim must be 
understood by all implementations, when this profile doesn't use it or contain 
validation rules for it.  Even if a producer included a "nbf" claim, the 
consumer for this profile can safely ignore it, since no validation rules 
accompany it for ID Tokens.  The same is true of all other JWT-defined claims.  
And the same needs to be true of the parallel CWT claims as well.  For 
instance, we shouldn't force all CWT applications to understand and process 
"nbf" any more than we force all JWT applications to.

There's nothing insecure about this but there is something efficient it that we 
must preserve - particularly for constrained implementations.

-- Mike

-Original Message-
From: Carsten Bormann [mailto:c...@tzi.org] 
Sent: Tuesday, May 16, 2017 3:26 PM
To: Mike Jones <michael.jo...@microsoft.com>
Cc: Jim Schaad <i...@augustcellars.com>; Samuel Erdtman <sam...@erdtman.se>; 
ace <Ace@ietf.org>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

On May 16, 2017, at 00:16, Mike Jones <michael.jo...@microsoft.com> wrote:
> 
> I disagree with the suggestion (tracked in 
> https://github.com/erwah/ietf/issues/37) about claims that must be 
> understood.  We shouldn’t force implementations to understand claims not used 
> by their application.  See my comment in the issue.

Not sure what is the “implementation” and what is the “application” here.

If an application puts in a “must understand” claim key, I’m not sure who is 
forcing what here.

If we don’t have “must understand” claim keys, then there is no way for an 
application to signal that necessity.
Security issues with recipient applications that don’t correctly interpret the 
CWT they received, follow.  Not good.

Grüße, Carsten


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

As things currently stand, I do not know that there is any way for an issuer to 
say that you must understand this claim to use this.  This is partly profile, 
but not entirely.

Jim


-Original Message-
From: Carsten Bormann [mailto:c...@tzi.org] 
Sent: Tuesday, May 16, 2017 3:26 PM
To: Mike Jones <michael.jo...@microsoft.com>
Cc: Jim Schaad <i...@augustcellars.com>; Samuel Erdtman <sam...@erdtman.se>; 
ace <Ace@ietf.org>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

On May 16, 2017, at 00:16, Mike Jones <michael.jo...@microsoft.com> wrote:
> 
> I disagree with the suggestion (tracked in 
> https://github.com/erwah/ietf/issues/37) about claims that must be 
> understood.  We shouldn’t force implementations to understand claims not used 
> by their application.  See my comment in the issue.

Not sure what is the “implementation” and what is the “application” here.

If an application puts in a “must understand” claim key, I’m not sure who is 
forcing what here.

If we don’t have “must understand” claim keys, then there is no way for an 
application to signal that necessity.
Security issues with recipient applications that don’t correctly interpret the 
CWT they received, follow.  Not good.

Grüße, Carsten


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Carsten Bormann]

On May 16, 2017, at 00:16, Mike Jones  wrote:
> 
> I disagree with the suggestion (tracked in 
> https://github.com/erwah/ietf/issues/37) about claims that must be 
> understood.  We shouldn’t force implementations to understand claims not used 
> by their application.  See my comment in the issue.

Not sure what is the “implementation” and what is the “application” here.

If an application puts in a “must understand” claim key, I’m not sure who is 
forcing what here.

If we don’t have “must understand” claim keys, then there is no way for an 
application to signal that necessity.
Security issues with recipient applications that don’t correctly interpret the 
CWT they received, follow.  Not good.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

Actually, I think both of those were Carsten not me

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Monday, May 15, 2017 3:17 PM
To: Jim Schaad <i...@augustcellars.com>; 'Samuel Erdtman' <sam...@erdtman.se>
Cc: 'ace' <Ace@ietf.org>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

I’ve gone through all the review feedback and agree with most of it.  There’s 
only two of the comments that I have issues with.

 

I disagree with the suggestion (tracked in 
https://github.com/erwah/ietf/issues/37) about claims that must be understood.  
We shouldn’t force implementations to understand claims not used by their 
application.  See my comment in the issue.

 

I agree with the suggestion (tracked in 
https://github.com/erwah/ietf/issues/38) that we allow string-valued labels, 
but disagree that they should be restricted to non-production use.  Rather, per 
my comment in https://github.com/erwah/ietf/issues/40, I think we should use 
the same rules for allocating labels as COSE did.  That approach has already 
been widely reviewed and I believe is perfectly viable.  Note that this will 
also address the comment about the 1-65536 label range.

 

Thanks for your detailed review, as always, Jim.

 

-- Mike

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Monday, May 15, 2017 2:44 PM
To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >; 
'Samuel Erdtman' <sam...@erdtman.se <mailto:sam...@erdtman.se> >
Cc: 'ace' <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

Thanks for confirming this, Jim.  Since that’s the case, I’m fine with us going 
with requiring tags for the inner nested CWTs and dropping the use of the CWT 
content-type for this purpose.

 

-- Mike

 

From: Jim Schaad [mailto:i...@augustcellars.com] 
Sent: Monday, May 15, 2017 2:31 PM
To: Mike Jones <michael.jo...@microsoft.com 
<mailto:michael.jo...@microsoft.com> >; 'Samuel Erdtman' <sam...@erdtman.se 
<mailto:sam...@erdtman.se> >
Cc: 'ace' <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

It is correct that the tag can be added and subtracted at will w/o changing 
anything.

 

 

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Monday, May 15, 2017 2:17 PM
To: Samuel Erdtman <sam...@erdtman.se <mailto:sam...@erdtman.se> >; Jim Schaad 
<i...@augustcellars.com <mailto:i...@augustcellars.com> >
Cc: ace <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

I agree that for nested CWTs, it’s OK to mandate that the appropriate tags be 
prefixed to the inner CWT, if that’s the mechanism we decide to use to encode 
and detect nested JWTs.  That would then raise the question though, of whether 
we also would continue to mandate the use of the CWT content-type or whether we 
would drop this.  I think it’s better that we specify one mechanism for 
detecting nested CWTs, rather than having two.

 

Before we decide this, I’d like to confirm an assumption about COSE operations 
and COSE CBOR tags.  I believe that the COSE crypto operations *do not* cover 
the CBOR COSE tag, such as the COSE_Sign tag for signed objects.  If this is 
the case, it means that a COSE object without tags can have the appropriate tag 
prefixed to it without changing the crypto (and that similarly, a CWT tag could 
also be added without changing the crypto).  Is this correct?  If so, then 
using CBOR tags would be fine for the inner CWT in a nested CWT, since you 
could create the inner CWT without any tags and then later decide to put it in 
a nested CWT without re-signing, etc.  If this is the case, I’d be OK with 
always prefixing the inner CWT in a nested CWT with CWT and COSE CBOR tags.  
Whereas if adding the tags requires redoing the crypto, I’d rather stay with 
the current approach.

 

-- Mike

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Monday, May 15, 2017 2:23 AM
To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >; Mike 
Jones <michael.jo...@microsoft.com <mailto:michael.jo...@microsoft.com> >
Cc: ace <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

Thanks for clarifications Jim, see my comments inline.

Mike, there is a question for you inlined too.

 

On Sun, May 14, 2017 at 10:12 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

 

 

From: Samuel Erdtman [mailto:sam...@erdtman.se <mailto:sam...@erdtman.se> ] 
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad 

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Mike Jones]

I’ve gone through all the review feedback and agree with most of it.  There’s 
only two of the comments that I have issues with.

I disagree with the suggestion (tracked in 
https://github.com/erwah/ietf/issues/37) about claims that must be understood.  
We shouldn’t force implementations to understand claims not used by their 
application.  See my comment in the issue.

I agree with the suggestion (tracked in 
https://github.com/erwah/ietf/issues/38) that we allow string-valued labels, 
but disagree that they should be restricted to non-production use.  Rather, per 
my comment in https://github.com/erwah/ietf/issues/40, I think we should use 
the same rules for allocating labels as COSE did.  That approach has already 
been widely reviewed and I believe is perfectly viable.  Note that this will 
also address the comment about the 1-65536 label range.

Thanks for your detailed review, as always, Jim.

-- Mike

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Monday, May 15, 2017 2:44 PM
To: Jim Schaad <i...@augustcellars.com>; 'Samuel Erdtman' <sam...@erdtman.se>
Cc: 'ace' <Ace@ietf.org>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Thanks for confirming this, Jim.  Since that’s the case, I’m fine with us going 
with requiring tags for the inner nested CWTs and dropping the use of the CWT 
content-type for this purpose.

-- Mike

From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: Monday, May 15, 2017 2:31 PM
To: Mike Jones 
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>; 'Samuel 
Erdtman' <sam...@erdtman.se<mailto:sam...@erdtman.se>>
Cc: 'ace' <Ace@ietf.org<mailto:Ace@ietf.org>>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

It is correct that the tag can be added and subtracted at will w/o changing 
anything.



From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Monday, May 15, 2017 2:17 PM
To: Samuel Erdtman <sam...@erdtman.se<mailto:sam...@erdtman.se>>; Jim Schaad 
<i...@augustcellars.com<mailto:i...@augustcellars.com>>
Cc: ace <Ace@ietf.org<mailto:Ace@ietf.org>>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

I agree that for nested CWTs, it’s OK to mandate that the appropriate tags be 
prefixed to the inner CWT, if that’s the mechanism we decide to use to encode 
and detect nested JWTs.  That would then raise the question though, of whether 
we also would continue to mandate the use of the CWT content-type or whether we 
would drop this.  I think it’s better that we specify one mechanism for 
detecting nested CWTs, rather than having two.

Before we decide this, I’d like to confirm an assumption about COSE operations 
and COSE CBOR tags.  I believe that the COSE crypto operations *do not* cover 
the CBOR COSE tag, such as the COSE_Sign tag for signed objects.  If this is 
the case, it means that a COSE object without tags can have the appropriate tag 
prefixed to it without changing the crypto (and that similarly, a CWT tag could 
also be added without changing the crypto).  Is this correct?  If so, then 
using CBOR tags would be fine for the inner CWT in a nested CWT, since you 
could create the inner CWT without any tags and then later decide to put it in 
a nested CWT without re-signing, etc.  If this is the case, I’d be OK with 
always prefixing the inner CWT in a nested CWT with CWT and COSE CBOR tags.  
Whereas if adding the tags requires redoing the crypto, I’d rather stay with 
the current approach.

-- Mike

From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Monday, May 15, 2017 2:23 AM
To: Jim Schaad <i...@augustcellars.com<mailto:i...@augustcellars.com>>; Mike 
Jones <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>
Cc: ace <Ace@ietf.org<mailto:Ace@ietf.org>>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Thanks for clarifications Jim, see my comments inline.
Mike, there is a question for you inlined too.

On Sun, May 14, 2017 at 10:12 PM, Jim Schaad 
<i...@augustcellars.com<mailto:i...@augustcellars.com>> wrote:


From: Samuel Erdtman [mailto:sam...@erdtman.se<mailto:sam...@erdtman.se>]
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad <i...@augustcellars.com<mailto:i...@augustcellars.com>>
Cc: ace <Ace@ietf.org<mailto:Ace@ietf.org>>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Hi Jim,
Thanks for your review and comments, see some initial replies inline.

On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad 
<i...@augustcellars.com<mailto:i...@augustcellars.com>> wrote:
Not ready to ship.


* I find the text for NumericDate confusing and would suggest this is a
cleaner wording.

The "NumericDate"

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Mike Jones]

Thanks for confirming this, Jim.  Since that’s the case, I’m fine with us going 
with requiring tags for the inner nested CWTs and dropping the use of the CWT 
content-type for this purpose.

-- Mike

From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: Monday, May 15, 2017 2:31 PM
To: Mike Jones <michael.jo...@microsoft.com>; 'Samuel Erdtman' 
<sam...@erdtman.se>
Cc: 'ace' <Ace@ietf.org>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

It is correct that the tag can be added and subtracted at will w/o changing 
anything.



From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Monday, May 15, 2017 2:17 PM
To: Samuel Erdtman <sam...@erdtman.se<mailto:sam...@erdtman.se>>; Jim Schaad 
<i...@augustcellars.com<mailto:i...@augustcellars.com>>
Cc: ace <Ace@ietf.org<mailto:Ace@ietf.org>>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

I agree that for nested CWTs, it’s OK to mandate that the appropriate tags be 
prefixed to the inner CWT, if that’s the mechanism we decide to use to encode 
and detect nested JWTs.  That would then raise the question though, of whether 
we also would continue to mandate the use of the CWT content-type or whether we 
would drop this.  I think it’s better that we specify one mechanism for 
detecting nested CWTs, rather than having two.

Before we decide this, I’d like to confirm an assumption about COSE operations 
and COSE CBOR tags.  I believe that the COSE crypto operations *do not* cover 
the CBOR COSE tag, such as the COSE_Sign tag for signed objects.  If this is 
the case, it means that a COSE object without tags can have the appropriate tag 
prefixed to it without changing the crypto (and that similarly, a CWT tag could 
also be added without changing the crypto).  Is this correct?  If so, then 
using CBOR tags would be fine for the inner CWT in a nested CWT, since you 
could create the inner CWT without any tags and then later decide to put it in 
a nested CWT without re-signing, etc.  If this is the case, I’d be OK with 
always prefixing the inner CWT in a nested CWT with CWT and COSE CBOR tags.  
Whereas if adding the tags requires redoing the crypto, I’d rather stay with 
the current approach.

-- Mike

From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Monday, May 15, 2017 2:23 AM
To: Jim Schaad <i...@augustcellars.com<mailto:i...@augustcellars.com>>; Mike 
Jones <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>
Cc: ace <Ace@ietf.org<mailto:Ace@ietf.org>>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Thanks for clarifications Jim, see my comments inline.
Mike, there is a question for you inlined too.

On Sun, May 14, 2017 at 10:12 PM, Jim Schaad 
<i...@augustcellars.com<mailto:i...@augustcellars.com>> wrote:


From: Samuel Erdtman [mailto:sam...@erdtman.se<mailto:sam...@erdtman.se>]
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad <i...@augustcellars.com<mailto:i...@augustcellars.com>>
Cc: ace <Ace@ietf.org<mailto:Ace@ietf.org>>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Hi Jim,
Thanks for your review and comments, see some initial replies inline.

On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad 
<i...@augustcellars.com<mailto:i...@augustcellars.com>> wrote:
Not ready to ship.


* I find the text for NumericDate confusing and would suggest this is a
cleaner wording.

The "NumericDate" term has the same meaning, syntax and
Processing rules as the "NumericDate" term defined in Section 2 of
JWT [RFC7519], except that the CBOR numeric representation
(Section 2.4.1 of [RC7049]) is used.  The encoding is modified so that
the leading tag (6.1 or 0xC1) MUST be omitted.



Could make sense, I created an issue in the issue tracker to look at this.


* What is a "CWT NumericDate" ?  Why is this not just a "NumericDate"?  You
should be consistent on how you are using this and the "StringOrURI" type
identifier.  Either use the CWT prefix or don't.

Makes sense to me, created an issue in the issue tracker to address this.


* s/except that a CWT StringOrURI/except that for a CWT, StringOrURI/

 Makes sense to me, created an issue in the issue tracker to address this.

* The algorithm for doing nesting detection is a gross abuse of the content
type parameter and can be far more easily done based on the already present
tagging of the COSE object.

Could you please explain a bit more, we are using the COSE tags but have made
them optional if the application for example only uses one thyme then it would
always know what to do and would not need to parse the tag saving a byte.

[JLS] The concept is pretty easy to explain.

If you are in a situation where the full description of the CWT – including

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

It is correct that the tag can be added and subtracted at will w/o changing 
anything.

 

 

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Monday, May 15, 2017 2:17 PM
To: Samuel Erdtman <sam...@erdtman.se>; Jim Schaad <i...@augustcellars.com>
Cc: ace <Ace@ietf.org>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

I agree that for nested CWTs, it’s OK to mandate that the appropriate tags be 
prefixed to the inner CWT, if that’s the mechanism we decide to use to encode 
and detect nested JWTs.  That would then raise the question though, of whether 
we also would continue to mandate the use of the CWT content-type or whether we 
would drop this.  I think it’s better that we specify one mechanism for 
detecting nested CWTs, rather than having two.

 

Before we decide this, I’d like to confirm an assumption about COSE operations 
and COSE CBOR tags.  I believe that the COSE crypto operations *do not* cover 
the CBOR COSE tag, such as the COSE_Sign tag for signed objects.  If this is 
the case, it means that a COSE object without tags can have the appropriate tag 
prefixed to it without changing the crypto (and that similarly, a CWT tag could 
also be added without changing the crypto).  Is this correct?  If so, then 
using CBOR tags would be fine for the inner CWT in a nested CWT, since you 
could create the inner CWT without any tags and then later decide to put it in 
a nested CWT without re-signing, etc.  If this is the case, I’d be OK with 
always prefixing the inner CWT in a nested CWT with CWT and COSE CBOR tags.  
Whereas if adding the tags requires redoing the crypto, I’d rather stay with 
the current approach.

 

-- Mike

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Monday, May 15, 2017 2:23 AM
To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >; Mike 
Jones <michael.jo...@microsoft.com <mailto:michael.jo...@microsoft.com> >
Cc: ace <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

Thanks for clarifications Jim, see my comments inline.

Mike, there is a question for you inlined too.

 

On Sun, May 14, 2017 at 10:12 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

 

 

From: Samuel Erdtman [mailto:sam...@erdtman.se <mailto:sam...@erdtman.se> ] 
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >
Cc: ace <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

Hi Jim,

Thanks for your review and comments, see some initial replies inline.

 

On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

Not ready to ship.


* I find the text for NumericDate confusing and would suggest this is a
cleaner wording.

The "NumericDate" term has the same meaning, syntax and
Processing rules as the "NumericDate" term defined in Section 2 of
JWT [RFC7519], except that the CBOR numeric representation
(Section 2.4.1 of [RC7049]) is used.  The encoding is modified so that
the leading tag (6.1 or 0xC1) MUST be omitted.



 

Could make sense, I created an issue in the issue tracker to look at this.

 


* What is a "CWT NumericDate" ?  Why is this not just a "NumericDate"?  You
should be consistent on how you are using this and the "StringOrURI" type
identifier.  Either use the CWT prefix or don't.


Makes sense to me, created an issue in the issue tracker to address this.
 


* s/except that a CWT StringOrURI/except that for a CWT, StringOrURI/


 Makes sense to me, created an issue in the issue tracker to address this.


* The algorithm for doing nesting detection is a gross abuse of the content
type parameter and can be far more easily done based on the already present
tagging of the COSE object.

 

Could you please explain a bit more, we are using the COSE tags but have made 
them optional if the application for example only uses one thyme then it would 
always know what to do and would not need to parse the tag saving a byte.

 

[JLS] The concept is pretty easy to explain.

 

If you are in a situation where the full description of the CWT – including 
nesting layering – is known from a profile, then there would be no need to have 
any COSE tags present on any layer of the CWT message.  I would however highly 
discourage using this situation for anything but a single layer CWT such as one 
that is based on the COSE_Encrypt0 message without any inner layering.  Doing 
otherwise is going to mean that libraries would be unable to automatically 
unwrap all of the layers on their own, but would need guidance on each layer as 
it was processed.

 

In the current document in step 5 of section 7.2,

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Mike Jones]

I agree that for nested CWTs, it’s OK to mandate that the appropriate tags be 
prefixed to the inner CWT, if that’s the mechanism we decide to use to encode 
and detect nested JWTs.  That would then raise the question though, of whether 
we also would continue to mandate the use of the CWT content-type or whether we 
would drop this.  I think it’s better that we specify one mechanism for 
detecting nested CWTs, rather than having two.

Before we decide this, I’d like to confirm an assumption about COSE operations 
and COSE CBOR tags.  I believe that the COSE crypto operations *do not* cover 
the CBOR COSE tag, such as the COSE_Sign tag for signed objects.  If this is 
the case, it means that a COSE object without tags can have the appropriate tag 
prefixed to it without changing the crypto (and that similarly, a CWT tag could 
also be added without changing the crypto).  Is this correct?  If so, then 
using CBOR tags would be fine for the inner CWT in a nested CWT, since you 
could create the inner CWT without any tags and then later decide to put it in 
a nested CWT without re-signing, etc.  If this is the case, I’d be OK with 
always prefixing the inner CWT in a nested CWT with CWT and COSE CBOR tags.  
Whereas if adding the tags requires redoing the crypto, I’d rather stay with 
the current approach.

-- Mike

From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Monday, May 15, 2017 2:23 AM
To: Jim Schaad <i...@augustcellars.com>; Mike Jones 
<michael.jo...@microsoft.com>
Cc: ace <Ace@ietf.org>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Thanks for clarifications Jim, see my comments inline.
Mike, there is a question for you inlined too.

On Sun, May 14, 2017 at 10:12 PM, Jim Schaad 
<i...@augustcellars.com<mailto:i...@augustcellars.com>> wrote:


From: Samuel Erdtman [mailto:sam...@erdtman.se<mailto:sam...@erdtman.se>]
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad <i...@augustcellars.com<mailto:i...@augustcellars.com>>
Cc: ace <Ace@ietf.org<mailto:Ace@ietf.org>>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Hi Jim,
Thanks for your review and comments, see some initial replies inline.

On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad 
<i...@augustcellars.com<mailto:i...@augustcellars.com>> wrote:
Not ready to ship.


* I find the text for NumericDate confusing and would suggest this is a
cleaner wording.

The "NumericDate" term has the same meaning, syntax and
Processing rules as the "NumericDate" term defined in Section 2 of
JWT [RFC7519], except that the CBOR numeric representation
(Section 2.4.1 of [RC7049]) is used.  The encoding is modified so that
the leading tag (6.1 or 0xC1) MUST be omitted.



Could make sense, I created an issue in the issue tracker to look at this.


* What is a "CWT NumericDate" ?  Why is this not just a "NumericDate"?  You
should be consistent on how you are using this and the "StringOrURI" type
identifier.  Either use the CWT prefix or don't.

Makes sense to me, created an issue in the issue tracker to address this.


* s/except that a CWT StringOrURI/except that for a CWT, StringOrURI/

 Makes sense to me, created an issue in the issue tracker to address this.

* The algorithm for doing nesting detection is a gross abuse of the content
type parameter and can be far more easily done based on the already present
tagging of the COSE object.

Could you please explain a bit more, we are using the COSE tags but have made
them optional if the application for example only uses one thyme then it would
always know what to do and would not need to parse the tag saving a byte.

[JLS] The concept is pretty easy to explain.

If you are in a situation where the full description of the CWT – including 
nesting layering – is known from a profile, then there would be no need to have 
any COSE tags present on any layer of the CWT message.  I would however highly 
discourage using this situation for anything but a single layer CWT such as one 
that is based on the COSE_Encrypt0 message without any inner layering.  Doing 
otherwise is going to mean that libraries would be unable to automatically 
unwrap all of the layers on their own, but would need guidance on each layer as 
it was processed.

In the current document in step 5 of section 7.2, there is an assumption that a 
COSE tag is going to exist in order to distinguish between the different types 
of COSE messages – I would not that these tags are not explicitly called for in 
section 7.1 – so the algorithm that I am going to suggest means that they are 
supposed to be present not implicit in any event.

In section 7.2 in step 7 the algorithm becomes:
If the payload starts with one the of COSE identification tags, then the 
message is recursive – go to step 1, wash rinse and repeat.

I think I see your point. In the case of nest

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

 

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad <i...@augustcellars.com>
Cc: ace <Ace@ietf.org>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

Hi Jim,

Thanks for your review and comments, see some initial replies inline.

 

On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

Not ready to ship.


* I find the text for NumericDate confusing and would suggest this is a
cleaner wording.

The "NumericDate" term has the same meaning, syntax and
Processing rules as the "NumericDate" term defined in Section 2 of
JWT [RFC7519], except that the CBOR numeric representation
(Section 2.4.1 of [RC7049]) is used.  The encoding is modified so that
the leading tag (6.1 or 0xC1) MUST be omitted.



 

Could make sense, I created an issue in the issue tracker to look at this.

 


* What is a "CWT NumericDate" ?  Why is this not just a "NumericDate"?  You
should be consistent on how you are using this and the "StringOrURI" type
identifier.  Either use the CWT prefix or don't.


Makes sense to me, created an issue in the issue tracker to address this.
 


* s/except that a CWT StringOrURI/except that for a CWT, StringOrURI/


 Makes sense to me, created an issue in the issue tracker to address this.


* The algorithm for doing nesting detection is a gross abuse of the content
type parameter and can be far more easily done based on the already present
tagging of the COSE object.

 

Could you please explain a bit more, we are using the COSE tags but have made 
them optional if the application for example only uses one thyme then it would 
always know what to do and would not need to parse the tag saving a byte.

 

[JLS] The concept is pretty easy to explain.

 

If you are in a situation where the full description of the CWT – including 
nesting layering – is known from a profile, then there would be no need to have 
any COSE tags present on any layer of the CWT message.  I would however highly 
discourage using this situation for anything but a single layer CWT such as one 
that is based on the COSE_Encrypt0 message without any inner layering.  Doing 
otherwise is going to mean that libraries would be unable to automatically 
unwrap all of the layers on their own, but would need guidance on each layer as 
it was processed.

 

In the current document in step 5 of section 7.2, there is an assumption that a 
COSE tag is going to exist in order to distinguish between the different types 
of COSE messages – I would not that these tags are not explicitly called for in 
section 7.1 – so the algorithm that I am going to suggest means that they are 
supposed to be present not implicit in any event.

 

In section 7.2 in step 7 the algorithm becomes:

If the payload starts with one the of COSE identification tags, then the 
message is recursive – go to step 1, wash rinse and repeat.

 


* Break section 8 into multiple paragraphs that deal with different types of
issues.


Might be reasonable I have created an issue in the issue tracker so that the 
comment is not lost.
 


* In section 8, the first sentence implies to me that you believe that COSE
is more of a problem that breaking of cryptographic algorithms, trust of
certificates/keys.  Not sure what needs to be done, but better clarity may
be a good idea.

 

Added this to the previously mentioned issue to address this to since it is in 
the same section 


* I have not done any validation of the examples.   You might want to have
an example which uses the real for one of the time types.

 

Sorry, but I don´t get it could you add some more context.

 

[JLS] Use the value of “1444064944.5” for one of the time values.  Although I 
doubt that less than second resolution is needed in almost any case, having an 
example where it is given is still a good idea.
 
Jim
 

 

 


Jim



-Original Message-
From: Ace [mailto:ace-boun...@ietf.org <mailto:ace-boun...@ietf.org> ] On 
Behalf Of Kepeng Li
Sent: Thursday, April 20, 2017 2:53 PM
To: ace@ietf.org <mailto:ace@ietf.org> 
Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net 
<mailto:hannes.tschofe...@gmx.net> >
Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

In Chicago, it was decided that we were going to WGLC the ACE CBOR Web Token
draft.

So this starts a working group last call for draft-ietf-ace-cbor-web-token
for submission as a Standards Track RFC, ending on 24:00 PDT on Tuesday, May
2, 2017.

The specification is available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-04

An HTML-formatted version is also available at:
http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-04.html

Thanks,


Kind Regards
Kepeng & Hannes


___
Ace mailing list
Ace@ietf.org <mailto:Ace@ietf.org> 
https://www.ietf.org/mailman/list

Re: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

[Carsten Bormann]

Review of draft-ietf-ace-cbor-web-token-04.txt
Reviewer: Carsten Bormann
Review result: A few technical issues; could use an editorial round

This specification sets out to translate JWT (RFC 7519) from JSON to
the CBOR world.  As such, it is relatively straightforward, and there
are only a few technical decisions that need to be made.  Clearly,
this should go ahead quickly, as it is sorely needed.


# Major technical

T1: Most fundamentally, the spec inherits a fundamental problem from JWT:
Some entries in the CWT ("claims") are actual independent claims that
can indeed be ignored if not understood, and other entries shape the
meaning of the actual claims in the CWT.  E.g., an nbf entry isn't
really a "claim" at all, it is an implicit parameter to the real
claims in the CWT.  This is, of course, a property that CWT shares
with JWT, but we could use the opportunity of defining CWT to be a bit
more specific.  E.g., we could use negative labels for entries that
shape others and unsigned ones for entries that can be ignored.
(BTW, all labels defined here would be the former category.)

T2: The spec doesn't clearly say that entry labels MUST be unsigned
numbers.  It could simply say that, but this creates an X-Dash
problem: Since people who want to experiment with CWT need to invent
numbers, they will, and there will be squatting galore.  CBOR actually
provides a nice way to solve this problem: Allow text strings as claim
labels for experimentation, replacing the need for a provisional
registration for each experiment.  No "production" CWT should have a
text label, of course; this is extremely easy to check.

T3: Section 7.2 repeats the giant mistake that JWT and the whole of
JOSE are being accused of: It tells you whether the CWT is a valid
CWT, but doesn't tell you whether it actually fulfills the security
objectives that you had.  Maybe add this explicitly to the steps.


# Other technical

T4: There was a recent move away from using CBOR Tag 1 for timestamps.
That move is fine, but why "NOT RECOMMENDED" now instead of completely
ruling it out?  Less options, more interoperability,

T5: The range 1 to 65536 is a seriously weird range.  If we do allow
one value that requires a four-byte representation then why not go for
1..4294967295?

T6: The IANA considerations may want to have different rules for
"good" label values (< 24, < 256 in that order) than for hoi polloi
ones.


# Major editorial

E1: On the editorial side, the abstract starts out by claiming [sic]
that CWT "is a profile" of JWT.  There is a definition of "profile" in
play that is a bit different from what some people might expect: a CWT
is not a JWT.

E2: The text is weirdly obsessed about CBOR serialization details.  It
is really making statements about the data model level, but dives into
serialization immediately instead.  This reads like a JSON spec would
read that would repeatedly talk about "double-quote-delimited strings,
which backslash escaping" each time a string is needed.  That's not
the way JSON is used, and we shouldn't start doing this for CBOR
either.  Just about every case that talks about "major type" really
should talk about the data that is desired.

E3: The definition of NumericDate does not reflect the decision that
using CBOR Tag 1 here is NOT RECOMMENDED.

E4: For those people who aren't the fourth co-author, maybe it would
help to provide the CDDL (not yet taking in any of the suggestions
above):

cwt = {
? iss,
? sub,
? aud,
? cti,
? exp,
? nbf,
? iat,
* otherlabel => value
}

iss = (1: text)
sub = (2: text)
aud = (3: text)
exp = (4: number) ; interpreted as with CBOR Tag 1
nbf = (5: number) ; interpreted as with CBOR Tag 1
iat = (6: number) ; interpreted as with CBOR Tag 1
cti = (7: bytes)

otherlabel = uint .ge 8
value = any

(We could play a bit with CDDL regexp support to distinguish URIs from
the other strings, but I skipped this.)


# Nits

s/to indicate type/to indicate the type/
s/contributions the specification/contributions to the specification/


Unfortunately, I haven't systematically checked the examples yet.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

[Kepeng Li]

Hello all,

Kindly remind you to review the draft and provide your feedback today.

Thanks,

Kind Regards
Kepeng

在 21/04/2017, 9:52 AM， "Ace on behalf of Kepeng Li"  写入:

>In Chicago, it was decided that we were going to WGLC the ACE CBOR Web
>Token draft.
>
>So this starts a working group last call for draft-ietf-ace-cbor-web-token
>for submission as a Standards Track RFC, ending on 24:00 PDT on Tuesday,
>May 2, 2017.
>
>The specification is available at:
>https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-04
>
>An HTML-formatted version is also available at:
>http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-04.html
>
>Thanks,
>
>
>Kind Regards
>Kepeng & Hannes
>
>
>___
>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] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

Not ready to ship.


* I find the text for NumericDate confusing and would suggest this is a
cleaner wording.

The "NumericDate" term has the same meaning, syntax and
Processing rules as the "NumericDate" term defined in Section 2 of
JWT [RFC7519], except that the CBOR numeric representation
(Section 2.4.1 of [RC7049]) is used.  The encoding is modified so that
the leading tag (6.1 or 0xC1) MUST be omitted.



* What is a "CWT NumericDate" ?  Why is this not just a "NumericDate"?  You
should be consistent on how you are using this and the "StringOrURI" type
identifier.  Either use the CWT prefix or don't.

* s/except that a CWT StringOrURI/except that for a CWT, StringOrURI/

* The algorithm for doing nesting detection is a gross abuse of the content
type parameter and can be far more easily done based on the already present
tagging of the COSE object.

* Break section 8 into multiple paragraphs that deal with different types of
issues.

* In section 8, the first sentence implies to me that you believe that COSE
is more of a problem that breaking of cryptographic algorithms, trust of
certificates/keys.  Not sure what needs to be done, but better clarity may
be a good idea.

* I have not done any validation of the examples.   You might want to have
an example which uses the real for one of the time types.

Jim


-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Kepeng Li
Sent: Thursday, April 20, 2017 2:53 PM
To: ace@ietf.org
Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net>
Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

In Chicago, it was decided that we were going to WGLC the ACE CBOR Web Token
draft.

So this starts a working group last call for draft-ietf-ace-cbor-web-token
for submission as a Standards Track RFC, ending on 24:00 PDT on Tuesday, May
2, 2017.

The specification is available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-04

An HTML-formatted version is also available at:
http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-04.html

Thanks,


Kind Regards
Kepeng & Hannes


___
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

[Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

[Kepeng Li]

In Chicago, it was decided that we were going to WGLC the ACE CBOR Web
Token draft.

So this starts a working group last call for draft-ietf-ace-cbor-web-token
for submission as a Standards Track RFC, ending on 24:00 PDT on Tuesday,
May 2, 2017.

The specification is available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-04

An HTML-formatted version is also available at:
http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-04.html

Thanks,


Kind Regards
Kepeng & Hannes


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace