Make the whole certificate-status decision path visible so responders can distinguish a revoked certificate from a broken dependency, stale evidence or client-policy choice
A research certificate-status service dependency map should connect certificate inventory, issuers, OCSP responders, CRL distribution, DNS, network, time, signing keys, databases, caches, stapling, clients, trust stores, suppliers, owners, monitoring, failure modes, fallback and test evidence. English matters because component, dependency, authority, state, policy and consequence are not interchangeable.
Choose the route closest to your task, or read straight through for the complete system.
People search for an OCSP dependency map, certificate revocation architecture diagram and PKI status-checking service map because a browser error or failed API can originate in the certificate, responder, network, time source, cache, client library or local policy.
A useful map names the trust purpose, certificate chains, status authorities, endpoints, signing and data dependencies, clients, caches, freshness rules, network routes, owners, suppliers, monitoring, failure modes, fallbacks, evidence and change triggers.
The mechanism is decision-path visibility. The writer turns a technical topology into a readable chain from certificate identity to the relying system’s final action.
This guide was checked on 12 October 2026. Approved PKI, security, network, incident, change, supplier, continuity, privacy and records procedures govern a real map.
Students can practise with a library-loan analogy: separate the book, catalogue, librarian, network, clock, borrower and borrowing rule, then ask which dependency could make the status answer late or unavailable.
Did You Know? OCSP can report good, revoked or unknown, yet a relying application still decides how to handle availability, freshness and policy. A dependency map keeps protocol status separate from service behaviour.
Find the section you need
Set the trust question · 2 chapters
Map status authority · 2 chapters
Map delivery · 2 chapters
Map relying clients · 2 chapters
1. Define the trust decision and map boundary
Back to contentsA map should answer a specific operational question rather than display every PKI component.
State service, transactions, data sensitivity, certificate roles, environments, user populations, regions, client types, decision points, exclusions and map owner.
The map covers client-authentication certificates used by the research administration portal.
What to check
- Name purpose
- Name certificates
- Name clients
- Name exclusions
Name the exact object, version, audience, evidence and decision instead of using a broad label.
Ask which missing dependency or stakeholder could make the conclusion unsafe.
Boundary: Do not mix unrelated certificate ecosystems into one unreadable diagram.
Learning transfer: Scope design supports architecture.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
2. Inventory certificate chains and identifiers
Back to contentsStatus queries are meaningful only when the mapped certificate and issuer are unambiguous.
Record certificate purpose, subject, issuer, serial, validity, chain, authority information access, CRL distribution points, algorithms, environments, owners and renewal routes using protected identifiers where needed.
The portal chain maps one leaf, intermediate and root with separate status endpoints.
What to check
- List roles
- List issuers
- List endpoints
- Name owners
Separate what was observed, what it means, who may decide and what must happen next.
Check that ownership, authority, time, exceptions, privacy and distribution are explicit.
Boundary: Do not publish sensitive identifiers more widely than required.
Learning transfer: Asset identity supports security.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
3. Map OCSP request, response and authority paths
Back to contentsThe responder, issuer and delegated signer may be different operational dependencies.
Show requester, endpoint, responder identity, authorised signing certificate, request form, response states, signature validation, produced time, thisUpdate, nextUpdate, nonce policy where relevant and archival evidence.
The client queries a delegated responder and validates its authorised signing chain.
What to check
- Map request
- Map signer
- Map state
- Map time
Write the reversal or review condition so a new reader can recognise when the conclusion expires.
Confirm every action has an accountable owner, evidence route, due condition and closure test.
Boundary: Do not describe OCSP “good” as proof of every property of the certificate holder.
Learning transfer: Protocol semantics support cryptography.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
CRLs may provide a parallel or fallback status route with different timing and scale.
Show issuer, publication system, distribution points, delta CRLs if used, signing, schedule, repositories, mirrors, DNS, network, proxy, cache, client retrieval and update evidence.
A regional proxy caches the issuer CRL and refreshes it on the approved schedule.
What to check
- Map publisher
- Map repository
- Map cache
- Map client
Name the exact object, version, audience, evidence and decision instead of using a broad label.
Ask which missing dependency or stakeholder could make the conclusion unsafe.
Boundary: Do not assume CRL availability because an endpoint answers a network ping.
Learning transfer: Publication chains support resilience.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
Status evidence depends on trusted signing and accurate temporal context.
Connect HSM or key service, key custody, certificate, database, replication, revocation event intake, authoritative records, clock source, synchronisation monitoring, backup and recovery.
Responder signatures use an HSM-backed key while status data replicates across two regions.
What to check
- Map key
- Map data
- Map time
- Map recovery
Separate what was observed, what it means, who may decide and what must happen next.
Check that ownership, authority, time, exceptions, privacy and distribution are explicit.
Boundary: Do not expose secrets or detailed attack paths in a broadly shared map.
Learning transfer: Trust foundations support engineering.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
6. Map DNS, network, proxy and availability dependencies
Back to contentsA valid responder can still be unreachable from selected clients.
Trace resolver, records, load balancer, firewall, routes, proxies, TLS, capacity, regions, health checks, denial-of-service protection, suppliers and change ownership.
Only the external proxy path reaches the OCSP endpoint for one client group.
What to check
- Map DNS
- Map route
- Map proxy
- Map owner
Write the reversal or review condition so a new reader can recognise when the conclusion expires.
Confirm every action has an accountable owner, evidence route, due condition and closure test.
Boundary: Do not collapse several network dependencies into one “internet” box.
Learning transfer: Connectivity reasoning supports operations.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
7. Map stapling, caches and freshness behaviour
Back to contentsCached status improves performance but creates important time and invalidation boundaries.
Show server stapling, cache layers, stored response identity, age, thisUpdate, nextUpdate, refresh trigger, failure behaviour, purge authority, clock dependency and client acceptance.
The web tier staples responses and refreshes before the approved freshness limit.
What to check
- Map cache
- Map freshness
- Map refresh
- Map purge
Name the exact object, version, audience, evidence and decision instead of using a broad label.
Ask which missing dependency or stakeholder could make the conclusion unsafe.
Boundary: Do not invent one universal freshness window; record the authorised condition.
Learning transfer: Temporal reasoning supports computing.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
8. Map relying clients, trust stores and local policy
Back to contentsThe same status evidence can produce different outcomes across clients.
List applications, libraries, versions, platforms, trust stores, policy settings, hard or soft failure behaviour, user messaging, telemetry, update routes and owners.
Desktop and mobile clients use different libraries and handle unreachable status differently.
What to check
- List clients
- List versions
- List policy
- Name owner
Separate what was observed, what it means, who may decide and what must happen next.
Check that ownership, authority, time, exceptions, privacy and distribution are explicit.
Boundary: Do not label a client choice as a responder state.
Learning transfer: Decision separation supports governance.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
A dependency map becomes operational when each important edge has observable evidence and an owner.
Attach metrics, logs, synthetic checks, signature and freshness validation, latency, errors, cache age, DNS and clock health, thresholds, alert routes, supplier contacts and first-response actions.
A synthetic check validates signed good and controlled revoked cases from both regions.
What to check
- Attach signal
- Attach owner
- Attach route
- Attach action
Write the reversal or review condition so a new reader can recognise when the conclusion expires.
Confirm every action has an accountable owner, evidence route, due condition and closure test.
Boundary: Do not equate metric collection with reviewed monitoring.
Learning transfer: Observability supports incident response.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
Each dependency can fail in a different way with different trust consequences.
Record unavailable, stale, invalid, unknown, compromised, misconfigured and overloaded states; connect detection, impact, containment, fallback, expiry, authority and prohibited workarounds.
A stale signed response triggers a hold while an unreachable endpoint follows service-specific continuity policy.
What to check
- Name failure
- Name impact
- Name safeguard
- Name authority
Name the exact object, version, audience, evidence and decision instead of using a broad label.
Ask which missing dependency or stakeholder could make the conclusion unsafe.
Boundary: Do not prescribe an unsafe fail-open or fail-closed rule outside approved risk decisions.
Learning transfer: Failure analysis supports safety.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
A static diagram decays unless readers can test and update it.
Walk critical paths, reconcile inventories, exercise selected failures safely, confirm owners and contacts, test monitoring, record limitations, approve distribution, protect sensitive detail and set event-driven update triggers.
A proxy change test reveals one unmapped client and the map is corrected before release.
What to check
- Walk path
- Test failure
- Confirm owner
- Set trigger
Separate what was observed, what it means, who may decide and what must happen next.
Check that ownership, authority, time, exceptions, privacy and distribution are explicit.
Boundary: Do not publish sensitive architecture without audience and access control.
Learning transfer: Maintained maps support continuity.
Write one sentence that states the evidence, one that states its limit, and one that states the next responsible action. Then test each noun, number, condition and source against the controlled document. Replace vague confidence with a traceable reason.
How to build this kind of English before the job title arrives
Back to contentsStudents do not need professional authority to practise the underlying language. They can learn to define scope, annotate conditions, compare versions, rebuild a timeline, match a number to its unit and explain uncertainty without embarrassment. Parents can ask calm questions: What decision is this document supporting? Which sentence carries the strongest claim? What would make that claim false? Which source would you open next?
Use a three-pass routine. First, map the document: title, owner, audience, date, sections and decision. Second, trace one claim from source to conclusion. Third, explain the limit and next action. This routine strengthens comprehension, science, mathematics, humanities and workplace readiness because it turns English into an evidence tool.
A student should never imitate professional authority. The useful goal is to recognise when a text needs a qualified reviewer, current rule or official decision. Knowing when to pause is part of literacy.
Define
Name the trust decision, certificate population and relying clients.
Authorise
Map issuer, responder, CRL, signer and time sources.
Deliver
Trace DNS, network, proxy, cache and stapling.
Decide
Connect client versions, trust stores and policy.
Prove
Attach monitoring, tests, owners and update triggers.
Good
The authoritative status response does not indicate revocation.
Revoked
Authoritative status identifies revocation.
Unknown
The responder cannot determine status.
Stale
Evidence is outside the authorised freshness condition.
Invalid
Identity, signature, format or chain validation fails.
Unavailable
A required service or path cannot be reached.
Each case turns fluent wording into a question about evidence, continuity, privacy or responsibility.
Case 1: Define the trust decision and map boundary
The map covers client-authentication certificates used by the research administration portal. Identify the shortcut, locate the controlling evidence, explain the practical consequence and write a proportionate repair.
Keep observed evidence, interpretation, decision, owner and verification separate so another reader can reconstruct the reasoning.
Case 2: Map CRL publication and retrieval paths
A regional proxy caches the issuer CRL and refreshes it on the approved schedule. Identify the shortcut, locate the controlling evidence, explain the practical consequence and write a proportionate repair.
Keep observed evidence, interpretation, decision, owner and verification separate so another reader can reconstruct the reasoning.
Case 3: Map relying clients, trust stores and local policy
Desktop and mobile clients use different libraries and handle unreachable status differently. Identify the shortcut, locate the controlling evidence, explain the practical consequence and write a proportionate repair.
Keep observed evidence, interpretation, decision, owner and verification separate so another reader can reconstruct the reasoning.
Case 4: Validate, publish and maintain the map
A proxy change test reveals one unmapped client and the map is corrected before release. Identify the shortcut, locate the controlling evidence, explain the practical consequence and write a proportionate repair.
Keep observed evidence, interpretation, decision, owner and verification separate so another reader can reconstruct the reasoning.
The learner should make the final evidence note independently.
Keep source wording, interpretation, consequence, decision, authority and version separate.
Set the trust question
Define purpose, scope, certificates and client decisions. Use Chapters 1–2 to build the evidence path.
Record the source, approved version, people affected, authority, exception and next check before compressing the result into a short note.
Map status authority
Show issuers, OCSP, CRLs, signing and time. Use Chapters 3–4 to build the evidence path.
Record the source, approved version, people affected, authority, exception and next check before compressing the result into a short note.
Map delivery
Trace DNS, network, caches, stapling and suppliers. Use Chapters 5–6 to build the evidence path.
Record the source, approved version, people affected, authority, exception and next check before compressing the result into a short note.
Map relying clients
Connect versions, trust stores, policies and fallbacks. Use Chapters 7–8 to build the evidence path.
Record the source, approved version, people affected, authority, exception and next check before compressing the result into a short note.
Prove the map
Test failure modes, monitoring, ownership and change. Use Chapters 9–10 to build the evidence path.
Record the source, approved version, people affected, authority, exception and next check before compressing the result into a short note.
Finish with what the evidence supports, what remains uncertain and what authorised action follows.
The underlying evidence should remain stable while emphasis and next action change with the reader.
Student lens
Use a school-project example to practise identity, version, authority and evidence without handling live confidential data.
Explain the decision aloud, then ask a classmate to find the source and repeat the check.
Parent or mentor lens
Ask calm questions about what the record proves, what remains uncertain and who controls the next action.
Support careful reasoning without turning a technical document into a promise or accusation.
Operational lens
Record certificate purpose, subject, issuer, serial, validity, chain, authority information access, CRL distribution points, algorithms, environments, owners and renewal routes using protected identifiers where needed.
Do not publish sensitive identifiers more widely than required.
Quality lens
Attach metrics, logs, synthetic checks, signature and freshness validation, latency, errors, cache age, DNS and clock health, thresholds, alert routes, supplier contacts and first-response actions.
Do not equate metric collection with reviewed monitoring.
Independent-reader lens
Walk critical paths, reconcile inventories, exercise selected failures safely, confirm owners and contacts, test monitoring, record limitations, approve distribution, protect sensitive detail and set event-driven update triggers.
Do not publish sensitive architecture without audience and access control.
Adaptation helps only when identity, source, status, rights and decision boundaries remain intact.
Use this map to connect each local writing choice with its operational consequence and limit.
Control 1: Define the trust decision and map boundary
A map should answer a specific operational question rather than display every PKI component. The practical response is to state service, transactions, data sensitivity, certificate roles, environments, user populations, regions, client types, decision points, exclusions and map owner.
Worked signal: The map covers client-authentication certificates used by the research administration portal. Boundary: Do not mix unrelated certificate ecosystems into one unreadable diagram. The transferable learning is that scope design supports architecture.
Control 2: Inventory certificate chains and identifiers
Status queries are meaningful only when the mapped certificate and issuer are unambiguous. The practical response is to record certificate purpose, subject, issuer, serial, validity, chain, authority information access, CRL distribution points, algorithms, environments, owners and renewal routes using protected identifiers where needed.
Worked signal: The portal chain maps one leaf, intermediate and root with separate status endpoints. Boundary: Do not publish sensitive identifiers more widely than required. The transferable learning is that asset identity supports security.
Control 3: Map OCSP request, response and authority paths
The responder, issuer and delegated signer may be different operational dependencies. The practical response is to show requester, endpoint, responder identity, authorised signing certificate, request form, response states, signature validation, produced time, thisUpdate, nextUpdate, nonce policy where relevant and archival evidence.
Worked signal: The client queries a delegated responder and validates its authorised signing chain. Boundary: Do not describe OCSP “good” as proof of every property of the certificate holder. The transferable learning is that protocol semantics support cryptography.
Control 4: Map CRL publication and retrieval paths
CRLs may provide a parallel or fallback status route with different timing and scale. The practical response is to show issuer, publication system, distribution points, delta CRLs if used, signing, schedule, repositories, mirrors, DNS, network, proxy, cache, client retrieval and update evidence.
Worked signal: A regional proxy caches the issuer CRL and refreshes it on the approved schedule. Boundary: Do not assume CRL availability because an endpoint answers a network ping. The transferable learning is that publication chains support resilience.
Control 5: Map signing keys, time and status data stores
Status evidence depends on trusted signing and accurate temporal context. The practical response is to connect HSM or key service, key custody, certificate, database, replication, revocation event intake, authoritative records, clock source, synchronisation monitoring, backup and recovery.
Worked signal: Responder signatures use an HSM-backed key while status data replicates across two regions. Boundary: Do not expose secrets or detailed attack paths in a broadly shared map. The transferable learning is that trust foundations support engineering.
Control 6: Map DNS, network, proxy and availability dependencies
A valid responder can still be unreachable from selected clients. The practical response is to trace resolver, records, load balancer, firewall, routes, proxies, TLS, capacity, regions, health checks, denial-of-service protection, suppliers and change ownership.
Worked signal: Only the external proxy path reaches the OCSP endpoint for one client group. Boundary: Do not collapse several network dependencies into one “internet” box. The transferable learning is that connectivity reasoning supports operations.
Control 7: Map stapling, caches and freshness behaviour
Cached status improves performance but creates important time and invalidation boundaries. The practical response is to show server stapling, cache layers, stored response identity, age, thisUpdate, nextUpdate, refresh trigger, failure behaviour, purge authority, clock dependency and client acceptance.
Worked signal: The web tier staples responses and refreshes before the approved freshness limit. Boundary: Do not invent one universal freshness window; record the authorised condition. The transferable learning is that temporal reasoning supports computing.
Control 8: Map relying clients, trust stores and local policy
The same status evidence can produce different outcomes across clients. The practical response is to list applications, libraries, versions, platforms, trust stores, policy settings, hard or soft failure behaviour, user messaging, telemetry, update routes and owners.
Worked signal: Desktop and mobile clients use different libraries and handle unreachable status differently. Boundary: Do not label a client choice as a responder state. The transferable learning is that decision separation supports governance.
Control 9: Map monitoring, alerts and accountable response
A dependency map becomes operational when each important edge has observable evidence and an owner. The practical response is to attach metrics, logs, synthetic checks, signature and freshness validation, latency, errors, cache age, DNS and clock health, thresholds, alert routes, supplier contacts and first-response actions.
Worked signal: A synthetic check validates signed good and controlled revoked cases from both regions. Boundary: Do not equate metric collection with reviewed monitoring. The transferable learning is that observability supports incident response.
Control 10: Analyse failure modes, safeguards and fallback
Each dependency can fail in a different way with different trust consequences. The practical response is to record unavailable, stale, invalid, unknown, compromised, misconfigured and overloaded states; connect detection, impact, containment, fallback, expiry, authority and prohibited workarounds.
Worked signal: A stale signed response triggers a hold while an unreachable endpoint follows service-specific continuity policy. Boundary: Do not prescribe an unsafe fail-open or fail-closed rule outside approved risk decisions. The transferable learning is that failure analysis supports safety.
Control 11: Validate, publish and maintain the map
A static diagram decays unless readers can test and update it. The practical response is to walk critical paths, reconcile inventories, exercise selected failures safely, confirm owners and contacts, test monitoring, record limitations, approve distribution, protect sensitive detail and set event-driven update triggers.
Worked signal: A proxy change test reveals one unmapped client and the map is corrected before release. Boundary: Do not publish sensitive architecture without audience and access control. The transferable learning is that maintained maps support continuity.
A complete record does not merely sound organised; it lets an authorised reader reproduce the decision, see its boundary and know what to do when conditions change.
Strong technical English states the tested object, source, version, authority, limit and consequence. These boundaries make that discipline visible.
Boundary 1: Map OCSP request, response and authority paths
The responder, issuer and delegated signer may be different operational dependencies. Show requester, endpoint, responder identity, authorised signing certificate, request form, response states, signature validation, produced time, thisUpdate, nextUpdate, nonce policy where relevant and archival evidence. The writer should identify the exact evidence object, its version, the responsible role and the decision this evidence can support.
Use this worked signal: The client queries a delegated responder and validates its authorised signing chain. Then challenge the statement with one plausible exception, one privacy or access constraint, one downstream dependency and one fact that would force the conclusion to change. Do not describe OCSP “good” as proof of every property of the certificate holder.
Boundary 2: Map DNS, network, proxy and availability dependencies
A valid responder can still be unreachable from selected clients. Trace resolver, records, load balancer, firewall, routes, proxies, TLS, capacity, regions, health checks, denial-of-service protection, suppliers and change ownership. The writer should identify the exact evidence object, its version, the responsible role and the decision this evidence can support.
Use this worked signal: Only the external proxy path reaches the OCSP endpoint for one client group. Then challenge the statement with one plausible exception, one privacy or access constraint, one downstream dependency and one fact that would force the conclusion to change. Do not collapse several network dependencies into one “internet” box.
Boundary 3: Map monitoring, alerts and accountable response
A dependency map becomes operational when each important edge has observable evidence and an owner. Attach metrics, logs, synthetic checks, signature and freshness validation, latency, errors, cache age, DNS and clock health, thresholds, alert routes, supplier contacts and first-response actions. The writer should identify the exact evidence object, its version, the responsible role and the decision this evidence can support.
Use this worked signal: A synthetic check validates signed good and controlled revoked cases from both regions. Then challenge the statement with one plausible exception, one privacy or access constraint, one downstream dependency and one fact that would force the conclusion to change. Do not equate metric collection with reviewed monitoring.
Boundary 4: Validate, publish and maintain the map
A static diagram decays unless readers can test and update it. Walk critical paths, reconcile inventories, exercise selected failures safely, confirm owners and contacts, test monitoring, record limitations, approve distribution, protect sensitive detail and set event-driven update triggers. The writer should identify the exact evidence object, its version, the responsible role and the decision this evidence can support.
Use this worked signal: A proxy change test reveals one unmapped client and the map is corrected before release. Then challenge the statement with one plausible exception, one privacy or access constraint, one downstream dependency and one fact that would force the conclusion to change. Do not publish sensitive architecture without audience and access control.
A bounded claim helps the next reader test, revise and act on it.
Rebuild each decision chain, then compress it without losing its controlling condition.
Inventory certificate chains and identifiers
Status queries are meaningful only when the mapped certificate and issuer are unambiguous. Record certificate purpose, subject, issuer, serial, validity, chain, authority information access, CRL distribution points, algorithms, environments, owners and renewal routes using protected identifiers where needed. Example: The portal chain maps one leaf, intermediate and root with separate status endpoints.
Test identity, source, scope, date, authority, version, privacy and exception before accepting the conclusion.
Map OCSP request, response and authority paths
The responder, issuer and delegated signer may be different operational dependencies. Show requester, endpoint, responder identity, authorised signing certificate, request form, response states, signature validation, produced time, thisUpdate, nextUpdate, nonce policy where relevant and archival evidence. Example: The client queries a delegated responder and validates its authorised signing chain.
Test identity, source, scope, date, authority, version, privacy and exception before accepting the conclusion.
Map signing keys, time and status data stores
Status evidence depends on trusted signing and accurate temporal context. Connect HSM or key service, key custody, certificate, database, replication, revocation event intake, authoritative records, clock source, synchronisation monitoring, backup and recovery. Example: Responder signatures use an HSM-backed key while status data replicates across two regions.
Test identity, source, scope, date, authority, version, privacy and exception before accepting the conclusion.
Map stapling, caches and freshness behaviour
Cached status improves performance but creates important time and invalidation boundaries. Show server stapling, cache layers, stored response identity, age, thisUpdate, nextUpdate, refresh trigger, failure behaviour, purge authority, clock dependency and client acceptance. Example: The web tier staples responses and refreshes before the approved freshness limit.
Test identity, source, scope, date, authority, version, privacy and exception before accepting the conclusion.
Analyse failure modes, safeguards and fallback
Each dependency can fail in a different way with different trust consequences. Record unavailable, stale, invalid, unknown, compromised, misconfigured and overloaded states; connect detection, impact, containment, fallback, expiry, authority and prohibited workarounds. Example: A stale signed response triggers a hold while an unreachable endpoint follows service-specific continuity policy.
Test identity, source, scope, date, authority, version, privacy and exception before accepting the conclusion.
Repeat the exercise after a person, permission, version or timetable changes.
A polished line can conceal a missing definition, version, permission or condition.
Test 1
Ask which missing dependency or stakeholder could make the conclusion unsafe.
Write the expected result, actual result, evidence, limit and responsible follow-up in separate sentences.
Test 2
Check that ownership, authority, time, exceptions, privacy and distribution are explicit.
Write the expected result, actual result, evidence, limit and responsible follow-up in separate sentences.
Test 3
Confirm every action has an accountable owner, evidence route, due condition and closure test.
Write the expected result, actual result, evidence, limit and responsible follow-up in separate sentences.
Keep the failed version beside the repair so the learning remains visible.
Answer each prompt in a complete sentence tied to a current instruction, dated source, observation or authorised clarification. Write “unknown” when evidence does not support an answer.
- Name purpose? State the evidence and the narrow conclusion it permits.
- Name certificates? State the evidence and the narrow conclusion it permits.
- Name clients? State the evidence and the narrow conclusion it permits.
- Name exclusions? State the evidence and the narrow conclusion it permits.
- List roles? State the evidence and the narrow conclusion it permits.
- List issuers? State the evidence and the narrow conclusion it permits.
- List endpoints? State the evidence and the narrow conclusion it permits.
- Name owners? State the evidence and the narrow conclusion it permits.
- Map request? State the evidence and the narrow conclusion it permits.
- Map signer? State the evidence and the narrow conclusion it permits.
- Map state? State the evidence and the narrow conclusion it permits.
- Map time? State the evidence and the narrow conclusion it permits.
Independent-reader test
Ask a careful reader to identify the source, version, custody, authority, uncertainty and next action without private explanation.
Change test
Imagine the custodian, system, provider, requirement or timetable changes tomorrow. Mark every sentence that needs review.
Decision log
Keep the source, date, choice, responsible person and reason, including rejected alternatives that may become relevant later.
Parent or mentor conversation
Ask which words carry the strongest claim, what evidence controls them and what new fact would revise the conclusion.
Is this only a network diagram?
No; include authority, semantics, time, clients and decision policy.
Does OCSP good prove identity?
No; it is a bounded certificate-status statement.
Why map client versions?
Different libraries may interpret availability and freshness differently.
Should every secret be shown?
No; protect sensitive implementation details and key custody.
How often should the map change?
Use event triggers and risk-based review, not an invented universal interval.
What proves completeness?
Inventory reconciliation, critical-path walks, owner confirmation and failure tests.
- RFC 6960 — Online Certificate Status Protocol
- NIST SP 800-61 Rev. 3 — Incident Response Recommendations
- Why English? | Writing a Research Certificate-Status Service Incident Runbook
- Why English? | Writing a Research Certificate-Status Service Continuity Test
Cycle-sensitive facts were checked against current official pages on 12 October 2026. Always reopen the authority’s live page before a real decision.