RFC 5280¶
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., & Polk, W. (2008). RFC 5280.
Cited by¶
8 citations across 8 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Attestation
- The trust anchor is the public key, itself vouched for by a certificate chain terminating in a root the verifier already trusts.
This sourceDefines certificate chains terminating in a trusted root, the trust-anchor architecture for verifying a public-key binding.
Supported in partVerified against the work's full text
RFC 5280 has certification paths begin at a trust anchor and states the anchor comprises the CA's public key, name and constraints; it does not say the anchor's key is itself vouched for by a chain.
“Valid paths begin with certificates issued by a trust anchor. The algorithm requires the public key of the CA, the CA's name, and any constraints upon the set of paths that may be validated using this”
- The trust anchor is the public key, itself vouched for by a certificate chain terminating in a root the verifier already trusts.
- Authentication
- 4. A trust anchor. The chain of evidence bottoms out at a root — a root certificate, identity authority, notary, recognised expert — whose compromise invalidates everything downstream.
This sourceDefines the certificate chain that bottoms out at a trusted root — the trust anchor whose compromise invalidates everything downstream.
Supported in partVerified against the work's full text
RFC 5280 supplies the certificate-path frame — validation starts from a trust anchor taken as an a-priori input — but it never says a trust anchor's compromise invalidates everything downstream, and it covers no notaries or experts.
“The trust anchor is an input to the algorithm. There is no requirement that the same trust anchor be used to validate all certification paths.”
- 4. A trust anchor. The chain of evidence bottoms out at a root — a root certificate, identity authority, notary, recognised expert — whose compromise invalidates everything downstream.
- Capability Separation
- The transfer also moves specific intervention patterns across substrates: rotating issuer keys in cryptography corresponds to re-issuing physical credentials with new anti-counterfeit features in currency, to updating institutional signing keys in credentialing, and to renewing molecular self-marker recognition in immunology; publishing revocation lists corresponds to publishing disbarred professionals, lost or stolen prescription-pad numbers, and counterfeit serial numbers.
This sourceSpecifies certificate issuance, verification, and revocation lists in PKI.
Supported in partVerified against the work's full text
RFC 5280 documents issuer key changeover and certificate revocation lists in PKI, but says nothing of the currency, credentialing or immunology correspondences the claim draws.
“This extension is used where an issuer has multiple signing keys (either due to multiple concurrent key pairs or due to changeover).”
- The transfer also moves specific intervention patterns across substrates: rotating issuer keys in cryptography corresponds to re-issuing physical credentials with new anti-counterfeit features in currency, to updating institutional signing keys in credentialing, and to renewing molecular self-marker recognition in immunology; publishing revocation lists corresponds to publishing disbarred professionals, lost or stolen prescription-pad numbers, and counterfeit serial numbers.
- Certification
- The portable token is the X.509 certificate — a signed artifact the browser uses as a substitute for verifying the server's identity itself.
This sourceSpecifies X.509 certificates, the chain of trust up to a self-signed root CA in the trust store, and certificate revocation lists.
Supported in partVerified against the work's full text
RFC 5280 backs the CA and signed-certificate half of the claim and expressly places the certificate-validation procedure out of its scope, so it cannot carry the domain-validation clause.
“The binding is asserted by having a trusted CA digitally sign each certificate. The CA may base this assertion upon technical means (a.k.a., proof of possession through a challenge- response protocol), presentation of the private key, or on an assertion by the subject. A certificate has a limited valid lifetime, which is indicated in its signed contents. Because a certificate's signature and timeliness can be …”
- The portable token is the X.509 certificate — a signed artifact the browser uses as a substitute for verifying the server's identity itself.
- Green-Beard Effect
- The false-beard pressure is concrete: a stolen or forged credential is a tag-displayer that does not bear the legitimate cooperative cost, and the coupling-enforcement apparatus is the CA infrastructure plus certificate revocation lists.
This sourceDefines X.509 certificate-authority infrastructure and CRLs — the apparatus protecting credential validity against stolen or forged credentials.
Supported in partVerified against the work's full text
RFC 5280 defines X.509 certificates and CRLs, the apparatus the sentence names; it says nothing about false-beard pressure, tag-displayers, or cooperative cost.
“This specification profiles the format and semantics of certificates and certificate revocation lists (CRLs) for the Internet PKI.”
- The false-beard pressure is concrete: a stolen or forged credential is a tag-displayer that does not bear the legitimate cooperative cost, and the coupling-enforcement apparatus is the CA infrastructure plus certificate revocation lists.
- Validity-ending Event
- In software and security it is API deprecations with announced sunset dates, certificate revocation, token expiration, and end-of-life declarations, where a revoked key continues to exist as bytes but is no longer trusted.
Supported in partVerified against the work's full text
RFC 5280 shows that X.509 certificate revocation adds a CRL entry for the revoked certificate rather than deleting it, so the artifact persists as a referenceable object after it stops being usable.
“An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period.”
- In software and security it is API deprecations with announced sunset dates, certificate revocation, token expiration, and end-of-life declarations, where a revoked key continues to exist as bytes but is no longer trusted.
Mechanisms¶
- Certificate Chain Validation
- The discipline is a minimal, curated anchor set, hard-fail or stapled revocation, and using the standard path-validation algorithm rather than ad-hoc checks.
This sourceSpecifies a standards-track certification-path validation algorithm and requires conforming implementations to produce functionally equivalent validation results.
- The discipline is a minimal, curated anchor set, hard-fail or stapled revocation, and using the standard path-validation algorithm rather than ad-hoc checks.
- Credential Registry
- In digital systems the sharp edge of this is certificate revocation.
This sourceDefines the X.509 certificate-revocation-list profile used to identify certificates whose status has been revoked.
- In digital systems the sharp edge of this is certificate revocation.
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 6 of 8 citations: 6 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 3 other ways.
- https://www.rfc-editor.org/rfc/rfc5280 ×2
- https://datatracker.ietf.org/doc/rfc5280/ ×1
- https://doi.org/10.17487/RFC5280 ×1
Registry ID ref:f34eb1bfe2d5 · see in the full table