[Feature]: Populate isOptional on DBX baseline entries where the field is absent

从 dbx_info_msft_latest.json 开始，盘点每个缺少 isOptional 的撤销条目。确定每个缺失值是 true 还是 false，同时保留哈希、签名机构归属和顺序，然后验证每个条目都有显式的布尔值，并且基线仍是有效的 JSON。

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