These all look good to me. When you push the new version, I'll put it into IETF Last Call. Because of the proximity to IETF 124, I'll make it a 3 week last call (the next telechat isn't until 20 Nov anyway).
If you answer IETF Last Call and review comments promptly, the draft can move to the next step quickly (even w/ a 3 week last call). Deb On Sun, Oct 19, 2025 at 7:02 AM Paul Bastian <[email protected]> wrote: > 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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
