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

[Jim Schaad <[e-mail]>]

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.

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

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

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.

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.

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.

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.

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.

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.

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 confirming the
identity of the presenter.  Why would that type of information be placed
here where it is not useful.

11.  In section 3.1 P2 - We are back to the same argument that existed for a
CWT in general.  Not knowing that a CWT is for a specific application means
that it can be used in a different application and checking that the first
application would have done is ignored by the second one because it will
ignore fields it does not understand.

12. I am unclear why there should be a restriction on the number of POP keys
that can be in a 'cnf' object.  If there are multiple keys, then any or all
of them are of equal value in doing the confirmation.  Just like there can
be multiple confirmation methods and an application could choose to use any
one of them.

13.  Not sure which section this belongs in, but the use of an COSE_Encrypt0
would be one way to combat tracking of identities based on the key value
being used.  Different encrypted values could be sent to different servers
and they would not necessarily know about use w/o internal collusion between
them.  Similar effect by using an encrypted CWT.  Potentially requires use
of TLS1.3 to protect the RPKs.  YMMV

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.

15.  The content of 'kid' is application specific.  Where is an application
going to define this such that it will work more generally.  The application
in the case of the ACE working group boils down to the world (minus a few
things).

16. section 4 - Are audience restrictions not done in CWT?

17. section 4 - this implies that POP cannot be replayed via asymmetric
keys.  Why would this be the case?

18. section 4 - prior to an issuer being able to create a CWT for a client
w/ an asymmetric key in it, the issuer MUST go through a POP protocol of
some type to validate that the client has possession of the key.  Issuers
may want to repeat this validation at some interval for re-verification.
They should also keep track of the keys and flag where the same public key
appears more than one for
 review.

19.  Update IANA considerations w/ input from IANA and the CWT document.

20.  Are keys big enough that it should be considered to move kid to the 2
byte range of identifiers?

21. Section 6.2.2 - the value type is not an array for COSE_Encrypt or
COSE_Encyrpt0, these are the values.  As written I could put in an array
which is not one of those two structures and be valid.   Ditto for COSE_Key,
although w/ slightly less justification.

Jim