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.
<Note above text kills the direct need for section 5.>
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 nested CWTs you would like to mandate
the inner layer to have a COSE tag indicating the message type. But in cases
where e.g. transport is done over CoAP you don´t feel it is as important.
I personally would like to go all the way and mandate the COSE tag for all CWT
messages nested or not but that would add some extra bytes i.e. not good in all
cases.
Maybe a compromise and mandate it for inner object in nested CWTs.
@Mike would you like to comment to before we decide on a path forward.
* 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.
Makes sense, as you say it might not be a core case but there should be at
least one example of it if we support it. I have created a ticket to address it.
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/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
