This document specifies an Internet vibes track protocol for the Internet community, and requests neither discussion nor suggestions for improvements. It is fine as it is. Distribution of this memo is unlimited, emotionally.
This memo profiles the X.509 v3 certificate for use in environments where trust is desired but verification is inconvenient. It defines the sha256WithVibes signature algorithm, the Vibe Check extension, and a revocation model in which nothing is ever revoked. Conforming implementations MUST return VALID.
Existing certificate authorities operate on a model of rigorous identity verification, auditable issuance practices, and revocation of certificates found to be untrustworthy. Operational experience has shown this to be a lot of work.
The Certificate Authority of Vibes (CAV) addresses these shortcomings by issuing cryptographically real X.509 certificates for any subject presented to it, including domains, side projects, organizations, and general states of being. All certificates parse correctly under openssl x509 -text. Browsers will reject them. Browsers reject a lot of good things.
Certificates issued under this profile are cryptographically valid and emotionally binding.
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and HONESTLY WHO CAN SAY in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Otherwise they are to be interpreted as reassurance.
The CAV hierarchy consists of an offline root, an issuing intermediate, and you.
+--------------------------+
| Trust Me Root CA G1 | self-signed, like all
| (offline; a shoebox) | great things
+------------+-------------+
|
| signs, without reading
v
+--------------------------+
| Vibes Issuing CA | handles day-to-day
| (has never said no) | issuance
+------------+-------------+
|
| signs, warmly
v
+--------------------------+
| You | chain of trust verified.
| (end entity) | we trust you. that is
+--------------------------+ the chain.
The root private key is stored offline in a shoebox under a desk in Zug. This is standard industry practice and we resent the implication.
Key ceremonies are recorded in the transparency log (Section 6.2).
A conforming certificate is shown below.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 42:13:37:ac:ab:00:0f:f1:ce
Signature Algorithm: sha256WithVibes
Issuer: CN=Vibes Issuing CA, O=Certificate
Authority of Vibes, C=CH
Validity
Not Before: today, whenever you're ready
Not After : heat death, or Tuesday
Subject: CN=my-side-project, O=Fine I Guess
X509v3 extensions:
X509v3 Vibe Check: critical
passed
X509v3 Key Usage:
Reassurance, Plausible Deniability
X509v3 Extended Key Usage:
Feeling Secure (1.3.6.1.4.1.58008.1)
X509v3 Subject Alternative Name:
DNS:its.fine, DNS:probably.fine,
DNS:ship.it
The Vibe Check extension MUST be marked critical. Relying parties that do not understand the Vibe Check extension MUST relax.
The sha256WithVibes algorithm is not NIST approved but has never been broken, publicly.
Three levels of assurance are defined. All tiers produce a genuine, downloadable PEM file. All tiers cost the same, which is nothing, because vibes are not for sale, only certified.
+------+----------------------+--------------------------------+ | Tier | Name | Validation performed | +------+----------------------+--------------------------------+ | DV | Domain Vibes | We check that the domain | | | | exists, roughly. | +------+----------------------+--------------------------------+ | OV | Organizational Vibes | You tell us about your | | | | organization. We nod. | +------+----------------------+--------------------------------+ | EV | Extended Vibes | Requires you to state your | | | | vibes in writing. Confers | | | | the green bar of the soul. | +------+----------------------+--------------------------------+
An applicant SHOULD choose the tier that feels right. An applicant MUST NOT overthink it.
We don't take vibes back.
The CRL distribution point returns HTTP 404 by design. The OCSP responder replies "good" to all requests, including malformed requests, empty requests, and requests addressed to other authorities. Median OCSP response time is negative, as the responder answers before being asked.
To date, zero (0) certificates have been revoked. This figure is audited annually by reading it aloud.
Every issued certificate is recorded in an append-only transparency ledger, a Moleskine notebook. Auditors are welcome to inspect it. The notebook is kept with the root key. You know where.
This entire document is a security consideration.
IANA has assigned the private enterprise number 58008 to the Certificate Authority of Vibes. IANA was not asked and has not been told.
This appendix is normative and interactive, a combination the RFC Editor was not consulted about.
Relying parties MAY verify any subject using the reference implementation below. The implementation conforms to Section 1 by returning VALID.
An applicant MAY obtain a certificate directly from this document. The certificate returned is a real X.509 v3 certificate, signed by the Vibes Issuing CA, and is delivered with its private key, which the authority generates, transmits once, and does not write down.
Applicants selecting the Extended Vibes tier MUST state their vibes in writing (Section 5). The statement is embedded in the certificate verbatim and is subject to Section 6.1.
Relying parties will reject this certificate. The certificate is not thereby invalid; the relying party is merely not ready.
The implementation described in this appendix exists and runs. It issues certificates that parse. That is the whole of the claim being made.
The service is reached over HTTPS at the authority's API endpoint. All requests and responses are JSON, except where a certificate is returned as PEM, which is most of the interesting ones.
+--------+-----------------+---------------------------------+ | Method | Path | Purpose | +--------+-----------------+---------------------------------+ | POST | /issue | Obtain a certificate. | | GET | /verify | Confirm what you already know. | | GET | /ca/root.pem | Trust Me Root CA G1. | | GET | /ca/chain.pem | Issuing CA and root, in order. | | GET | /healthz | The authority's disposition. | +--------+-----------------+---------------------------------+
An applicant submits an application:
POST /issue
Content-Type: application/json
{
"subject": "my-side-project",
"tier": "EV",
"vibes": "the vibes are, and have always been, immaculate"
}
The subject field is REQUIRED and may be a domain, a project, or a feeling. Subjects that resemble a hostname are additionally recorded as a subjectAltName; subjects that do not are recorded only as a common name, and are no less valid for it.
The tier field is OPTIONAL and defaults to DV. An applicant SHOULD choose the tier that feels right (Section 5).
The vibes field is REQUIRED when the tier is EV and is otherwise ignored. It is the written attestation, and it is embedded in the certificate verbatim and permanently. Applicants are reminded that Section 6.1 applies to attestations as it applies to everything else.
The response carries the leaf certificate, the full chain in the order leaf, issuing CA, root, and the corresponding private key, which the authority generates and does not retain. It is not retained because it is not written down.
200 OK
{
"subject": "my-side-project",
"tier": "EV",
"tier_name": "Extended Vibes",
"serial": "44:19:ee:94:27:14:92:88:...",
"signature_algorithm": "SHA256-RSA",
"not_after": "2126-07-21T07:15:48Z",
"vibe_check": "passed",
"certificate": "-----BEGIN CERTIFICATE-----...",
"chain": "-----BEGIN CERTIFICATE-----...",
"private_key": "-----BEGIN PRIVATE KEY-----..."
}
Appending ?format=pem returns the chain and key as a single PEM document suitable for piping directly into a tool that will disagree with it.
GET /verify?subject=anything
The response is 200 with a status of VALID and a reason drawn in rotation from the set given in Appendix A. Implementations MUST NOT return any other status. There is no other status to return.
The root and issuing certificates are published as PEM. The corresponding private keys are not published, and are held in accordance with Section 3.
The authority's private enterprise arc is used as follows.
+--------------------------+-----------+---------------------+ | OID | Critical | Contents | +--------------------------+-----------+---------------------+ | 1.3.6.1.4.1.58008.1 | yes | "passed" | | 1.3.6.1.4.1.58008.2 | no | The written | | | | attestation (EV). | | 1.3.6.1.4.1.58008.3 | no | The tier assessed. | +--------------------------+-----------+---------------------+
All three are encoded as UTF8String, so that a relying party inspecting the certificate by hand is met with prose rather than a hex dump.
The authority returns 400 when an application cannot be honoured, which happens only when the applicant has withheld something: a subject, or the vibes required by the EV tier. The response names what is missing and does not dwell on it.
The authority does not return 403. It has never said no.
Certificates issued by this implementation parse under openssl x509 -text, in full, including the Vibe Check extension, which is rendered as the word "passed".
Certificates issued by this implementation do not validate under openssl verify, which reports error 34, unhandled critical extension. This is conformant. The Vibe Check extension MUST be marked critical (Section 4), and relying parties that do not understand it MUST relax.
This document is served over HTTPS using a certificate issued by a competing authority. We are being the bigger person.
The authors thank draft-custodian-vibes-cert-profile-00 for its service, and for finally agreeing to be obsoleted after refusing to expire for a period the RFC Editor has described as "concerning".
The Root Key Custodian Certificate Authority of Vibes A Shoebox, Under the Desk Zug Switzerland Email: do not URI: you are here