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

[Roman Danyliw]

Hi Mike!

Thanks for publishing -04.  The changes made in this version address the last 
of my WGLC comments per [Danyliw #7] and  [Danyliw #12].  More details below:

> From: Mike Jones [mailto:michael.jo...@microsoft.com] 
> Sent: Tuesday, November 6, 2018 3:43 AM
> To: Roman Danyliw ; ace@ietf.org
> Cc: Jim Schaad 
> 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, 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

[snip]

>  [Schaad #16] Section 4 - Are audience restrictions not done in CWT?  -- same 
> issues as [Danyliw #12]
>
> Mike> All claims in CWTs (and JWTs) are optional, including the "aud" 
> (audience) 
> claim.  Particular profiles can suggest and require particular claims, as 
> this 
> profile does.  I have deleted the unnecessary middle sentence, which 
> [Danyliw #12] correctly pointed out broke up the logical flow of the 
> exposition. 
> Thanks for pointing this out.

This change addresses my concerns.

[snip]

> [Danyliw #7] Page 6, Section 3.3, The sentence "The COSE_Key could, for 
> instance, be encrypted using a COSE_Encrypt0 representation using the 
> AES-CCM-16-64-128 algorithm" seems out of place.  What is this text 
> explaining relative to the examples?
>
> Mike> Thanks.  I deleted the confusing and unnecessary sentence.

This change addresses my concern.

Roman

___
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]

FYI - I wrote about this new version at http://self-issued.info/?p=1933 and as 
@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, 
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
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 s

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 c

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

[internet-drafts]

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-04.txt
Pages   : 15
Date: 2018-11-06

Abstract:
   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 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 CBOR and
   CWTs rather than JSON and JWTs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-04
https://datatracker.ietf.org/doc/html/draft-ietf-ace-cwt-proof-of-possession-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cwt-proof-of-possession-04


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://www.ietf.org/mailman/listinfo/ace