Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

[Mike Jones]

Thanks to Hannes and Jim for participating.  Based on their feedback and in 
deference to the ACE working group’s decision, I’m now willing to have the 
registrations occur as specified in the draft.

Let’s give Chuck a day for him to either agree or disagree and then propose 
that we proceed with the registrations on Wednesday.

   Cheers,
   -- Mike

From: Jim Schaad 
Sent: Monday, March 23, 2020 10:55 AM
To: 'Hannes Tschofenig' ; 'Seitz Ludwig' 
; Mike Jones ; 'Chuck 
Mortimore' 
Cc: chuck.mortim...@visa.com; cwt-reg-rev...@ietf.org; 
draft-ietf-ace-oauth-au...@ietf.org; drafts-expert-rev...@iana.org; ace@ietf.org
Subject: RE: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

And I thought this was why we “hired” experts.

As has been  noted previously in this discussion, there is no requirement that 
the scope must be a text string, it can be a binary string as well.  Further, I 
believe that there will start being some dictionary work being done at some 
point in the future when defining a new scope format so that any text strings 
could be compressed down.

I also am of the opinion that one of the major uses of CWTs is going to be as 
an authorization token and that scoping of authorization is an important part 
of this.   I would probably be more sympathetic to the argument of making it 
two bytes if that had been done for about half of the items currently 
registered.

I would make it a one byte because I think it is important, is going to be used 
by a lot of places where just audience is not sufficient to restrict scope, and 
ACE is the current hotspot where it is going to be used.  Both for general 
purpose authorization and for the group/multicast authorization as well.  My 
current expectation is still that most of the time HTTP will be using JWT not 
CWT.

Jim


From: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Sent: Monday, March 23, 2020 6:41 AM
To: Jim Schaad mailto:i...@augustcellars.com>>; 'Seitz 
Ludwig' mailto:ludwig.se...@combitech.se>>; 'Mike 
Jones' mailto:michael.jo...@microsoft.com>>; 
'Chuck Mortimore' 
mailto:charliemortim...@gmail.com>>
Cc: chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
ace@ietf.org<mailto:ace@ietf.org>
Subject: RE: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

Hi all,

This is an interesting case.

CWT was created based on the work on ACE-OAuth. I would therefore agree with 
Ludwig that it should receive priority treatment with regards to the selection 
of the value encodings.

I do, however, also have sympathy for the argument Chuck mentioned regarding 
the scope encoded as a string. Of course, there is no need to encode the scope 
as a human-readable string.

The main question is whether we should argue about one byte.

Highly-paid ACE chairs: what is your opinion?

Ciao
Hannes


From: Jim Schaad mailto:i...@augustcellars.com>>
Sent: Saturday, March 21, 2020 4:32 PM
To: 'Seitz Ludwig' 
mailto:ludwig.se...@combitech.se>>; 'Mike Jones' 
mailto:michael.jo...@microsoft.com>>; 'Chuck 
Mortimore' mailto:charliemortim...@gmail.com>>; 
Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
Cc: chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
ace@ietf.org<mailto:ace@ietf.org>
Subject: RE: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

No you should not need to make any changes in the document.  This will be taken 
care of by the RFC Editor.

Jim


From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Seitz Ludwig
Sent: Saturday, March 21, 2020 3:35 AM
To: Mike Jones 
mailto:michael.jo...@microsoft.com>>; Chuck 
Mortimore mailto:charliemortim...@gmail.com>>; 
hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>
Cc: chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] [Cwt-reg-review] [IANA #1158953] 

Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

[Mike Jones]

Ludwig, yes, while you’re a designated expert, note that the instructions to 
the designated experts at https://tools.ietf.org/html/rfc8392#section-9 
includes this text:
   In cases where a registration decision could
   be perceived as creating a conflict of interest for a particular
   Expert, that Expert should defer to the judgment of the other
   Experts.

So, as I see it, you should actually recuse yourself from this decision.  That 
said, I’ve sent a private note to Hannes asking him to also weigh in.

   Cheers,
   -- Mike

From: Seitz Ludwig 
Sent: Monday, March 16, 2020 3:18 AM
To: Mike Jones ; Chuck Mortimore 
; hannes.tschofe...@arm.com
Cc: drafts-expert-rev...@iana.org; cwt-reg-rev...@ietf.org; 
chuck.mortim...@visa.com; draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org
Subject: [EXTERNAL] RE: [Cwt-reg-review] [IANA #1158953] Requested review for 
IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

Hi Mike,

I will of course abide with a majority decision of the designated experts (note 
that I’m one of them too). I would therefore be very interested to hear Hannes 
take on this.

Regards,

Ludwig

From: Mike Jones 
mailto:michael.jo...@microsoft.com>>
Sent: den 13 mars 2020 19:17
To: Seitz Ludwig mailto:ludwig.se...@combitech.se>>; 
Chuck Mortimore mailto:charliemortim...@gmail.com>>
Cc: Ludwig Seitz mailto:ludwig_se...@gmx.de>>; 
drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>; 
chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

RFC 8693 defines the “scope” JWT claim for use with OAuth 2.0, and so is 
application-specific – just like the corresponding CWT “scope” claim is 
specific to ACE OAuth.

Unless Hannes (the other Designated Expert) disagrees with my and Chuck’s 
assessment by then, I propose that we proceed with the registrations on Monday, 
registering “scope” with value 41.

   -- Mike

From: Seitz Ludwig mailto:ludwig.se...@combitech.se>>
Sent: Thursday, March 12, 2020 1:05 AM
To: Chuck Mortimore 
mailto:charliemortim...@gmail.com>>; Mike Jones 
mailto:michael.jo...@microsoft.com>>
Cc: Ludwig Seitz mailto:ludwig_se...@gmx.de>>; 
drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>; 
chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

Hello Mike, Chuck,

Thank you for clarifying your assessment Mike, thank you Chuck for weighing in.

Mike you say: “the scope claim is specific to the ACE OAuth protocol”

This is not entirely correct, since the scope claim is defined  in  RFC 8693 
for Token Exchange, which is not an ACE protocol. Thus if any other protocol 
decides to use CWT and Token Exchange they would inherit the CWT abbreviation 
for that claim we are discussing here.
I would therefore argue that this claim abbreviation has a wider set of 
applications than just ACE.

As for the sparseness of 1 byte abbreviations: The range goes from -24 to 23. 
The CWT RFC uses 0-8 and none other are currently registered, so we have a few 
ones left.

Regards,

Ludwig


From: Chuck Mortimore 
mailto:charliemortim...@gmail.com>>
Sent: den 12 mars 2020 01:12
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Ludwig Seitz mailto:ludwig_se...@gmx.de>>; 
drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>; 
chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [EXTERNAL] Re: [Cwt-reg-review] [IANA #1158953] Requested review 
for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token 
Claims)

Agree with Mike's assessment.   (One caveat to that is that I'm not close 
enough to CWT to understand how scare the single byte identifiers actually are.)

On Wed, Mar 11, 2020 at 4:39 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

[Adding correct e-mail addresses for Chuck, who recently joined Visa]



There are two reasons that I believe not using 

Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

[Mike Jones]

RFC 8693 defines the “scope” JWT claim for use with OAuth 2.0, and so is 
application-specific – just like the corresponding CWT “scope” claim is 
specific to ACE OAuth.

Unless Hannes (the other Designated Expert) disagrees with my and Chuck’s 
assessment by then, I propose that we proceed with the registrations on Monday, 
registering “scope” with value 41.

   -- Mike

From: Seitz Ludwig 
Sent: Thursday, March 12, 2020 1:05 AM
To: Chuck Mortimore ; Mike Jones 

Cc: Ludwig Seitz ; drafts-expert-rev...@iana.org; 
cwt-reg-rev...@ietf.org; chuck.mortim...@visa.com; 
draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org
Subject: Re: [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

Hello Mike, Chuck,

Thank you for clarifying your assessment Mike, thank you Chuck for weighing in.

Mike you say: “the scope claim is specific to the ACE OAuth protocol”

This is not entirely correct, since the scope claim is defined  in  RFC 8693 
for Token Exchange, which is not an ACE protocol. Thus if any other protocol 
decides to use CWT and Token Exchange they would inherit the CWT abbreviation 
for that claim we are discussing here.
I would therefore argue that this claim abbreviation has a wider set of 
applications than just ACE.

As for the sparseness of 1 byte abbreviations: The range goes from -24 to 23. 
The CWT RFC uses 0-8 and none other are currently registered, so we have a few 
ones left.

Regards,

Ludwig


From: Chuck Mortimore 
mailto:charliemortim...@gmail.com>>
Sent: den 12 mars 2020 01:12
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Ludwig Seitz mailto:ludwig_se...@gmx.de>>; 
drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>; 
chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [EXTERNAL] Re: [Cwt-reg-review] [IANA #1158953] Requested review 
for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token 
Claims)

Agree with Mike's assessment.   (One caveat to that is that I'm not close 
enough to CWT to understand how scare the single byte identifiers actually are.)

On Wed, Mar 11, 2020 at 4:39 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

[Adding correct e-mail addresses for Chuck, who recently joined Visa]



There are two reasons that I believe not using up one of the scarce one-byte 
claim identifiers for "scope" is appropriate:

  1.  The claim values for scopes are not short themselves.  They are sets of 
ASCII strings separated by spaces. So the percentage difference in the total 
claim representation from adding a single byte will typically be small.
  2.  The single-byte claim identifiers already registered at 
https://www.iana.org/assignments/cwt/cwt.xhtml are claims that are likely to be 
useful to diverse sets of applications, and therefore merit the short 
identifiers; whereas, the scope claim is specific to the ACE OAuth protocol and 
not applicable to diverse sets of applications.  It’s reasonable to give 
protocol-specific claim identifiers 2-byte representations.



I’d be interested to hear from the two other designated experts on my 
assessment of the situation: Hannes and Chuck.



   -- Mike



-Original Message-
From: Cwt-reg-review 
mailto:cwt-reg-review-boun...@ietf.org>> On 
Behalf Of Ludwig Seitz
Sent: Saturday, February 29, 2020 6:25 AM
To: drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>
Cc: 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 ace@ietf.org<mailto:ace@ietf.org>
Subject: [EXTERNAL] Re: [Cwt-reg-review] [IANA #1158953] Requested review for 
IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)



On 2020-02-26 00:58, Amanda Baber via RT wrote:

> Ludwig, Hannes,

>

> Can you confirm that you can make the CBOR Web Token Claim change

> requested below?

>

> We also have Chuck Mortimore listed as an expert for this registry,

> but our message to his Salesforce address bounced.

>

> Best regards,

>

> Amanda Baber Lead IANA Services Specialist

>



I strongly disagree with the assessment that the scope claim should be pushed 
into the two-byte range.



The reason we introduced the scope claim is that an ACE RS typically does not 
have a direct connection to the AS, and is therefore unable to retrieve the 
scope of an access token from other sources than the access token itself.  I 
therefore assert that ACE access tokens would often need to contain this claim 
in or

Re: [Ace] [EXTERNAL] Re: [Cwt-reg-review] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

[Mike Jones]

[Adding correct e-mail addresses for Chuck, who recently joined Visa]



There are two reasons that I believe not using up one of the scarce one-byte 
claim identifiers for "scope" is appropriate:

  1.  The claim values for scopes are not short themselves.  They are sets of 
ASCII strings separated by spaces. So the percentage difference in the total 
claim representation from adding a single byte will typically be small..
  2.  The single-byte claim identifiers already registered at 
https://www.iana.org/assignments/cwt/cwt.xhtml are claims that are likely to be 
useful to diverse sets of applications, and therefore merit the short 
identifiers; whereas, the scope claim is specific to the ACE OAuth protocol and 
not applicable to diverse sets of applications.  It's reasonable to give 
protocol-specific claim identifiers 2-byte representations.



I'd be interested to hear from the two other designated experts on my 
assessment of the situation: Hannes and Chuck.



   -- Mike



-Original Message-
From: Cwt-reg-review  On Behalf Of Ludwig Seitz
Sent: Saturday, February 29, 2020 6:25 AM
To: drafts-expert-rev...@iana.org; cwt-reg-rev...@ietf.org
Cc: draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org
Subject: [EXTERNAL] Re: [Cwt-reg-review] [IANA #1158953] Requested review for 
IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)



On 2020-02-26 00:58, Amanda Baber via RT wrote:

> Ludwig, Hannes,

>

> Can you confirm that you can make the CBOR Web Token Claim change

> requested below?

>

> We also have Chuck Mortimore listed as an expert for this registry,

> but our message to his Salesforce address bounced.

>

> Best regards,

>

> Amanda Baber Lead IANA Services Specialist

>



I strongly disagree with the assessment that the scope claim should be pushed 
into the two-byte range.



The reason we introduced the scope claim is that an ACE RS typically does not 
have a direct connection to the AS, and is therefore unable to retrieve the 
scope of an access token from other sources than the access token itself.  I 
therefore assert that ACE access tokens would often need to contain this claim 
in order to inform the RS.

Since one of the major drivers of the ACE work has been to reduce the 
authorization overhead (otherwise we could just have used vanilla OAuth 2.0), I 
find it strange to needlessly add to the overhead by making the encoding of a 
frequently used claim longer than necessary.



I am willing to listen to the arguments that have lead the expert reviewer to 
denying a value in the one-byte range, and discuss the reasoning further on 
list.



Regards,



Ludwig





> On Tue Feb 18 22:42:22 2020, 
> michael.jo...@microsoft.com wrote:

>> I'm mostly OK with these registrations, however, DO NOT assign the

>> value 9 to "scope".   Rather, please put it in the two-byte range

>> - for instance, with the value 41.

>>

>> -- Mike

>>

>> -Original Message- From: Cwt-reg-review

>> mailto:cwt-reg-review-boun...@ietf.org>> On 
>> Behalf Of Sabrina Tanamal via RT

>> Sent: Tuesday, February 18, 2020 1:06 PM Cc:

>> cwt-reg-rev...@ietf.org Subject: [EXTERNAL] 
>> [Cwt-reg-review] [IANA

>> #1158953] Requested review for IANA registration in

>> draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

>>

>> Hi all,

>>

>> Resending this request for draft-ietf-ace-oauth-authz.

>>

>> Thanks,

>>

>> Sabrina Tanamal Senior IANA Services Specialist

>>

>>> On Sat Dec 21 11:37:11 2019, 
>>> ludwig_se...@gmx.de wrote:

 Hello CWT registry reviewers,



 the IESG-designated experts for the CWT claims registry have asked

 me to send a review request to you about the claims registered

 here:



 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ft

 o





ols.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-authz-29%23section-

 8.13

 mp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Ce23f64ac1ad74269c

 3





c408d7b4b65d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63717656

 7656665548sdata=r01W5Bx0gJh9ZPH8eNS%2BY765CnGq11DkknsHYQ751Dk%

 3





Dreserved=0



 Thank you in advance for you review comments.



 Regards,



 Ludwig



>>

>> ___ Cwt-reg-review

>> mailing list cwt-reg-rev...@ietf.org

>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww

>> .ietf.org%2Fmailman%2Flistinfo%2Fcwt-

>>

>>

reg-

>> reviewdata=02%7C01%7CMichael.Jones%40microsoft.com%7Ce23f64ac1ad

>> 74269c3c408d7b4b65d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63

>> 7176567656675543sdata=XxBhQmqxGkCRiBxh0PdhX2IJD8TnbwWl%2Feo8VUsH

>> Osg%3Dreserved=0

>



___

Cwt-reg-review 

[Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) is now RFC 8747

[Mike Jones]

I'm pleased to report that Proof-of-Possession Key Semantics for CBOR Web 
Tokens (CWTs) is now RFC 8747.  
The abstract of the specification is:

This specification describes how to declare in a CBOR Web Token (CWT) (which is 
defined by RFC 8392) that the presenter of the CWT possesses a particular 
proof-of-possession key. Being able to prove possession of a key is also 
sometimes described as being the holder-of-key. This specification provides 
equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web 
Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) 
and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens 
(JWTs).

This is one of a series of specifications, including CWT [RFC 
8392] - which mirrors JWT [RFC 
7519], in which we are intentionally 
bringing functionality that is available in JSON to the CBOR and IoT world.

   -- Mike

P.S.  This notice was also posted at https://self-issued.info/?p=2066 and as 
@selfissued.

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

Re: [Ace] [EXTERNAL] RE: Access token question

[Mike Jones]

And https://tools.ietf.org/html/rfc8693#section-7.4, which registers “scope” at 
https://www.iana.org/assignments/jwt/jwt.xhtml.

-- Mike

From: Jim Schaad 
Sent: Friday, February 21, 2020 9:15 AM
To: 'Francesca Palombini' ; 'Seitz Ludwig' 
; Mike Jones 
Cc: 'Ace Wg' 
Subject: [EXTERNAL] RE: Access token question

You are missing something

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-8.13<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-authz-33%23section-8.13=02%7C01%7CMichael.Jones%40microsoft.com%7C41e26bbcdb7c4f902d7908d7b6f1a860%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637179021340478864=bMozqI2BYqMAAViWLIIKzJBvQFa30eqKVHtqUiC3bH8%3D=0>

defined here

From: Francesca Palombini 
mailto:francesca.palomb...@ericsson.com>>
Sent: Friday, February 21, 2020 4:37 AM
To: Seitz Ludwig mailto:ludwig.se...@combitech.se>>; 
Mike Jones mailto:michael.jo...@microsoft.com>>; 
Jim Schaad mailto:i...@augustcellars.com>>
Cc: Ace Wg mailto:ace@ietf.org>>
Subject: Access token question

Hi,

Quick question regarding access token and scope.
I know that “scope” semantics is left to the application to define, but in 
general I would expect to include there some information about resource and 
method/operations allowed on that resource. Please correct me if any of this is 
not exact.

It was my understanding that “scope” (or more precisely the “scope” value) 
defined for the Client-AS request and response should be included in the access 
token as well. Checking in CWT, there is no such “scope” claim defined. “aud” 
claim is indeed defined for the CWT, but that should correspond to “aud” 
parameter in the ACE request/response. So where do I put the exact resource and 
operations in the access token?

What am I missing?

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

Re: [Ace] [EXTERNAL] [Jwt-reg-review] [IANA #1160802] Re: Requested review for IANA registration in draft-ietf-ace-oauth-params

[Mike Jones]

I am OK with these JWT claim registrations.

-- Mike

-Original Message-
From: Jwt-reg-review  On Behalf Of Sabrina 
Tanamal via RT
Sent: Friday, January 24, 2020 8:59 AM
Cc: r...@cert.org; daniel.miga...@ericsson.com; jwt-reg-rev...@ietf.org; 
i...@augustcellars.com; ludwig_se...@gmx.de; ka...@mit.edu; 
ludwig.se...@combitech.se; ace@ietf.org; bcampb...@pingidentity.com
Subject: [EXTERNAL] [Jwt-reg-review] [IANA #1160802] Re: [Ace] Requested review 
for IANA registration in draft-ietf-ace-oauth-params

Hi Ben, 

Since there are multiple experts for this registry, we can ask the others to 
review the registration. 

Thanks,

Sabrina Tanamal
Senior IANA Services Specialist

On Fri Jan 24 01:46:47 2020, ka...@mit.edu wrote:
> Thanks for putting the effort in, Brian.
> 
> IANA, do you need to assign a new expert to reviewi the JWT Claims 
> registration request from this document, or are the experts expected 
> to be self-organizing here?
> 
> Thanks,
> 
> Ben
> 
> On Thu, Jan 23, 2020 at 02:31:20PM -0700, Brian Campbell wrote:
> > Apologies, I forgot to reply-all at some earlier point and dropped 
> > the mailing lists and other cc's off the thread. Added back now.
> >
> > And also apologies because I think I need to recuse myself from the 
> > DE responsibility on the JWT registry request here. I've spent more 
> > time than I'd like to admit or really have to spare on it and am 
> > still struggling to understand.
> >
> > I appreciate you pointing out the authz-info endpoint in ACE but I 
> > still don't follow how "rs_cnf" in an access token would really work 
> > in practice.
> > The client sends the token to the RS's authz-info endpoint on an 
> > insecure connection or one that has the server auth with potentially 
> > different key and the RS stores the access token for later use. Then 
> > on resource access the RS looks up the access token (with respect to 
> > the cnf key in it) based on the key the client used in establishing 
> > a new mutually authentication connection to the RS. For the RS to 
> > choose a key for server it will use during the handshake (and as far 
> > as I know the server key is the first in the authn process of the 
> > handshake) based on the "rs_cnf" in the access token, it needs to 
> > remember and associate that client and the access token with 
> > something else (IP address?) that will be available during the 
> > handshake. It doesn't fit together for me in a way that seems likely 
> > to work or be interoperable but, like I said, I'm really struggling 
> > to understand.
> >
> > On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig 
> > 
> > wrote:
> >
> > > Hi Brian,
> > >
> > >
> > >
> > > Comments inline.
> > >
> > >
> > >
> > > /Ludwig
> > >
> > >
> > >
> > > *From:* Brian Campbell 
> > > *Sent:* den 13 januari 2020 21:22
> > > *To:* Seitz Ludwig 
> > > *Subject:* Re: [Ace] Requested review for IANA registration in 
> > > draft-ietf-ace-oauth-params
> > >
> > >
> > >
> > > Thanks for the response and updates Ludwig,
> > >
> > >
> > >
> > > Please bear with me while I try to wrap my head around some things.
> > >
> > >
> > >
> > > The JWT registration request for the "rs_cnf" claim points to Sec
> > > 3.3
> > >  > > Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params-data=02%
> > > 7C01%7CMichael.Jones%40microsoft.com%7Cdbbd65cde4094540932b08d7a0f
> > > 0220f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637154825550691
> > > 547sdata=giictWf%2BpzXWEBH2HBC1vyHYr68OhfO9zPK3Wq0x%2FQc%3D
> > > mp;reserved=0
> > > 08#section-3.3>
> > > saying it is "a hint [in the access token] to the RS about which 
> > > key it should use to authenticate towards the client".  But 
> > > doesn't the client have to go through the DTLS/TLS handshake with 
> > > the RS (which is presumably when it authenticates to the client) 
> > > before it presents the access token?
> > > I'm not seeing how this would work as seems the RS won't see the 
> > > hint until after it needs it.
> > >
> > >
> > >
> > >
> > >
> > > [LS] Not in the ACE flow. We use the access token to establish 
> > > keys at the RS both for the client and the RS. We have therefore 
> > > defined a new ACE-OAuth endpoint (authz-info) at the RS. The 
> > > client can POST access tokens to this endpoint without prior 
> > > authentication.
> > >
> > > At that point, the RS only validates the signature/MAC by the AS.
> > >
> > >
> > >
> > > Later at the time of access, the corresponding token is linked to 
> > > the access request via the pop-mechanism and the client/access 
> > > specific parts are validated (e.g. scope, subject).
> > >
> > >
> > >
> > > Hope that clarifies things a bit.
> > >
> > >
> > >
> > > On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig 
> > > 
> > > wrote:
> > >
> > > Hello again Brian,
> > >
> > >
> > >
> > > Thank you for reviewing this! Indeed the handling of JWT/JSON 
> > > interactions was handled 

[Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) sent to the RFC Editor

[Mike Jones]

I'm pleased to report that the Proof-of-Possession Key Semantics for CBOR Web 
Tokens (CWTs) specification is now technically stable and will shortly be an 
RFC - an Internet standard.  Specifically, it has now progressed to the RFC 
Editor queue, meaning that the only remaining step before finalization is 
editorial due diligence.  Thus, implementations can now utilize the draft 
specification with confidence that that breaking changes will not occur as it 
is finalized.

The abstract of the specification is:
This specification describes how to declare in a CBOR Web Token (CWT) (which is 
defined by RFC 8392) that the presenter of the CWT possesses a particular 
proof-of-possession key. Being able to prove possession of a key is also 
sometimes described as being the holder-of-key. This specification provides 
equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web 
Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) 
and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens 
(JWTs).

Thanks to the ACE working group for 
completing this important specification.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11

An HTML-formatted version is also available at:

  *   
https://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-11.html

   -- Mike

P.S.  This note was also posted at https://self-issued.info/?p=2025 and as 
@selfissued.

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

Re: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-11.txt

[Mike Jones]

This version addresses the remaining IESG review comment by Mirja Kühlewind, 
which removes the language about contacting the IESG should the Designated 
Experts not act on IANA registrations in a timely way, per a decision by the 
IESG on today's telechat.

-- Mike

-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Thursday, October 31, 2019 7:44 AM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-11.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : Proof-of-Possession Key Semantics for CBOR Web Tokens 
(CWTs)
Authors : Michael B. Jones
  Ludwig Seitz
  Göran Selander
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-cwt-proof-of-possession-11.txt
Pages   : 16
Date: 2019-10-31

Abstract:
   This specification describes how to declare in a CBOR Web Token (CWT)
   (which is defined by RFC 8392) that the presenter of the CWT
   possesses a particular proof-of-possession key.  Being able to prove
   possession of a key is also sometimes described as being the holder-
   of-key.  This specification provides equivalent functionality to
   "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC
   7800) but using Concise Binary Object Representation (CBOR) and CWTs
   rather than JavaScript Object Notation (JSON) and JSON Web Tokens
   (JWTs).


The IETF datatracker status page for this draft is:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-cwt-proof-of-possession%2Fdata=02%7C01%7CMichael.Jones%40microsoft.com%7C6fe566449c1b4805cee708d75e10ba0b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637081298248386929sdata=cElMuuONfQiYsRqMjJs4wMHUtsvanpy6%2F1hWGvY7FN0%3Dreserved=0

There are also htmlized versions available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-cwt-proof-of-possession-11data=02%7C01%7CMichael.Jones%40microsoft.com%7C6fe566449c1b4805cee708d75e10ba0b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637081298248386929sdata=8253o%2BDZTDVf4HeuoYu%2BbpHR91CQrswnV%2FsCfGQ95Es%3Dreserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-cwt-proof-of-possession-11data=02%7C01%7CMichael.Jones%40microsoft.com%7C6fe566449c1b4805cee708d75e10ba0b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637081298248386929sdata=cJ%2B7qAhU78Vr1sXrcTzQNSEojTo8VbZS%2FimuNyX2CCs%3Dreserved=0

A diff from the previous version is available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-cwt-proof-of-possession-11data=02%7C01%7CMichael.Jones%40microsoft.com%7C6fe566449c1b4805cee708d75e10ba0b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637081298248386929sdata=M%2BkS9bx%2BIgswYIDwiLo31elWcakFKG9Wni2VrKVyVUA%3Dreserved=0


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Ace mailing list
Ace@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Facedata=02%7C01%7CMichael.Jones%40microsoft.com%7C6fe566449c1b4805cee708d75e10ba0b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637081298248386929sdata=cVK4RObuN77arf0SyvC6thrDdprjgReHirSFx2pwMso%3Dreserved=0
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Mike Jones]

Per the decision on the telechat, I have published -11, which removes the IESG 
appeal language in favor of direct appeal to the IESG.  See 
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11#section-7.

Please update the document status accordingly.

Thank you,
-- Mike

-Original Message-
From: Mike Jones 
Sent: Wednesday, October 30, 2019 5:48 PM
To: Benjamin Kaduk 
Cc: Roman D. Danyliw ; ace-cha...@ietf.org; Mirja Kuehlewind 
; The IESG ; ace@ietf.org; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; Barry Leiba 

Subject: RE: [Ace] Mirja Kühlewind's No Objection on 
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

Thanks for the clarification, Ben.  I'm fine with this going either way (appeal 
to IESG or appeal to IANA).  Just drop me a note after the issue is discussed 
on the telechat and I'll turn around a new draft right away tomorrow, if 
requested.

Later,
-- Mike

-Original Message-
From: Ace  On Behalf Of Benjamin Kaduk
Sent: Wednesday, October 30, 2019 5:29 PM
To: Mike Jones 
Cc: Roman D. Danyliw ; ace-cha...@ietf.org; Mirja Kuehlewind 
; The IESG ; ace@ietf.org; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; Barry Leiba 

Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

Just to be clear, IANA raising the issue to the IESG is described in Section 
5.3 of RFC 8126, which would be the default expectations if an individual 
document/registry did not give other instructions.

-Ben

On Thu, Oct 31, 2019 at 12:13:58AM +, Mike Jones wrote:
> I'm in the process of creating -10, which addresses the IESG comments other 
> than Mirja's.  I'm reluctant to change the registration instructions, as they 
> are currently identical to those for CWTs (and many other specifications 
> going back to at least RFC 6749, modulo the name of the mailing list).  That 
> said, if the IESG *really* wants to change the party to appeal to in the case 
> of non-action from the Designated Experts from the IESG to IANA, I'm amenable 
> to also making that change tomorrow, immediately following the telechat, so 
> we can send the spec on to the RFC Editor.  Let me know what you decide.
> 
>   Thanks again,
>   -- Mike
> 
> -Original Message-
> From: Barry Leiba 
> Sent: Monday, October 28, 2019 2:00 PM
> To: Mike Jones 
> Cc: Mirja Kuehlewind ; Benjamin Kaduk 
> ; Roman D. Danyliw ; ace-cha...@ietf.org; 
> The IESG ; ace@ietf.org; 
> draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> Subject: Re: [Ace] Mirja Kühlewind's No Objection on
> draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
> 
> The issue isn't using a mailing list.  The issue is the instructions to IANA 
> about how to do management and tracking, stuff that they do just fine without 
> working groups trying -- will all good intentions -- to tell them how.
> 
> The fact that there are a lot of RFCs that do it just says that working 
> groups do this frequently, and most ADs don't notice or don't care.  And the 
> reality is that IANA will manage the registration process how they do it, 
> accommodating reasonable special instructions when they can.  The point is 
> that documents shouldn't be giving special instructions unless there really 
> is something special needed for a particular reason.
> 
> Barry
> 
> On Mon, Oct 28, 2019 at 12:19 PM Mike Jones  
> wrote:
> >
> > The practice of using a mailing list for registration requests to enable 
> > public visibility of them goes back at least to .well-known URI 
> > registrations 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5785data=02%7C01%7CMichael.Jones%40microsoft.com%7C0b217822fdab454c213408d75d995cec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080785592172015sdata=dvBR4fRzp1xSMcqXyaSa68Px7AJs3alwwTPJVH4YyMA%3Dreserved=0
> >  by Mark Nottingham in April 2010.  OAuth 2.0 followed this practice in RFC 
> > 6749, as did the JOSE specs and JWT in RFCs 7515-19.  The rest is history, 
> > as they say.
> >
> > -- Mike
> >
> > -Original Message-
> > From: Mirja Kuehlewind 
> > Sent: Monday, October 28, 2019 8:54 AM
> > To: Benjamin Kaduk 
> > Cc: Barry Leiba ; Roman D. Danyliw 
> > ; ace-cha...@ietf.org; The IESG ; 
> > ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> > Subject: Re: [Ace] Mirja Kühlewind's No Objection on
> > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
> >
> > These are all quite recents examples, so maybe the procedures ar

Re: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-10.txt

[Mike Jones]

This version addresses IESG comments from Adam Roach and Éric Vyncke, both of 
which resulted in local editorial improvements to the document.

-- Mike

-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, October 30, 2019 5:33 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-10.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : Proof-of-Possession Key Semantics for CBOR Web Tokens 
(CWTs)
Authors : Michael B. Jones
  Ludwig Seitz
  Göran Selander
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-cwt-proof-of-possession-10.txt
Pages   : 16
Date: 2019-10-30

Abstract:
   This specification describes how to declare in a CBOR Web Token (CWT)
   (which is defined by RFC 8392) that the presenter of the CWT
   possesses a particular proof-of-possession key.  Being able to prove
   possession of a key is also sometimes described as being the holder-
   of-key.  This specification provides equivalent functionality to
   "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC
   7800) but using Concise Binary Object Representation (CBOR) and CWTs
   rather than JavaScript Object Notation (JSON) and JSON Web Tokens
   (JWTs).


The IETF datatracker status page for this draft is:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-cwt-proof-of-possession%2Fdata=02%7C01%7CMichael.Jones%40microsoft.com%7C8f8fbd0554a54a425eac08d75d99d814%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080787671770750sdata=1DMKhvl%2BZrTderZqQO1dPMWxGvPpUBH0QakWZ7nhT%2Bw%3Dreserved=0

There are also htmlized versions available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-cwt-proof-of-possession-10data=02%7C01%7CMichael.Jones%40microsoft.com%7C8f8fbd0554a54a425eac08d75d99d814%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080787671770750sdata=I%2BL3A86s5uufPp8vRfK31GNJbtJrDC3umOhxH7z5rCI%3Dreserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-cwt-proof-of-possession-10data=02%7C01%7CMichael.Jones%40microsoft.com%7C8f8fbd0554a54a425eac08d75d99d814%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080787671770750sdata=ulFodpYOpfmgwrqzuX%2Fz6mTiNSL0vrjS3rnGX5mMuU0%3Dreserved=0

A diff from the previous version is available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-cwt-proof-of-possession-10data=02%7C01%7CMichael.Jones%40microsoft.com%7C8f8fbd0554a54a425eac08d75d99d814%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080787671770750sdata=cchPquPB5ZSCFJfLp91Bp2azdFz7HhttSNk0W%2BvIPic%3Dreserved=0


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Ace mailing list
Ace@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Facedata=02%7C01%7CMichael.Jones%40microsoft.com%7C8f8fbd0554a54a425eac08d75d99d814%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080787671770750sdata=TaKbHEKFGIXDUdMrJoceYzSO4wsWDCVisMdWqQHZfUA%3Dreserved=0
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Mike Jones]

Thanks for the clarification, Ben.  I'm fine with this going either way (appeal 
to IESG or appeal to IANA).  Just drop me a note after the issue is discussed 
on the telechat and I'll turn around a new draft right away tomorrow, if 
requested.

Later,
-- Mike

-Original Message-
From: Ace  On Behalf Of Benjamin Kaduk
Sent: Wednesday, October 30, 2019 5:29 PM
To: Mike Jones 
Cc: Roman D. Danyliw ; ace-cha...@ietf.org; Mirja Kuehlewind 
; The IESG ; ace@ietf.org; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; Barry Leiba 

Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

Just to be clear, IANA raising the issue to the IESG is described in Section 
5.3 of RFC 8126, which would be the default expectations if an individual 
document/registry did not give other instructions.

-Ben

On Thu, Oct 31, 2019 at 12:13:58AM +, Mike Jones wrote:
> I'm in the process of creating -10, which addresses the IESG comments other 
> than Mirja's.  I'm reluctant to change the registration instructions, as they 
> are currently identical to those for CWTs (and many other specifications 
> going back to at least RFC 6749, modulo the name of the mailing list).  That 
> said, if the IESG *really* wants to change the party to appeal to in the case 
> of non-action from the Designated Experts from the IESG to IANA, I'm amenable 
> to also making that change tomorrow, immediately following the telechat, so 
> we can send the spec on to the RFC Editor.  Let me know what you decide.
> 
>   Thanks again,
>   -- Mike
> 
> -Original Message-
> From: Barry Leiba 
> Sent: Monday, October 28, 2019 2:00 PM
> To: Mike Jones 
> Cc: Mirja Kuehlewind ; Benjamin Kaduk 
> ; Roman D. Danyliw ; ace-cha...@ietf.org; 
> The IESG ; ace@ietf.org; 
> draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
> draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
> 
> The issue isn't using a mailing list.  The issue is the instructions to IANA 
> about how to do management and tracking, stuff that they do just fine without 
> working groups trying -- will all good intentions -- to tell them how.
> 
> The fact that there are a lot of RFCs that do it just says that working 
> groups do this frequently, and most ADs don't notice or don't care.  And the 
> reality is that IANA will manage the registration process how they do it, 
> accommodating reasonable special instructions when they can.  The point is 
> that documents shouldn't be giving special instructions unless there really 
> is something special needed for a particular reason.
> 
> Barry
> 
> On Mon, Oct 28, 2019 at 12:19 PM Mike Jones  
> wrote:
> >
> > The practice of using a mailing list for registration requests to enable 
> > public visibility of them goes back at least to .well-known URI 
> > registrations 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5785data=02%7C01%7CMichael.Jones%40microsoft.com%7C0b217822fdab454c213408d75d995cec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080785592172015sdata=dvBR4fRzp1xSMcqXyaSa68Px7AJs3alwwTPJVH4YyMA%3Dreserved=0
> >  by Mark Nottingham in April 2010.  OAuth 2.0 followed this practice in RFC 
> > 6749, as did the JOSE specs and JWT in RFCs 7515-19.  The rest is history, 
> > as they say.
> >
> > -- Mike
> >
> > -Original Message-
> > From: Mirja Kuehlewind 
> > Sent: Monday, October 28, 2019 8:54 AM
> > To: Benjamin Kaduk 
> > Cc: Barry Leiba ; Roman D. Danyliw 
> > ; ace-cha...@ietf.org; The IESG ; 
> > ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> > Subject: Re: [Ace] Mirja Kühlewind's No Objection on
> > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
> >
> > These are all quite recents examples, so maybe the procedures are changing 
> > at the moment. I guess we as the IESG should be aware and figure out what 
> > the right procedure actually should be here.
> >
> > > On 28. Oct 2019, at 16:31, Benjamin Kaduk  wrote:
> > >
> > > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote:
> > >> Yeh, it's very common for authors to try to tell IANA how to 
> > >> handle registrations, and I often push back on that as inappropriate.
> > >> There are certainly special conditions that IANA should be told 
> > >> about, but this is standard work-flow management stuff that ought 
> > >> to be left to IANA.  I do think it should be cha

Re: [Ace] Éric Vyncke's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Mike Jones]

Thanks for your review, Éric.  The "iss" claim is now explained on first use at 
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-10#section-3 
(paralleling the treatment of the first use of the "sub" claim).

Thanks again,
-- Mike

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: Wednesday, October 30, 2019 6:46 AM
To: The IESG 
Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace-cha...@ietf.org; 
r...@cert.org; ace@ietf.org
Subject: Éric Vyncke's No Objection on 
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-ace-cwt-proof-of-possession-09: 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.htmldata=02%7C01%7CMichael.Jones%40microsoft.com%7Cac997d452a7b4e78a10408d75d3f6f7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080399363452091sdata=jEXnivuGKVwaa0Yq%2FxDxF4PF4hQGRiU96rA%2Bv5jfAME%3Dreserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-cwt-proof-of-possession%2Fdata=02%7C01%7CMichael.Jones%40microsoft.com%7Cac997d452a7b4e78a10408d75d3f6f7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080399363452091sdata=VeFFk%2BcqykLKnsynNFWQgS9ERD28gGD%2Ba7chtRh0CYo%3Dreserved=0



--
COMMENT:
--

Thank you for the work put into this document. The document is easy to read. I 
only one nit in section 3 and feel free to ignore all of it: While "sub" is 
explained as being the "subject", nothing is written about "iss" claim on the 
first time this term is used, it is only explained the 2nd time.

For my IESG colleagues, I second Mirja's comment about adding a IANA registry 
entry based on email.

Regards,

-éric


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

Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Mike Jones]

I'm in the process of creating -10, which addresses the IESG comments other 
than Mirja's.  I'm reluctant to change the registration instructions, as they 
are currently identical to those for CWTs (and many other specifications going 
back to at least RFC 6749, modulo the name of the mailing list).  That said, if 
the IESG *really* wants to change the party to appeal to in the case of 
non-action from the Designated Experts from the IESG to IANA, I'm amenable to 
also making that change tomorrow, immediately following the telechat, so we can 
send the spec on to the RFC Editor.  Let me know what you decide.

Thanks again,
-- Mike

-Original Message-
From: Barry Leiba  
Sent: Monday, October 28, 2019 2:00 PM
To: Mike Jones 
Cc: Mirja Kuehlewind ; Benjamin Kaduk ; 
Roman D. Danyliw ; ace-cha...@ietf.org; The IESG 
; ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

The issue isn't using a mailing list.  The issue is the instructions to IANA 
about how to do management and tracking, stuff that they do just fine without 
working groups trying -- will all good intentions -- to tell them how.

The fact that there are a lot of RFCs that do it just says that working groups 
do this frequently, and most ADs don't notice or don't care.  And the reality 
is that IANA will manage the registration process how they do it, accommodating 
reasonable special instructions when they can.  The point is that documents 
shouldn't be giving special instructions unless there really is something 
special needed for a particular reason.

Barry

On Mon, Oct 28, 2019 at 12:19 PM Mike Jones  wrote:
>
> The practice of using a mailing list for registration requests to enable 
> public visibility of them goes back at least to .well-known URI registrations 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5785data=02%7C01%7CMichael.Jones%40microsoft.com%7C085270914a0b42e5007908d75be9e2ea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078932422930532sdata=bwglng9A7A8OGaV4vicvLAAcd%2FqcK7Q%2Fv9cnywn8fDo%3Dreserved=0
>  by Mark Nottingham in April 2010.  OAuth 2.0 followed this practice in RFC 
> 6749, as did the JOSE specs and JWT in RFCs 7515-19.  The rest is history, as 
> they say.
>
> -- Mike
>
> -Original Message-
> From: Mirja Kuehlewind 
> Sent: Monday, October 28, 2019 8:54 AM
> To: Benjamin Kaduk 
> Cc: Barry Leiba ; Roman D. Danyliw 
> ; ace-cha...@ietf.org; The IESG ; 
> ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
> draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
>
> These are all quite recents examples, so maybe the procedures are changing at 
> the moment. I guess we as the IESG should be aware and figure out what the 
> right procedure actually should be here.
>
> > On 28. Oct 2019, at 16:31, Benjamin Kaduk  wrote:
> >
> > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote:
> >> Yeh, it's very common for authors to try to tell IANA how to handle 
> >> registrations, and I often push back on that as inappropriate.  
> >> There are certainly special conditions that IANA should be told 
> >> about, but this is standard work-flow management stuff that ought 
> >> to be left to IANA.  I do think it should be changed before this is 
> >> published, probably just removing that last sentence.
> >
> > While I'm not opposed to normalizing on a default procedure, I think 
> > the authors were just trying to follow existing examples.
> >
> > RFC 7519:
> >
> >   Values are registered on a Specification Required [RFC5226] basis
> >   after a three-week review period on the jwt-reg-rev...@ietf.org
> >   mailing list, on the advice of one or more Designated Experts.
> >   However, to allow for the allocation of values prior to publication,
> >   the Designated Experts may approve registration once they are
> >   satisfied that such a specification will be published.
> >
> >   Registration requests sent to the mailing list for review should use
> >   an appropriate subject (e.g., "Request to register claim: example").
> >
> >   Within the review period, the Designated Experts will either approve
> >   or deny the registration request, communicating this decision to the
> >   review list and IANA.  Denials should include an explanation and, if
> >   applicable, suggestions as to how to make the request successful.
> >   Registration requests that are undetermined for a period longer th

Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Mike Jones]

The practice of using a mailing list for registration requests to enable public 
visibility of them goes back at least to .well-known URI registrations 
https://tools.ietf.org/html/rfc5785 by Mark Nottingham in April 2010.  OAuth 
2.0 followed this practice in RFC 6749, as did the JOSE specs and JWT in RFCs 
7515-19.  The rest is history, as they say.

-- Mike

-Original Message-
From: Mirja Kuehlewind  
Sent: Monday, October 28, 2019 8:54 AM
To: Benjamin Kaduk 
Cc: Barry Leiba ; Roman D. Danyliw ; 
ace-cha...@ietf.org; The IESG ; ace@ietf.org; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

These are all quite recents examples, so maybe the procedures are changing at 
the moment. I guess we as the IESG should be aware and figure out what the 
right procedure actually should be here.

> On 28. Oct 2019, at 16:31, Benjamin Kaduk  wrote:
> 
> On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote:
>> Yeh, it's very common for authors to try to tell IANA how to handle 
>> registrations, and I often push back on that as inappropriate.  There 
>> are certainly special conditions that IANA should be told about, but 
>> this is standard work-flow management stuff that ought to be left to 
>> IANA.  I do think it should be changed before this is published, 
>> probably just removing that last sentence.
> 
> While I'm not opposed to normalizing on a default procedure, I think 
> the authors were just trying to follow existing examples.
> 
> RFC 7519:
> 
>   Values are registered on a Specification Required [RFC5226] basis
>   after a three-week review period on the jwt-reg-rev...@ietf.org
>   mailing list, on the advice of one or more Designated Experts.
>   However, to allow for the allocation of values prior to publication,
>   the Designated Experts may approve registration once they are
>   satisfied that such a specification will be published.
> 
>   Registration requests sent to the mailing list for review should use
>   an appropriate subject (e.g., "Request to register claim: example").
> 
>   Within the review period, the Designated Experts will either approve
>   or deny the registration request, communicating this decision to the
>   review list and IANA.  Denials should include an explanation and, if
>   applicable, suggestions as to how to make the request successful.
>   Registration requests that are undetermined for a period longer than
>   21 days can be brought to the IESG's attention (using the
>   i...@ietf.org mailing list) for resolution.
> 
> RFC 8414:
> 
>   Values are registered on a Specification Required [RFC8126] basis
>   after a two-week review period on the oauth-ext-rev...@ietf.org
>   mailing list, on the advice of one or more Designated Experts.
>   However, to allow for the allocation of values prior to publication,
>   the Designated Experts may approve registration once they are
>   satisfied that such a specification will be published.
> 
>   Registration requests sent to the mailing list for review should use
>   an appropriate subject (e.g., "Request to register OAuth
>   Authorization Server Metadata: example").
> 
>   Within the review period, the Designated Experts will either approve
>   or deny the registration request, communicating this decision to the
>   review list and IANA.  Denials should include an explanation and, if
>   applicable, suggestions as to how to make the request successful.
>   Registration requests that are undetermined for a period longer than
>   21 days can be brought to the IESG's attention (using the
>   i...@ietf.org mailing list) for resolution.
> 
> RFC 8447:
> 
>   Specification Required [RFC8126] registry requests are registered
>   after a three-week review period on the 
>   mailing list, on the advice of one or more designated experts.
>   However, to allow for the allocation of values prior to publication,
>   the designated experts may approve registration once they are
>   satisfied that such a specification will be published.
> 
>   Registration requests sent to the mailing list for review SHOULD use
>   an appropriate subject (e.g., "Request to register value in TLS bar
>   registry").
> 
>   Within the review period, the designated experts will either approve
>   or deny the registration request, communicating this decision to the
>   review list and IANA.  Denials SHOULD include an explanation and, if
>   applicable, suggestions as to how to make the request successful.
>   Registration requests that are undetermined for a period longer than
>   21 days can be brought to the IESG's attention (using the
>mailing list) for resolution.
> 
> [I stopped looking here]
> 
> So if we're going to change things around, maybe we should issue an 
> IESG statement.
> 
> -Ben
> 
> 

___
Ace mailing list
Ace@ietf.org

[Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing Gen-ART and SecDir reviews

[Mike Jones]

A new version of the Proof-of-Possession Key Semantics for CBOR Web Tokens 
(CWTs) specification has been published addressing the Gen-ART and SecDir 
review comments.  Thanks to Christer Holmberg and Yoav Nir, respectively, for 
these useful reviews.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09

An HTML-formatted version is also available at:

  *   
http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-09.html

   -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=2016 and as 
@selfissued.

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

Re: [Ace] Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08

[Mike Jones]

Hi Yoav,

https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09 has been 
published, which addresses your review comments in the ways proposed below.  
Thanks again for your review!

   -- Mike

From: Mike Jones
Sent: Wednesday, October 16, 2019 1:21 PM
To: Yoav Nir ; sec...@ietf.org
Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; i...@ietf.org; 
ace@ietf.org
Subject: RE: Secdir last call review of 
draft-ietf-ace-cwt-proof-of-possession-08


Thanks a lot for your review, Yoav.  Replies are inline, prefixed by “Mike>”…



-Original Message-
From: Yoav Nir via Datatracker mailto:nore...@ietf.org>>
Sent: Sunday, October 6, 2019 11:52 AM
To: sec...@ietf.org<mailto:sec...@ietf.org>
Cc: 
draft-ietf-ace-cwt-proof-of-possession@ietf.org<mailto:draft-ietf-ace-cwt-proof-of-possession@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; ace@ietf.org<mailto:ace@ietf.org>
Subject: Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08



Reviewer: Yoav Nir

Review result: Has Nits



I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written primarily for the benefit of the security area directors.

Document editors and WG chairs should treat these comments just like any other 
last call comments.



I think the document shows that security aspects have been considered and 
handled well. However, the document has issues with clarity and readability:



For starters, the Abstract and Introduction are nearly identical. The 
Introduction could instead be used to explain the domain, who the "players" are 
and what they are trying to accomplish. Instead, section 2 introduces the terms 
Issuer, Presenter and Recipient with definitions that sound like the CA, the 
End Entity and the Relying Party from PKI, with a little OAuth terminology 
mixed in. There is no explanation about who this issuer is, and what the trust 
model is.



Mike> This document structure is intentionally parallel to RFC 7800.  In 
particular, the Terminology section is there specifically to introduce the 
players.  Yes, editorially, this could have been done in the Introduction, but 
this is the style typically used by OAuth, JOSE, COSE, and ACE specifications.  
I’m reluctant to deviate from it in this particular specification unless 
there’s a compelling reason to do so.



Mike> Who the issuer is is discussed in the last paragraph of Section 3.  The 
trust model is described in the last paragraph of Section 4 (Security 
Considerations).



Mike> Therefore, unless there is a specific change that you want to suggest, I 
propose to leave the Introduction and Terminology sections as is.



The Security Considerations section also has some problems.  Quoting the second

paragraph:

   Applications utilizing proof of possession SHOULD also utilize

   audience restriction, as described in Section 3.1.3 of [CWT], as it

   provides additional protections.  Audience restriction can be used by

   recipients to reject messages intended for different recipients.



Why? Why is the aud claim needed with a cnf claim (but not in other cases)?

Neither this document nor RFC 8392 provides insight as to when aud is 
appropriate. That they allow recipients to reject messages not intended for 
them does not sound like a security feature.



Mike> Having an audience in a token is a security feature, as it prevents a 
legitimate token intended for one recipient from being replayed to gain access 
at a different recipient.  You’re right that this is useful/required in many 
situations even when “cnf” isn’t being used.  However, reviewers of drafts of 
what became RFC 7800 wanted this text added to remind people that audience 
restriction is often useful even when you have proof of possession, as it 
defends against different threats.



Mike> To make this clearer, I propose to add this parenthetical remark at the 
end of this paragraph: “(Of course, applications not using proof of possession 
can also benefit from using audience restriction to reject messages intended 
for different recipients.)”  If you’d prefer different wording, please let me 
know what it is.



Paragraph 3 says: "A recipient might not understand the "cnf" claim."   This

re-affirms that we need an explanation of who the parties to this protocol are.

We generally don't send messages to recipients that don't understand them. Is 
this a closed system with known entities, or is this a protocol where the 
parties contact random other parties on the Internet?



Mike> Per my response to the Genart review, we’re already proposing to delete 
this paragraph, as it’s not actionable.  Note that the requirement to ignore 
not-understood claims comes from Section 3 of RFC 8392 (which also was 
inherited from 

Re: [Ace] Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08

[Mike Jones]

Hi Christer,

https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09 has been 
published, which addresses your review comments in the ways proposed below.  
Thanks again for your review!

   -- Mike

From: Mike Jones
Sent: Wednesday, October 16, 2019 12:40 PM
To: Christer Holmberg ; gen-...@ietf.org
Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; i...@ietf.org; 
ace@ietf.org
Subject: RE: Genart last call review of 
draft-ietf-ace-cwt-proof-of-possession-08


Thanks for your review, Christer.  Replies are inline, prefixed by "Mike>"…



-Original Message-
From: Christer Holmberg via Datatracker 
mailto:nore...@ietf.org>>
Sent: Friday, October 4, 2019 10:44 AM
To: gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: 
draft-ietf-ace-cwt-proof-of-possession@ietf.org<mailto:draft-ietf-ace-cwt-proof-of-possession@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>; ace@ietf.org<mailto:ace@ietf.org>
Subject: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08



Reviewer: Christer Holmberg

Review result: Ready with Issues



I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaqdata=02%7C01%7CMichael.Jones%40microsoft.com%7C4ffc136d2e014bc995db08d748f27b79%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637058078607739810sdata=Lusqkbg276AKiI%2Fd5MNEMGYKLcP3y%2FfrHP5L1u6UqYw%3Dreserved=0>.



Document: draft-ietf-ace-cwt-proof-of-possession-08

Reviewer: Christer Holmberg

Review Date: 2019-10-04

IETF LC End Date: 2019-10-09

IESG Telechat date: Not scheduled for a telechat



Summary: For most part the document is ready, but I have a few editorial 
comments and an issue.



Major issues: N/A



Minor issues:



The text says in the Security Considerations that one must ensure that the 
might not understand the "cnf" claim, and that applications must ensure that 
receivers support it.



Q1: How are you going to ensure that, and why do you have to ensure that? RFC

8392 doesn't even seem to require that one must ensure that the receivers 
support CWT.



Mike> I agree that this text isn't actually actionable.  I propose that we 
simply delete it.



Q2: For receivers that do support CWT, RFC 8392 says that unsupported claims 
must be discarded. If that can't be applied for "cnf" I think you need to 
explain why.



Mike> The RFC 8392 requirement does apply.  This is also aligned with the text 
in 3.1, so I don't think there are any changes needed to the spec for this.



Nits/editorial comments:



Q_ED_1: Please use [RFC8392] instead of [CWT] when referencing to RFC 8392.



Mike> OK – will do.



Q_ED_2: Shall CBOR be enhanced on first occurrence (in the Abstract or 
Introduction), or is it on the list of well-known abbreviations?



Mike> I’d be glad to expand it to enhance readability.



Q_ED_3: Add a reference for CBOR map on first occurrence.



(I was looking in RFC 7049, and while it mentions maps in many places I could 
not find a proper definition for "CBOR map")



Mike> Sure.  I can add a reference to Section 2.1 of RFC 7049.


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

Re: [Ace] Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08

[Mike Jones]

Thanks a lot for your review, Yoav.  Replies are inline, prefixed by “Mike>”…



-Original Message-
From: Yoav Nir via Datatracker 
Sent: Sunday, October 6, 2019 11:52 AM
To: sec...@ietf.org
Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; i...@ietf.org; 
ace@ietf.org
Subject: Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08



Reviewer: Yoav Nir

Review result: Has Nits



I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written primarily for the benefit of the security area directors.

Document editors and WG chairs should treat these comments just like any other 
last call comments.



I think the document shows that security aspects have been considered and 
handled well. However, the document has issues with clarity and readability:



For starters, the Abstract and Introduction are nearly identical. The 
Introduction could instead be used to explain the domain, who the "players" are 
and what they are trying to accomplish. Instead, section 2 introduces the terms 
Issuer, Presenter and Recipient with definitions that sound like the CA, the 
End Entity and the Relying Party from PKI, with a little OAuth terminology 
mixed in. There is no explanation about who this issuer is, and what the trust 
model is.



Mike> This document structure is intentionally parallel to RFC 7800.  In 
particular, the Terminology section is there specifically to introduce the 
players.  Yes, editorially, this could have been done in the Introduction, but 
this is the style typically used by OAuth, JOSE, COSE, and ACE specifications.  
I’m reluctant to deviate from it in this particular specification unless 
there’s a compelling reason to do so.



Mike> Who the issuer is is discussed in the last paragraph of Section 3.  The 
trust model is described in the last paragraph of Section 4 (Security 
Considerations).



Mike> Therefore, unless there is a specific change that you want to suggest, I 
propose to leave the Introduction and Terminology sections as is.



The Security Considerations section also has some problems.  Quoting the second

paragraph:

   Applications utilizing proof of possession SHOULD also utilize

   audience restriction, as described in Section 3.1.3 of [CWT], as it

   provides additional protections.  Audience restriction can be used by

   recipients to reject messages intended for different recipients.



Why? Why is the aud claim needed with a cnf claim (but not in other cases)?

Neither this document nor RFC 8392 provides insight as to when aud is 
appropriate. That they allow recipients to reject messages not intended for 
them does not sound like a security feature.



Mike> Having an audience in a token is a security feature, as it prevents a 
legitimate token intended for one recipient from being replayed to gain access 
at a different recipient.  You’re right that this is useful/required in many 
situations even when “cnf” isn’t being used.  However, reviewers of drafts of 
what became RFC 7800 wanted this text added to remind people that audience 
restriction is often useful even when you have proof of possession, as it 
defends against different threats.



Mike> To make this clearer, I propose to add this parenthetical remark at the 
end of this paragraph: “(Of course, applications not using proof of possession 
can also benefit from using audience restriction to reject messages intended 
for different recipients.)”  If you’d prefer different wording, please let me 
know what it is.



Paragraph 3 says: "A recipient might not understand the "cnf" claim."   This

re-affirms that we need an explanation of who the parties to this protocol are.

We generally don't send messages to recipients that don't understand them. Is 
this a closed system with known entities, or is this a protocol where the 
parties contact random other parties on the Internet?



Mike> Per my response to the Genart review, we’re already proposing to delete 
this paragraph, as it’s not actionable.  Note that the requirement to ignore 
not-understood claims comes from Section 3 of RFC 8392 (which also was 
inherited from RFC 7519), and so is not unique to this specification.



Mike> The exact parties to the protocol are dependent upon the application, as 
discussed in the last paragraph of Section 4.  This specification is defining 
PoP key representations.  It’s intentionally leaving the messages conveying 
CWTs with “cnf” claims up to the applications using them.  Again, this is 
intentionally exactly parallel to RFC 7800.



I'd also lose some of the Introduction to Crypto in the second-to-last 
paragraph.



Mike> I agree that this is overly pedantic.  I propose to delete the 
parenthetical “e.g.” clause at the end, which will make it once again exactly 
parallel to the corresponding text in RFC 7800.  Let me know if you’d a 
specific further change to this paragraph.

Re: [Ace] Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08

[Mike Jones]

Thanks for your review, Christer.  Replies are inline, prefixed by "Mike>"…



-Original Message-
From: Christer Holmberg via Datatracker 
Sent: Friday, October 4, 2019 10:44 AM
To: gen-...@ietf.org
Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; i...@ietf.org; 
ace@ietf.org
Subject: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08



Reviewer: Christer Holmberg

Review result: Ready with Issues



I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



.



Document: draft-ietf-ace-cwt-proof-of-possession-08

Reviewer: Christer Holmberg

Review Date: 2019-10-04

IETF LC End Date: 2019-10-09

IESG Telechat date: Not scheduled for a telechat



Summary: For most part the document is ready, but I have a few editorial 
comments and an issue.



Major issues: N/A



Minor issues:



The text says in the Security Considerations that one must ensure that the 
might not understand the "cnf" claim, and that applications must ensure that 
receivers support it.



Q1: How are you going to ensure that, and why do you have to ensure that? RFC

8392 doesn't even seem to require that one must ensure that the receivers 
support CWT.



Mike> I agree that this text isn't actually actionable.  I propose that we 
simply delete it.



Q2: For receivers that do support CWT, RFC 8392 says that unsupported claims 
must be discarded. If that can't be applied for "cnf" I think you need to 
explain why.



Mike> The RFC 8392 requirement does apply.  This is also aligned with the text 
in 3.1, so I don't think there are any changes needed to the spec for this.



Nits/editorial comments:



Q_ED_1: Please use [RFC8392] instead of [CWT] when referencing to RFC 8392.



Mike> OK – will do.



Q_ED_2: Shall CBOR be enhanced on first occurrence (in the Abstract or 
Introduction), or is it on the list of well-known abbreviations?



Mike> I’d be glad to expand it to enhance readability.



Q_ED_3: Add a reference for CBOR map on first occurrence.



(I was looking in RFC 7049, and while it mentions maps in many places I could 
not find a proper definition for "CBOR map")



Mike> Sure.  I can add a reference to Section 2.1 of RFC 7049.


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

[Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing remaining Area Director comments

[Mike Jones]

A new version of the Proof-of-Possession Key Semantics for CBOR Web Tokens 
(CWTs) specification has been published to address the remaining Area Director 
review comments by Benjamin Kaduk. Thanks to Ludwig Seitz for doing the bulk of 
the editing for this version.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-08

An HTML-formatted version is also available at:

  *   
http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-08.html

   -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=2010 and 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] New Version Notification - draft-ietf-ace-cwt-proof-of-possession-07.txt

[Mike Jones]

On Ben's (2): "The only things that were removed that I wanted to check if we 
should think about keeping was the note that the same key might be referred to 
by different key IDs in messages directed to different recipients.  What do 
people think about that?"  I'm fine restoring that text.

Could you also do that, Ludwig?

Thanks all,
-- Mike

-Original Message-
From: Ludwig Seitz  
Sent: Wednesday, September 25, 2019 2:34 AM
To: Mike Jones ; Samuel Erdtman 

Cc: Benjamin Kaduk ; 
draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
Subject: Re: New Version Notification - 
draft-ietf-ace-cwt-proof-of-possession-07.txt

On 25/09/2019 10:13, Mike Jones wrote:
> Does one of you have the time to create a PR today making the two 
> changes?  I’ll then be able to review it and publish sometime in the 
> next 24 hours.  Or if not, I’ll plan to do it myself while flying back 
> from Korea to the US tomorrow.
> 
>     Thanks all,
> 
>     -- Mike
> 
> *From:* Samuel Erdtman 
> *Sent:* Wednesday, September 25, 2019 12:18 AM
> *To:* Ludwig Seitz 
> *Cc:* Mike Jones ; Benjamin Kaduk 
> ; draft-ietf-ace-cwt-proof-of-possession@ietf.org; 
> ace@ietf.org
> *Subject:* Re: New Version Notification - 
> draft-ietf-ace-cwt-proof-of-possession-07.txt
> 
> +1
> 
> On Wed, Sep 25, 2019 at 8:31 AM Ludwig Seitz  <mailto:ludwig.se...@ri.se>> wrote:
> 
> On 25/09/2019 02:23, Mike Jones wrote:
>  > I'm fine with us making both of the proposed changes.
>  >
>  >                               Thanks,
>  >                               -- Mike
>  >
> 
> +1
> 
> -- 
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
> 


I'm in the process of doing the PR, but I noticed that I can only 
address Ben's (1) and (3).

For (2) Ben was asking for our opinion.

I think we could take the note about different key IDs referring to the 
same key and reintroduce it in the text as it is a useful reminder.

(I mean that chunk:
" Note that the value of a Key ID is not always the same for different 
parties. When sending a COSE encrypted message with a shared key,
the Key ID may be different on both sides of the conversation,
with the appropriate one being included in the message based on the 
recipient of the message.")



/Ludwig


-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

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

Re: [Ace] New Version Notification - draft-ietf-ace-cwt-proof-of-possession-07.txt

[Mike Jones]

Does one of you have the time to create a PR today making the two changes?  
I’ll then be able to review it and publish sometime in the next 24 hours.  Or 
if not, I’ll plan to do it myself while flying back from Korea to the US 
tomorrow.

   Thanks all,
   -- Mike

From: Samuel Erdtman 
Sent: Wednesday, September 25, 2019 12:18 AM
To: Ludwig Seitz 
Cc: Mike Jones ; Benjamin Kaduk ; 
draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
Subject: Re: New Version Notification - 
draft-ietf-ace-cwt-proof-of-possession-07.txt

+1

On Wed, Sep 25, 2019 at 8:31 AM Ludwig Seitz 
mailto:ludwig.se...@ri.se>> wrote:
On 25/09/2019 02:23, Mike Jones wrote:
> I'm fine with us making both of the proposed changes.
>
>   Thanks,
>   -- Mike
>

+1

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] New Version Notification - draft-ietf-ace-cwt-proof-of-possession-07.txt

[Mike Jones]

I'm fine with us making both of the proposed changes.

Thanks,
-- Mike

-Original Message-
From: Benjamin Kaduk  
Sent: Tuesday, September 24, 2019 4:35 PM
To: draft-ietf-ace-cwt-proof-of-possession@ietf.org
Cc: ace@ietf.org
Subject: Re: New Version Notification - 
draft-ietf-ace-cwt-proof-of-possession-07.txt

On Tue, Sep 24, 2019 at 04:33:18PM -0700, Benjamin Kaduk wrote:
> Hi all,
> 
> Thanks for the updates; they look good!
> 
> Before I kick off the IETF LC, I just have two things I wanted to 
> double-check (we may not need a new rev before the LC):
> 
> (1) In Section 3.2 (Representation of an Asymmetric 
> Proof-of-Possession Key), the last paragraph is a somewhat different 
> from the main content, in that it mentions using "COSE_Key" for an 
> encrypted symmetric key, analogous to the last paragraph of Section 
> 3.2 of RFC 7800.  I had wanted to see some additional discussion, but 
> we agreed that this was analogous to RFC 7800 and we did not need to 
> go "out of parity" with it on this point.  So we should be able to go 
> ahead without new text here, but did we want to explicitly refer back 
> to that portion of RFC 7800 to make the connection clear?
> 
> (2) In 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fcwt-cnf%2Fi-d%2Fpull%2F27%2Ffilesdata=02%7C01%7CMichael.
> Jones%40microsoft.com%7C3db4c9b38e6a4b2a13e408d74147db9e%7C72f988bf86f
> 141af91ab2d7cd011db47%7C1%7C1%7C637049649201375862sdata=vAL0NqVzv
> sqDAt5JYv0HdtUomFc5ldKJQtla3dtL%2BuM%3Dreserved=0 we removed a large 
> chunk of text since it contained several things that are inaccurate.  The 
> only things that were removed that I wanted to check if we should think about 
> keeping was the note that the same key might be referred to by different key 
> IDs in messages directed to different recipients.  What do people think about 
> that?

Oops, and my notes were unfortunately misalgined to the terminal window
size:

(3) I think we were going to change the [JWT] reference to [CWT], in Section 4:

   Applications utilizing proof of possession SHOULD also utilize
   audience restriction, as described in Section 4.1.3 of [JWT], as it
   provides additional protections.  Audience restriction can be used by
   recipients to reject messages intended for different recipients.

That way we won't get asked to make [JWT] a normative reference.

-Ben

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

[Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing Area Director review comments

[Mike Jones]

The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification 
has been updated to address the Area Director review comments by Benjamin 
Kaduk.  Thanks to Ludwig Seitz and Hannes Tschofenig for their work on 
resolving the issues raised.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-07

An HTML-formatted version is also available at:

  *   
http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-07.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=2004 and 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

[Mike Jones]

Please see my review of the PR, Ludwig.

-Original Message-
From: Ludwig Seitz  
Sent: Sunday, August 25, 2019 11:40 PM
To: Benjamin Kaduk 
Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06

Hi Ben,

fixed more of your comments here: https://github.com/cwt-cnf/i-d/pull/24 
(waiting for Mike to double-check and merge them).

As for those that are still open, comments are inline.

/Ludwig

On 13/08/2019 01:15, Benjamin Kaduk wrote:

>>>  The "COSE_Key" member MAY also be used for a COSE_Key representing a
>>>  symmetric key, provided that the CWT is encrypted so that the key is
>>>  not revealed to unintended parties.  The means of encrypting a CWT is
>>>  explained in [RFC8392].  If the CWT is not encrypted, the symmetric
>>>  key MUST be encrypted as described in Section 3.3.
>>>
>>> It's hard for me to escape the conclusion that this paragraph needs to
>>> be a dedicated section with a bit more discussion about how exactly this
>>> usage is performed and encoded.
>>>
>>
>> This mirrors the corresponding procedure in RFC 7800. Would it be OK to
>> just refer to that document
>> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)?
> 
> (Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in
> the opposite order.)
> Well, I still wouldn't like it.  But I don't think I have grounds to block
> the document from advancing if you just refer back to JWT.
>

Göran and I have discussed this, and we agree that it is indeed 
underspecified (e.g. which key is used to encrypt this "inner" 
COSE_Encrypt0 contained in the cnf element?). Additionally I can 
personally confirm that this is a headache to implement (and I haven't 
even touched a constrained implementation).

We see two alternatives here:

1.) Remove the possibility to have a separate encrypted cnf element. 
Instead mandate that the whole CWT should be encrypted if it contains a 
secret key.

+ make spec easier (to implement) and doesn't requires a long 
specification on how to handle this case

- breaks direct equivalence with RFC 7800

2.) Add some dedicated section that explains how the key for this inner 
encrypted cnf element is selected and communicated to the RS.

+ The draft remains functionally equivalent to RFC 7800

- Increased draft complexity at questionable gain
- Possible implementer headaches, especially on constrained devices

There is an issue about this here:
https://github.com/cwt-cnf/i-d/issues/19


>>>  The following example CWT Claims Set of a CWT (using CBOR diagnostic
>>>  notation, with linebreaks for readability) illustrates the use of an
>>>  encrypted symmetric key as the "Encrypted_COSE_Key" member value:
>>>
>>> {
>>>  /iss/ 1 : "coaps://server.example.com",
>>>  /sub/ 2 : "24400320",
>>>  /aud/ 3: "s6BhdRkqt3",
>>>  /exp/ 4 : 1311281970,
>>>  /iat/ 5 : 1311280970,
>>>  /cnf/ 8 : {
>>>  /COSE_Encrypt0/ 2 : [
>>>
>>> Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
>>>
>>> [I did not validate the COSE_Encrypt0 output]
>>>
>>
>> COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key
>> is not. We'd have to define it or write an explanatory comment.
> 
> Maybe I'm confused about how the diagnostic notation works, but the
> top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matches
> iss/sub/aud/etc. in the preceding notation.  If the rules are different for
> map keys whose corresponding values are themselves structured data types,
> then I should just unconfuse myself and we can move on with things...
> 
>

Issue created here https://github.com/cwt-cnf/i-d/issues/20
Will fix.


>>
>>>  o  A recipient can decide not to use a CWT based on a created Key ID
>>> if it does not fit the recipient's requirements.
>>>
>>> I'm not sure I understand the semantics being described here.  Are we
>>> saying that the issuer might give a presenter a CWT, and by the time the
>>> presenter presents the CWT to the recipient, the recipient says "this is
>>> no good" and denies the transaction in question, forcing the presenter
>>> to go back to the issuer and try again?  (How do we know that the issuer
>>> would make any different choices the second time around?)
>>
>> This risk always exists. In a constrained device world, the recipient
>> may already have cleared out the key referenced by the key ID, which
>> would force it to reject a CWT using this as proof-of-possession.
>>
>> I'm not sure how to give good guidance in this case. The error message
>> delivered by the recipient rejecting the CWT might be helpful I suppose.
>> Do you think this merits some text?
> 
> It's not entirely clear to me that we need to add more text here, but if we
> did, it would focus on what "decide not to use" means at a protocol level,
> and perhaps how the CWT might not "fit the recipient's requirements" (e.g.,
> the key id 

[Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec fixing nits

[Mike Jones]

The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification 
has been updated to address issues identified by Roman Danyliw while writing 
his shepherd review.  Thanks to Samuel Erdtman for fixing an incorrect example.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-06

An HTML-formatted version is also available at:

  *   
http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-06.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1949 and 
@selfissued.

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

[Ace] CWT equivalent of JWT.io

[Mike Jones]

Does anyone know of an online tool that will decode CWTs like https://jwt.io/ 
does for JWTs?

   Thanks,
   -- Mike

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

Re: [Ace] Syntax check of examples in draft-ietf-ace-cwt-proof-of-possession-05

[Mike Jones]

Thanks - we'll address that as well.

-- Mike

-Original Message-
From: Ace  On Behalf Of Roman Danyliw
Sent: Friday, November 30, 2018 11:10 AM
To: ace@ietf.org
Subject: [Ace] Syntax check of examples in 
draft-ietf-ace-cwt-proof-of-possession-05

Hello!

As part of my shepherd review, I ran all of the examples in 
draft-ietf-ace-cwt-proof-of-possession-05 through a CBOR diagnostic-to-CBOR 
validator (thanks Carsten for cbor.me).  All of the examples were fine but the 
first one in Section 3.3:

--[current text]--
 {
  /kty/ 1 : /Symmetric/ 4,
  /alg/ 3 : /HMAC256/ 5,
  /k/ -1 : h'6684523ab17337f173500e5728c628547cb37df
 e68449c65f885d1b73b49eae1A0B0C0D0E0F10'
 }
--[end]--

The error was:

Expected one of [ \t\n\r], "/", [0-9a-fA-F] at line 5, column 56 (byte 184) 
after { /kty/ 1 : /Symmetric/ 4, /alg/ 3 : /HMAC256/ 5, /k/ -1 : 
h'6684523ab17337f173500e5728c628547cb37df e68449c65f885d1b73b49eae1A0B0C0D0E0F10

It appears that the string of hex encoded octets in /k/ is short one character.

Roman 

___
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] Idnits on draft-ietf-ace-cwt-proof-of-possession-05

[Mike Jones]

Will do...

-Original Message-
From: Ace  On Behalf Of Roman Danyliw
Sent: Friday, November 30, 2018 8:50 AM
To: ace@ietf.org
Subject: [Ace] Idnits on draft-ietf-ace-cwt-proof-of-possession-05

Hi!

As part of the shepherd review, I ran idnits on 
draft-ietf-ace-cwt-proof-of-possession-05.  The following nits were found.  
Could these please be fixed in a revised draft.

--[ snip ]--  

  Checking nits according to https://www.ietf.org/id-info/checklist :
  

  ** There is 1 instance of too long lines in the document, the longest one
 being 1 character in excess of 72.

Checking references for intended status: Proposed Standard
  

  ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)

  == Outdated reference: A later version (-17) exists of
 draft-ietf-ace-oauth-authz-16

  -- Obsolete informational reference (is this intentional?): RFC 7159
 (Obsoleted by RFC 8259)


 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).

--[ snip ]--

The line which exceeds 72 characters is in Section 3.4.  Specifically:

 /protected header / h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,

Regards,
Roman

___
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] IPR Conformance check for draft-ietf-ace-cwt-proof-of-possession

[Mike Jones]

Likewise, I am not aware of any IPR that pertains to this specification.

-- Mike

From: Ace  on behalf of Göran Selander 

Sent: Friday, November 30, 2018 8:50:24 AM
To: Roman Danyliw; ace@ietf.org
Subject: Re: [Ace] IPR Conformance check for 
draft-ietf-ace-cwt-proof-of-possession


Correction!

I am NOT aware of any IPR related to this draft.


(Thanks Roman for spotting the unfortunate missing words !)

Göran

> 30 nov. 2018 kl. 16:42 skrev Göran Selander :
>
>
> I aware of any IPR related to this draft.
>
> BR
> Göran
>
> On 2018-11-27, 15:44, "Ace on behalf of Roman Danyliw"  on behalf of r...@cert.org> wrote:
>
>Hello draft-ietf-ace-cwt-proof-of-possession authors,
>(Hi Mike, Ludwig, Goeran, Samuel and Hannes,)
>
>As the shepherd for draft-ietf-ace-cwt-proof-of-possession, I'd like to 
> confirm with the authors that all IPR disclosures have occurred per RFC6702:
>
>--[ shepherd questions ]--
>
>(7) Has each author confirmed that any and all appropriate IPR disclosures 
> required for full conformance with the provisions of BCP 78 and BCP 79 have 
> already been filed. If not, explain why?
>
>--[end question]--
>
>Can you please respond to the list answering this question (e.g., "As a 
> co-author, I don't hold any IPR nor am I aware of any related to this draft").
>
>Thanks,
>Roman
>
>___
>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 mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec adding Key ID considerations

[Mike Jones]

Key ID confirmation method considerations suggested by Jim Schaad have been 
added to the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) 
specification.  Per discussions in the working group meeting in Bangkok, it's 
now time for the shepherd review.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-05

An HTML-formatted version is also available at:

  *   
http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-05.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1938 and 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession

[Mike Jones]

Jim - am I right that the text you were suggesting be added to the "kid" 
treatment is that in the thread "[Ace] Text for KID in POP" which introduces 
the text in 
https://mailarchive.ietf.org/arch/msg/ace/v_Ci7kRMC0poffGmrSNYb5-sjrA and 
corrects it in 
https://mailarchive.ietf.org/arch/msg/ace/garcXUmWNHmEgZNS7FKT-AYBgMI?

I'll look at it again now...

   Thanks,
   -- Mike

From: Jim Schaad 
Sent: Thursday, November 8, 2018 11:30 AM
To: Mike Jones ; 'Roman Danyliw' ; 
ace@ietf.org
Subject: RE: Summarizing WGLC discussion of 
draft-ietf-ace-cwt-proof-of-possession

I do not believe that the big comment that I have left has been addressed.

From: Mike Jones 
mailto:michael.jo...@microsoft.com>>
Sent: Tuesday, November 6, 2018 3:43 PM
To: Roman Danyliw mailto:r...@cert.org>>; 
ace@ietf.org<mailto:ace@ietf.org>
Cc: Jim Schaad mailto:i...@augustcellars.com>>
Subject: RE: Summarizing WGLC discussion of 
draft-ietf-ace-cwt-proof-of-possession


Thanks for the useful summary, Roman.  Replies are inline below prefixed by 
"Mike>".  I've just published draft 
-04<https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-04>, 
which contains the small number of changes described below.  I believe that 
this completes resolution of the WGLC feedback.



-Original Message-
From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Roman Danyliw
Sent: Friday, July 13, 2018 12:56 AM
To: ace@ietf.org<mailto:ace@ietf.org>
Subject: [Ace] Summarizing WGLC discussion of 
draft-ietf-ace-cwt-proof-of-possession



Hello!



This email is intended to summarize the outcome of the WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02 to date.  This call was started on 
May 8 [1] and discussion occurred around two reviews of this -02 draft:



** Jim Schaad [Schaad], per 
https://www.ietf.org/mail-archive/web/ace/current/msg02747.html

** Roman Danyliw [Danyliw], per 
https://www.ietf.org/mail-archive/web/ace/current/msg02793.html



After discussion on the mailing list, -03 of the draft was produced.



Synthesizing the robust mailing list discussion, I see the following previously 
identified issues as still needing closure.  The nature of the resolution 
varies.  Given the volume of the discussion threads, I may have missed a 
response or failed to line up a text change in -03 to an issue.  Please correct 
the status of any given point of feedback below.



==[ -03 contains changes, but ML discussion doesn't indicate closure ]== The 
following feedback was made about the -02 draft; changes to the relevant text 
was made in -03; but follow-up discussions on the mailing list doesn't indicate 
closure of the issue.  If the originator of the feedback (it looks like only 
Jim for this section) feels the issue is closed, please speak up.



[Schaad #6]  Under what circumstances would a 'sub' claim be present and it is 
not the presenter?  I can see that a holder of the key may be implicitly (or 
anonymously)  named, but putting something in the subject field which is not 
identifying the presenter is something that I would reject without a good 
presentation of why in the  document.



Mike> The draft is written as it is to both provide non-normative guidance for 
expected simple use cases, while also allowing flexibility for more complicated 
use cases.  In particular, in some profiles, the subject of the CWT and the 
presenter of the CWT for proof-of-possession purposes may be different parties. 
 The party presenting the CWT to the recipient would be in possession of the 
CWT because it communicated with the issuer but the subject can be different 
than the presenter.  That's why the subject language is written as a suggestion 
to profile writers, rather than normatively.  I'll note that this also aligned 
with the treatment in RFC 7800, which this draft mirrors, by design.



Jim> I am not going to fight this, but this type of behavior is what makes it 
really hard to try and do any sort of formal proofs with CWTs.  One cannot 
model that the confirmation key is associated with a specific identity since 
that identity could be in any one of 3 different fields or implicit and one 
cannot know which of those is the correct one in the generic case.



[Schaad #7]  I would disagree with the claim that if the 'sub' claim is missing 
then it would normally be the issuer.  For the world of IoT, I would expect 
that the subject would not be present because there is no need to identify the 
subject to the recipient.  I.e. it is an anonymous subject.



Mike> As with the previous issue, this section of the draft provides 
non-normative guidance for expected simple use cases, while not precluding 
profiling specifications from using the standard CWT claims in the manner that 
makes sense for their application.  The "iss" langua

Re: [Ace] Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession

[Mike Jones]

FYI - I wrote about this new version at http://self-issued.info/?p=1933 and as 
@selfissued<https://twitter.com/selfissued>.

   -- Mike

From: Ace  On Behalf Of Mike Jones
Sent: Tuesday, November 6, 2018 3:43 PM
To: Roman Danyliw ; ace@ietf.org
Cc: Jim Schaad 
Subject: Re: [Ace] Summarizing WGLC discussion of 
draft-ietf-ace-cwt-proof-of-possession


Thanks for the useful summary, Roman.  Replies are inline below prefixed by 
"Mike>".  I've just published draft 
-04<https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-04>, 
which contains the small number of changes described below.  I believe that 
this completes resolution of the WGLC feedback.



-Original Message-
From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Roman Danyliw
Sent: Friday, July 13, 2018 12:56 AM
To: ace@ietf.org<mailto:ace@ietf.org>
Subject: [Ace] Summarizing WGLC discussion of 
draft-ietf-ace-cwt-proof-of-possession



Hello!



This email is intended to summarize the outcome of the WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02 to date.  This call was started on 
May 8 [1] and discussion occurred around two reviews of this -02 draft:



** Jim Schaad [Schaad], per 
https://www.ietf.org/mail-archive/web/ace/current/msg02747.html

** Roman Danyliw [Danyliw], per 
https://www.ietf.org/mail-archive/web/ace/current/msg02793.html



After discussion on the mailing list, -03 of the draft was produced.



Synthesizing the robust mailing list discussion, I see the following previously 
identified issues as still needing closure.  The nature of the resolution 
varies.  Given the volume of the discussion threads, I may have missed a 
response or failed to line up a text change in -03 to an issue.  Please correct 
the status of any given point of feedback below.



==[ -03 contains changes, but ML discussion doesn't indicate closure ]== The 
following feedback was made about the -02 draft; changes to the relevant text 
was made in -03; but follow-up discussions on the mailing list doesn't indicate 
closure of the issue.  If the originator of the feedback (it looks like only 
Jim for this section) feels the issue is closed, please speak up.



[Schaad #6]  Under what circumstances would a 'sub' claim be present and it is 
not the presenter?  I can see that a holder of the key may be implicitly (or 
anonymously)  named, but putting something in the subject field which is not 
identifying the presenter is something that I would reject without a good 
presentation of why in the  document.



Mike> The draft is written as it is to both provide non-normative guidance for 
expected simple use cases, while also allowing flexibility for more complicated 
use cases.  In particular, in some profiles, the subject of the CWT and the 
presenter of the CWT for proof-of-possession purposes may be different parties. 
 The party presenting the CWT to the recipient would be in possession of the 
CWT because it communicated with the issuer but the subject can be different 
than the presenter.  That's why the subject language is written as a suggestion 
to profile writers, rather than normatively.  I'll note that this also aligned 
with the treatment in RFC 7800, which this draft mirrors, by design.



[Schaad #7]  I would disagree with the claim that if the 'sub' claim is missing 
then it would normally be the issuer.  For the world of IoT, I would expect 
that the subject would not be present because there is no need to identify the 
subject to the recipient.  I.e. it is an anonymous subject.



Mike> As with the previous issue, this section of the draft provides 
non-normative guidance for expected simple use cases, while not precluding 
profiling specifications from using the standard CWT claims in the manner that 
makes sense for their application.  The "iss" language here also intentionally 
parallels the RFC 7800 treatment of this claim.



[Schaad #8]  It is not clear to me that either of the sub and iss claims would 
normally be present.  They might be present but neither is needed.  The subject 
can be anonymous and the issuer is identified by the key used to validate the 
security on the CWT.



Mike> Your points above align with the design in the draft.  That's why both 
"iss" and "sub" are optional.  Their usage is profile-dependent, as it is in 
RFC 7800 (and CWT and JWT).



[Schaad #9]  In section 3.1 the first two sentences appear to be contradictory. 
 Members are used to identify the POP key.  Other things than a POP key can be 
used than a POP key.  If they are used to identify the POP key- why would they 
not deal with the POP key?  I think that you should do a separation and define 
the 'cnf' file which can hold any number of confirmation methods and then have 
a section on defining some POP cnf method field holders.



Mike> The apparently contradictory language in draft -02 was re

Re: [Ace] Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession

[Mike Jones]

Thanks for the useful summary, Roman.  Replies are inline below prefixed by 
"Mike>".  I've just published draft 
-04, 
which contains the small number of changes described below.  I believe that 
this completes resolution of the WGLC feedback.



-Original Message-
From: Ace  On Behalf Of Roman Danyliw
Sent: Friday, July 13, 2018 12:56 AM
To: ace@ietf.org
Subject: [Ace] Summarizing WGLC discussion of 
draft-ietf-ace-cwt-proof-of-possession



Hello!



This email is intended to summarize the outcome of the WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02 to date.  This call was started on 
May 8 [1] and discussion occurred around two reviews of this -02 draft:



** Jim Schaad [Schaad], per 
https://www.ietf.org/mail-archive/web/ace/current/msg02747.html

** Roman Danyliw [Danyliw], per 
https://www.ietf.org/mail-archive/web/ace/current/msg02793.html



After discussion on the mailing list, -03 of the draft was produced.



Synthesizing the robust mailing list discussion, I see the following previously 
identified issues as still needing closure.  The nature of the resolution 
varies.  Given the volume of the discussion threads, I may have missed a 
response or failed to line up a text change in -03 to an issue.  Please correct 
the status of any given point of feedback below.



==[ -03 contains changes, but ML discussion doesn't indicate closure ]== The 
following feedback was made about the -02 draft; changes to the relevant text 
was made in -03; but follow-up discussions on the mailing list doesn't indicate 
closure of the issue.  If the originator of the feedback (it looks like only 
Jim for this section) feels the issue is closed, please speak up.



[Schaad #6]  Under what circumstances would a 'sub' claim be present and it is 
not the presenter?  I can see that a holder of the key may be implicitly (or 
anonymously)  named, but putting something in the subject field which is not 
identifying the presenter is something that I would reject without a good 
presentation of why in the  document.



Mike> The draft is written as it is to both provide non-normative guidance for 
expected simple use cases, while also allowing flexibility for more complicated 
use cases.  In particular, in some profiles, the subject of the CWT and the 
presenter of the CWT for proof-of-possession purposes may be different parties. 
 The party presenting the CWT to the recipient would be in possession of the 
CWT because it communicated with the issuer but the subject can be different 
than the presenter.  That's why the subject language is written as a suggestion 
to profile writers, rather than normatively.  I'll note that this also aligned 
with the treatment in RFC 7800, which this draft mirrors, by design.



[Schaad #7]  I would disagree with the claim that if the 'sub' claim is missing 
then it would normally be the issuer.  For the world of IoT, I would expect 
that the subject would not be present because there is no need to identify the 
subject to the recipient.  I.e. it is an anonymous subject.



Mike> As with the previous issue, this section of the draft provides 
non-normative guidance for expected simple use cases, while not precluding 
profiling specifications from using the standard CWT claims in the manner that 
makes sense for their application.  The "iss" language here also intentionally 
parallels the RFC 7800 treatment of this claim.



[Schaad #8]  It is not clear to me that either of the sub and iss claims would 
normally be present.  They might be present but neither is needed.  The subject 
can be anonymous and the issuer is identified by the key used to validate the 
security on the CWT.



Mike> Your points above align with the design in the draft.  That's why both 
"iss" and "sub" are optional.  Their usage is profile-dependent, as it is in 
RFC 7800 (and CWT and JWT).



[Schaad #9]  In section 3.1 the first two sentences appear to be contradictory. 
 Members are used to identify the POP key.  Other things than a POP key can be 
used than a POP key.  If they are used to identify the POP key- why would they 
not deal with the POP key?  I think that you should do a separation and define 
the 'cnf' file which can hold any number of confirmation methods and then have 
a section on defining some POP cnf method field holders.



Mike> The apparently contradictory language in draft -02 was reworded in draft 
-03 to address this comment.  In particular, it now explicitly states that the 
"cnf" claim is used to carry confirmation methods, some of which identify 
proof-of-possession keys.  This aligns both with RFC 7800 and the SAML 2.0 
SubjectConfirmation element design (both by intentionally, since there's no 
need to reinvent the wheel when an existing design already works well).



[Schaad #10]  In section 3.1 P1 - I am not sure why you have something here 
about confirming the authenticity of the token as oppose to 

Re: [Ace] WGLC for draft-ietf-ace-authz

[Mike Jones]

This sounds like a good solution, Ludwig.  Thanks for the productive 
conversation.

-- Mike

-Original Message-
From: Ludwig Seitz  
Sent: Wednesday, October 31, 2018 2:08 AM
To: Mike Jones ; ace@ietf.org
Subject: Re: [Ace] WGLC for draft-ietf-ace-authz

On 30/10/2018 19:52, Mike Jones wrote:
> Thanks for your responses, Ludwig.
> 

>
>  I could live with "access_token" having a single-byte representation, 
> since as you point out, it is needed for every ACE OAuth interaction.  
> An "error" value is only needed when something goes wrong, so that 
> doesn't seem like a case that needs to be optimized for space.  A 
> two-byte "error" representation will only be used when errors have 
> occurred, so shouldn't be a problem.
> 
> -- Mike
> 
> -Original Message- From: Ace  On Behalf


Thank you for the quick and comprehensive answer Mike!

I conclude the following:

We are in agreement about giving "profile", "error", "token_type" and 
"grant_type" two-byte abbreviations in CBOR.

"scope" and "access_token" will get a one-byte abbreviation aligned with the 
unused numbers from CWT claims.

At IETF 103 I will propose the solution of registering all parameter 
abbreviations in the CWT claim registry in order to align abbreviations and 
avoid duplicate assignments.

If a signed request (and response) format is needed I am all for using CWT in 
the context of ACE access token requests, responses and introspection requests 
and responses. I will take up that discussion at IETF 103.

I will propose to make "token_type" and "grant_type" OPTIONAL, deviating from 
the OAuth 2.0 specs and defining the default token type to be "PoP" 
and the default grant_type to be "client_credentials".
This will avoid having to send grant_type with every access token request and 
token_type with every successful access token response.


Regards,

Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC for draft-ietf-ace-oauth-params

[Mike Jones]

3.1, 3.2, and 4.1, parameter definitions: None of these parameter definitions 
specify the syntax of the parameters defined, making understanding these quite 
confusing.  Yes, this is talked about later in the doc but there are not even 
forward references to where the definitions are completed in most cases.  
Please fully specify the parameters when they are defined.



3.1 req_aud: Doesn't this duplicate the "resource" parameter defined by 
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?  If so, 
please delete this parameter.  If not, say how it is different and why the 
differences are necessary.



5 cnf in the introspection response: Which token is being referred to by the 
phrase "bound to the token".  The access token?  The refresh token?  Another 
kind of token?  Please make this more specific.



6 CBOR Mappings.  The table contains the magic numbers 8, 17, 18, and 19.  
>From what space are these numbers being allocated and what registry are they 
in?  Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth 
parameters should all be registered in the CWT Claims registry because of the 
possibility of them being used in signed requests in a manner analogous to 
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17.  The parameters need to 
be registered to avoid claim number conflicts.



Missing Examples:  The best thing you could do to help developers understand 
what these values are and how they use them is to add examples, just as was 
done in RFC 7800.  Please add examples of each of the parameters using the JSON 
representations of them.  Optionally, also add CBOR examples if you believe 
that they will convey important information to developers that the JSON 
example's don't.



  Thank you,

  -- Mike



-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Monday, October 8, 2018 2:35 PM
To: ace@ietf.org
Subject: [Ace] WGLC for draft-ietf-ace-oauth-params



The chairs believe that the set of documents dealing with the OAuth framework 
for constrained environments is nearing the point that we should

be able to advance it to the IESG for publication.   We therefore want to

have a full list of issues that need to be dealt with at the Bangkok meeting.



This starts a 2 week WGLC for draft-ietf-ace-oauth-params



We know that the following issues are outstanding:



draft-ietf-ace-oauth-params:

*  No current known issues





Jim & Roman







___

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] PoP Key Distribution

[Mike Jones]

I've replied on the OAuth mailing list.  You can join it at 
https://www.ietf.org/mailman/listinfo/oauth to participate in the discussion.

From: Ace  On Behalf Of Hannes Tschofenig
Sent: Tuesday, July 3, 2018 12:47 PM
To: ace@ietf.org
Subject: [Ace] FW: PoP Key Distribution

Note that I posted a mail to the OAuth list about the PoP key distribution, 
which also relates to the work on ACE-OAuth.
If you are interested in this topic please feel free to join the discussion on 
the OAuth mailing list.

From: Hannes Tschofenig
Sent: 03 July 2018 21:46
To: oa...@ietf.org
Subject: PoP Key Distribution

Hi all,

we have been working on an update for the draft-ietf-oauth-pop-key-distribution 
document in time for the deadline but we noticed several issues that are 
worthwhile to bring to your attention.

draft-ietf-oauth-pop-key-distribution defines a mechanism that allows the 
client to talk to the AS to request a PoP access token and associated keying 
material.

There are two other groups in the IETF where this concept is used.


  *   The guys working on RTCWEB is the first. Misi (Mészáros Mihály) has been 
helping us to understand their needs. They have defined their own token format, 
which has been posted on the OAuth group a while ago for review.


  *   The other group is ACE with their work on an OAuth-based profile for IoT.

Where should the parameters needed for PoP key distribution should be defined? 
Currently, they are defined in two places -- in 
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in 
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03. In 
particular, the audience and the token_type parameters are defined in both 
specs.

IMHO it appears that OAuth would be the best place to define the HTTP-based 
parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, and 
alike. Of course, this is subject for discussion, particularly if there is no 
interest in doing so in the OAuth working group.

There is also a misalignment in terms of the content.. 
draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which does 
not exist in the draft-ietf-ace-oauth-authz document. The 
draft-ietf-ace-oauth-authz document does, however, have a profile parameter, 
which does not exist in draft-ietf-oauth-pop-key-distribution. Some alignment 
is therefore needed. In the meanwhile the work on OAuth meta has been finalized 
and could potentially be re-used.

When the work on draft-ietf-oauth-pop-key-distribution was initially started 
there was only a single, standardized token format, namely the JWT. Hence, it 
appeared reasonable to use the JWT keying structure for delivering keying 
material from the AS to the client.

In the meanwhile two other formats have been standardized, namely RFC 7635 and 
the CWT. For use with those specs it appears less ideal to transport keys from 
the AS to the client using the JSON/JOSE-based format. It would be more 
appropriate to use whatever PoP token format is used instead. Currently, this 
hasn't been considered yet.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

Thanks, Ludwig.  Note that last paragraph of the new Operational Considerations 
section at 
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03#section-6 
addresses this issue.  In particular, the last sentence of the section talks 
about the need to keep keys used in different contexts separate if there is 
otherwise any chance of confusion.

I'll also note that for the constrained environments that ACE is addressing, I 
expect that deployments with exactly one PoP key to be predominant use case.  
In this use case, such confusion is impossible in the first place.

-- Mike

-Original Message-
From: Ace  On Behalf Of Ludwig Seitz
Sent: Tuesday, July 3, 2018 2:33 AM
To: 'ace' 
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

On 2018-07-03 11:31, Ludwig Seitz wrote:

> 
> 6. Client B gets 2 from AS bound via the cnf claim to KID="A"
> 
This should of course read:

Client B gets T2 from AS ...


/Ludwig

-- 
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] Montreal IETF Agenda

[Mike Jones]

I'd like 15 minutes to discuss draft-ietf-ace-cwt-proof-of-possession.

Thanks,
-- Mike

-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Monday, June 25, 2018 4:36 AM
To: ace@ietf.org
Subject: [Ace] Montreal IETF Agenda

If you want a spot on the agenda please let the chairs know.

Please include topic/draft, presenter and a time request.

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] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

The sentence I sent was in addition to Hannes language to address the multiple 
CWT case discussed in the thread - not a replacement for it.

-- Mike

-Original Message-
From: Jim Schaad  
Sent: Saturday, June 23, 2018 9:05 AM
To: Mike Jones ; Hannes Tschofenig 
; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: RE: Key IDs ... RE: [Ace] WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

No not really, Hannes's language is much closer to what I am looking for.  I 
don't care if they are different kinds of CWTs.  I care about impersonation.

> -Original Message-
> From: Mike Jones 
> Sent: Friday, June 22, 2018 10:44 PM
> To: Jim Schaad ; Hannes Tschofenig 
> ; draft-ietf-ace-cwt-proof-of- 
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: Key IDs ... RE: [Ace] WGLC on 
> draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> I think you're looking for language something along these lines, right
Jim?
> 
> "Likewise, if PoP keys are used for multiple different kinds of CWTs 
> in an application and the PoP keys are identified by Key IDs, care 
> must be taken
to
> keep the keys for the different kinds of CWTs segregated so that an
attacker
> cannot cause the wrong PoP key to be used by using a valid Key ID for 
> the wrong kind of CWT."
> 
>   -- Mike
> 
> -Original Message-
> From: Jim Schaad 
> Sent: Friday, June 22, 2018 7:59 AM
> To: Hannes Tschofenig ; Mike Jones 
> ; draft-ietf-ace-cwt-proof-of- 
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: Key IDs ... RE: [Ace] WGLC on 
> draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> That language works if you assume that there is only one CWT that an 
> RS
will
> look to.  If there are multiple CWTs then one needs coordination 
> language between them.
> 
> > -Original Message-
> > From: Hannes Tschofenig 
> > Sent: Friday, June 22, 2018 6:36 AM
> > To: Jim Schaad ; 'Mike Jones'
> > ; draft-ietf-ace-cwt-proof-of- 
> > possess...@ietf.org
> > Cc: ace@ietf.org
> > Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Hi Jim,
> >
> > I would like to comment on this issue.
> >
> > -
> > > > 14.  I have real problems w/ the use of a KID for POP 
> > > > identification.  It
> > may
> > > identify the wrong key or, if used for granting access, may have 
> > > problems
> > w/
> > > identity collisions.  These need to be spelt out someplace to help 
> > > people tracking down questions of why can't I verify w/ this CWT, 
> > > I know it's
> > right.
> > >
> > > The Key ID is a hint to help identify which PoP key to use.  Yes, 
> > > if a Key
> > ID is
> > > sent that doesn't correspond to the right PoP key, failures may occur.
> > > I
> > view
> > > that as usage bug - not a protocol problem.  If keys aren't 
> > > consistently
> > known
> > > and identified by both parties, there are lots of things that can 
> > > go
> > wrong, and
> > > this is only one such instance.  That said, I can try to say 
> > > something
> > about the
> > > need for keys to be consistently and known by both parties, if you 
> > > think
> > that
> > > would help.
> >
> > > My problem is that if there are two different people with the same 
> > > Key ID,
> > either intentionally or unintentionally, then using the key ID to 
> > identify
> the
> > key may allow the other person to masquerade as the first person.  I 
> > am unworried about the instance of a failure to get a key based on a 
> > key
id.
> > That is not the problem you are proposing to address.
> >
> > -
> >
> > I think we should document this issue. Here is some text proposal 
> > that
> could
> > go into a separate operational consideration section (or into the 
> > security consideration section instead).
> >
> > "
> > - Operational Considerations
> >
> > The use of CWTs with proof-of-possession keys requires additional 
> > information to be shared between the involved parties in order to 
> > ensure correct processing. The recipient needs to be able to use 
> > credentials to
> verify
> > the authenticity, integrity and potentially the confidentiality of 
> > the CWT
> and
> > its content. This requires the recipient to know information about 
> > the
> issuer.
> > Like-wise there needs to be an upfron

Re: [Ace] Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

I agree with this proposed update and will apply it to the editor's draft.

-Original Message-
From: Ace  On Behalf Of Hannes Tschofenig
Sent: Friday, June 22, 2018 6:36 AM
To: Roman Danyliw ; ace@ietf.org
Subject: [Ace] Replay ... RE: WGLC feedback on 
draft-ietf-ace-cwt-proof-of-possession-02

Hi Roman,

Thanks for your review.

As I was re-reading the reviews I spotted this comment:

>  (14) (Editorial)  Page 8, Section 4, Per "Replay can also be avoided if a 
> sub-key is derived from a shared secret that is specific to the instance of 
> the PoP demonstration."  PoP is spelled out everywhere else in this draft but 
> here.  Yes, the acronym is defined, but for readability, I recommend against 
> it using it and consistently spelling it out here too.

I believe the current text is a bit confusing. Here is what it says:

Proof of possession via encrypted symmetric secrets is subject to replay 
attacks.
This attack can, for example, be avoided when a signed nonce or challenge is 
used since the recipient can use a distinct nonce or challenge for each 
interaction.
Replay can also be avoided if a sub-key is derived from a shared secret that is 
specific to the instance of the proof-of-possession demonstration.

This somehow gives the impression that replay attacks are only a concern for 
symmetric key techniques.
Of course, this is not true. Furthermore, the text gives the impression that 
this attack is actually something that can be covered within the CWT-PoP token 
spec itself. This is also not the case.

For this reason I am suggesting to change the paragraph to:
"
CBOR Web Tokens with proof-of-possession keys are used in context of an 
architecture, such as ACE-OAuth [REF], where protocols are used by a presenter 
to request these tokens and to subsequently use them with recipients. To avoid 
replay attacks when the proof-of-possession tokens are sent to presenters a 
security protocol, which uses nonces or timestamps, has to be utilized.
Note that a discussion of the architecture or specific protocols CWT 
proof-of-possession tokens are used with are outside the scope of this 
specification. "

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
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] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

See my note just now proposing this text to Jim:

"Likewise, if PoP keys are used for multiple different kinds of CWTs in an 
application and the PoP keys are identified by Key IDs, care must be taken to 
keep the keys for the different kinds of CWTs segregated so that an attacker 
cannot cause the wrong PoP key to be used by using a valid Key ID for the wrong 
kind of CWT."

As long as the PoP keys for different contexts are kept segregated, Key ID 
collisions or reuse cause no problems.

-- Mike

-Original Message-
From: Benjamin Kaduk  
Sent: Friday, June 22, 2018 1:44 PM
To: Hannes Tschofenig 
Cc: Jim Schaad ; Mike Jones 
; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

On Fri, Jun 22, 2018 at 01:36:16PM +, Hannes Tschofenig wrote:
> Hi Jim,
> 
> 
> > My problem is that if there are two different people with the same 
> > Key ID,
> either intentionally or unintentionally, then using the key ID to 
> identify the key may allow the other person to masquerade as the first 
> person.  I am unworried about the instance of a failure to get a key based on 
> a key id.
> That is not the problem you are proposing to address.
> 
> -
> 
> I think we should document this issue. Here is some text proposal that 
> could go into a separate operational consideration section (or into the 
> security consideration section instead).
> 
> "
> - Operational Considerations
> 
> The use of CWTs with proof-of-possession keys requires additional 
> information to be shared between the involved parties in order to 
> ensure correct processing. The recipient needs to be able to use 
> credentials to verify the authenticity, integrity and potentially the 
> confidentiality of the CWT and its content. This requires the recipient to 
> know information about the issuer.
> Like-wise there needs to be an upfront agreement between the issuer 
> and the recipient about the claims that need to be present and what degree of 
> trust can be put into those.
> 
> When an issuer creates a CWT containing a key id claim, it needs to 
> make sure that it does not issue another CWT containing the same key 
> id with a different content, or for a different subject, within the 
> lifetime of the CWTs, unless intentionally desired. Failure to do so may 
> allow one party to impersonate another party with the potential to gain 
> additional privileges.
> "

When would this be "intentionally desired"?  It seems like there would be 
better ways to share authorization between parties than to issue such duplicate 
CWTs.

-Ben

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

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

I think you're looking for language something along these lines, right Jim?

"Likewise, if PoP keys are used for multiple different kinds of CWTs in an 
application and the PoP keys are identified by Key IDs, care must be taken to 
keep the keys for the different kinds of CWTs segregated so that an attacker 
cannot cause the wrong PoP key to be used by using a valid Key ID for the wrong 
kind of CWT."

-- Mike

-Original Message-
From: Jim Schaad  
Sent: Friday, June 22, 2018 7:59 AM
To: Hannes Tschofenig ; Mike Jones 
; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: RE: Key IDs ... RE: [Ace] WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

That language works if you assume that there is only one CWT that an RS will 
look to.  If there are multiple CWTs then one needs coordination language 
between them.

> -Original Message-
> From: Hannes Tschofenig 
> Sent: Friday, June 22, 2018 6:36 AM
> To: Jim Schaad ; 'Mike Jones'
> ; draft-ietf-ace-cwt-proof-of- 
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> I would like to comment on this issue.
> 
> -
> > > 14.  I have real problems w/ the use of a KID for POP 
> > > identification.  It
> may
> > identify the wrong key or, if used for granting access, may have 
> > problems
> w/
> > identity collisions.  These need to be spelt out someplace to help 
> > people tracking down questions of why can't I verify w/ this CWT, I 
> > know it's
> right.
> >
> > The Key ID is a hint to help identify which PoP key to use.  Yes, if 
> > a Key
> ID is
> > sent that doesn't correspond to the right PoP key, failures may occur.
> > I
> view
> > that as usage bug - not a protocol problem.  If keys aren't 
> > consistently
> known
> > and identified by both parties, there are lots of things that can go
> wrong, and
> > this is only one such instance.  That said, I can try to say 
> > something
> about the
> > need for keys to be consistently and known by both parties, if you 
> > think
> that
> > would help.
> 
> > My problem is that if there are two different people with the same 
> > Key ID,
> either intentionally or unintentionally, then using the key ID to 
> identify
the
> key may allow the other person to masquerade as the first person.  I 
> am unworried about the instance of a failure to get a key based on a key id.
> That is not the problem you are proposing to address.
> 
> -
> 
> I think we should document this issue. Here is some text proposal that
could
> go into a separate operational consideration section (or into the 
> security consideration section instead).
> 
> "
> - Operational Considerations
> 
> The use of CWTs with proof-of-possession keys requires additional 
> information to be shared between the involved parties in order to 
> ensure correct processing. The recipient needs to be able to use 
> credentials to
verify
> the authenticity, integrity and potentially the confidentiality of the 
> CWT
and
> its content. This requires the recipient to know information about the
issuer.
> Like-wise there needs to be an upfront agreement between the issuer 
> and the recipient about the claims that need to be present and what 
> degree of trust can be put into those.
> 
> When an issuer creates a CWT containing a key id claim, it needs to 
> make sure that it does not issue another CWT containing the same key 
> id with a different content, or for a different subject, within the 
> lifetime of the
CWTs,
> unless intentionally desired. Failure to do so may allow one party to 
> impersonate another party with the potential to gain additional
privileges.
> "
> 
> 
> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents 
> to
any
> other person, use it for any purpose, or store or copy the information 
> in
any
> medium. Thank you.

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

Re: [Ace] CWT-PoP & Multiple PoP keys

[Mike Jones]

Good.  Having resolved this, I believe we should be in position to do a release 
addressing the WGLC comments this week.

-- Mike

-Original Message-
From: Ace  On Behalf Of Ludwig Seitz
Sent: Wednesday, June 20, 2018 12:14 AM
To: ace@ietf.org
Subject: Re: [Ace] CWT-PoP & Multiple PoP keys

On 2018-06-20 08:57, Hannes Tschofenig wrote:
> Hi Jim,
> 
> I had a chat with Mike about relaxing the CWT-PoP spec to allow 
> multiple PoP keys in a single CWT token.
> 
> He is concerned about the departure from RFC 7800 and, after giving it 
> a bit more thoughts, I believe there is an issue. Initially, when we 
> started the work our promise was that this is really just an 
> alternative encoding of RFC 7800. With changes like those we are 
> obviously breaking that concept. Having multiple keys within a single 
> CWT is a corner case and I am not sure anymore whether I indeed want 
> to go into that direction. In our implementation we are also not using 
> multiple keys in a single CWT either.
> 
> Ciao
> 
> Hannes
>

I agree that having multiple PoP keys in cnf for CWT-PoP seem like overkill. 
After all this is a draft aimed at constrained environments.
I also sympathize with Mike's suggestion to keep CWT-PoP aligned with RFC 7800.

/Ludwig


> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended

Sending confidential email to a public mailing list again Hannes? You are a 
rebel ;-)


-- 
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] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

The proposed change to allow multiple PoP keys in a single "cnf" element 
introduces unnecessary syntactic and semantic ambiguity. It also breaks the 
semantic equivalence with RFC 7800. Hannes, you're right that there's not 
consensus to do this.


Please see my review of your pull request at

https://github.com/cwt-cnf/i-d/pull/13/files/b81205b292acb393592f2e803a47670e46928c73.


Thanks,

-- Mike


From: Hannes Tschofenig 
Sent: Monday, June 18, 2018 5:02:32 AM
To: Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: RE: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02

Hi Jim,

I have made changes to the draft based on your review and the updated version 
of the document can be found at https://github.com/cwt-cnf/i-d/pull/13
However, I am not sure we have consensus on the changes.

Ciao
Hannes

-Original Message-
From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: 17 June 2018 01:03
To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: RE: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02

We have seen a number of messages on this document, but we have not yet seen
an updated draft that addresses all of these issues.  When should we expect
a new version.  It would have been nice to have had two published before
Montreal but that does not seem likely at this point.

Jim


> -Original Message-
> From: Ace  On Behalf Of Roman Danyliw
> Sent: Wednesday, May 16, 2018 6:18 AM
> To: ace@ietf.org
> Subject: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-
> 02
>
> Hello!
>
> A reminder to the WG, draft-ietf-ace-cwt-proof-of-possession is in WGLC.
> Please send feedback to the mailing list by Wednesday, May 23.
>
> Thanks,
> Roman and Jim
>
> > -Original Message-
> > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Roman Danyliw
> > Sent: Tuesday, May 08, 2018 6:19 PM
> > To: ace@ietf.org
> > Subject: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> >
> > Hello!
> >
> > Consistent with the feedback from the editor team at the London
> > meeting, we are starting a working group last call (WGLC) for the
> > "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)" draft:
> >
> > ** draft-ietf-ace-cwt-proof-of-possession-02
> > **
> > https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02
> >
> > Please send comments to the mailing list -- feedback on issues or
> > needed changes; as well as endorsements that this draft is ready.
> >
> > This WGLC will end on Wednesday, May 23, 2018.
> >
> > Thanks,
> > Roman 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

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Mike Jones]

Thanks for your useful comments, Jim.  Replies are inline below.

-Original Message-
From: Jim Schaad  
Sent: Wednesday, May 9, 2018 6:51 AM
To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

I'll pull out the list of comments that I wrote a month ago but didn't start 
that computer up recently.

1.  Are all of the authors necessary?  As a chair I need to justify a count of 
more than 5 to the IESG.

The authors are the union of the set of authors of 
draft-jones-ace-cwt-proof-of-possession-00 and draft-ietf-ace-oauth-authz-04, 
which both contained independently developed and largely parallel treatments of 
the CWT PoP confirmation subject.  Ludwig was the primary author of this text 
in the second, so he should definitely be retained as an editor.  I'll leave it 
up to the other authors of draft-ietf-ace-oauth-authz-04 to self-identify 
whether they materially contributed to the CWT PoP confirmation text or not.  
Maybe we can delete those who don't self-identify as contributors.

2.  Is the last sentence in section 1 necessary?  Are you actually defining any 
strings that could be case-sensitive?

Sure - we can delete the text "Unless otherwise noted, all the protocol 
parameter names and values are case sensitive."  It's a holdover from RFC 7800 
that doesn't apply here.

3.  Terminology: In the definition of Issuer please make 'its' clearer.  It is 
not clear whose claims are being bound.

We can change "its claims" to "the claims in the CWT".

4.  Terminology: I still think this is 'Presenter' is a very strange term to 
use for this definition.  I would really like to see it be made something that 
makes sense and then say the term is the same as this in JWT.  The term has a 
model of use with it that I do not believe can be sustained even for the ACE 
Oauth case but really not in other cases.

This is the standard term for this role in the industry.  For instance, Section 
1.2 (Terminology) of "SAML V2.0 Holder-of-Key Assertion Profile Version 1.0" 
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key-cd-01.pdf
 defines "Presenter" with an equivalent meaning.

Also, for this reason, this is the same terminology used for this role in RFC 
7800.  It is used pervasively throughout both this document and RFC 7800 - 
including in the diagrams in the introduction of RFC 7800.  I believe we would 
be doing a disservice to readers and implementers if we were to use a different 
term from that in RFC 7800 (and SAML) when the meaning is identical.

5.  Terminology: Recipient matches presenter, and it matches the OAuth model
and not a trust model world.   Relying party or service provider make far
more sense to me.

Same response as to 4.  We owe it to readers and implementers to keep the 
terminology consistent with RFC 7800 and industry practice.

6.  Under what circumstances would a 'sub' claim be present and it is not the 
presenter?  I can see that a holder of the key may be implicitly (or
anonymously) named, but putting something in the subject field which is not 
identifying the presenter is something that I would reject without a good 
presentation of why in the document.

Just as in https://tools.ietf.org/html/draft-ietf-secevent-token-13 (which is 
in the hands of the RFC Editor), it's dependent upon the profiling 
specification how the "sub" claim is used.  In some cases the subject and/or 
presenter will be identified with some combination of "iss" and/or "sub".  In 
other profiles, different representations will be appropriate, such as the use 
of the "subject_type" value in the RISC example in 
https://tools.ietf.org/html/draft-ietf-secevent-token-13#section-2.1.4.

Remember that in both JWT and CWT, the inclusion of *all* claims is left up to 
the profile.  The same is true of RFC 7800 and this spec (other than the use of 
the "cnf" claim).  We shouldn't tie the hands of profiles in a way that 
prevents them from using the representation of the presenter that is most 
natural for their use case.

7.  I would disagree with the claim that if the 'sub' claim is missing then it 
would normally be the issuer.  For the world of IoT, I would expect that the 
subject would not be present because there is no need to identify the subject 
to the recipient.  I.e. it is an anonymous subject.

I'm fine adding language saying that in some use cases, such IoT use cases, 
explicit identification of the presenter may not be necessary because in some 
cases, the recipient already implicitly has this information.  And I can drop 
the "normally" language about "iss" and instead tone it down to talk about "in 
some use cases".

8.  It is not clear to me that either of the sub and iss claims would normally 
be present.  They might be present but neither is needed.  The subject can be 
anonymous and the issuer is identified by the key used to validate the security 
on the CWT.

[Ace] “CBOR Web Token (CWT)” is now RFC 8392

[Mike Jones]

The “CBOR Web Token (CWT)” specification is now RFC 
8392 - an IETF standard.  The 
abstract for the specification is:

CBOR Web Token (CWT) is a compact means of representing claims to be 
transferred between two parties.  The claims in a CWT are encoded in the 
Concise Binary Object Representation (CBOR) and CBOR Object Signing and 
Encryption (COSE) is used for added application-layer security protection.  A 
claim is a piece of information asserted about a subject and is represented as 
a name/value pair consisting of a claim name and a claim value.  CWT is derived 
from JSON Web Token (JWT) but uses CBOR rather than JSON.

Special thanks to Erik Wahlström for 
starting this work and to Samuel Erdtman for 
doing most of the heavy lifting involved in creating correct and useful 
CBOR and 
COSE examples.

Next up – finishing “Proof-of-Possession Key Semantics for CBOR Web Tokens 
(CWTs)”, 
which provides the CWT equivalent of “Proof-of-Possession Key Semantics for 
JSON Web Tokens (JWTs)” [RFC 7800].

-- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1844 and as 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] OAuth-Authz Interop

[Mike Jones]

Before any interop work is done, I suggest that it would be better to first 
address the significant CBOR number assignment issues I pointed out in my 
review on October 10, 2017 
https://www.ietf.org/mail-archive/web/ace/current/msg02364.html, so that the 
interop is more likely to occur using number assignments that are less likely 
to change.  I'm repeating the most important of these comments below, since it 
was apparently not acted upon.


5.5.5 Mapping parameters to CBOR
It looks to me like these values are intended to align with those registered in 
the CBOR Web Token (CWT) Claims registry initially populated by 
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#section-9.1.2.  If 
so, the spec should make this relationship explicit.  However, it would be 
inappropriate to use the rare single-byte CBOR integer values for 
application-specific claim keys.  I would suggest that the claim identifiers 
for client_id through refresh_token and profile start at 256 (a two-byte CBOR 
value) and go up from there.  In that case, I suspect they could be 
successfully registered in the CWT Claims registry – which I think you want.  
(“cnf” will already be registered by draft-ietf-ace-cwt-proof-of-possession.)



Likewise, please search the review for all instances of the words “register” 
and “registry” and revised the spec accordingly before any interop work is 
started.



-- Mike





-Original Message-
From: Ace  On Behalf Of Ludwig Seitz
Sent: Tuesday, May 8, 2018 3:54 AM
To: ace@ietf.org
Subject: Re: [Ace] OAuth-Authz Interop



On 2018-05-08 08:57, Ludwig Seitz wrote:

> On 2018-05-07 18:44, Jim Schaad wrote:

>> I have been meaning to get this out for a while and have failed.  A

>> doodle poll to setup an interop event for this work is at

>> https://doodle.com/poll/k27g9r26bghvnytu If you want to participate

>> and none of the times are good please let me know.

>>

>> Things for testing:

>> 1)  DTLS profile w/ shared secret

>> 2)  DTLS profile w/ RPK

>> 3)  OSCORE profile

>>

>>

>

> Note that I'm in the process of writing a test manual, I'll put it up

> on the WG github as soon as it has some form and structure. Feel free

> to contribute. I'm hoping to have it online by the end of the day.

>

> /Ludwig

>

>



You can find my first draft of the interop manual here:



https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt



Note that large parts are still work in progress, but the test plan for the 
token endpoint should give you a hint as to how I was thinking it could work.



Feel free to propose changes and improvements.





/Ludwig



--

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 for draft-ietf-ace-cwt-proof-of-possession?

[Mike Jones]

Dear ACE chairs,

I never heard back on this.  Given that CWT is in AUTH48 as RFC-to-be 8392, I 
believe it's time to start WGLC on draft-ietf-ace-cwt-proof-of-possession.

   Thanks,
   -- Mike

From: Mike Jones
Sent: Wednesday, May 2, 2018 2:45 PM
To: Jim Schaad <i...@augustcellars.com>; Roman Danyliw <r...@cert.org>
Cc: Ludwig Seitz <lud...@sics.se>; goran.selan...@ericsson.com; 
e...@wahlstromstekniska.se; Samuel Erdtman <sam...@erdtman.se>; Hannes 
Tschofenig <hannes.tschofe...@arm.com>; Benjamin Kaduk <ka...@mit.edu>
Subject: WGLC for draft-ietf-ace-cwt-proof-of-possession?

The ACE minutes from London 
https://datatracker.ietf.org/meeting/101/materials/minutes-101-ace-00 record 
that the editors thought that draft-ietf-ace-cwt-proof-of-possession was ready 
for working group last call.  I haven't seen any further discussion of the 
draft on the mailing list since then, making me think that the working group 
agrees with this conclusion.  Especially given that 
draft-ietf-ace-cbor-web-token is in the RFC Editor Queue (in the Edit state), 
it seems like it's probably time to move CWT PoP along as well.

Do the chairs agree, and if so what are the next steps?  (For that matter, if 
the chairs don't agree, what are the next steps? ;-) )

Thanks all,
-- Mike
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] CBOR Web Token (CWT) spec for the RFC Editor

[Mike Jones]

One more clarification to the CBOR Web Token (CWT) specification has been made 
to address a comment by IESG member Adam Roach.  This version is being sent to 
the RFC Editor in preparation for its publication 
as an RFC.  The change was:

  *   Added section references when the terms "NumericDate" and "StringOrURI" 
are used, as suggested by Adam Roach.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-15

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-15.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1796 and as 
@selfissued.

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

Re: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-cbor-web-token-12: (with COMMENT)

[Mike Jones]

Hi Alexey,

https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-14 should address 
your comments.  Changes motivated by your comments were:
  - Added the text "IANA must only accept registry updates from the Designated 
Experts and should direct all requests for registration to the review mailing 
list" from RFC 7519, as suggested by Amanda Baber of IANA, which is also 
intended to address Alexey Melnikov's comment.

Thanks again,
-- Mike

-Original Message-
From: Jim Schaad  
Sent: Sunday, March 4, 2018 1:12 PM
To: 'Alexey Melnikov' ; 'The IESG' 
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; ka...@mit.edu; 
ace@ietf.org
Subject: RE: Alexey Melnikov's No Objection on 
draft-ietf-ace-cbor-web-token-12: (with COMMENT)



> -Original Message-
> From: Alexey Melnikov [mailto:aamelni...@fastmail.fm]
> Sent: Sunday, March 4, 2018 1:01 PM
> To: Jim Schaad ; The IESG 
> Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; 
> ka...@mit.edu; ace@ietf.org
> Subject: Re: Alexey Melnikov's No Objection on 
> draft-ietf-ace-cbor-web-
> token-12: (with COMMENT)
> 
> On Sun, Mar 4, 2018, at 7:39 PM, Jim Schaad wrote:
> > IANA does ask for the expert review as part of the processing it 
> > does even for standards track documents.  This is because, in part, 
> > they are responsible for doing the final number assignment.  That is 
> > which number in the range is actually used.  The interesting 
> > question would be what happens if the IESG and the DEs disagree about such 
> > things.
> 
> This is exactly why I am asking about this. It might also possible to 
> game the system to ask IESG approval of a Proposed Standard that 
> bypasses Expert Review.

Interesting.  The text that IANA and I finally agreed to for the COSE Algorithm 
registry is "Standards Action With Expert Review".

That would make sure that it cannot bypass the Expert Review.

Jim

> 
> >  I would
> > expect that this would result in a long discussion with some type of 
> > final agreement between them.
> >
> > Jim
> >
> >
> > > -Original Message-
> > > From: Alexey Melnikov [mailto:aamelni...@fastmail.fm]
> > > Sent: Sunday, March 4, 2018 11:19 AM
> > > To: The IESG 
> > > Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; 
> > > ka...@mit.edu; ace@ietf.org
> > > Subject: Alexey Melnikov's No Objection on
> > > draft-ietf-ace-cbor-web-token-
> > > 12: (with COMMENT)
> > >
> > > Alexey Melnikov has entered the following ballot position for
> > > draft-ietf-ace-cbor-web-token-12: 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:
> > > --
> > > --
> > > --
> > >
> > > Just to double check: a CWT claim registration from a Proposed 
> > > Standard still needs to be submitted to the review mailing list, 
> > > but it is not really subject to Expert Review, correct? You might 
> > > want to make
> it clearer.
> >
> >

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

[Ace] CBOR Web Token (CWT) spec addressing IESG comments

[Mike Jones]

The CBOR Web Token (CWT) specification has been updated to address comments 
received from Internet Engineering Steering Group 
(IESG) members.  Changes were:

  *   Cleaned up the descriptions of the numeric ranges of claim keys being 
registered in the registration template for the "CBOR Web Token (CWT) Claims" 
registry, as suggested by Adam Roach.
  *   Clarified the relationships between the JWT and CWT "NumericDate" and 
"StringOrURI" terms, as suggested by Adam Roach.
  *   Eliminated unnecessary uses of the word "type", as suggested by Adam 
Roach.
  *   Added the text "IANA must only accept registry updates from the 
Designated Experts and should direct all requests for registration to the 
review mailing list" from RFC 7519, as suggested by Amanda Baber of IANA, which 
is also intended to address Alexey Melnikov's comment.
  *   Removed a superfluous comma, as suggested by Warren Kumari.
  *   Acknowledged additional reviewers.

Special thanks to Security Area Director Kathleen Moriarty for helping get this 
across the finish line!

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-14

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-14.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1794 and as 
@selfissued.
___
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)

[Mike Jones]

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<mailto: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<mailto:e...@rtfm.com>>
Sent: Wednesday, March 7, 2018 12:40 PM
To: The IESG <i...@ietf.org<mailto:i...@ietf.org>>
Cc: 
draft-ietf-ace-cbor-web-to...@ietf.org<mailto:draft-ietf-ace-cbor-web-to...@ietf.org>;
 ace-cha...@ietf.org<mailto:ace-cha...@ietf.org>; 
ka...@mit.edu<mailto:ka...@mit.edu>; ace@ietf.org<mailto: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)

[Mike Jones]

Hi Ekr.  Thanks for the review comments.  Responses are inline below, prefixed 
by "Mike>"...

-Original Message-
From: Eric Rescorla  
Sent: Wednesday, March 7, 2018 12:40 PM
To: The IESG 
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.

  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.

-- Mike

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

Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)

[Mike Jones]

Fair enough.  I'll work on alternate exposition for these types to avoid any 
potential confusion.

Thanks again,
-- Mike

-Original Message-
From: Adam Roach <a...@nostrum.com> 
Sent: Wednesday, March 7, 2018 10:28 PM
To: Mike Jones <michael.jo...@microsoft.com>; Benjamin Kaduk <ka...@mit.edu>
Cc: The IESG <i...@ietf.org>; draft-ietf-ace-cbor-web-to...@ietf.org; 
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: 
(with COMMENT)

On 3/7/18 11:47 PM, Mike Jones wrote:
> The point of including new CWT definitions for "StringOrURI" and 
> "NumericDate" was so that we could use them directly.  Prefixing them with 
> "CWT" isn't necessary for the meaning to be clear in context.


Given that the current formulation confused both Benjamin and me, I think this 
assertion doesn't hold up to scrutiny.

/a

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

Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)

[Mike Jones]

Thanks, Ben and Adam.  I've recoded a note to address the improvements below 
one the submission tool reopens.

For what it's worth, I independently noticed the unintended overlap between the 
Standards Action and Specification Required number ranges in a conversation 
today with IANA.

The point of including new CWT definitions for "StringOrURI" and "NumericDate" 
was so that we could use them directly.  Prefixing them with "CWT" isn't 
necessary for the meaning to be clear in context.

Thanks both for the attention to detail.

-- Mike

-Original Message-
From: Benjamin Kaduk  
Sent: Wednesday, March 7, 2018 8:24 PM
To: Adam Roach 
Cc: The IESG ; draft-ietf-ace-cbor-web-to...@ietf.org; 
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: 
(with COMMENT)

Hi Adam,

With my shepherd hat...

On Wed, Mar 07, 2018 at 04:05:32PM -0800, Adam Roach wrote:
> 
> Thanks to the WG, chairs, and
> 
> §3.1.1:
> 
> >  The "iss" (issuer) claim has the same meaning and processing rules 
> > as  the "iss" claim defined in Section 4.1.1 of [RFC7519], except 
> > that  the value is of type StringOrURI.  The Claim Key 1 is used to  
> > identify this claim.
> 
> 
> 1) Given that RFC 7159 defines "iss" to contain a "StringOrURI" value, it's
>not clear what the "except" clause is attempting to convey.

I had to ask about this as well -- the crux is that the "StringOrURI" JWT type 
is different from the CWT "StringOrURI"
type.  IIRC there used to be an extra descriptor in here but it was removed as 
redundant.

> 2) Given the many uses of the word "type" in this context (including CBOR
>types and the JWT 'typ' field), and given that RFC 7519 never refers to
>"StringOrURI" as a "type," I think that the use of the word "type" here
>is likely to lead to reader confusion.

In combination with the above, maybe we want "the value is a CWT StringOrURI 
value".  Authors?

> This comment -- or a congruent form of it involving "NumericDate" 
> rather than "StringOrURI" -- applies to §3.1.2 through §3.1.6.

(Right.)

> --
> -
> 
> §9.1:
> 
> >  Criteria that should be applied by the Designated Experts includes  
> > determining whether the proposed registration duplicates existing  
> > functionality, whether it is likely to be of general applicability 
> > or  whether it is useful only for a single application, and whether 
> > the  registration description is clear.  Registrations for the 
> > limited set  of values between -256 and 255 and strings of length 1 
> > are to be  restricted to claims with general applicability.
> 
> Use of the word "between" without qualifying it as inclusive or 
> exclusive of the endpoints is ambiguous. Suggest either "values from 
> -256 to 255" or "values between -256 and 255 inclusive".

Agreed, it should be qualified as inclusive.

> --
> -
> 
> §9.1.1:
> 
> > CBOR map key for the claim.  Different ranges of values use
> > different registration policies [RFC8126].  Integer values between
> > -256 and 255 and strings of length 1 are designated as Standards
> > Action.  Integer values from -65536 to 65535 and strings of length
> > 2 are designated as Specification Required
> 
> Same comment as above.
> 
> Also, please replace "from -65536 to 65535" with "from -65536 to -257 
> and from
> 256 to 65535".

Good catch!

Thanks,

Ben

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

Re: [Ace] Opsdir telechat review of draft-ietf-ace-cbor-web-token-12

[Mike Jones]

Thanks for taking the time to review the specification, Carlos.  You are now 
listed in the acknowledgements at 
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13#appendix-B.

-- Mike

-Original Message-
From: Carlos Martinez  
Sent: Friday, March 2, 2018 12:06 PM
To: ops-...@ietf.org
Cc: ace@ietf.org; i...@ietf.org; draft-ietf-ace-cbor-web-token@ietf.org
Subject: Opsdir telechat review of draft-ietf-ace-cbor-web-token-12

Reviewer: Carlos Martinez
Review result: Ready

Reviewer: Carlos Martínez
Review Result: Ready

I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of 
the IETF drafts. Comments that are not addressed in last call may be included 
in AD reviews during the IESG review.  Document editors and WG chairs should 
treat these comments just like any other last call comments.

I found the document easy to read. The specification is clear and examples in 
Appendix C are of real help for us who are not experts in the area.

I believe the document to be ready.

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

Re: [Ace] AD Review of draft-ietf-ace-cbor-web-token-12

[Mike Jones]

You'll find the requested change in the second paragraph of 
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13#section-9.1 and 
the Claim Key description in 
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13#section-9.1.1.

Thanks again,
-- Mike

-Original Message-
From: Ace <ace-boun...@ietf.org> On Behalf Of Mike Jones
Sent: Friday, February 16, 2018 2:21 PM
To: Kathleen Moriarty <kathleen.moriarty.i...@gmail.com>
Cc: ace@ietf.org
Subject: Re: [Ace] AD Review of draft-ietf-ace-cbor-web-token-12

Be glad to.  I'll add it to my to-do list for this draft.

-- Mike

-Original Message-
From: Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> 
Sent: Friday, February 16, 2018 1:17 PM
To: Mike Jones <michael.jo...@microsoft.com>
Cc: ace@ietf.org
Subject: Re: [Ace] AD Review of draft-ietf-ace-cbor-web-token-12

On Fri, Feb 16, 2018 at 3:46 PM, Mike Jones <michael.jo...@microsoft.com> wrote:
> This information is in the registration template at 
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-12#section-9.1.1, 
> as follows:
>

OK, could you clarify that in the IANA section with a simple pointer to the 
registration template?

This update can come with any other IETF last call comments.

Thank you!
Kathleen

>Claim Key:
>   CBOR map key for the claim.  Integer values between -256 and 255
>   and strings of length 1 are designated as Standards Track
>   Required.  Integer values from -65536 to 65535 and strings of
>   length 2 are designated as Specification Required.  Integer values
>   of greater than 65535 and strings of length greater than 2 are
>   designated as Expert Review.  Integer values less than -65536 are
>   marked as Private Use.
>
> Thanks again,
> -- Mike
>
> -Original Message-
> From: Ace <ace-boun...@ietf.org> On Behalf Of Kathleen Moriarty
> Sent: Friday, February 16, 2018 12:42 PM
> To: ace@ietf.org
> Subject: [Ace] AD Review of draft-ietf-ace-cbor-web-token-12
>
> Hello,
>
> Thanks for your work on draft-ietf-ace-cbor-web-token-12
>
> The draft looks good and I'll kick off IETF last call today, but have an 
> important question that may require clarification in the draft.
>
> In the IANA section 9.1, how does one know which document type is needed?  
> Could you add text about how one might differentiate the values to drive that 
> decision?
>
>Depending upon the values being requested, registration requests are
>evaluated on a Standards Track Required, Specification Required,
>Expert Review, or Private Use basis [RFC8126] after a three-week
>review period on the cwt-reg-rev...@ietf.org mailing list, on the
>advice of one or more Designated Experts.
>
>
> --
>
> Best regards,
> Kathleen
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace



-- 

Best regards,
Kathleen
___
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] CBOR Web Token (CWT) draft addressing IETF last call comments

[Mike Jones]

The CBOR Web Token (CWT) specification has been updated to address IETF last 
call comments received to date, including GenArt, SecDir, Area Director, and 
additional shepherd comments.  Changes were:

  *   Clarified the registration criteria applied to different ranges of Claim 
Key values, as suggested by Kathleen Moriarty and Dan Romascanu.
  *   No longer describe the syntax of CWT claims as being the same as that of 
the corresponding JWT claims, as suggested by Kyle Rose.
  *   Added guidance about the selection of the Designated Experts, as 
suggested by Benjamin Kaduk.
  *   Acknowledged additional reviewers.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-13.html

-- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1789 and as 
@selfissued.

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

Re: [Ace] Agenda Items for London

[Mike Jones]

I would like to do brief presentations on the status of these drafts:
  - draft-ietf-ace-cbor-web-token
  - draft-ietf-ace-cwt-proof-of-possession

15 minutes each should be sufficient.

Thanks,
-- Mike

-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Tuesday, February 27, 2018 4:34 PM
To: ace@ietf.org
Subject: [Ace] Agenda Items for London

Please let the chairs know if you want a slot on the agenda for London.
Please give us an idea of what you think you need to cover, how long you think 
it will take and who is doing the presentations.

For people doing the presentations, I would like to get slides during the week 
of March 12th so that the chairs can do a fast review and get them posted 
before the Monday morning meeting.  I really do not want to need to do this 
first thing Monday morning.

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] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Mike Jones]

Replies inline…

From: Ace  On Behalf Of Dan Romascanu
Sent: Tuesday, February 27, 2018 2:23 PM
To: Jim Schaad 
Cc: gen-art ; ace@ietf.org; ietf ; Benjamin 
Kaduk ; draft-ietf-ace-cbor-web-token@ietf.org
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Hi Jim,

There are still a few problems:

1. The policies and mapping to the values ranges are hidden in the Claim Key 
field in the template (the comment also made by Kathleen)

Per my earlier note, I will be making this language clearer when the next 
revision is published.

2. At least one incorrect policy name is used: Standards Track Required - do 
you mean Standards Action (?)

Thanks – I’ll update the terminology when the next draft is published.

3. You describe a process that involves a mail list 
(cwt-reg-rev...@ietf.org) and Experts Review. 
This description is not clear. Usually IANA approaches one DE for advice and 
expects the advice from the same DE in a reasonable period of time. If I 
understand correctly the process described in Section 9.1 one or more DEs make 
a recommendation and run it with the mail list. Who establishes the consensus 
on the mail list? Assuming the mail list disagrees with the DE recommendation, 
who decides?

This is the process used for the .well-known URI spec, the JSON Web Token (JWT) 
spec, the JOSE specs, many OAuth specs and it works well.  It allows interested 
parties to see and comment on registration requests.  The Designated Experts 
are still the ones to decide.  See these references for some uses of this kind 
of publicly-visible registration procedure:

https://tools.ietf.org/html/rfc5785#section-5.1 (using 
wellknown-uri-rev...@ietf.org)
https://tools.ietf.org/html/rfc6749#section-11.1 (using 
oauth-ext-rev...@ietf.org)
https://tools.ietf.org/html/rfc7515#section-9 (using 
jose-reg-rev...@ietf.org)
https://tools.ietf.org/html/rfc7800#section-6 (using 
jose-reg-rev...@ietf.org)

I can find more examples of the use of this publicly-visible registration 
procedure if you like.

Regards,
Dan

  Thanks for the 
careful review, Dan,
  -- Mike

On Tue, Feb 27, 2018 at 7:53 PM, Jim Schaad 
> wrote:
Integer values between -256 and 255 and strings of length 1 are designated as 
Standards Track Required.

Integer values from -65536 to 65535 and strings of length 2 are designated as 
Specification Required.

Integer values of greater than 65535 and strings of length greater than 2 are 
designated as Expert Review.

Integer values less than -65536 are marked as Private Use.

So that says what IANA policy is to be used for each of the different items.  
This defines the policies and the ranges for those policies.

There is not anything that is making a distinction on what the criteria to be 
used by the DE in the document which is separate, but I don’t think that is 
needed.  This is why they are DEs.

I still don’t see what you think is missing.

Jim


From: Dan Romascanu [mailto:droma...@gmail.com]
Sent: Tuesday, February 27, 2018 2:00 AM
To: Benjamin Kaduk >
Cc: Jim Schaad >; gen-art 
>; 
draft-ietf-ace-cbor-web-token@ietf.org;
 ietf >; ace@ietf.org
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Hi,
See also my other notes.
I believe that what the document tries to say is:
Register R is divided into four different ranges R1, R2, R3, R4 (defining the 
value limits may be useful)
Values in range R1 are allocated according to policy P1 in the case that ...
Values in range R2 are allocated according to policy P2 in the case that ...
Values in range R3 are allocated according to policy P3 in the case that ...
Values in range R4 are allocated according to policy P4 in the case that ...
But it doesn't say it. Mentioning four concurrent policies for the same 
registry without separation of values range, and without providing clear 
instructions when each policy is recommended to be used, seems confusing to me, 
and may be confusing for users of this document in the future.
Regards,
Dan

On Tue, Feb 27, 2018 at 5:40 AM, Benjamin Kaduk 
> wrote:
On Mon, Feb 26, 2018 at 11:19:04PM +0200, Dan Romascanu wrote:
> Hi Jim,
>
> Thank you for your answer and for addressing my comments.
>
> On item #2:
>
>
>
> On Mon, Feb 26, 2018 at 10:12 PM, 

Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Mike Jones]

I agree with Jim.  This information is in the registration template at 
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-12#section-9.1.1, as 
follows:



   Claim Key:

  CBOR map key for the claim.  Integer values between -256 and 255

  and strings of length 1 are designated as Standards Track

  Required.  Integer values from -65536 to 65535 and strings of

  length 2 are designated as Specification Required.  Integer values

  of greater than 65535 and strings of length greater than 2 are

  designated as Expert Review.  Integer values less than -65536 are

  marked as Private Use.


Note that I already took an action item based on Kathleen’s AD review to add a 
reference to this information in Section 9.1 where it talks about the different 
policies used – to avoid any possible confusion.  I will do this edit at the 
same time we address any other IETF Last Call feedback.

Cheers,
-- Mike

From: Jim Schaad 
Sent: Tuesday, February 27, 2018 9:53 AM
To: 'Dan Romascanu' ; 'Benjamin Kaduk' 
Cc: 'gen-art' ; draft-ietf-ace-cbor-web-token@ietf.org; 
'ietf' ; ace@ietf.org
Subject: RE: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Integer values between -256 and 255 and strings of length 1 are designated as 
Standards Track Required.

Integer values from -65536 to 65535 and strings of length 2 are designated as 
Specification Required.

Integer values of greater than 65535 and strings of length greater than 2 are 
designated as Expert Review.

Integer values less than -65536 are marked as Private Use.

So that says what IANA policy is to be used for each of the different items.  
This defines the policies and the ranges for those policies.

There is not anything that is making a distinction on what the criteria to be 
used by the DE in the document which is separate, but I don’t think that is 
needed.  This is why they are DEs.

I still don’t see what you think is missing.

Jim


From: Dan Romascanu [mailto:droma...@gmail.com]
Sent: Tuesday, February 27, 2018 2:00 AM
To: Benjamin Kaduk >
Cc: Jim Schaad >; gen-art 
>; 
draft-ietf-ace-cbor-web-token@ietf.org;
 ietf >; ace@ietf.org
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Hi,
See also my other notes.
I believe that what the document tries to say is:
Register R is divided into four different ranges R1, R2, R3, R4 (defining the 
value limits may be useful)
Values in range R1 are allocated according to policy P1 in the case that ...
Values in range R2 are allocated according to policy P2 in the case that ...
Values in range R3 are allocated according to policy P3 in the case that ...
Values in range R4 are allocated according to policy P4 in the case that ...
But it doesn't say it. Mentioning four concurrent policies for the same 
registry without separation of values range, and without providing clear 
instructions when each policy is recommended to be used, seems confusing to me, 
and may be confusing for users of this document in the future.
Regards,
Dan

On Tue, Feb 27, 2018 at 5:40 AM, Benjamin Kaduk 
> wrote:
On Mon, Feb 26, 2018 at 11:19:04PM +0200, Dan Romascanu wrote:
> Hi Jim,
>
> Thank you for your answer and for addressing my comments.
>
> On item #2:
>
>
>
> On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad 
> > wrote:
>
> >
> >
> > > -Original Message-
> > > From: Dan Romascanu [mailto:droma...@gmail.com]
> > >
> >
> > ...
>
> > >
> > > 2. I am a little confused by the definition of policies in Section 9.1:
> > >
> > >Depending upon the values being requested, registration requests are
> > >evaluated on a Standards Track Required, Specification Required,
> > >Expert Review, or Private Use basis [RFC8126] after a three-week
> > >review period on the 
> > > cwt-reg-rev...@ietf.org mailing list, on 
> > > the
> > >advice of one or more Designated Experts.
> > >
> > > How does this work? The request is forwarded to the designated expert,
> > > he/she make a recommendation concerning the policy on the mail list, and
> > > depending on the feedback received a policy is selected? Who establishes
> > > consensus?
> > >
> > > Frankly, I wonder if this can work at all. Are there other examples of
> > four
> > > different policies for the same registry, applied on a case-to-case
> > basis?
> >
> > This is the same approach that is being 

Re: [Ace] CBOR Web Token (CWT) draft addressing shepherd review comments

[Mike Jones]

Good point.  I'll make a note to update the description the next time we 
publish a draft to not imply that values in the Private Use range are 
registered.  I don't think it's worth publishing another draft for just this 
until we receive Kathleen's AD review, at which point I'll address it.

Grüße,
-- Mike 

-Original Message-
From: Carsten Bormann <c...@tzi.org> 
Sent: Friday, February 2, 2018 9:28 PM
To: Mike Jones <michael.jo...@microsoft.com>
Cc: ace@ietf.org
Subject: Re: [Ace] CBOR Web Token (CWT) draft addressing shepherd review 
comments

»
Depending upon the values being requested, registration requests are
evaluated on a Standards Track Required, Specification Required,
Expert Review, or Private Use basis [RFC8126] «

This might give the impression that IANA registrations can be made on a 
“Private Use” basis.
RFC 8126 Section 4.1 says about Private Use:

   […] IANA does not record assignments from registries
   or ranges with this policy (and therefore there is no need for IANA
   to review them) and assignments are not generally useful for broad
   interoperability.  It is the responsibility of the sites making use
   of the Private Use range to ensure that no conflicts occur (within
   the intended scope of use).

Maybe it is better to just point at the section giving the actual policies?

Grüße, Carsten

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

Re: [Ace] shepherd review of draft-ietf-ace-cbor-web-token-11

[Mike Jones]

Thanks for your useful review, Ben.  I believe that 
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-12 addresses all your 
comments and is ready to send to Kathleen.

Best wishes,
-- Mike

-Original Message-
From: Benjamin Kaduk  
Sent: Friday, February 2, 2018 2:25 PM
To: ace@ietf.org; draft-ietf-ace-cbor-web-to...@ietf.org
Subject: shepherd review of draft-ietf-ace-cbor-web-token-11

Hi all,

We're getting ready to send this to Kathleen for processing (hopefully to 
finish before her term as AD does!), but there are a few nits that should be 
fixed with a new rev before we actually push the button.

We currently have an informational reference to RFC 5226, which has since been 
replaced by RFC 8126; we should update our citation to the newer document with 
guidelines for writing IANA considerations.

In section 9.1 the second pargaraph says that the values are registerd on a 
"Specification Required" basis, but we have some ranges that are just "Expert 
Review".  So I think this text should say "Expert Review" instead (with some of 
the guidance to the experts being that certain subranges have additional 
requirements).

We also note that the Experts should consider "whether it is useful only for a 
single application", and it's not entirely clear to me what the reuslt of that 
consideration should be.  Is only being useful for a single application 
supposed to be grounds for rejecting a registration?  (That doesn't seem 
necessarily true, for the Expert Review range.)  Or is that just a factor for 
whether "nice-looking"
names should be allowed for them?  Or something else?

In section 9.4, we attempt to register a value from the CBOR Tag registry; 
however, the template in RFC 7049 includes a "description of semantics" field, 
and not the "reference" field that we provide.

Finally, in the acknowledgments, we can ask the RFC Editor to use the non-ASCII 
"Gőran" if he so desires.  (Last I heard the tooling isn't there to use 
non-ASCII for internet drafts yet, though.)

Authors, will you be able to prepare a new version with these changes?

Thanks,

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

[Ace] CBOR Web Token (CWT) draft addressing shepherd review comments

[Mike Jones]

The CBOR Web Token (CWT) specification has been updated to address the shepherd 
comments by Benjamin Kaduk.  Changes were:

  *   Updated the RFC 5226 reference to RFC 8126.
  *   Made the IANA registration criteria consistent across sections.
  *   Stated that registrations for the limited set of values between -256 and 
255 and strings of length 1 are to be restricted to claims with general 
applicability.
  *   Changed the "Reference" field name to "Description of Semantics" in the 
CBOR Tag registration request.
  *   Asked the RFC Editor whether it is possible to preserve the non-ASCII 
spellings of the names Erik Wahlström and Göran Selander in the final 
specification.

Thanks to Ben for his careful review of the specification!

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-12

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-12.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1776 and as 
@selfissued.


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

Re: [Ace] shepherd review of draft-ietf-ace-cbor-web-token-11

[Mike Jones]

Thanks for the detailed read, Ben.  Will do.

-- Mike

-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu] 
Sent: Friday, February 2, 2018 2:25 PM
To: ace@ietf.org; draft-ietf-ace-cbor-web-to...@ietf.org
Subject: shepherd review of draft-ietf-ace-cbor-web-token-11

Hi all,

We're getting ready to send this to Kathleen for processing (hopefully to 
finish before her term as AD does!), but there are a few nits that should be 
fixed with a new rev before we actually push the button.

We currently have an informational reference to RFC 5226, which has since been 
replaced by RFC 8126; we should update our citation to the newer document with 
guidelines for writing IANA considerations.

In section 9.1 the second pargaraph says that the values are registerd on a 
"Specification Required" basis, but we have some ranges that are just "Expert 
Review".  So I think this text should say "Expert Review" instead (with some of 
the guidance to the experts being that certain subranges have additional 
requirements).

We also note that the Experts should consider "whether it is useful only for a 
single application", and it's not entirely clear to me what the reuslt of that 
consideration should be.  Is only being useful for a single application 
supposed to be grounds for rejecting a registration?  (That doesn't seem 
necessarily true, for the Expert Review range.)  Or is that just a factor for 
whether "nice-looking"
names should be allowed for them?  Or something else?

In section 9.4, we attempt to register a value from the CBOR Tag registry; 
however, the template in RFC 7049 includes a "description of semantics" field, 
and not the "reference" field that we provide.

Finally, in the acknowledgments, we can ask the RFC Editor to use the non-ASCII 
"Gőran" if he so desires.  (Last I heard the tooling isn't there to use 
non-ASCII for internet drafts yet, though.)

Authors, will you be able to prepare a new version with these changes?

Thanks,

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

Re: [Ace] Removal of the Client Token from ACE-OAuth draft

[Mike Jones]

I agree with Hannes and Ben that the Client Token is speculative in nature, 
solving a problem that's it's not clear that we even have.  It certainly isn't 
OAuth.

I already made this point in my earlier comprehensive review of the spec, but 
I'll repeat again here.  Please remove it!

-- Mike

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Benjamin Kaduk
Sent: Thursday, February 1, 2018 6:31 PM
To: Hannes Tschofenig 
Cc: ace@ietf.org
Subject: Re: [Ace] Removal of the Client Token from ACE-OAuth draft

On Thu, Feb 01, 2018 at 01:59:48PM +, Hannes Tschofenig wrote:
> Hi all,
> 
> the Client Token is a new mechanism in the ACE-OAuth that aims to solve a 
> scenario where the Client does not have connectivity to the Authorization 
> Server to obtain an access token while the Resource Server does.

This sounds eerily reminiscent of the IAKERB GSS-API mechanism, where the 
initiator uses the acceptor as a proxy to contact the Kerberos KDC, obtain an 
initial ticket, and obtain the credentials needed to complete the "normal" 
Kerberos exchange with the acceptor.
(An early draft of) it got implemented, but the spec kind of died and we don't 
know of anyone actually using it.

So, I support not including it unless we have some actual use cases in mind.

-Ben

> The solution is therefore for the Client to use the Resource Server to relay 
> messages to the Authorization Server.
> 
> While this sounds nice it does not follow the OAuth model and we, at 
> ARM, have not seen anyone requesting this feature. It is also not 
> fully specified in the spec: since I have been doing a formal analysis 
> of this protocol variant for the OAuth Security Workshop I had to 
> notice that it is not secure. (I will post the paper to the list 
> asap.)
> 
> Note that I am not saying that we should never do this work but I prefer that 
> someone who really cares about this use case describes it in an independent 
> document.
> 
> In summary, I am again requesting that the Client Token functionality is 
> removed from the ACE-OAuth draft.
> 
> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

> ___
> 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 mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] CBOR Web Token (CWT) draft correcting an example

[Mike Jones]

A new CBOR Web Token (CWT) draft has been published that applies a correction 
to an example.  The full list of changes is:

  *   Corrected the "iv" value in the signed and encrypted CWT example.
  *   Mention CoAP in the application/cwt media type registration.
  *   Changed references of the form "Section 4.1.1 of JWT " to "Section 4.1.1 of " so that 
rfcmarkup will generate correct external section reference links.
  *   Updated Acknowledgements.

Thanks to Samuel Erdtman for validating all the examples once more and finding 
the issue with the signed and encrypted example.  Thanks to Benjamin Kaduk for 
pointing out additional improvements that could be applied from the second WGLC 
comments.
The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-11

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-11.html

   -- Mike

P.S.  This notice was also posted http://self-issued.info/?p=1769 and as 
@selfissued.

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

[Ace] CBOR Web Token (CWT) addressing 2nd WGLC comments

[Mike Jones]

A new CBOR Web Token (CWT) draft has been published that addresses comments 
received during the second working group last call.  Thanks to Hannes 
Tschofenig, Esko Dijk, Ludwig Seitz, Carsten Bormann, and Benjamin Kaduk for 
their feedback.  All changes made were clarifications or formatting 
improvements.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-10

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-10.html

   -- Mike

P.S.  This notice was also posted http://self-issued.info/?p=1761 and as 
@selfissued.
___
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  on behalf of Samuel Erdtman 
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 
> 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]
Sent: Wednesday, December 6, 2017 13:48
To: Esko Dijk >
Cc: Benjamin Kaduk >; 
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 
> 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 

Re: [Ace] CWT - Scope Claim

[Mike Jones]

I agree that CWT shouldn't define claims beyond those that correspond to the 
JWT claims.  Other specs can do that via the registry established for that 
purpose.

-- Mike

From: Ace  on behalf of Jim Schaad 

Sent: Tuesday, October 31, 2017 8:06:04 AM
To: Hannes Tschofenig; 'Samuel Erdtman'
Cc: ace@ietf.org
Subject: Re: [Ace] CWT - Scope Claim

I have an outstanding comment to the effect that I want a binary scope value – 
specifically to allow for a CBOR encoded object – on the framework document.

In terms of defining it in this document rather than in the framework, my first 
response would be ‘no’ only because this was designed to be a direct copy of 
the JWT document and it was not defined there.  Other than that I would not 
care one way or the other.

Jim


From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, October 31, 2017 2:58 AM
To: Samuel Erdtman 
Cc: ace@ietf.org
Subject: Re: [Ace] CWT - Scope Claim

Hi Samuel,

You are correct that we should register it also with the JWT.

Additionally, I wonder whether the string representation of the claim for the 
CWT is the most efficient way to represent the scope. Shouldn’t we rather use 
CBOR capabilities here since we are trying to optimize 2 bytes in other areas?

Ciao
Hannes

From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: 31 October 2017 10:46
To: Hannes Tschofenig
Cc: ace@ietf.org
Subject: Re: [Ace] CWT - Scope Claim

The framework does register a CWT 'scoop' claim, but I think it has to register 
it with JWT too to be correct.

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-8.5

//Samuel

On Tue, Oct 31, 2017 at 10:28 AM, Hannes Tschofenig 
> wrote:
Hi all,

I was wondering whether we should define a claim, scope, that captures the 
scope that was granted by the authorization server.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] CWT - Audience

[Mike Jones]

Not having support for multiple audiences is semantically a non-starter.  There 
are some differences in CWT from JWT that are intentional (such as binary key 
IDs) to better align CWT with COSE, but this particular divergence is 
unacceptable.

My conclusion is that I will need read CWT line-by-line before Singapore and 
compile a list of such problems that have somehow made it into the spec.  I was 
(apparently naively) assuming it was aligned, but apparently that's not the 
case.

Thanks for catching this, Hannes!

-- Mike

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, October 31, 2017 8:50 AM
To: Kathleen Moriarty ; Carsten Bormann 

Cc: Samuel Erdtman ; ace@ietf.org
Subject: Re: [Ace] CWT - Audience

> > I sure noticed the difference, but thought that this was an intended 
> > simplification: simply not allowing audiences with multiple strings.
> I believe it was an intentional change, but am sure Jim and others can 
> clarify.

The downside of that change is the following:
 * Misalignment with the JWT, and
 * If you want to use the CWT token with multiple audiences then you have to 
request a new token for each audience.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
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] CBOR Web Token (CWT) specification adding CBOR_Key values and Key IDs to examples

[Mike Jones]

A new CBOR Web Token (CWT) draft has been published that adds CBOR_Key values 
and Key IDs to examples.  Thanks to Samuel Erdtman for working on the examples, 
as always.  Thanks to Giridhar Mandyam for validating the examples!

I believe that it's time to request publication, as there remain no known 
issues with the specification.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-09.html

-- Mike

P.S.  This notice was also posted http://self-issued.info/?p=1744 and as 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag

[Mike Jones]

I also agree that the spec already has this right.  Typically no tag will be 
needed because the application knows the data structure is a CWT from context.  
The tag is available for any use cases where it's needed to resolve ambiguity 
that might otherwise be present.

-- Mike

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Carsten Bormann
Sent: Thursday, October 19, 2017 10:05 AM
To: Jim Schaad 
Cc: Hannes Tschofenig ; ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag

On Oct 19, 2017, at 18:41, Jim Schaad  wrote:
> 
>   • I already know that this is going to be a CWT so I save a byte.
>   • I don’t know so I waste a tag byte in that case.

Right.  In REST protocols, we usually have a media type, so we don’t need the 
CBOR Tag.
Within some other data structures, or in legacy protocols such as MQTT, we may 
not have that, so a tag is a good single standard way to indicate this.

(Does the latter case need to be a single byte [which is then preceded by 0xd8, 
by the way]?  Maybe that would not have been necessary(*), but then CWTs are 
going to be rather common.  
And 61 is a “=“, which is cool for our hexdump reading population :-)

Grüße, Carsten

(*) The number is already assigned, BTW.

___
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] Initial Working Group Draft of Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)

[Mike Jones]

The initial working group draft of the Proof-of-Possession Key Semantics for 
CBOR Web Tokens (CWTs) specification has been posted. It contains the same 
normative content as 
draft-jones-ace-cwt-proof-of-possession-01.
  The abstract of the specification is:
This specification describes how to declare in a CBOR Web Token (CWT) that the 
presenter of the CWT possesses a particular proof-of-possession key.  Being 
able to prove possession of a key is also sometimes described as the presenter 
being a holder-of-key.  This specification provides equivalent functionality to 
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but 
using CBOR and CWTs rather than JSON and JWTs.

I look forward to working with my co-authors and the working group to hopefully 
complete this quickly!

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-00

An HTML-formatted version is also available at:

  *   
http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-00.html

-- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1735 and as 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] CBOR Web Token (CWT) specification addressing all known issues

[Mike Jones]

A new CBOR Web Token (CWT) draft has been published that updates the diagnostic 
notation for embedded objects in the examples.  Thanks to Samuel Erdtman for 
making these updates.  Thanks to Carsten Bormann for reviewing the examples!

This addresses all known issues with the specification.  I believe that it is 
now time to request publication.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-08.html

-- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1728 and as 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Related work for draft-erdtman-ace-rpcc

[Mike Jones]

These RFCs are all pertain to OAuth Client Authentication using signed 
assertions:

  *   RFC 7521 - Assertion Framework for OAuth 2.0 Client Authentication and 
Authorization Grants
  *   RFC 7522 - Security Assertion Markup Language (SAML) 2.0 Profile for 
OAuth 2.0 Client Authentication and Authorization Grants
  *   RFC 7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client 
Authentication and Authorization Grants

I'd encourage you to think about whether using the JWT Profile, in particular, 
would achieve the goals you're after.

   Best wishes,
   -- Mike

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

Re: [Ace] ace - Requested session has been scheduled for IETF 99

[Mike Jones]

I'd like to request these ACE agenda slots in Prague:
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) - 
draft-jones-ace-cwt-proof-of-possession - Michael B. Jones - 15 minutes
CBOR Web Token (CWT) - draft-ietf-ace-cbor-web-token - Michael B. Jones 
- 5 minutes

Thanks,
-- Mike

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of "IETF Secretariat"
Sent: Friday, June 23, 2017 5:07 PM
To: ace-cha...@ietf.org; kepeng@alibaba-inc.com
Cc: kathleen.moriarty.i...@gmail.com; ace@ietf.org
Subject: [Ace] ace - Requested session has been scheduled for IETF 99

Dear Kepeng Li,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by the original request. 

ace Session 1 (2:30:00)
Monday, Morning Session I 0930-1200
Room Name: Congress Hall I size: 250
-



Request Information:


-
Working Group Name: Authentication and Authorization for Constrained 
Environments Area Name: Security Area Session Requester: Kepeng Li

Number of Sessions: 1
Length of Session(s):  2.5 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: core oauth saag lwig tokbind tls




People who must be present:
  Kathleen Moriarty
  Hannes Tschofenig
  Kepeng Li

Resources Requested:

Special Requests:
  Avoid entire SEC areas. Please avoid a session on Friday!
-

___
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] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

[Mike Jones]

Hi Jim.  Draft -07 now uses deterministic signing algorithms, thanks to Samuel. 
 Could you take another crack at reproducing the examples?

   -- Mike

From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: Thursday, June 22, 2017 3:09 PM
To: 'Samuel Erdtman' 
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; 'ace' 
Subject: RE: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

See below.

Jim

From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Thursday, June 22, 2017 1:40 AM
To: Jim Schaad >
Cc: 
draft-ietf-ace-cbor-web-to...@ietf.org;
 ace >
Subject: Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

Thanks Jim!
Se comments inline

On Sun, Jun 18, 2017 at 9:21 PM, Jim Schaad 
> wrote:
Comments on this version of the draft.

Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR tag at 
this point

In section 7.1 step 6 describes how one can add the CWT CBOR Tag to the full 
CWT if transport layer cannot indicate that this is a CWT. In this case you 
would want first the COSE tag and then the CWT tag this is described in section 
6. We asked Carsten about this before we added the text so it should be okay.
In section 7.2 step 6 and 7 CWT CBOR tag is not mentioned as far as I can tell.

[JLS]  So if an intermediary adds a layer of wrapping (i.e. encrypts it to the 
end point) but the original entity who signed it put the CWT tag on it, it will 
be and invalid CWT if the tag was not removed?


Appendix A.3 - I was unable to reproduce the example.  I assume that this means 
that a deterministic signature algorithm is not being used.  While a verifier 
cannot tell if one is being used, the COSE document does strongly suggest that 
one be used.  Additionally, it helps in testing if one is used so that a 
signature creator can be more easily tested.

Correct I have not used a deterministic signing algorithm. I have used 
COSE-JAVA to create the examples, is it possible to configure that 
implementation to generate deterministic ECDSA signatures?
When working with my JS implementation I have noticed that support for 
deterministic ECDSA implementations are hard to find.

[JLS] With COSE-JAVA, if you are using anything remotely recent is 
deterministic, so that should not be a problem.  I put this change into the 
sources about 8 months ago.  The problem may be the same issue as for A.5 where 
something is different in the data to be signed.



Appendix A.5 - I was unable to reproduce the example.  Specially the tag value 
does not match with the one that I compute.

That is bad. but apart from the tag it looks good?

[JLS] Yes apart from the tag I matched everything – including the encryption.  
This bothers me if you are using the COSE-JAVA to produce the examples.  I 
routinely run regression tests on both language libraries so they should 
produce the same output given the same inputs.  This triggers in my mind that 
you might have done something odd with the external data and thus we are 
generating different tags.   It would be something that is being done for 
signing and for encryption but not mac.



Minor:

In section 2:  Is there a reason not to define CWT claim value in this section

Sorry I´m not following, could you please explain a bit more`?

[JLS] You thought it was reasonable to define a “CWT encoded claim key” in the 
terms.  I was just thinking that it would be symmetric to have the values have 
defined here at the same time.



-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf 
Of internet-dra...@ietf.org
Sent: Monday, June 5, 2017 6:27 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments of the IETF.

Title   : CBOR Web Token (CWT)
Authors : Michael B. Jones
  Erik Wahlström
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-cbor-web-token-05.txt
Pages   : 23
Date: 2017-06-05

Abstract:
   CBOR Web Token (CWT) is a compact means of representing claims to be
   transferred between two parties.  The claims in a CWT are encoded in
   the Concise Binary Object Representation (CBOR) and CBOR Object
   Signing and Encryption (COSE) is used for added application layer
   security protection.  A claim is a piece of information asserted
   about a subject and is 

[Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing review comments

[Mike Jones]

The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification 
has been updated to address comments received since its initial publication.  
Changes were:

  *   Tracked CBOR Web Token (CWT) Claims Registry updates.
  *   Addressed review comments by Michael Richardson and Jim Schaad.
  *   Added co-authors Ludwig Seitz, Göran Selander, Erik Wahlström, Samuel 
Erdtman, and Hannes Tschofenig.

Thanks for the feedback received to date!

The specification is available at:

  *   https://tools.ietf.org/html/draft-jones-ace-cwt-proof-of-possession-01

An HTML-formatted version is also available at:

  *   
http://self-issued.info/docs/draft-jones-ace-cwt-proof-of-possession-01.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1711 and as 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review of draft-jones-ace-cwt-proof-of-possession-00

[Mike Jones]

Thanks for your useful review, Jim.  Replies are inline below...



-Original Message-
From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: Tuesday, June 27, 2017 12:50 AM
To: draft-jones-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: Review of draft-jones-ace-cwt-proof-of-possession-00



Abstract - I am unclear how this is a profile of RFC 7800 rather than a

restatement of that document.   In what way does this qualify as a profile?



The draft now says that it provides equivalent functionality to RFC 7800 rather 
than being a profile of it.



Introduction - I do not understand the second half of the first sentence in the 
introduction.  It claims that the document is going to show how proof of 
possession is done, however this seems to be explicitly declared as out of 
scope in section 3.5.



You're right.  I have deleted the second half.



Section 2 - Since this document is currently planned to come from the ACE 
working group,  I would suggest that it would be reasonable to provide the 
equivalent terminology to what is in this document. -- see actors



Maybe we can talk about specific proposed edits in Prague.



Section 3 - para 1 - missed  a s/JSON/CBOR/



Fixed



Section 3 - para 2 - I am not sure of the following:

- Why this is included here and not a separate section



It was here in RFC 7800.  It could be moved and given its own section but 
wanted to start out with a completely parallel document.



- Why the concept of an anonymous POP is not supported



I assume you're talking about a situation in which the identity of the 
presenter is not known or revealed?  I assume this is related to your next 
comment?



- Why the concept of the issuer being inferred from the authentication key on 
the CWT is not supported



If this is done in practice, particularly within ACE, this could be explicitly 
mentioned in the future.



- I will note that draft-ietf-ace-oauth-authz does not require either of these 
fields to be present.



Thanks for pointing this out.  I've removed this requirement to give profiles 
full freedom of how to identify the presenter.



Section 3.1 - The first two sentences seems to be slightly contradictory - the 
first says the cnf claim is used to identify the POP key.  The second states 
that it may have something other than a POP key in it.



It's really about saying that "confirmation" is broader than 
"confirmation-by-PoP".  This draft covers the latter, but defines the "cnf" 
claim to enable the broader uses, as in SAML 2.0.  I'll think about how to word 
this more clearly.



Section 3.1 - I am not a fan of MUST ignore statements at this level.  It 
should be  profile statement if anything.



The "MUST be ignored" is essential for future extensibility.  Otherwise, 
anything new added breaks everything already deployed.



Section 3.1 - last paragraph - Does this mean that only one claim can be in the 
cnf claim - or are some values of different levels?  For example -can I have a 
COSE_Key and an Kid?  This might be considered to be multiple POP keys.



As long as the "kid" refers to the same key, you're golden.  I think it already 
says that somewhere, but I'll look into it further.



Section 3.2 - Profiles can require that additional elements can be required in 
the COSE_Key element - and example would be to require that the algorithm 
identifier be present.



That's fine.  The spec already says that other key elements can be included.



Section 3.2 - I do not understand why this paragraph is doing in this section 
give the section title.  Why is it not in section 3.3 or in a separate section. 
 I think it makes mores sense at the end of the next section.



Public keys are represented in the clear.  That's different than the symmetric 
keys in 3.3, which have to be encrypted to prevent them from being revealed.



Section 3.3 - Why is title not symmetric with section 3.2 and the word 
encrypted be absent?



See the previous reply



Section 3.4 - This section just makes me uncomfortable.  Use a value that was 
potentially chosen for collisions does not seem to be a good idea.  I think 
this really needs some additional guidance about using.



If both parties already have the key, using a Key ID rather than transmitting 
the key is an optimization that is used in practice.  What else would you like 
us to say about this?



Section 4 - Is there any reason to suppose that the use of asymmetric secrets 
are immune from replay attacks?



Is there particular Security Considerations text that you'd like to see 
included about this?



Section 3.1 - para 1 -sentence #2  -  I do not understand the implication that 
the POP key implies the authenticity of the token.  That statement makes no 
sense to me.  This would look  like a self-signed certificate as the 
authentication point.



See the SAML 2.0 comment earlier.



Jim



I plan to publish an updated version in the next day or so, after giving the 
authors of 

Re: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)

[Mike Jones]

Thanks, Michael.  My editors draft now corrects the JSON -> CBOR issue.

Jim Schaad also commented on the second paragraph.  The editors draft relaxes 
its requirements to give profiles or applications full flexibility on how to 
identify the presenter.

After giving the editors of draft-ietf-ace-oauth-authz a chance to have a look 
at the new draft, I plan to publish it in a day or so.

I'd be glad to talk with you in person in Prague about the needs of the new 
work you mention below and how to meet them.

Best wishes,
-- Mike

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: Monday, May 22, 2017 11:17 AM
To: Mike Jones <michael.jo...@microsoft.com>
Cc: ace@ietf.org
Subject: Re: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)


Come to the discussion late, cleaning my inbox.

section 3 says:

 "The value of the cnf claim is a JSON object and the members of that object
 identify the proof-of-possession key."

And somehow, I think that the claim ought to be a CBOR object?
Same for the paragraph of 3.4.

I found the next paragraph about whether the sub or iss is the presenter to be 
obtuse.  Maybe it is lacking some ACE RS/C/AS terminology?

I am trying to figure out if the nonce-full mechanism that we describe in 
draft-ietf-anima-bootstrapping-keyinfra or anima-voucher, and later to be 
re-interpreted as CWT in draft-ietf-6tisch-dtsecurity-secure-join should 
reference RFC 7800 and this document instead.


--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works  -= IPv6 
IoT consulting =-



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

[Ace] CBOR Web Token (CWT) specification addressing editorial comments

[Mike Jones]

A new CBOR Web Token (CWT) draft has been published that addresses editorial 
comments made by Carsten Bormann and Jim Schaad.  All changes were editorial in 
nature.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-06

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-06.html

-- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1707 and as 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] CBOR Web Token (CWT) specification addressing WGLC feedback

[Mike Jones]

A new CBOR Web Token (CWT) draft has been published that addresses the Working 
Group Last Call (WGLC) feedback received.  Changes were:

* Say that CWT is derived from JWT, rather than CWT is a profile of JWT.

* Used CBOR type names in descriptions, rather than major/minor type 
numbers.

* Clarified the NumericDate and StringOrURI descriptions.

* Changed to allow CWT claim names to use values of any legal CBOR map 
key type.

* Changed to use the CWT tag to identify nested CWTs instead of the CWT 
content type.

* Added an example using a floating-point date value.

* Acknowledged reviewers.

Thanks to Samuel Erdtman for doing the majority of the editing for this draft.  
As always, people are highly encouraged to validate the examples.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05

An HTML-formatted version is also available at:

* http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-05.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1695 and as 
@selfissued.

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

Re: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)

[Mike Jones]

Thanks for the catch. Yes, this should be a CBOR map. I failed to make this 
change when transforming RFC 7800 into this draft. I'll correct it in the next 
version.



– Mike



From: Michael Richardson<mailto:mcr+i...@sandelman.ca>
Sent: Monday, May 22, 2017 2:19 PM
To: Mike Jones<mailto:michael.jo...@microsoft.com>
Cc: ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)



Come to the discussion late, cleaning my inbox.

section 3 says:

 "The value of the cnf claim is a JSON object and the members of that object
 identify the proof-of-possession key."

And somehow, I think that the claim ought to be a CBOR object?
Same for the paragraph of 3.4.

I found the next paragraph about whether the sub or iss is the presenter to
be obtuse.  Maybe it is lacking some ACE RS/C/AS terminology?

I am trying to figure out if the nonce-full mechanism that we describe
in draft-ietf-anima-bootstrapping-keyinfra or anima-voucher, and later to
be re-interpreted as CWT in draft-ietf-6tisch-dtsecurity-secure-join should
reference RFC 7800 and this document instead.


--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



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

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

[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] CWT and PoP Tokens

[Mike Jones]

See the reply that I just sent to Ludwig.  I believe that we could get a 
straight RFC 7800 (“cnf” claim) port done as an RFC at the same time or soon 
after CWT becomes an RFC.  ACE needs PoP keys and other applications do too, 
and we should try to provide them expeditiously.  I invited Ludwig to be a 
co-editor on the straight port with me to help make sure we move it forward 
promptly.



draft-ietf-ace-oauth-authz could then profile the RFC 7800 port by saying how 
it uses the general confirmation syntax (this profiling text already exists).



Would that work for people?



   Best wishes,

   -- Mike



-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Carsten Bormann
Sent: Friday, April 21, 2017 1:33 AM
To: Hannes Tschofenig 
Cc: Ace@ietf.org
Subject: Re: [Ace] CWT and PoP Tokens



On Apr 21, 2017, at 09:56, Hannes Tschofenig 
> wrote:

>

> * the CWT spec maps some of the JWT claims to CBOR but does not

> contain anything regarding PoP tokens.

> * the ACE framework provides the PoP-related components (see

> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-06#section-5.5.4.5).

>

> Now, the question to the group is whether they are happy with this

> split. Another option would be to include the cnf claims needed for

> the PoP token functionality already in the CWT spec.



Probably, the “cnf” claims attain their actual meaning through the framework.

It will be hard to do a framework-independent definition of those in the CWT 
spec.

So I am very happy with that split.



Grüße, Carsten


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

[Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)

[Mike Jones]

With the CBOR Web Token 
(CWT) specification 
nearing completion, which provides the CBOR equivalent of JWTs, I thought that 
it was also time to introduce the CBOR equivalent of RFC 
7800, "Proof-of-Possession Key Semantics 
for JSON Web Tokens (JWTs)", so that applications using CWTs will have a 
standard representation for proof-of-possession keys.  I know that PoP keys are 
important to ACE applications, for instance.  I 
therefore took RFC 7800 and produced the CBOR/CWT equivalent of it.

The specification is available at:

* https://tools.ietf.org/html/draft-jones-ace-cwt-proof-of-possession-00

An HTML-formatted version is also available at:

* 
http://self-issued.info/docs/draft-jones-ace-cwt-proof-of-possession-00.html

-- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1673 and as 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] CBOR Web Token (CWT) specification correcting inconsistencies in examples

[Mike Jones]

A revised CBOR Web Token (CWT) draft has been published that corrects 
inconsistencies in the examples.  Thanks to Jim Schaad for validating the 
examples and pointing out the inconsistencies and to Samuel Erdtman for fixing 
them.  As before, people are highly encouraged to validate the updated examples.

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

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1671 and as 
@selfissued.

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

Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

[Mike Jones]

Let me second the thanks for the thorough review, Jim, and especially for 
validating the examples.  Replies to some of the points are inline…

-- Mike

From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Sunday, April 2, 2017 10:58 PM
To: Jim Schaad 
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace 
Subject: Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

Thanks for the review Jim,
See inline comments

On Sat, Apr 1, 2017 at 5:03 AM, Jim Schaad 
> wrote:
Given that it was stated that the authors believe that the document was
ready for publication, I decided to do another review pass.

1.  Following the discussion in the SET WG meeting, I believe that it would
be reasonable to define some inputs for the external data fields to allow
for distinguishing between the different uses of JWT structures.  Language
about different applications extending this structure would also be
reasonable.

I was not part of that discussion, could you please link to some resource or 
notes from that meeting.

In the SecEvent WG, after I gave this invited presentation on JOSE/JWT 
security,
 there was a discussion on whether it would be useful to document best 
practices on using JWTs.  After the repeating the same presentation in the 
OAuth working group, it was agreed that we would do that and I would write down 
some of the possible issues using JWTs and mitigations.  Some of this will be 
in the form of advice to implementers.  Some of it will be advice to protocol 
designers.  Given that CWTs are intentionally parallel to JWTs, I expect that 
much of the JWT BCP language will also apply to CWTs.  I’ll make a mental note 
to also be thinking about CWTs when writing about JWTs.


2.  I do not know if the authors looked at changing the Type3StringOrURI so
that it would explicitly tag URIs or not.  I do no remember seeing any
discussions on the list but have not gone back to search

We have no looked at changing this. Is there any good motivation for actually 
doing this change?

Having it just be a string as it is now is parallel with JWTs (which don’t have 
the tagging option available to them). My inclination is to keep it parallel.  
Alternatively, we could say that it’s also legal to tag the value as a URI if 
it is one.  What do others think?


3.  I find the description of Type6NumericDate to be slightly confusing as
it appears to imply that this is not using a numeric value when it does.

I think the idea is to say that it is not a JSON number but a CBOR number. I 
have added a ticket to look at the wording.
https://github.com/erwah/ietf/issues/28
I agree that clearer wording can be used, talking about a CBOR number tagged as 
a numeric date.


4.  The authors need to look at their use of Type6NumericDate and determine
if this is what they really want to do.  All of the examples are incorrect
because of this tag usage.

Examples should be updated, see below


5.  After the discussions in the SET group, do the authors which to
re-consider the MUST ignore statement in the first paragraph of section 3?

I have not seen the SET group discussion could you please link to it.

Ignoring claims that are not understood is critical to extensibility.  It’s 
served JWTs well and will serve CWTs well in the same regard.  Without this, 
every system using a CWT would be brittle by design.


6.  The string "6 tag value 1" is normally written as "6.1" when looking at
pretty-printed CBOR diagnostics.   This would be clearer than what is
written.

Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/26


7.  The text should be altered to use a TBD for the CWT tag rather than
using a constant so this is highlighted.

Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/25

I disagree with this.  The values in the registry are already marked as “TBD 
(maybe 61)”.  It would just add clutter, detracting from the readability of the 
spec, to replicate this elsewhere.  Besides, the examples need a specific 
number.  If IANA changes the number, we will of course, update the spec 
accordingly, once a final assignment is determined.

8.  The note for step 5 in section 6.1 is problematic from a number of
things.  A) AEAD algorithms are required, so it is not clear that the
recommendation makes sense.  B) there is a big difference between signing
and MACing in terms of the amount and type of integrity provided.  Replacing
signing w/ AEAD loses a lot.

I think you are correct and I have considered removing it, I added in in an 
early attempt to be smart.
I have added a issue to evaluate the value of this statement and remove if 
considered useless.
https://github.com/erwah/ietf/issues/24

I agree with deleting it.


9.  Step 6 

Re: [Ace] Call for presentations for IETF98

[Mike Jones]

I'd be glad to do a presentation on the status of CBOR Web Token (CWT) 
draft-ietf-ace-cbor-web-token.  It should take 10-15 minutes.

Thanks,
-- Mike

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Kepeng Li
Sent: Tuesday, March 14, 2017 9:22 PM
To: Ace@ietf.org
Subject: [Ace] Call for presentations for IETF98

Hi everyone,

So far, the chairs have had two requests for presentations at the ACE meeting 
of IETF98, which we will be accommodating along with discussion on the current 
draft progress.

We're putting the agenda together now, and we would like to know if anyone else 
has a topic that they'd like to present and discuss at the upcoming face to 
face.

Please send feedback to Hannes and me before the end of 17th Mar, including 
draft name, presenter, how much time, objectives.

Thanks.

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

[Ace] IANA Considerations added to CBOR Web Token (CWT)

[Mike Jones]

The CBOR Web Token (CWT) specification now establishes the IANA CWT Claims 
registry and registers the CWT claims defined by the specification.  The 
application/cwt CoAP content type is now also registered.

This version adds Samuel Erdtman as an editor in recognition of his already 
significant contributions to the specification.

The specification is available at:

* http://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-01

An HTML-formatted version is also available at:

* http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-01.html

  -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1580 and as 
@selfissued.

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

Re: [Ace] A question for the ACE framework and CWT

[Mike Jones]

I agree that we don’t need to / want to add this to the registry.

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Samuel Erdtman
Sent: Tuesday, July 5, 2016 1:45 PM
To: Ace@ietf.org
Subject: Re: [Ace] A question for the ACE framework and CWT

ping, any thoughts on this?
//Samuel

On Tue, Jun 21, 2016 at 8:32 AM, Samuel Erdtman 
> wrote:
It was pointed out to me that the sentence below ended abruptly (thanks Ludwig)

"On the other hand it is not relay necessary to have it there, the reason for 
the mapping registries is to avoid CBOR label/key conflicts between attributes. 
So information about"

It should be

On the other hand it is not relay necessary to have it there, the reason for 
the mapping registries is to avoid CBOR label/key conflicts between attributes. 
So information about major type can just as well be kept in the specification 
defining the mapping.
//Samuel

On Sat, Jun 18, 2016 at 12:38 PM, Samuel Erdtman 
> wrote:
Hi
When writing the IANA mapping sections for the ACE framework and CWT I first 
required registrations to include the CBOR major type, Later I did not (e.g. 
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02#section-10.7). I 
would like to here the preferences of the group so that we can update mapping 
registries to have the same format.
The benefit of having the CBOR major type in the registry is that one then has 
more of the important information in one place.
On the other hand it is not relay necessary to have it there, the reason for 
the mapping registries is to avoid CBOR label/key conflicts between attributes. 
So information about

In COSE (https://tools.ietf.org/html/draft-ietf-cose-msg-13) it is included 
"value  This contains the CBOR type for the value portion of the label."
I would vote to keep data in registries at a minimum, i.e. exclude CBOR Major 
type from there.

Opinions?
Best regards
//Samuel



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