Summary

  • RFC 6493 makes minimal contact data for an RPKI CA maintainer discoverable in a signed object, but explicitly says the record is not an identity certificate and does not replace WHOIS.
  • A fully validated object proves that the signature, RFC 6488 object checks and RFC 6493 version and payload-profile checks passed; it does not prove that the address is monitored, that a human acknowledged the problem or that the contact can authorize a remedy.
  • A useful response ledger separates object validity, contact scope, channel reachability, acknowledgement, authority to act and completed escalation or handoff.

The practical problem behind the Ghostbusters Record is narrow and important. An operator may see that a certificate on the path from a Route Origin Authorization to a trust anchor has expired, is about to expire, or is affected by a stale Certificate Revocation List. RPKI certificate names are intentionally poor guides to human identity. RFC 6493 therefore asks a simple operational question: who can be contacted about the CA certificate that needs attention?

The answer is a signed object whose payload is a tightly restricted vCard. It can name a contactable person or role responsible for the CA certificate and may include a postal address, telephone number or email address. The profile requires the vCard wrapper, a version and a formatted name, plus at least one contact channel. Its goal is minimal data, not a complete staff directory.

That economy is a feature, but it establishes a boundary. RFC 6493 says the Ghostbusters Record is not an identity certificate. It is an attestation to contact data made by the maintainer of the CA certificate below which the signing end-entity certificate was issued. It is also not resource-registry WHOIS data and describes a CA-certificate maintainer, not necessarily the resource holder.

Validation answers another bounded question. The record uses the RFC 6488 signed-object template and an EE certificate. The relying party validates the object, checks its version, extracts the vCard and verifies that the payload obeys the profile. Only then is the contact payload made available to the requesting application. This is strong evidence that a particular signed payload passed the specified cryptographic and syntactic checks.

It is not evidence that the mailbox is read today. The specification warns that the contact data are self-asserted and were not verified by the CA that issued the superior CA certificate. The record is optional, and a CA can publish zero or more records. A valid object may name a person, an administrative role or a network operations centre. None of those labels reveals an on-call schedule, acknowledgement target, delegated authority, substitute contact or escalation path.

The difference matters during a time-sensitive certificate or CRL problem. Sending a message is not the same as reaching an accountable responder. Reaching a responder is not the same as obtaining authority to change a certificate, publish a corrected object or activate a continuity procedure. One signed contact record should not be inflated into proof of an entire incident-command system.

A response ledger can preserve those distinctions without changing the protocol. Its first state records the Ghostbusters object hash, validation time, certificate path and result. Its second records what the contact actually claims: person, role or organization and the channel types present. Its third records a bounded reachability test without publishing sensitive operational details. Its fourth records acknowledgement of the specific issue. Its fifth records whether the responder has authority to act or must escalate. Its sixth records the resulting handoff, action or explicit failure to reach an authorized party.

This ledger is an editorial governance proposal, not an RFC requirement. It should not expose private schedules, create a surveillance file or turn contact data into identity proof. It simply prevents six different claims from collapsing into the word “contacted.” Evidence from one test is also local: it does not prove universal Ghostbusters deployment or the readiness of another CA.

Public contact information carries its own cost. RFC 6493 notes that telephone numbers may attract abusive calls and email addresses may attract spam. Testing therefore needs restraint: predictable limits, controlled disclosure, protection against harassment and a way to rotate channels without destroying the historical proof that a prior record existed.

For Number Resource Society, the useful advocacy position is modest. It can ask institutions to publish bounded evidence about whether signed contact paths remain usable and whether escalation responsibility is clear. It cannot certify a CA, verify someone’s identity, operate the repository or declare an incident closed. Authority stays with the operators and institutions that control the affected certificate and publication process.

Sources