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 
Cc: Jim Schaad ; Samuel Erdtman ; 
ace 
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

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

[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 ; 'Samuel Erdtman' 
Cc: 'ace' 
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  >; 
'Samuel Erdtman'  >
Cc: 'ace'  >
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  >; 'Samuel Erdtman'  >
Cc: 'ace'  >
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  >; Jim Schaad 
 >
Cc: ace  >
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  >; Mike 
Jones  >
Cc: ace  >
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  > wrote:

 

 

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

 

Hi Jim,

Thanks for