Following various discussions about the after prefix part in GCVE, BCP-04 will include recommendations and best practices, especially for GNAs that do not have an ID generation and allocation process.
As mentioned in issue #4 concerning the generic regular expression, which allows a wide range of possibilities, we would like to define best practices to help GNAs create meaningful identifiers. The document should include good examples from different organizations already performing ID allocation, such as GitHub (GHSA), the CVE Program, and others.
Following discussions in a standard work-group with the GCVE board regarding the recommended size of GCVE identifiers, it was agreed that no strict size limit will be enforced (similar to the flexibility of URIs). However, a recommendation is provided.
The recommendation is to use identifiers of up to 128 bytes including the prefix.
Another discussion point in the work-group concerned the use of non–7-bit character sets. Some GNAs expressed interest in supporting UTF-8 characters in identifiers. While this would improve flexibility, it could also introduce significant overhead in software implementations that process GCVE identifiers.
To capture these decisions, two sections will be added in BCP-04:
ID Format (including size considerations)
Encoding (supported character sets and constraints)
Based on input from @ClausHoumann, GCVE identifiers are not limited to describing a newly disclosed vulnerability. They may also:
extend the description of an existing vulnerability (e.g., with additional metadata),
serve as a reference to a patch, or
establish a parent/child relationship with another vulnerability.
The design of GCVE explicitly allows multiple identifiers for the same vulnerability to provide complementary information or alternative perspectives (e.g., in cases of vendor refusal or disagreement). There is no single authoritative identifier for a given vulnerability. Instead, GNAs may provide different viewpoints on similar vulnerabilities.
The model also allows a GNA to reference another GCVE identifier issued by a different GNA, covering scenarios such as parallel or independent vulnerability discoveries.
Can we base the max length on some sensible technical limit for likely other protocols? I get the desire to limit to 128 bytes, but it seems a little arbitrary.
According to this StackOverflow discussion (first hit for “url max length”), the longest practical length for an HTTP URL (including domain, GET parameters) is about 2000 “characters.” So, let’s reduce “characters” to “bytes” (ignoring multibyte characters for now), and just know that 2000 bytes is a very hard ceiling for an entire URL that links to a GCVE record. It would be hard to defend a GCVE ID greater than 2000 bytes. And you’ll want a little wiggle room to handle those domains and GET parameters.
But also, 2000 is way bigger than 128, so I feel like a 128-byte limit seems pretty low.
The DNS spec defines a max length for names, so why not just borrow from that spec and make 255 the max length.
It’s defensible, since it comes from a well-established standard, and any future encoding will fit comfortably in a one-byte unsigned length field (if you’re using signed lengths, seek counseling). Notably, a 255 byte maxlen doesn’t invalidate the extant example of a 146-byte identifier, which is very real and serious and has very important information encoded in it.
The 255 byte could be also a valid max length. What’s your feeling @cedric about it? I see some use-case with TXT records too which are also limited to 255 characters. If there are no formal objection, we could extend those to 255 byte and update the BCP-04. I have a feeling this discussion might go down in history…
I’m not sure the number of byte should be specified as the encoding is not (and I don’t think it’s relevant to specify it in this context). Moreover, since there is a reference of 7 bits character, it’s not obvious if we are talking about 255 characters or 291 characters (with a 7 bits encoding).
So, it would be better to s/byte/character/ in the document
