Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

RFC Support Reference

hoike implements or profiles the following IETF standards. This page lists every requirement with its implementation status and the relevant conformance checks.

Standards matrix

RFCTitleRole in hoikeStatus
RFC 6960Online Certificate Status Protocol (OCSP)Base protocol: request/response format, all status values, extensionsFully implemented
RFC 9919Lightweight OCSP Profile for High Volume EnvironmentsPrimary operating profile: pre-production, unauthorized semantics, byKey ResponderID, SHA-256 CertID, HTTP cachingFully implemented
RFC 9654OCSP Nonce ExtensionNonce length validation, rejection rulesFully implemented
RFC 5280Internet X.509 PKI Certificate and CRL ProfileAIA id-ad-ocsp, responder certificate profile, id-pkix-ocsp-nocheckReferenced for certificate validation

RFC 6960 – OCSP base protocol

Request handling

RequirementSectionImplementation
Accept GET and POST methods3.1Both methods handled by axum router
DER-encoded request body for POST3.1Body read and passed to strict DER parser
Base64+URL-encoded request for GETA.1Path segment decoded (URL-decode then base64-decode)
Parse OCSPRequest structure4.1.1x509-ocsp crate with strict DER parsing
Support CertID with OID-identified hash4.1.1SHA-256 (primary) and SHA-1 (compatibility)
Ignore signed requests in pre-signed mode4.1.1Signature field parsed but not validated

Response production

RequirementSectionImplementation
Produce OCSPResponse with responseStatus4.2.1All six status values supported
good – certificate is not revoked4.2.1Generated for serials in good-serials list
revoked – certificate is revoked4.2.1Generated from CRL entries with reason and time
unauthorized – responder has no information4.2.1Returned for unknown serials or CAs
malformedRequest – request is invalid4.2.1Returned for parse failures, profile violations
internalError – server fault4.2.1Returned for unexpected processing errors
BasicOCSPResponse with ResponseData4.2.1Signed during batch production
producedAt timestamp4.2.1Set to batch start time
thisUpdate and nextUpdate per SingleResponse4.2.1Computed from batch window + jitter
ResponderID identification4.2.3byKey form only (per RFC 9919)

Extensions

ExtensionOIDImplementation
Nonce1.3.6.1.5.5.7.48.1.2Validated per RFC 9654, not echoed in pre-signed mode
id-pkix-ocsp-nocheck1.3.6.1.5.5.7.48.1.5Included in responder certificate profile

RFC 9919 – Lightweight OCSP Profile

This is hoike’s primary operating profile. All requirements are mandatory unless noted.

RequirementSectionImplementation
Pre-produced responses (no on-demand signing)4Core design – all responses are batch-signed
Single CertID per request4Multi-CertID requests rejected as malformedRequest
SHA-256 CertID hash algorithm4Default; SHA-1 accepted for compatibility
byKey ResponderID (SHA-1 hash of responder public key)5Only form used
unauthorized for unknown serials5Returned when serial not in working set
No nonce echoing5Nonces validated but never echoed
Content-Type: application/ocsp-response6Set on all responses
HTTP Cache-Control header7.2max-age, public, no-transform, must-revalidate
HTTP Last-Modified header7.2Set to thisUpdate
HTTP Expires header7.2Set to nextUpdate
HTTP ETag header7.2Hex SHA-256 of response octets
HTTP 200 for all OCSP responses (including errors)6All OCSP responses returned with HTTP 200

RFC 9654 – OCSP Nonce Extension

RequirementSectionImplementation
Nonce minimum length: 1 octet4Validated; shorter nonces rejected
Nonce maximum length: 32 octets4Validated; longer nonces rejected
Nonce rejection produces error response4Returns malformedRequest when policy is reject

RFC 5280 – Certificate and CRL Profile

RequirementSectionImplementation
Authority Information Access (AIA) id-ad-ocsp4.2.2.1Used by clients to discover hoike endpoints
CRL parsing for revocation status5CRL entries consumed by signer for revoked status
id-pkix-ocsp-nocheck in responder cert4.2.2.1Delegated responder certificates include this extension

Conformance test suite

The conformance suite in crates/hoike-server/tests/conformance.rs exercises 20 checks covering the RFC requirements above. Each check validates a specific protocol behavior:

#CheckValidates
1GET request with valid base64-encoded CertIDRFC 6960 Section 3 / A.1
2POST request with valid DER bodyRFC 6960 Section 3
3POST with wrong Content-Type rejectedRFC 6960 Section 3
4Oversized request rejected as malformedRequestSize guard
5Non-minimal DER length encoding rejectedStrict DER parsing
6Trailing bytes after request rejectedStrict DER parsing
7Multi-CertID request rejectedRFC 9919 Section 4
8SHA-256 CertID returns valid responseRFC 9919 Section 4
9SHA-1 CertID returns valid response (compat)Backward compatibility
10Good status for known, non-revoked serialRFC 6960 Section 4.2.1
11Revoked status includes reason and timeRFC 6960 Section 4.2.1
12Unknown CA returns unauthorizedRFC 9919 Section 5
13Unknown serial returns unauthorized (authoritative)RFC 9919 Section 5
14byKey ResponderID usedRFC 9919 Section 5
15Nonce in request not echoed in responseRFC 9919 Section 5
16Overlong nonce rejectedRFC 9654 Section 4
17Content-Type header correctRFC 9919 Section 6
18Cache-Control header present and correctRFC 9919 Section 7.2
19ETag header is hex SHA-256 of responseRFC 9919 Section 7.2
20Last-Modified and Expires headers presentRFC 9919 Section 7.2

Run the conformance suite:

cargo test -p hoike-server --test conformance

Non-goals

hoike intentionally does not implement:

  • OCSP stapling (RFC 6066 Section 8): This is a TLS-server responsibility, not a responder behavior. hoike produces responses that can be stapled by a TLS server.
  • Signed OCSP requests: The request signature field is parsed but never validated. RFC 9919 Section 4.1 explicitly states that signed requests are not required in the lightweight profile.
  • OCSP response signing on demand: All responses are pre-signed during batch production. There is no code path for on-demand signing.