Hi Deb,
we've worked through your comments and I've provided our feedback inline
further down the mail.
We incorporate all the changes to draft -13 in a PR to our github
repository:
https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/305/files
We intend to merge this at Monday evening CET, right before the cutoff
unless we hear any objections.
Best regards,
Paul + Christian + Tobias
On 10/4/25 17:35, Deb Cooley wrote:
Here are my comments on this draft. Apologies for the delay.
Note: there is one action to myself wrt compression vulnerabilities
(see my comment on Section 11/13). I'll take advice/comment on these
from those who have dealt with these more than I have.
Deb
------------
Introduction: JOSE Tokens has a reference to the IANA registry? Is
there something other than JWT? Why not RFC 7515 or one of the other
JWT references?
Agreed. we swapped reference to JOSE IANA registry with RFC7515.
Section 1.2: no reply necessary, I'm a PKIX Person, these are
observations: OCSP stapling: This is only 'less up-to-date' if the
server doesn't pull OCSP responses 'often enough'. The larger issue
is that the OCSP Staple has to be requested by the client (or RP in
your language). Web PKI is going the route of short lived
certificates as none of the other mechanisms have scaled. It will be
interesting to see if the token status list concept works better.
Section 5.1 and 5.2, exp, ttl: In PKIX, this time is not technically
an expiry, but an expectation of the next time to issue. It is,
however, treated like an expiry, which means that systems lock up and
refuse connections if they don't have fresher CRLs. Is that what you
want here? The ttl option, which might be less prone to
misunderstanding, if it is listed as a time period vice a point in
time. Also, a ref to the diagram at the end of 13.7 might help (it
certainly helped me understand how you intended these two values to
work together).
I think it was similar feedback that led us to include both exp and ttl.
Agreed to include the reference to Section 13.7.
Working through this we noticed that the implementation consideration
says that exp and ttl are RECOMMENDED, while Section 5 data structures
says they are OPTIONAL. We opted to align with them being RECOMMENDED in
the data structures definition.
Section 5.1 and 5.2, #2: Signature or a MAC algorithm? Keyed MAC?
MACs can (generally) be recomputed, which you don't want.
Agreed. We have added a new section "Status List Token Protection" to
the security considerations, explaining that signatures are the default
and what kind of scenarios are exceptions, where MACs may be useful.
Section 8.1, para 6: Seems like it could be dangerous. Please add
something to Sec Cons to address the potential issues w/ redirects
(why is an infinite redirect bad).
Agreed. We have added a new section "Redirection 3xx" to the security
considerations, explaining what to look out for and linking guidance
from RFC9110.
Section 8.3: numbered lists within numbered lists, there has to be a
better way, maybe numbered lists with alpha sub lists?
Agreed, changed sub lists to alpha.
Section 11: Add a mention of how expired or out of time TTL settings
can be used as a denial of service mechanism. There are a bunch of
ways this can happen, for example, the entity that generates the token
status list is down, or promulgation of the token status list is
blocked. Is there a mitigation for user/integrators of this type of
service?
I'm unsure how TTL settings can be expired or out of time, as its just a
time duration? We've added security guidance for ttl, see other comment.
Section 11/13, compression vulnerabilities: I don't want to hold up
this draft, but I need to consult, as I haven't dealt with compression
issues in a million years (or it seems that way). If there are known
issues with zlib and DEFLATE, we need to mention the issue in Section
11 and the mitigation in Section 13 (or some other reasonable
combination).
To my knowledge, issues only exist with implementations, not the
algorithm itself. Potential threats are so-called "zipbombs" although
modern implementations should have guards against such.
Section 12.3: KYC?
Clarified. Know-Your-Customer - identity proofing in the financial sector.
Section 13.7: Is there guidance on how an issuer should choose both
exp and ttl? If the ttl/exp are too long, a RP doesn't know to check
for a refreshed token status list? If the ttl/exp are too short then
there might be a DOS when the status token list is not refreshed in time.
Agreed. We have added a new Section "Expiration and Caching" to the
security considerations, explaining that Status Issuers could be careful
with their choice of ttl (ttl being too small). However, we like to
avoid guidance containing specific values as this is highly use-case
specific.
Section 14.7: (no change required to the draft) If this request for
registration has already been made, please send me the link to the
mail archive. If this request has not yet been made, please do that
ASAP in accordance with RFC 6838 (and supply me the link to the mail
archive). These requests often take some time, and require some nudging.
I believe we didn't, I think we were not aware it's our job, but we can
have a look.
Normative Reference: Living standards are not classically acceptable
as normative standards in IETF specifications. Can you get either a
permanent anchor or a snapshot for the
(https://whatwg.org/working-mode#anchors) [CORS] reference? (for an
example see draft-ietf-oauth-browser-based-apps)
Agreed, Changed to pinpoint the current version.
Normative Reference: RFC 5226 has been obsoleted by RFC 8126, should
this be updated?
Updated.
--------------------------
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
