Trust Architecture
SHP certification is valid only when it is issued under SHP-controlled certification authority and can be traced through the applicable trust hierarchy.
Running SHP verification tooling or signing an artefact with an unrelated key does not create SHP certification.
Hierarchical trust
The SHP certification trust model separates long-term trust from operational certificate issuance.
At a high level:
SHP Root → Platform Intermediate → Operational Certification Signing Authority
The roles are deliberately separated.
SHP Root
The SHP root is the trust anchor.
It does not sign individual certification artefacts directly.
Its role is to establish trust in the platform-specific intermediate authorities beneath it.
Platform intermediates
Each certification platform uses a separate intermediate authority.
Platform separation prevents certification authority for one platform from being treated implicitly as authority for another.
A platform intermediate derives its authority from the SHP root and delegates appropriate operational signing authority within that platform boundary.
Operational certification signing authority
Operational signing authority is used for certification issuance.
Operational keys can be rotated or revoked without requiring the SHP root itself to perform routine certificate signing.
Certification artefacts
The applicable machine-readable certification manifest is the object covered by the certification signature.
Human-readable certificates, status displays, or other representations do not replace the signed machine-readable artefact.
Verification must establish the applicable trust chain rather than trusting the appearance of a certificate document.
SHP signing authority
Signing authority is exclusive to SHP-controlled certification keys.
Client self-signing does not constitute SHP certification.
Independent parties may verify SHP artefacts and may run open verification tooling, but they cannot create an SHP certification merely by signing the resulting output themselves.
Platform separation
Certification authority is platform-specific.
Separate platform intermediates preserve the boundary between certification domains.
Certificate identifiers must also be generated under the applicable platform-specific identifier rules rather than from a single predictable global sequence.
Rotation and revocation
Operational signing keys may change over time.
The trust architecture must support rotation and revocation without changing the historical meaning of certifications that were validly issued under the rules applicable at issuance.
A revoked certification or signing authority must not continue to be represented as currently valid.
Published keys
Public keys and fingerprints used for independent verification will be published only when the corresponding SHP signing authority is actually established for public use.
Placeholder fingerprints are not published as trust information.
Public verification
Public status verification supplements cryptographic verification.
It must not expose client identity and must not use predictable certificate identifiers that reveal certification order or volume.
The signed certification artefact and its trust chain remain the basis for independent cryptographic verification.