a decompression bomb and maximumNumberOfEntries
The specification states that
This specification uses a minimum list length of 131,072.
and
The default status list size is 131,072 entries, equivalent to 16 KB of single bit values.
What's a maximum list length, or maximumNumberOfEntries?
Should the specification provide any means and/or recommendations to protect holders and verifiers from excessive resource consumption (CPU, memory) by accidental, unintentional, or even malicious actions by issuers?
We should probably set (or suggest) a maximum list size of 2^26 (= 67108864) as this is the largest list that fits in 10MiB (67108864 bits / 8 / 1024 / 1024 = 8MiB) with maximum randomness. 10MiB is a common boundary adopted elsewhere in the VC ecosystem for maximum document storage size (based on various limits in common document storage systems like MongoDB/Couchbase being in the 16-20MiB range). This 10MiB boundary has been considered sufficient to allow for headroom for additional metadata to be stored in these systems in a single document. Other document storage systems have boundaries that are already considered too small for many VCs (1-2MiB, such as Firestore/Dynamo/Cosmos, etc.).
It looks like we might want to discuss or give additional guidance in the security considerations section around handling of lists wrt. excessive resource consumption.