docs(sbom): correct NTIA/SPDX claims; fix broken anchor

Three documentation corrections from the wolfssl-1zj review:

  * README.md previously said 'Both produce SPDX 2.3 + CycloneDX
    1.6 JSON validated against NTIA minimum elements'.  Neither
    entry point runs an NTIA-minimum-elements checker.  The
    autotools 'make sbom' path runs pyspdxtools (SPDX-spec
    validation, not NTIA-specific) and gates the build on it;
    the standalone embedded path runs no validation by default.
    Replace with text saying the SBOMs are intended to satisfy
    NTIA minimum elements, that only the autotools path runs
    SPDX validation, and that neither path runs an NTIA checker
    by default.  Matters because downstream integrators quoting
    this README to auditors must not be misled into claiming
    NTIA validation has been performed (1zj.13).

  * doc/CRA.md previously named ntia-conformance-checker
    alongside pyspdxtools as a tool that 'will reject the SBOM
    otherwise' when a LicenseRef has no hasExtractedLicensingInfos
    block.  ntia-conformance-checker validates the NTIA Minimum
    Elements (supplier, component name, version, unique ID,
    dependency relationships, author, timestamp) -- it does NOT
    enforce SPDX 2.3 \xc2\xa710.1 extracted-text completeness, which is
    a SPDX schema concern enforced by pyspdxtools.  A reader who
    relied on the claim would get a false pass on a malformed
    LicenseRef SBOM.  Drop the misleading mention; add a
    sentence stating what ntia-conformance-checker actually
    checks (1zj.16).

  * doc/SBOM.md anchor link 'See [Prerequisites for make bomsh]
    (#3-make-bomsh)' resolved to the top of section 3 instead
    of the \xc2\xa73.1 prerequisites subsection.  Fix to the GFM
    auto-anchor for '### 3.1 Prerequisites for make bomsh',
    which is #31-prerequisites-for-make-bomsh (1zj.18).

Closes wolfssl-1zj.13, wolfssl-1zj.16, wolfssl-1zj.18

Author: MarkAtwood

README.md

@@ -45,9 +45,13 @@ Act (CRA) compliance via two entry points:
 - `make sbom` for Linux server / Debian / RPM / Yocto / FIPS-Ready
   builds that already use `./configure && make`.
 
-Both produce SPDX 2.3 + CycloneDX 1.6 JSON validated against NTIA
-minimum elements. See `doc/SBOM.md` for per-toolchain recipes and the
-full flag reference.
+Both produce SPDX 2.3 + CycloneDX 1.6 JSON intended to satisfy the
+NTIA minimum elements. The `make sbom` path additionally runs
+SPDX-spec validation via `pyspdxtools` and gates the build on it;
+the standalone path validates only on demand (see `doc/SBOM.md`
+§ 1.3). Neither path runs an NTIA-minimum-elements checker by
+default. See `doc/SBOM.md` for per-toolchain recipes and the full
+flag reference.
 
 ## OmniBOR / Bomsh
 

doc/CRA.md

@@ -181,9 +181,12 @@ make sbom \
 `SBOM_LICENSE_TEXT` is **required** whenever `SBOM_LICENSE_OVERRIDE` uses a
 custom `LicenseRef-*` identifier.  SPDX 2.3 §10.1 requires the actual licence
 text to be embedded in `hasExtractedLicensingInfos` for any LicenseRef used in
-the document; conformant validators (e.g. `pyspdxtools`, `ntia-conformance-checker`)
-will reject the SBOM otherwise.  The file should contain the plain-text
-licence agreement you received from wolfSSL.
+the document; SPDX-conformant validators (e.g. `pyspdxtools`) will reject the
+SBOM otherwise.  `ntia-conformance-checker` validates a separate set of NTIA
+minimum elements (supplier, component name, version, unique identifier,
+dependency relationships, author, timestamp) and will **not** catch a missing
+extracted-text block — do not rely on it to gate this case.  The file should
+contain the plain-text licence agreement you received from wolfSSL.
 
 If `SBOM_LICENSE_OVERRIDE` is set to a `LicenseRef-*` and `SBOM_LICENSE_TEXT`
 is missing, `make sbom` exits with an error rather than emit an invalid SBOM

doc/SBOM.md

@@ -381,7 +381,7 @@ make bomsh
 ```
 
 Additionally requires `bomtrace3` and `bomsh_create_bom.py` in `PATH`.
-See [Prerequisites for make bomsh](#3-make-bomsh) below.
+See [Prerequisites for make bomsh](#31-prerequisites-for-make-bomsh) below.
 
 All tools are detected by `configure`; either target fails with a clear
 error message if a required tool is missing.