Hi Paul, Apparently my review (based on -06) and your publication of -07 happened at about the same time. I will reread -07 and provide my feedback soon.
Regarding point 4, I wrote a quick test while having lunch that shows that a deflate (level=12) compressed bit-stream becomes much more efficient than a compressed CBOR array, well before the 1.2% average token revocation percentage on the Internet (the numbers differ slightly on each run because the bits which are invalid are randomly selected, but are very close each run): Tokens % Revoked CBOR size Field size ------ --------- --------- ---------- 10^4 0.0% 24 29 10^4 0.1% 51 55 10^4 0.3% 112 93 10^4 0.5% 165 128 10^4 0.8% 240 168 10^4 1.0% 284 191 10^4 1.2% 328 206 10^4 1.5% 401 235 10^4 2.0% 510 279 10^4 3.0% 735 331 10^4 5.0% 1167 429 10^5 0.0% 24 47 10^5 0.1% 327 245 10^5 0.3% 833 540 10^5 0.5% 1284 803 10^5 0.8% 1977 1178 10^5 1.0% 2422 1382 10^5 1.2% 2867 1590 10^5 1.5% 3529 1870 10^5 2.0% 4638 2329 10^5 3.0% 6588 2888 10^5 5.0% 10557 3806 10^6 0.0% 24 156 10^6 0.1% 2667 1925 10^6 0.3% 7359 4861 10^6 0.5% 11592 7361 10^6 0.8% 17246 10764 10^6 1.0% 20874 12854 10^6 1.2% 24348 14825 10^6 1.5% 29415 17538 10^6 2.0% 37700 21857 10^6 3.0% 53821 28415 10^6 5.0% 85279 37429 thanks, -rohan On Thu, Feb 6, 2025 at 12:11 AM Paul Bastian <paul.bast...@posteo.de> wrote: > Hi Rohan, thanks for your feedback. Answers are inline: > On 06.02.25 02:21, Rohan Mahy wrote: > > Hi, > I support the overall goals of this document. I do *not* think the > document was ready for WGLC; at minimum there are still plenty of TBDs and > TODOs in the text. Below are some comments: > > We do not have any TODOs in the text. We have TBD in the text for values > that will be defined by IANA registry which is standard procedure in other > drafts as well. > > > 1. I would prefer we make the document standards track instead of > informational. > > This is correct, this draft has always been planned for the standards > track, we will fix the metadata to accompany for that. > > > 2. You have to read through to section 6.2 to see how a verifier > determines the index of a token it receives in the status value array. > Please add one sentence in the Introduction saying that the index is in the > referenced token. You could even update the diagram to reflect this. > > This in incorrect, the introduction currently contains the following text: > "Each Referenced Token is allocated an index during issuance that > represents its position within this bit array. The value of the bit(s) at > this index corresponds to the Referenced Token's status." We like the other > idea, we will investigate the idea to add this to the diagram. > > > 3. The document uses status_list (JSON object) and StatusList (CBOR map) > to refer to the map, but Status List seems to be used to refer to both the > compressed byte string (in Section 5) and the uncompressed byte array of > status values (in Section 4 step 2, and Section 4.1 2nd sentence). > > This is correct, we will separate, the parts of section 4 that talk about > the the uncompressed byte array into its own subsection and not use the > wording Status List for this. Otherwise, through out the rest of the > document, Status List refers to the compressed byte array as defined in the > terminology. > > > 4. CRLs (Certificate Revocation Lists) are a list of the serial numbers of > every invalidated certificate (with a reason code). While a compressed 1 or > 2 bit status per token tends to be very compact per issued token, it would > be useful for the draft to show an analysis of what percentage of issued > tokens would need to be invalid before a status list would be smaller than > a CRL-like structure that only references invalid indexes in a (possibly > compressed) ordered list (assuming randomly distributed invalidations). > > I have not seen performance or comparative measures like this in many > other drafts, we have made analysis and performance measures for our > presentations at IEFT, for example here: > https://docs.google.com/presentation/d/1m59OC8uKM4nZ14aH2TM9r2mxEhOiP-G5uqzAZ7oOAUk/edit#slide=id.g2318b641e56_0_23 > > The comparison with the CRL depends on a bunch of parameters and > assumptions, so it's not that easy. > > What does the working group think about including performance metrics > itself in the draft? > > > 5. There is no discussion of maximum or recommended limits to the size of > a Status List. Starting ambitiously, idx is a JSON Number, so we should > probably follow the recommendation in > https://datatracker.ietf.org/doc/html/rfc8259#section-6 and say it MUST > NOT be larger than (2^53) - 1, but a 1-bit status list with that many > indexes would be 10TB with > 10:1 compression. I think the document needs > to define a reasonable maximum size, and could allow profiles to make that > smaller. > > I haven't seen an guidance like this in CRL draft either and I believe > that our assumptions about reasonable sizes in 2025 will not hold in 2035, > so I'm hesitant to add this kind of guidance. > > > 6. I think it is a mistake to compress the entire status_list (JSON > object) or StatusList (CBOR map). Instead it would be better to compress > just the status value array (the "lst" field). > > - Naive implementations might try to decompress the entire object/map > to get the bit field before trying to read the array. > - If you make the "lst" field an uncompressed byte string in JSON, it > will need to be base64url encoded *before* you compress it. Then the > status_list object would need to be base64url encoded again. That's > wasteful and accomplishes nothing as far as I can tell. > - Because JSON maps and CBOR maps are encoded differently, compressing > the object/map will make it hard to use a status list across token encoding > environments. If only the contents of the "lst" field was compressed, it > would allow an issuer to generate JWT/CWT pairs with the same index and use > one status list between them. (both would be invalidated together). > > I think this is a misunderstanding. The Status List from Section 4 is > already compressed in the Step 3. Section 4.1 about Status List in JSON > Format has an "lst" field that then contains the compressed byte array, > which must however be base64-encoded as JSON does not support. byte array. > Section 4.2 about Status List in CBOR Format has an "lst" field that then > contains the compressed byte array directly. I don't see how we can be any > more space-efficient than this. Therefore, JSON and CBOR structures would > contain the same Status List byte array. > > Furthermore, we have test vectors in the Appendix, so that implementations > can verify correctness. > > 7. I am surprised by some details of the CBOR encoding: > > - Traditionally, CWT maps have integer keys for comment values. Why > not replace "bits" with 1, and "lst" with 2? > - The document registers CWT claim keys 65534 and 65535. Why not ask > for unused numbers in the 24-256 range? > - It wasn't immediately clear from the text that the status list is a > bstr encoding of the compressed serialized map. If we implement my > recommendation in #6, this problem goes away. > > - We have talked to people from the CBOR world and apparently this is what > people do today, e.g. in the ISO mdoc world, but we are open for > discussions here. > - We have talked to Mike Jones about this, who is one of the designated > experts for CWT and this was his recommendation > - We have the text: "lst: REQUIRED. Byte string (Major Type 2) that > contains the Status List as specified in Section 4 > <https://drafts.oauth.net/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.html#status-list>." > which clearly references bstr. > > 8. There should be a CDDL snippet for the CBOR. I would be happy to > provide one once points 6 and 7 are addressed. > > If CDDL is requested and helps the understanding, then we can add this to > the draft. > > > 9. I think it will be important for implementers to have some advice on > constructing a logical scope for Referenced Tokens to be interoperable, so > that issuers have good practices for recycling indexes. For example if all > the tokens with the same status list URL have roughly the same duration of > validity, cycling through URL paths would eventually allow reuse after all > previously referenced tokens had expired. > Is it ok to generate a Status List for 100 tokens, then generate a new > Status List with the same "referenced token scope" that covers 200 tokens > (including the first 100 tokens)? If so, that would be good to say. > > We have some guidance here: > https://drafts.oauth.net/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.html#name-referenced-token-lifecycle > saying "The lifetime of a Status List Token depends on the lifetime of its > Referenced Tokens. Once all Referenced Tokens are expired, the Issuer may > stop serving the Status List Token." We did not want to encourage re-usage > of indices, as this may introduce security issues. > > 10. NIT: Section 6.3 refers to status_list but I think you mean StatusList > > The CWT status structure says: "Each data item in the Status CBOR > structure comprises a key-value pair, where the key must be a CBOR text > string (Major Type 3) specifying the identifier of the status mechanism and > the corresponding value defines its contents. This specification defines > the following data items:", so indeed "status_list" refers to a CBOR text > string. > > > Thanks, > -rohan > > Thanks for your feedback. Best regards, > > Paul+Christian > > > > On Thu, Jan 2, 2025 at 5:53 AM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > wrote: > >> All, >> >> This is a WG Last Call for the *Token Status List *document. >> https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ >> >> Please, review this document and reply on the mailing list if you have >> any comments or concerns, by *Jan 17th*. >> Note that this document will be discussed during the OAuth WG *interim* >> on *Jan 13th*. >> >> Regards, >> Rifaat & Hannes >> >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-le...@ietf.org >> > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
