[2.0]: Define the certificate bytes covered by certificateProperties.fingerprint

[jaooli-cyber]

Context

This follows the discussion in #1031. A maintainer noted that changing the CycloneDX 1.x semantics could be considered breaking and asked that any corresponding CycloneDX 2.0 issue be tracked separately.

I reviewed the current 2.0-dev branch at commit a1c8aeb2e4e6a72851fd937f210e9b5add1cf514.

In schema/2.0/model/cyclonedx-cryptography-2.0.schema.json, certificateProperties.fingerprint is still described as:

The fingerprint is a cryptographic hash of the certificate excluding it's signature.

PR #903 added support for standard and custom fingerprint algorithms, but does not appear to define the exact certificate bytes covered by this field.

Interoperability question

For an X.509 certificate, at least three different inputs could be interpreted:

1. The complete DER-encoded Certificate, including signatureAlgorithm and signatureValue.
2. The DER-encoded tbsCertificate, excluding the outer signature.
3. The DER-encoded SubjectPublicKeyInfo, which identifies the public key rather than the certificate.

These produce different values. OpenSSL certificate fingerprints, Java X509Certificate.getEncoded() and Go x509.Certificate.Raw normally operate on the complete DER-encoded certificate.

Without an explicit definition, two producers can generate different values for the same certificate while both documents remain schema-valid.

Requested clarification

Could CycloneDX 2.0 explicitly define the intended input bytes for certificateProperties.fingerprint?

If the conventional certificate fingerprint is intended, possible wording would be:

A cryptographic hash of the complete DER-encoded certificate, including its signature algorithm and signature value. Certificates represented in another encoding, such as PEM, are decoded to DER before hashing.

If tbsCertificate is intended instead, it would be helpful to name that structure explicitly and distinguish it from the conventional certificate fingerprint.

Testing contribution

For a neutral CBOM interoperability test-suite prototype, our current test policy uses SHA-256 over the complete DER certificate for certificate identity and SHA-256 over SPKI for public-key identity. These remain explicit test-policy choices rather than assumed CycloneDX semantics.

If useful, we would be happy to provide fully synthetic fixtures containing complete-DER, tbsCertificate and SPKI fingerprints, together with expected values and cross-implementation checks.

[jaooli-cyber]

I went ahead and prepared the synthetic fixtures and reproducible results rather than waiting for the normative decision.

For the same fully synthetic X.509 certificate, the observed SHA-256 values are:

• Complete DER-encoded Certificate:
  930cf530dc4c4e44ed906c1bfe4612b1bea4b076edf5ed7a4e77a8d9bd501745

• DER-encoded TBSCertificate:
  8e0a5991d3b224c59bc428e4af0dd4092c7e303bef29deb432a1ee87ae58aa3a

• DER-encoded SubjectPublicKeyInfo:
  7b1902c98fabcd980266ca4ed46e890e51ccca4f34f931a20ae2d3ef4fa5afe0

The three values are pairwise distinct.

A dependency-free DER parser and OpenSSL independently agreed on the extracted Certificate, TBSCertificate and SPKI byte domains. OpenSSL's conventional certificate-fingerprint command corresponds to SHA-256 over the complete DER-encoded Certificate.

I also created three CycloneDX 1.7 candidate CBOM documents carrying each value in certificateProperties.fingerprint. All three pass schema validation with the pinned CycloneDX CLI image. The SPKI variant is included deliberately as a confusion control because it identifies the public key rather than the certificate.

This demonstrates that schema validation alone cannot determine which byte domain a producer hashed. It does not claim that all three interpretations are normatively correct, does not assert standards non-conformance and does not prejudge the CycloneDX 2.0 decision.

A sanitised public reproduction package is being prepared with the synthetic certificate and public key, reproducer, candidate CBOM documents, automated results, schema-validation outputs and integrity manifests. It will contain no private key, production data or internal infrastructure information. I will link it here once it has been reviewed and published.

If useful, I would be happy to adapt these fixtures to the repository's preferred test format or prepare a focused pull request once the appropriate destination and intended semantics are confirmed.

[jaooli-cyber]

The sanitised public reproduction is now available:

• Repository: https://github.com/jaooli-cyber/cyclonedx-certificate-fingerprint-fixtures
• Immutable release: https://github.com/jaooli-cyber/cyclonedx-certificate-fingerprint-fixtures/releases/tag/v0.1.0
• Successful CI run: https://github.com/jaooli-cyber/cyclonedx-certificate-fingerprint-fixtures/actions/runs/33872367183

It contains the fully synthetic certificate and corresponding public key, the dependency-free DER/OpenSSL reproducer, three CycloneDX 1.7 candidate CBOM documents, deterministic JSON and JUnit results, an integrity manifest, mutation controls, and digest-pinned CycloneDX CLI validation.

The repository contains no private key, production data or internal infrastructure information.

All focused tests pass, deterministic regeneration matches the checked-in baseline byte for byte, and all three candidate CBOM documents pass CycloneDX 1.7 schema validation.

As before, these results demonstrate the interoperability ambiguity but do not select a normative CycloneDX interpretation, assert standards non-conformance or imply CycloneDX endorsement.

If these fixtures are useful, I would be happy to adapt them to the preferred upstream test structure or prepare a focused pull request once the intended semantics and destination are confirmed.