# GCVE-BCP-08 - GCVE GNA Directory File (draft)

**URL:** <https://discourse.ossbase.org/t/gcve-bcp-08-gcve-gna-directory-file-draft/754>\
**Category:** GCVE\
**Tags:** gcve\
**Created:** [January 31, 2026, 8:23am UTC](https://discourse.ossbase.org/t/gcve-bcp-08-gcve-gna-directory-file-draft/754 "2026-01-31T08:23:37Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![adulau](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/adulau/32/6_2.png) [@adulau](https://discourse.ossbase.org/u/adulau)\
**Post date:** [January 31, 2026, 8:23am UTC](https://discourse.ossbase.org/t/gcve-bcp-08-gcve-gna-directory-file-draft/754/1 "2026-01-31T08:23:37Z")

</div>

Following various discussions and the meeting at FOSDEM, we will create the GCVE-BCP-08 describing the directory JSON format.

# GCVE-BCP-08 - GCVE GNA Directory File

## Status of This Document

This document defines **GCVE-BCP-08** , which specifies the structure and semantics  
of the **GCVE GNA Directory File**. This file `gcve.json` enumerates known **GCVE Numbering Authorities (GNAs)** and associated metadata used by the GCVE ecosystem.

## Scope

The GCVE GNA Directory File is a JSON document containing an array of GNA descriptors. Each entry represents a registered or reserved GNA identifier and provides optional metadata describing publication endpoints, allocation capabilities, and intended usage.

This directory is intended to be:

- Machine-readable
- Publicly distributable
- Stable, except for metadata updates

## File Format

- **Format:** JSON
- **Top-level structure:** Array of objects
- **Encoding:** UTF-8
- **Time format:** RFC 3339 / ISO 8601 UTC timestamps

## GNA Entry Fields

Each GNA entry MAY contain the following fields:

| Field name | Type | Required | Description |
| --- | --- | --- | --- |
| `id` | integer | YES | Unique numeric GNA identifier |
| `short_name` | string | YES | Short, human-readable identifier |
| `full_name` | string | YES | Full legal or organizational name |
| `usage` | string | NO | Normative usage description or restrictions |
| `cpe_vendor_name` | string | NO | Associated CPE vendor name |
| `gcve_url` | string | NO | Public vulnerability disclosure page |
| `gcve_api` | string | NO | API endpoint providing machine-readable interface |
| `gcve_dump` | string | NO | Bulk data or advisory feed |
| `gcve_allocation` | string | NO | Allocation policy or identifier issuance page |
| `gcve_pull_api` | string | NO | Endpoint for GCVE pull-based synchronization in GCVE-BCP-05 format |
| `inserted_at` | string | YES | Entry creation timestamp (UTC) (generated) |
| `updated_at` | string | YES | Last metadata update timestamp (UTC) (generated) |

### Notes

- The `usage` field is **normative** when present.
- Some IDs (e.g. `0`, `65535`) are **reserved** and carry special semantic meaning.
- Absence of a URL or API field does **not** imply lack of authority, only absence  
of declared endpoints.

## Reserved and Special GNA IDs

### ID `0` — CVE Program

This GNA ID is used as a prefix and **MUST** be followed by the official CVE ID.

### ID `65535` — Test GNA

This GNA ID is reserved for testing purposes. It may appear in publications generated by instances testing the publication process; however, any content produced using this GNA ID **MUST NOT** be considered valid or authoritative.

---

<div class="post-metadata">

**Author:** ![jgamblin](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/jgamblin/32/574_2.png) [@jgamblin](https://discourse.ossbase.org/u/jgamblin)\
**Post date:** [January 31, 2026, 8:37pm UTC](https://discourse.ossbase.org/t/gcve-bcp-08-gcve-gna-directory-file-draft/754/2 "2026-01-31T20:37:26Z")

</div>

Thanks for putting this draft together. Establishing a machine-readable directory for GNAs is a critical step for the ecosystem. After reviewing the proposal, I have five primary suggestions to ensure the directory is robust enough for real-world operations.

### GNA Status and Lineage Tracking (M&A / Rebranding)

In the vulnerability management landscape, authorities frequently merge, change names, or are acquired. The current schema identifies who a GNA is, but it doesn’t track what happened to them over time.

I propose adding a **status** field and a **superseded\_by** field. This allows the directory to track the “ancestry” of an authority. For example, when Alcatel-Lucent was acquired by Nokia, their responsibilities shifted. Without lineage tracking, we risk “orphaned” identifiers or ambiguity in historical records when looking up older vulnerabilities.

### Missing Fields: Alignment with CVE CNAsList

The current draft is missing high-value fields that make the CVE Program’s directory so useful. Specifically, we should look at the fields used in the official CNAsList.json ([https://raw.githubusercontent.com/CVEProject/cve-website/dev/src/assets/data/CNAsList.json](https://raw.githubusercontent.com/CVEProject/cve-website/dev/src/assets/data/CNAsList.json)).

To ensure the GCVE directory is functionally useful for researchers and automation, we should include:

- **Detailed Scope:** A clear definition of the products or services the GNA is authorized to cover.

- **Contact Information:** A standardized way to list security contact points, such as a contact email or security advisory page.

### Proposed JSON Structure Example

Combining the points above, here is how a transition and the additional metadata might look in the JSON:

JSON

```auto
[
  {
    "id": 101,
    "short_name": "ALU",
    "full_name": "Alcatel-Lucent",
    "status": "deprecated",
    "superseded_by": 102,
    "usage": "Legacy entry for historical record following acquisition by Nokia.",
    "scope": "All Alcatel-Lucent networking hardware and software.",
    "cpe_vendor_name": "alcatel-lucent",
    "gcve_url": "https://www.alcatel-lucent.com/security",
    "contact": [
      {
        "type": "email",
        "value": "security@alcatel-lucent.com"
      }
    ],
    "inserted_at": "2024-01-01T12:00:00Z",
    "updated_at": "2026-01-31T09:00:00Z"
  },
  {
    "id": 102,
    "short_name": "NOKIA",
    "full_name": "Nokia",
    "status": "active",
    "usage": "Normative GNA for Nokia and acquired subsidiaries.",
    "scope": "Authoritative GNA for all Nokia products and legacy Alcatel-Lucent acquisitions.",
    "cpe_vendor_name": "nokia",
    "gcve_url": "https://www.nokia.com/notices/responsible-disclosure/",
    "gcve_api": "https://api.nokia.com/v1/gcve",
    "gcve_dump": "https://www.nokia.com/security/advisories/bulk.json",
    "gcve_allocation": "https://www.nokia.com/security/gna-policy",
    "gcve_pull_api": "https://api.nokia.com/v1/gcve/sync",
    "contact": [
      {
        "type": "email",
        "value": "psirt@nokia.com"
      }
    ],
    "inserted_at": "2026-01-31T09:00:00Z",
    "updated_at": "2026-01-31T09:00:00Z"
  }
]

```

### 4. Enforce RFC 3339 for Temporal Fields

The current draft references both RFC 3339 and ISO 8601. While related, ISO 8601’s broad flexibility often introduces parsing friction in automated pipelines.

I am currently having this exact discussion with the CVE Program regarding their own standards. To ensure strict machine-readability and ecosystem-wide alignment, **we should pick exactly one format.** I strongly recommend we commit exclusively to **RFC 3339**. Detailed reasoning for this distinction can be found here: [https://ijmacd.github.io/rfc3339-iso8601/](https://ijmacd.github.io/rfc3339-iso8601/)

### 5. Schema and Data Constraints

- **Schema Versioning:** We should consider a top-level `schema_version` field to help parsers handle future updates to the JSON structure.

- **ID Range:** Since 65535 is already reserved, we should explicitly define the `id` field as a 16-bit unsigned integer to ensure consistency across different database and language implementations.

---

<div class="post-metadata">

**Author:** ![cedric](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/cedric/32/112_2.png) [@cedric](https://discourse.ossbase.org/u/cedric)\
**Post date:** [January 31, 2026, 10:50pm UTC](https://discourse.ossbase.org/t/gcve-bcp-08-gcve-gna-directory-file-draft/754/3 "2026-01-31T22:50:42Z")

</div>

A new release of the [GCVE client](https://pypi.org/project/gcve/) is available.

The client has been used for some time as a module in Vulnerability-Lookup to maintain a synchronized local cache of GNAs. It can as well be used as a command line tool.

This new release now also supports caching the new `references.json` file. This addition will be particularly useful for the next version of Vulnerability-Lookup!

---

<div class="post-metadata">

**Author:** ![adulau](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/adulau/32/6_2.png) [@adulau](https://discourse.ossbase.org/u/adulau)\
**Post date:** [February 1, 2026, 7:38am UTC](https://discourse.ossbase.org/t/gcve-bcp-08-gcve-gna-directory-file-draft/754/4 "2026-02-01T07:38:42Z")

</div>

Thanks! Indeed that’s a good point. Do we need to document the reference file in the same BCP or we keep it as experimental for the time being? and see later if it’s required to document it more deeply?

---

<div class="post-metadata">

**Author:** ![adulau](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/adulau/32/6_2.png) [@adulau](https://discourse.ossbase.org/u/adulau)\
**Post date:** [February 1, 2026, 5:28pm UTC](https://discourse.ossbase.org/t/gcve-bcp-08-gcve-gna-directory-file-draft/754/5 "2026-02-01T17:28:33Z")

</div>

This version includes feedback from @cedric , @jgamblin, and participants of the  
informal FOSDEM workshop in Brussels who are familiar with the CNA model and the  
CVE Program.

Regarding the integration of CNA-related fields, no decision has yet been made  
on how these should be represented in the JSON structure. The current idea is  
to introduce a dedicated namespace in which the complete original CNA entry  
could be embedded without modification. And a new one for GCVE to avoid some  
legacy which might not be required but also future extension in GCVE.

The `status` field, as proposed by @jgamblin, has now been integrated, and there  
is strong consensus on this aspect. The agreement on using RFC 3339 for  
timestamps was also clear, and we now explicitly avoid referencing ISO standards,  
as they are not open standards.

Regarding the proposed structural change to add a schema version, introducing a  
new root-level element may break existing parsers. We therefore need to evaluate  
alternative approaches for introducing a versioning mechanism without  
disrupting current implementations.

# GCVE-BCP-08 — GCVE GNA Directory File

## Status of This Document

This document defines **GCVE-BCP-08** , which specifies the structure and semantics  
of the **GCVE GNA Directory File**. This file enumerates known **GCVE Numbering  
Authorities (GNAs)** and associated metadata used by the GCVE ecosystem.

The key words **MUST** , **MUST NOT** , **SHOULD** , **SHOULD NOT** , and **MAY** in this document are to be interpreted as described in RFC 2119.

## Purpose and Applicability

This Best Current Practice (BCP) exists **for implementers, parsers, and users**  
of the GCVE GNA Directory File.

The directory file described in this document is **exclusively generated and  
maintained by GCVE **and serves as the** official and authoritative directory**  
of GCVE Numbering Authorities. Third parties **MUST NOT** generate alternative or  
competing versions of this directory while claiming GCVE authority.

The GCVE GNA Directory File **MUST** be published as a **signed artifact** by  
GCVE. The digital signature establishes the authenticity and integrity of the  
directory and allows consumers to verify that the file originates from GCVE and  
has not been altered.

The signature format, trust model, and verification procedures are defined in  
**GCVE-BCP-01**. Consumers of this file **MUST** verify the signature in  
accordance with GCVE-BCP-01 prior to processing or relying on the contents of  
the directory.

Consumers of the file (including tooling, aggregation platforms, vulnerability  
databases, and archival systems) **MUST** interpret and process the file  
according to this specification to ensure consistent handling of identifiers,  
authority lineage, and historical data.

This BCP does **not** define a submission or modification mechanism for GNAs.  
It strictly defines the **format, semantics, authenticity requirements, and  
interpretation** of the file as published by GCVE.

## Scope

The GCVE GNA Directory File is a JSON (ECMA 404) document containing an array of GNA  
descriptors. Each entry represents a registered or reserved GNA identifier and  
provides optional metadata describing publication endpoints, allocation  
capabilities, lifecycle status, and usage constraints.

This directory is intended to be:

- Machine-readable
- Publicly distributable
- Stable and append-only, except for metadata updates

## Authority Lifecycle and Lineage

In the vulnerability management ecosystem, authorities may merge, be acquired,  
change names, or cease operations. To prevent ambiguity in historical records  
and to avoid orphaned identifiers, the GCVE GNA Directory **MUST** support  
explicit lifecycle and lineage tracking.

Each GNA entry **MAY** include a `status` field indicating its current lifecycle  
state. When an authority is no longer active due to renaming, merger, or  
acquisition, the entry **SHOULD** include a `superseded_by` field referencing the  
`id` of the successor GNA.

Consumers of the directory **MUST** treat superseded GNA IDs as historically  
valid and **MUST NOT** reinterpret or reassign identifiers issued under a prior  
authority.

## Timestamp Requirements

All timestamps in the GCVE GNA Directory File **MUST** conform strictly to  
**RFC 3339** and **MUST** be expressed in UTC. The use of the `Z` suffix is  
**REQUIRED**.

## File Format

- **Format:** JSON
- **Encoding:** UTF-8
- **Top-level structure:** Array of GNA objects
- **Timestamp format:** RFC 3339 (UTC)

## GNA Entry Fields

Each GNA entry **MAY** contain the following fields:

| Field name | Type | Required | Description |
| --- | --- | --- | --- |
| `id` | integer | YES | Unique numeric GNA identifier |
| `short_name` | string | YES | Short, human-readable identifier |
| `full_name` | string | YES | Full legal or organizational name |
| `status` | string | NO | Lifecycle state of the authority |
| `superseded_by` | integer | NO | Identifier of the successor GNA |
| `usage` | string | NO | Normative usage description or restrictions |
| `cpe_vendor_name` | string | NO | Associated CPE vendor name |
| `gcve_url` | string | NO | Public vulnerability disclosure page |
| `gcve_api` | string | NO | API endpoint providing GCVE-compatible data |
| `gcve_dump` | string | NO | Bulk data or advisory feed |
| `gcve_allocation` | string | NO | Allocation policy or identifier issuance page |
| `gcve_pull_api` | string | NO | Endpoint for GCVE pull-based synchronization |
| `inserted_at` | string | YES | Entry creation timestamp (RFC 3339, UTC) |
| `updated_at` | string | YES | Last metadata update timestamp (RFC 3339, UTC) |

### `status` field

When present, the `status` field **MUST** take one of the following values:

- `active` — currently valid and operational
- `renamed` — authority renamed, same operational scope
- `merged` — authority merged into another entity
- `acquired` — authority acquired by another entity
- `retired` — authority no longer active, no successor declared
- `reserved` — reserved or special-purpose identifier

If `status` is `renamed`, `merged`, or `acquired`, the `superseded_by` field  
**SHOULD** be present.

### Notes

- The `usage` field is **normative** when present.
- Presence in this directory **MUST NOT** be interpreted as an assertion of  
trustworthiness.
- Consumers **MUST** apply their own trust, validation, and policy controls.

## Reserved and Special GNA IDs

### ID `0` — CVE Program

This GNA ID is used as a prefix and **MUST** be followed by the official CVE ID.

### ID `65535` — Test GNA

This GNA ID is reserved for testing purposes. It may appear in publications  
generated by instances testing the publication process; however, any content  
produced using this GNA ID **MUST NOT** be considered valid or authoritative.

## JSON Schema

The following JSON Schema formally defines the structure of the GCVE GNA  
Directory File.

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://gcve.eu/schema/gcve-bcp-08-gna-directory.json",
  "title": "GCVE GNA Directory File (GCVE-BCP-08)",
  "type": "array",
  "items": {
    "type": "object",
    "required": ["id", "short_name", "full_name", "inserted_at", "updated_at"],
    "properties": {
      "id": {
        "type": "integer",
        "minimum": 0
      },
      "short_name": {
        "type": "string",
        "minLength": 1
      },
      "full_name": {
        "type": "string",
        "minLength": 1
      },
      "status": {
        "type": "string",
        "enum": ["active", "renamed", "merged", "acquired", "retired", "reserved"]
      },
      "superseded_by": {
        "type": "integer",
        "minimum": 0
      },
      "usage": {
        "type": "string"
      },
      "cpe_vendor_name": {
        "type": "string"
      },
      "gcve_url": {
        "type": "string",
        "format": "uri"
      },
      "gcve_api": {
        "type": "string",
        "format": "uri"
      },
      "gcve_dump": {
        "type": "string",
        "format": "uri"
      },
      "gcve_allocation": {
        "type": "string",
        "format": "uri"
      },
      "gcve_pull_api": {
        "type": "string",
        "format": "uri"
      },
      "inserted_at": {
        "type": "string",
        "format": "date-time",
        "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\\.[0-9]+)?Z$"
      },
      "updated_at": {
        "type": "string",
        "format": "date-time",
        "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\\.[0-9]+)?Z$"
      }
    },
    "additionalProperties": false
  }
}
```

---

<div class="post-metadata">

**Author:** ![adulau](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/adulau/32/6_2.png) [@adulau](https://discourse.ossbase.org/u/adulau)\
**Post date:** [May 29, 2026, 1:02pm UTC](https://discourse.ossbase.org/t/gcve-bcp-08-gcve-gna-directory-file-draft/754/6 "2026-05-29T13:02:46Z")

</div>

We need to fully review the document after the workshop in Luxembourg with @cedric which shows that the format is a bit complex.