Thanks Martin for the comments and Benjamin for addressing some of them!
Comments on the remaining ones:
> (2.1) "...can use any signing algorithm." I presume there ought to be some
> qualifiers on allowed algorithms?
The algorithms referred to here are the ones defined by the usual JWT/JWS, as
in JWA (RFC7518). The reader should be able to get it from the context without
ambiguity.
> (4) I presume it's important that any resouree server rejection of the
token
> should be constant-time. Is this somewhere in the RFC tree, or do we need
to
> explicitly say it here and/or in Security Considerations?
I am thinking of analogous descriptions in other specs and I don’t recall
mentions of that aspect, hence I assumed we didn’t have to specify it here
either. In particular, I glanced thru RFC6750 section 3, which this spec
specializes for the specific JWT AT scenario, and they don’t mention that
either.
On 4/8/21, 12:12, "Benjamin Kaduk" <ka...@mit.edu> wrote:
On Thu, Apr 01, 2021 at 01:32:08PM -0700, Martin Duke via Datatracker wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-oauth-access-token-jwt-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-oauth-access-token-jwt/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (2.1) "...can use any signing algorithm." I presume there ought to be some
> qualifiers on allowed algorithms?
>
> (4) and (5) "This specification
> does not provide a mechanism for identifying a specific key as the
> one used to sign JWT access tokens."
>
> I don't understand; there's a key ID right there in the token header?
The concern here is about identifying keys authorized to sign JWS access
tokens. The server-provided metadata that lists such keys has a single
bucket that covers keys used for signing different things, so you don't get
any security benefit from key isolation, and a compromise of any of the
(other) keys listed by the server would allow the attacker to sign JWT
access tokens that are accepted as valid.
So in a sense this is not about which key was actually used, but rather
which key is supposed to be used.
> (4) I presume it's important that any resouree server rejection of the
token
> should be constant-time. Is this somewhere in the RFC tree, or do we need
to
> explicitly say it here and/or in Security Considerations?
(A good question, but I don't actually have the answer handy in memory.)
-Ben
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
