Feature Overview
Populate isOptional on DBX baseline entries where the field is absent
Summary
In the global DBX baseline (dbx_info_msft_latest.json), some revocation entries carry an explicit isOptional flag while others omit it entirely. Consumers that parse this baseline have to infer optionality from the field's absence, which is ambiguous and error-prone. Please set isOptional explicitly on every entry so the field is always present with a defined boolean value.
Context
The baseline mixes mandatory and optional revocations (e.g., the BlackLotus-attributed hashes are marked isOptional). Today that distinction is only reliable for entries that already include the field. Entries missing it force consumers to guess whether absence means false, true, or "unspecified."
Request
- Add
isOptional to all entries in dbx_info_msft_latest.json that currently lack it, with an explicit true/false value.
- Treat the field as required going forward so future additions always include it.
Why it matters
Explicit, always-present optionality lets downstream tooling parse the baseline deterministically instead of relying on field absence as implicit signal. (Motivation on our side: our DBX parsing tooning consumes this baseline and currently has to special-case missing isOptional.)
Proposed change
For each entry without the field, add "isOptional": <true|false> reflecting its intended enforcement status. No change to hashes, signing-authority attribution, or ordering — field-population only.
Open questions
- For entries where the field is currently absent, what is the intended default —
false (mandatory), or should each be reviewed individually?
Solution Overview
In the global DBX baseline (dbx_info_msft_latest.json), the isOptional flag is present on some revocation entries but omitted on others. Consumers that parse this baseline currently have to infer optionality from the field's absence, which is ambiguous.
Please populate isOptional explicitly on every entry that currently lacks it, with a defined true/false value, and treat the field as required going forward so future additions always include it.
This makes the mandatory-vs-optional distinction (e.g., the BlackLotus-attributed hashes marked isOptional) parseable deterministically, instead of relying on field absence as an implicit signal. No change to hashes, signing-authority attribution, or ordering is requested — this is field-population only.
Alternatives Considered
Inferring optionality from field absence on the consumer side (treating missing isOptional as false). Rejected because absence is ambiguous — it could mean mandatory, optional, or unspecified — and requires every downstream tool to hard-code the same assumption rather than reading an explicit value from the baseline.
Urgency
Low
Are you going to implement the feature request?
I will implement the feature
Do you need maintainer feedback?
No maintainer feedback needed
Anything else?
No response
Feature Overview
Populate
isOptionalon DBX baseline entries where the field is absentSummary
In the global DBX baseline (
dbx_info_msft_latest.json), some revocation entries carry an explicitisOptionalflag while others omit it entirely. Consumers that parse this baseline have to infer optionality from the field's absence, which is ambiguous and error-prone. Please setisOptionalexplicitly on every entry so the field is always present with a defined boolean value.Context
The baseline mixes mandatory and optional revocations (e.g., the BlackLotus-attributed hashes are marked
isOptional). Today that distinction is only reliable for entries that already include the field. Entries missing it force consumers to guess whether absence meansfalse,true, or "unspecified."Request
isOptionalto all entries indbx_info_msft_latest.jsonthat currently lack it, with an explicittrue/falsevalue.Why it matters
Explicit, always-present optionality lets downstream tooling parse the baseline deterministically instead of relying on field absence as implicit signal. (Motivation on our side: our DBX parsing tooning consumes this baseline and currently has to special-case missing
isOptional.)Proposed change
For each entry without the field, add
"isOptional": <true|false>reflecting its intended enforcement status. No change to hashes, signing-authority attribution, or ordering — field-population only.Open questions
false(mandatory), or should each be reviewed individually?Solution Overview
In the global DBX baseline (dbx_info_msft_latest.json), the isOptional flag is present on some revocation entries but omitted on others. Consumers that parse this baseline currently have to infer optionality from the field's absence, which is ambiguous.
Please populate isOptional explicitly on every entry that currently lacks it, with a defined true/false value, and treat the field as required going forward so future additions always include it.
This makes the mandatory-vs-optional distinction (e.g., the BlackLotus-attributed hashes marked isOptional) parseable deterministically, instead of relying on field absence as an implicit signal. No change to hashes, signing-authority attribution, or ordering is requested — this is field-population only.
Alternatives Considered
Inferring optionality from field absence on the consumer side (treating missing isOptional as false). Rejected because absence is ambiguous — it could mean mandatory, optional, or unspecified — and requires every downstream tool to hard-code the same assumption rather than reading an explicit value from the baseline.
Urgency
Low
Are you going to implement the feature request?
I will implement the feature
Do you need maintainer feedback?
No maintainer feedback needed
Anything else?
No response