]> NIO Inc.

China lijun.liao@nio.io

RISE AB

Sweden marco.tiloca@ri.se

RISE AB

Sweden joel.hoglund@ri.se

RISE AB

Sweden rikard.hoglund@ri.se

University of Glasgow

United Kingdom shahid.raza@glasgow.ac.uk

Security COSE Working Group Internet-Draft This document specifies CBOR-encoded PKI structures for use with C509 certificates (draft-ietf-cose-cbor-encoded-cert), X.509 certificates (RFC 5280), and future certificate types. It defines C509 CRL and C509 OCSP, compact CBOR encodings of X.509 Certificate Revocation Lists (RFC 5280) and OCSP messages (RFC 6960), respectively. The structures defined in this document are certificate-type agnostic and can be used with C509 certificates, X.509 certificates, or future certificate types without modification. C509 OCSP improves on RFC 6960 by signing a wider set of fields to prevent algorithm-substitution and certificate-chain substitution attacks, replacing plaintext serial numbers with hashes to preserve requestor privacy, replacing the two-hash issuer identity with a single certificate hash, and identifying all participants (requestor, responder, issuer) by a uniform certificate hash rather than type-specific fields. C509 CRL and C509 OCSP are not wire-format-compatible with their DER-encoded X.509 counterparts and cannot be converted to or from them without semantic interpretation. Additionally, this document specifies the PEM representation of the C509 structures following the framework of . About This Document Status information for this document may be found at . Discussion of this document takes place on the CBOR Object Signing and Encryption (cose) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Public Key Infrastructure (PKI) for constrained environments requires compact certificate representations and compact revocation information. defines C509 certificates, a CBOR encoding of X.509 certificates that reduces certificate size by over 50% for typical constrained-device profiles. However, revocation mechanisms such as Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) messages have not yet received the same treatment. CRLs as defined in can be large, especially when many certificates have been revoked or when CRL extensions add overhead. In the complementary OCSP mechanism defined in , OCSP responses carry per-certificate status information and may be exchanged during TLS and DTLS handshakes via OCSP stapling , directly affecting handshake latency. Note on terminology: The label "C509" is used for consistency with the C509 certificate encoding and to promote a cohesive C509 PKI ecosystem (C509 certificates, CRLs, OCSP, and related tooling). Although this document uses "C509" in its names, the encodings and protocols defined here are certificate-type agnostic and apply equally to X.509 certificates and other certificate types; see . This document specifies:

• C509 CRL -- a natively signed CBOR encoding of X.509 CRLs (). The signature is computed over the CBOR Sequence TBSCertList; no ASN.1 encoding is involved. Three key improvements are made over :
  • Reduce the search complexity for a given certificate serial number from O(n) to O(log(n)):
    • Replace the implicit certificateIssuer mechanism with explicit per-issuer grouping.
    • Use a dedicated list for the removeFromCRL revocation entries.
    • Use fixed-length entry encoding.
  • Define a new standalone C509CRLInfo structure to carry CRL information without the (large) revocation list itself.
  • Define dedicated fields for the common extensions to simplify the encoding: crlNumber, authorityKeyIdentifier, deltaCRLIndicator.
• C509 OCSP -- a CBOR encoding of OCSP requests and responses (). The encoding compresses common fields while preserving semantic equivalence. Four key improvements are made over :
  • The signature in signed requests and responses is computed over a wider set of fields than in , including the signature algorithm and the certificate chain, preventing algorithm-substitution and certificate-chain substitution attacks.
  • Certificate serial numbers in requests and responses are replaced by hashes (serialNumberHash), providing privacy against passive observers who do not already know the queried serial numbers.
  • The issuer is identified by a single hash over the issuer certificate (issuerCertHash) rather than by the two-hash CertID, reducing per-issuer overhead.
  • All participants (requestor, responder, issuer) are identified by a hash over their certificate (requestorCertHash, responderCertHash, issuerCertHash) rather than by a plaintext Subject distinguished name or SubjectKeyIdentifier, avoiding structural CHOICE types such as the X.509 ResponderID (byName or byKey) and simplifying support for different certificate types (e.g., C509, X.509, or future types) because the same hash applies regardless of the certificate encoding.

The CRL and OCSP structures defined in this document are certificate-type agnostic: they can be used with C509 certificates, X.509 certificates, or any future certificate type without modification; see . C509 CRL and C509 OCSP apply the same compression techniques as C509 certificates: static fields are elided, OIDs are replaced with short integers, time values are compressed to POSIX timestamps, and redundant encoding is removed. Implementers may use the CBOR playground to inspect encoded examples. C509 CRL and C509 OCSP are not wire-format-compatible with their DER-encoded counterparts defined in and . Systems that use C509 CRL or C509 OCSP must explicitly support these CBOR-encoded formats; they cannot be transparently substituted for or derived from the corresponding DER-encoded structures. C509 CRL and C509 OCSP are designed to be compatible with certificate profiles for constrained deployments, such as .

Alternative Certificate Status Checking Mechanisms This section considers both widely deployed certificate-status mechanisms and closely related prior work for constrained environments. Several such mechanisms can be used to check certificate status, but none of them replaces the work in this document.

• X.509 CRLs and OCSP (, ) provide the baseline revocation mechanisms, but their DER encodings are not compact enough for constrained deployments and are not certificate-type agnostic. This document keeps their semantics while defining CBOR encodings that are smaller and easier to process.
• OCSP stapling (, ) reduces client latency by having the server provide a fresh OCSP response, but it does not define a revocation status format of its own. It still depends on the underlying OCSP message structure, so it cannot replace a compact, standalone status representation.
• Short-lived certificates reduce reliance on revocation, but they do not provide revocation status when certificates must remain valid for longer periods or must be withdrawn immediately after compromise. They also shift the problem to more frequent issuance and renewal rather than eliminating status checking.
• CRLSets are a browser-distributed revocation blocklist rather than a general-purpose revocation protocol. They cover only a limited subset of certificates and are tied to a specific browser ecosystem, so they cannot provide complete, interoperable status checking for arbitrary C509, X.509, or future certificate types.
• CRLite compresses revocation information into a browser-oriented filter-based representation, which is useful for client-side deployment at scale. However, it is not a wire-format replacement for CRLs or OCSP, does not preserve the full per-certificate status structures defined here, and is not a certificate-type-agnostic status format that other implementations can exchange directly.
• Compact CBOR revocation for IoT (TinyOCSP and CCRL) are prior research mechanisms that reduce OCSP and CRL overhead for low-power IoT, confirming the feasibility and benefits of CBOR-based revocation on constrained hardware. They are a precursor to this work. However, they were specified as point solutions rather than as interoperable, certificate-type-agnostic wire formats aligned with the C509 certificate encoding ; this document generalizes those mechanisms into complete C509 CRL and C509 OCSP structures usable with C509, X.509, and future certificate types.

The compactness benefit over the DER-encoded baselines is concrete and substantial. For the representative profiles in the worked examples (), C509 CRLs are 18% to 52% smaller than the equivalent X.509 CRLs (for example, a CRL carrying revoked certificates is reduced from 335 to 177 bytes, a 47% reduction), and C509 OCSP messages are 40% to 73% smaller (for example, a Simple OCSP request from 150 to 51 bytes, and a Basic OCSP response without the responder's certificate from 837 to 248 bytes); see . These alternatives are useful in specific deployments, but they do not provide the CBOR-based, certificate-type-agnostic revocation structures defined here for C509, X.509, and future certificate types.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the terminology from , , , , , , and . Unless otherwise stated, "CBOR" refers to deterministically encoded CBOR as specified in Sections and of .

Common Types The following types are imported from : Name, Extension, Extensions, Defined, COSE_C509, and AlgorithmIdentifier. Additionally, the following type is imported from : COSE_X509. This document further defines the following constrained aliases for use in all CDDL definitions: The CDDL definitions in this document are split into three files: c509common.cddl (the definitions above), c509crl.cddl (), and c509ocsp.cddl (). Both c509crl.cddl and c509ocsp.cddl depend on c509common.cddl and on the types imported from and . IntAlgorithmIdentifier is the int-only instantiation of AlgorithmIdentifier from . It is used throughout this document wherever an algorithm identifier appears in the wire encoding. IntExtension is the instantiation of Extension from with an integer extensionID. As in C509 certificates (), the absolute value of extensionID is the value from the "C509 Extensions" registry, and its sign indicates whether the extension is critical: critical extensions are encoded with a negative sign and non-critical extensions with a positive sign. It is used throughout this document wherever a single extension appears in the wire encoding. IntExtensions is the instantiation of Extensions from where all embedded Extension entries are IntExtension entries. An IntExtensions field with no extensions is encoded as an empty array.

Encoding of Time Fields Time fields are encoded as unwrapped CBOR epoch-based date/time (~time). The value MUST be a non-negative integer. In POSIX time , leap seconds are ignored; a leap second has the same POSIX time as the second before it.

C509 CRL

Overview A C509 CRL is a natively signed CBOR encoding of an X.509 v2 CRL as defined in . The signature is computed over the CBOR Sequence TBSCertList; no ASN.1 encoding is involved. A C509 CRL preserves the semantics of the corresponding DER-encoded X.509 CRL for the subset of RFC 5280 structures supported by this document. A C509 CRL is not wire-format-compatible with a DER-encoded X.509 CRL. The two formats cannot be mechanically converted to or from each other without semantic interpretation of the contained data.

C509 CRL CDDL The following CDDL defines the top-level C509CRL structure and the TBSCertList sequence:

CDDL for C509CRL

Field Encodings

CRLInfoData and C509CRLInfo CRLInfoData is a CDDL group that carries all CRL fields except revokedCertsList. C509CRLInfo is the standalone CBOR array form of CRLInfoData; it can be used to convey CRL information (crlType, signature algorithm, issuer identity, CRL number, validity window, base CRL number, extensions) without the potentially large revocation list. TBSCertList embeds CRLInfoData and adds revokedCertsList.

crlType The crlType field serves as the discriminator for C509CRL: CRL types

Value	Type
0	C509CRL

Future specifications may define additional types by assigning new integer values.

signatureAlgorithm Encoded identically to the int choice of issuerSignatureAlgorithm in C509 certificates (see ). Algorithm integer values are from the same registry used for C509 certificates. Unlike in , where the signature algorithm appears outside the TBSCertList and is therefore not covered by the CRL signature, signatureAlgorithm is part of CRLInfoData within TBSCertList and is therefore covered by the signature. This prevents algorithm-substitution attacks on the CRL.

authoritySubject and authorityKeyIdentifier The authoritySubject and authorityKeyIdentifier fields identify the CRL authority. The authoritySubject field identifies the subject of the CRL issuer. When the CRL is issued by a C509 CA, authoritySubject is a Name value identical to the subject field of the authority C509 certificate. When the CRL is issued by an X.509 CA (e.g., in a hybrid deployment where a legacy CA issues a C509-format CRL), authoritySubject is encoded as #6.121(bytes) (tag 121 is alternative 0), where the byte string contains the DER-encoded Name from the subject field of the issuing X.509 CA certificate (). Since the Name structure may also be bytes, the DER-encoded subject is wrapped in a 121-tagged structure. The authorityKeyIdentifier field is identical to the value of the authority's subjectKeyIdentifier extension. This field corresponds to the X.509 CRL extension authorityKeyIdentifier (). It is promoted to a dedicated field because it MUST be present in conforming X.509 CRLs and because making it explicit simplifies the structure and reduces encoded size compared to representing it as a generic extension.

crlNumber The crlNumber field is encoded as a positive integer (CRLNumber, from 1 to 2^63 - 1). It corresponds to the cRLNumber extension in , which this document replaces with a dedicated field. The value is monotonically increasing for both full and delta CRLs.

thisUpdate and nextUpdate The thisUpdate field is encoded as described in . The nextUpdate field is encoded as a uint63 representing the number of seconds from thisUpdate until the next CRL is expected to be issued. It is encoded as null when no next update time is known.

baseCrlNumber The baseCrlNumber field is encoded as null for a full CRL. For a delta CRL, it contains the CRL number of the corresponding base full CRL. It corresponds to the deltaCRLIndicator extension in , which this document replaces with a dedicated field.

reasonCode Encoding The reasonCode ENUMERATED value is encoded as one unsigned byte. The byte values are aligned with the ENUMERATED values of the CRLReason type defined in ; a C509 revocationReason byte value equals the corresponding ASN.1 ENUMERATED integer value for the same reason code. reasonCode encoding

Byte	reasonCode
0x00	unspecified
0x01	keyCompromise
0x02	cACompromise
0x03	affiliationChanged
0x04	superseded
0x05	cessationOfOperation
0x06	certificateHold
-	removeFromCRL
0x09	privilegeWithdrawn
0x0A	aACompromise

removeFromCRL (enumeration value 0x08) is not encoded in revokedCerts. Certificates removed from the CRL are instead indicated in the removedFromCRLCerts field of PerIssuerRevokedCerts.

revokedCertsList and PerIssuerRevokedCerts

Design Considerations In X.509 CRLs (), an indirect CRL uses the certificateIssuer CRL entry extension to indicate that a revocation entry -- and all subsequent entries -- belong to a different issuer. This mechanism has two significant drawbacks:

• It is implicit and positional, making it difficult to parse correctly and error-prone to implement.
• It is impossible to represent an issuer that has no currently revoked certificates (e.g., to carry per-issuer extensions or to explicitly indicate that the issuer is known but has an empty revocation list), because there is no entry to attach the certificateIssuer extension to.

PerIssuerRevokedCerts solves both problems by introducing an explicit intermediate structure that groups all revocation information for one issuer. The issuer is identified directly in the issuer field of the structure rather than being inferred from the position of a CRL entry extension. This makes the grouping unambiguous and easy to parse, and it allows an issuer to appear in the list even when it has no revoked certificates. A second design problem in X.509 CRLs is that each revocation entry has variable length because:

• the serial number length differs between certificates,
• the revocation date uses different encodings depending on whether the date falls before or after 2050,
• optional per-entry extensions (e.g., reason code) may or may not be present.

This variable-length layout makes it impossible to determine whether a given serial number is present in the list without scanning every entry sequentially, resulting in O(n) lookup time. In this document, the revokedCertsControl structure introduces fixed parameters (serialNumberLength, dateLength) that make every entry within revokedCerts exactly the same size. The flags field can additionally indicate that entries are sorted in ascending order by serial number, enabling binary search and reducing lookup time to O(log(n)). Using a compact byte-string concatenation rather than a CBOR array of structured items further reduces encoded size and accelerates parsing. Furthermore, certificates removed from the CRL (delta CRL removeFromCRL entries in X.509) are kept in a dedicated removedFromCRLCerts field rather than mixed into revokedCerts. This keeps revokedCerts free of removal noise, reducing its size and allowing implementations to process currently revoked and removed entries independently.

Fields The revokedCertsList field is either a CBOR array of one or more PerIssuerRevokedCerts entries, each describing the revocation state for certificates issued by one issuer, or CBOR null. Since PerIssuerRevokedCerts is a CDDL group, the fields of each entry are inlined in the array rather than wrapped in a nested array; an array with n entries therefore contains 5n elements. revokedCertsList MUST be encoded as CBOR null when all of the following conditions hold: no certificates are currently revoked, no certificates have been removed from the CRL, the only issuer that would appear is the CRL's own authoritySubject (i.e., the issuer field is null), and there are no non-empty per-issuer extensions. Each PerIssuerRevokedCerts entry describes revoked certificates for one issuer using the following fields:

• The issuer field identifies the issuer of the certificates covered by this PerIssuerRevokedCerts entry. When the issuer is a C509 CA, it is encoded as a Name value identical to the issuer field of the covered C509 certificates. When the issuer is an X.509 CA, it is encoded as #6.121(bytes) (tag 121 is alternative 0), where the byte string contains the DER-encoded Name from the issuer field of the covered X.509 certificates (). If the issuer is identical to the CRL's authoritySubject field, it MUST be encoded as CBOR null.
• The revokedCertsControl field defines the controls for interpreting removedFromCRLCerts and revokedCerts. If either removedFromCRLCerts or revokedCerts is non-null, revokedCertsControl MUST NOT be null. If both removedFromCRLCerts and revokedCerts are null, revokedCertsControl MUST be null to reduce CRL size.
  • The flags field is an unsigned integer encoding boolean control bits for crlType = 0: bit 0 indicates whether entries in revokedCerts are sorted in ascending order by the integer value of the certificate serial number; bit 1 indicates whether each entry contains a reason code. Bits greater than 1 are reserved for crlType = 0 and MUST be zero and MUST be ignored by receivers. Future crlType values defined in successor documents may assign additional bit meanings.
  • The serialNumberLength field defines the length, in bytes, of a certificate serial number. It MUST be greater than 0. It is the smallest value that can encode all certificate serial numbers without leading zeros. Each certificate serial number is encoded as a fixed-length big-endian integer of length serialNumberLength. If the encoded value is shorter than serialNumberLength, it is left-padded with zeros.
  • The dateLength field defines the length, in bytes, of the big-endian encoded revocation-date offset relative to baseDate. A value of 0 means that no revocation date is included in revokedCerts entries. This is permitted in C509-native deployments where the revocation date is not required -- for example, when minimizing revocation data is more important than recording the revocation time. Implementations that need to convert a C509 CRL to an RFC 5280 DER-encoded CRL MUST set dateLength to a non-zero value, since requires a revocationDate in every CRL entry. When dateLength is non-zero, the offset MUST fit within the specified byte length without leading zero bytes.
  • The baseDate field is a reference time used to compute revocation and removal dates, encoded as described in . It MUST be greater than or equal to the issuer certificate's notBefore, which ensures that all stored offsets are non-negative. It is RECOMMENDED to set baseDate to the earliest revocation date and removal-from-CRL date among all entries in this CRL, as this minimizes the magnitude of stored offsets and reduces encoding size. Any time between the issuer certificate's notBefore (inclusive) and that earliest date (inclusive) is a conformant value. Revocation dates in revokedCerts and removal dates in removedFromCRLCerts are stored as non-negative offsets, in seconds, from baseDate.
• The extensions field contains per-issuer extensions.
• The revokedCerts field is a CBOR byte string containing the concatenated byte sequence of revoked-certificate entries. Each entry is the concatenation of:
  • a big-endian encoded certificate serial number of length serialNumberLength;
  • a big-endian encoded revocation-date offset from baseDate, in seconds, of length dateLength (absent when dateLength is 0); and
  • an optional reason code (1 byte if bit 1 of flags is set, absent otherwise).
  If there are no entries, this field MUST be encoded as CBOR null instead of a zero-length byte string. The revocation date for a given entry is recovered by adding the stored offset to baseDate. When dateLength is 0, no revocation date is stored and no date recovery is possible. Revoked-certificate entries have fixed length. If bit 0 of flags is set, entries are sorted in ascending order, enabling binary search for a given serial number in O(log(n)) time.
• The removedFromCRLCerts field contains a concatenated byte sequence of entries for certificates removed from the CRL since publication of the CRL with crlNumber = baseCrlNumber. Each entry is the concatenation of:
  • a big-endian encoded certificate serial number of length serialNumberLength; and
  • a big-endian encoded removal-date offset from baseDate, in seconds, of length dateLength (absent when dateLength is 0).
  If there are no entries, this field MUST be encoded as CBOR null instead of a zero-length byte string. The removal date for a given entry is recovered by adding the stored offset to baseDate. When dateLength is 0, no removal date is stored and no date recovery is possible. Removed-certificate entries have fixed length. If bit 0 of flags is set, entries are sorted in ascending order, enabling binary search for a given serial number in O(log(n)) time.

CRL Extensions The crlExtensions field contains extensions for the CRL. This document does not define any new CRL-level extensions. lists X.509 CRL extensions and their equivalents. CRL extensions and their equivalents

Code	Extension	Reference	Equivalent
-	authorityKeyIdentifier		field authorityKeyIdentifier
-	issuerAltName		-
-	cRLNumber		field crlNumber
-	deltaCRLIndicator		field baseCrlNumber
-	issuingDistributionPoint		-
-	freshestCRL		-
-	authorityInfoAccess		-
-	orderedList	OID 2.5.29.56 (ITU-T X.509, Section 9.5.2.5)	bit 0 of flags (ascSerialNum); - (ascRevDate)
-	toBeRevoked	OID 2.5.29.58 (ITU-T X.509, Section 9.5.2.6)	-
-	revokedGroups	OID 2.5.29.59 (ITU-T X.509, Section 9.5.2.7)	-

Per-Issuer Extensions The extensions field of PerIssuerRevokedCerts contains per-issuer extensions. This document defines one per-issuer extension (expiredCertsOnCRL, see ). lists per-issuer extensions defined in this document. Per-issuer extensions and their equivalents

Code	Extension	Reference	Equivalent
TBD4	expiredCertsOnCRL	OID 2.5.29.60 (ITU-T X.509, Section 9.5.2.8)	-

expiredCertsOnCRL The expiredCertsOnCRL extension indicates that this CRL includes revocation information for certificates that have already expired. The extension value is a time value indicating the earliest expiration date of certificates included on the CRL; certificates that expired on or after this date are listed even if they are expired when the CRL is generated. The extension value MUST be encoded as follows. The value is encoded as described in . When this extension is present, a relying party processing expired certificates (for example, for audit or archiving purposes) SHOULD use the indicated date to determine the extent of historical revocation coverage.

CRL Entry Extensions lists X.509 CRL entry extensions. No corresponding extension is defined in this document. CRL entry extensions defined for X.509 CRLs

Code	Extension	Reference	Equivalent
-	reasonCode	/ ITU-T X.509, Section 9.6.2.1	fields removedFromCRLCerts and revokedCerts
-	holdInstructionCode	/ ITU-T X.509, Section 9.6.2.2	-
-	invalidityDate	/ ITU-T X.509, Section 9.6.2.3	-
-	certificateIssuer	/ ITU-T X.509, Section 9.6.2.4	field issuer within PerIssuerRevokedCerts

signatureValue Encoded identically to signatureValue in C509 certificates (see ).

PEM Representation The CBOR-encoded C509CRL is first Base64-encoded and then wrapped between "-----BEGIN C509 CRL-----" and "-----END C509 CRL-----", following the framework of .

C509 CRL PEM Encoding

C509 OCSP

Overview C509 OCSP defines CBOR encodings for OCSP requests and OCSP responses as defined in . The encoding follows the same compression principles as C509 CRL and C509 certificates. C509 OCSP requests and responses are not wire-format-compatible with DER-encoded OCSP messages as defined in . The two formats cannot be mechanically converted to or from each other without semantic interpretation of the contained data. C509OCSPRequest and C509OCSPResponse are designed to be extensible. The first field of every message is ocspRequestType or ocspResponseType, an integer that identifies the structure type. Future specifications may define additional types by assigning new integer values, enabling new request or response structures to be introduced without modifying the existing types.

Hash Algorithms The hashAlgorithm field of C509 OCSP requests and responses identifies the hash algorithm used to compute all hashes within the enclosing structure. Its value is the integer identifier of a hash algorithm from the "COSE Algorithms" registry , e.g., -16 for SHA-256, -43 for SHA-384, and -44 for SHA-512 . Any hash algorithm in that registry can be used, subject to the restrictions below; for example, SHA3-256 or SM3 can be used once they are registered. The hash algorithm MUST produce an output of at least 20 bytes, so that HashId20 values can be derived (see ). Consequently, SHA-256/64 (-15) MUST NOT be used. Other truncated hash algorithms, such as SHA-512/256 (-17), SHOULD NOT be used: this document already defines the truncated identifiers HashId8 and HashId20, so using a truncated hash algorithm provides no benefit. SHA-1 (-14) MUST NOT be used either, since it is not collision resistant. For SHAKE128 (-18) and SHAKE256 (-45), the output length is as specified in , i.e., 256 and 512 bits, respectively. For an extendable-output function whose output length is not fixed by its registration, such as TurboSHAKE128 (-261) and TurboSHAKE256 (-262) , the output length is the length of the identifier being computed, i.e., 8 bytes for HashId8 and 20 bytes for HashId20.

Identification of Certificates To reduce OCSP message size, this document defines two truncated-hash identifier types used to refer to certificates compactly:

• HashId8: the leading 8 bytes of the hash value computed using the enclosing hashAlgorithm. HashId8 is used to identify issuer certificates and the certificates of OCSP requestors and responders in request and response structures where a short identifier provides sufficient uniqueness in the deployment context.
• HashId20: the leading 20 bytes of the hash value computed using the enclosing hashAlgorithm. HashId20 is intended for identifying certificate serial numbers (the serialNumberHash field) when higher uniqueness is required to minimize collision risk. When derived from a secure hash (e.g., SHA-256 or SHA3-256) and treated as a random output, it gives ~2^160 preimage work and ~2^80 collision resistance (birthday bound) for the truncated value. Since the relying party verifies a certificate's signature before querying OCSP, an adversary needs to construct a different certificate that (a) validates under the same issuer chain and (b) has a serial number whose hash truncation equals an existing certificate's HashId20. Such a construction is practically infeasible.

HashId20 is used to carry the hash of the certificate serial number of the target certificate, computed using the hashAlgorithm of the enclosing structure. The serial number is encoded in big-endian byte order without a leading zero byte (as in C509 certificates) before hashing. In X.509, a CertificateSerialNumber INTEGER is DER-encoded with a leading zero byte when the most-significant bit is set; that leading zero MUST be stripped before computing the hash. Using a hash rather than the plain serial number preserves the privacy of the requestor: an observer cannot determine which certificate is being queried without already knowing the serial number.

C509 OCSP Request

CDDL

CDDL for C509OCSPRequest

Field Encodings

ocspRequestType The ocspRequestType field serves as the discriminator for C509OCSPRequest: OCSP request types

Value	Type
0	C509UnsignedOCSPRequest
1	C509SignedOCSPRequest
2	C509SimpleOCSPRequest

issuerCertHash The issuerCertHash field appears in PerIssuerOCSPRequest, PerIssuerOCSPResponse, C509SimpleOCSPRequest, and TBSSimpleOCSPResponse. It contains a hash of the issuer certificate:

• issuerCertHash: hash computed over the deterministically encoded certificate, i.e., the CBOR-encoded C509Certificate or the DER-encoded () X.509 certificate. For a CBOR re-encoded X.509 certificate (c509CertificateType = 3, see ), the hash MUST be computed over the DER-encoded X.509 certificate, not over its C509 encoding, since such a certificate may have more than one conformant CBOR encoding (see ). The hash algorithm is specified by the hashAlgorithm field of the enclosing request or response structure.

In X.509 OCSP (), the CertID structure identifies the issuer using two separate hashes: issuerNameHash (a hash of the DER-encoded issuer name) and issuerKeyHash (a hash of the issuer's public key bit string). This two-hash approach was designed for interoperability with DER-encoded X.509 structures, but it doubles the per-issuer overhead in the message. In C509 OCSP, the issuer is identified by a single hash of the issuer certificate (issuerCertHash), which is simpler, smaller, and unambiguous. Implementations that need to cross-reference a C509 issuerCertHash with an RFC 6960 DER-encoded CertID must recompute the respective hash inputs; the values are not directly comparable.

PerIssuerOCSPRequests, PerIssuerOCSPRequest, SingleCertRequests and SingleCertRequest PerIssuerOCSPRequests is a list of PerIssuerOCSPRequest entries. In X.509 OCSP (), every Request entry embeds a full CertID containing the issuer identity fields (hashAlgorithm, issuerNameHash, issuerKeyHash) alongside the serialNumber. When multiple certificates from the same issuer are queried in a single request, these issuer fields are repeated verbatim for every entry, wasting space. PerIssuerOCSPRequest solves this by grouping all single-certificate requests for the same issuer under one entry: the issuerCertHash field is encoded once and shared across all SingleCertRequest entries in the singleRequests list, eliminating the per-entry duplication. Since PerIssuerOCSPRequest and SingleCertRequest are CDDL groups, the fields of each entry are inlined in the enclosing array rather than wrapped in a nested array.

• The extensions field contains per-issuer extensions that apply to all single-certificate requests in this PerIssuerOCSPRequest entry; see .
• The singleRequests field is a list of SingleCertRequest entries for certificates from this issuer.

Each SingleCertRequest contains:

• The serialNumberHash field is the truncated hash of the certificate serial number of the target certificate, computed using the hashAlgorithm of the enclosing request structure. The serial number is encoded in big-endian byte order without a leading zero byte (as in C509 certificates) before hashing. Using a hash rather than the plain serial number preserves the privacy of the requestor: an observer cannot determine which certificate is being queried without already knowing the serial number.
• The extensions field contains extensions for the single request; see .

C509UnsignedOCSPRequest

• The ocspRequestType field MUST be 0.
• The hashAlgorithm field specifies the hash algorithm used to compute issuerCertHash and serialNumberHash. The algorithm is encoded as specified in .
• The nonce field contains the request nonce, or MUST be null when no nonce is present. The nonce MUST be generated by a cryptographically strong pseudorandom number generator and MUST be between 16 and 32 bytes long. An OCSP server MUST reject a request whose nonce is shorter than 16 bytes or longer than 32 bytes by returning a C509ErrorOCSPResponse with responseStatus set to malformedRequest (1).
• The extensions field contains request-level extensions; see .
• The requests field is a list of PerIssuerOCSPRequest entries, each grouping target certificates by issuer; see .

C509SignedOCSPRequest

• The ocspRequestType field MUST be 1.
• The signatureAlgorithm field specifies the signature algorithm, as defined in .
• The hashAlgorithm field specifies the hash algorithm used to compute requestorCertHash, issuerCertHash, and serialNumberHash. The algorithm is encoded as specified in .
• The nonce field is as defined for C509UnsignedOCSPRequest ().
• The requestorCertHash field is a hash of the signer's certificate, computed using hashAlgorithm. When requestorCerts is not null, it carries the corresponding certificate chain so that the receiver can verify the identity of the requestor.
• The extensions field contains request-level extensions; see .
• The requests field is as defined for C509UnsignedOCSPRequest ().
• The requestorCerts field contains a sorted certificate chain starting with the signer's certificate, or MUST be null if no certificates are transported. When the signer holds a C509 certificate chain, the value is COSE_C509. When the signer holds an X.509 certificate chain, the value is #6.121(COSE_X509), wrapping a COSE_X509 chain with CBOR tag 121 (alternative 0).
• The signatureValue field is the signature computed over the CBOR Sequence of the TBSOCSPRequest group.

C509SimpleOCSPRequest C509SimpleOCSPRequest is a compact request format for querying the status of a single certificate. Unlike C509UnsignedOCSPRequest, which uses a two-level PerIssuerOCSPRequests / SingleCertRequest grouping to batch multiple serial numbers across one or more issuers, C509SimpleOCSPRequest flattens the structure into a single CBOR array for the common case of a one-certificate query.

• The ocspRequestType field MUST be 2.
• The hashAlgorithm field specifies the hash algorithm used to compute issuerCertHash and serialNumberHash. The algorithm is encoded as specified in .
• The nonce field is as defined for C509UnsignedOCSPRequest ().
• The issuerCertHash field identifies the issuer of the target certificate; see .
• The serialNumberHash field is the hash of the certificate serial number of the target certificate, computed as in .
• The extensions field contains request-level extensions; see .

PEM Representation The CBOR-encoded C509 OCSP request is first Base64-encoded and then wrapped between "-----BEGIN C509 OCSP REQUEST-----" and "-----END C509 OCSP REQUEST-----", following the framework of .

C509 OCSP Request PEM Encoding

C509 OCSP Response

CDDL

CDDL for C509OCSPResponse

Field Encodings

C509ErrorOCSPResponse If the OCSP server cannot process the OCSP query, it returns a C509ErrorOCSPResponse. The ocspResponseType value MUST be 0, and responseStatus has the following enumerated values, as in : responseStatus values

int	responseStatus
-	successful
1	malformedRequest
2	internalError
3	tryLater
5	sigRequired
6	unauthorized

C509BasicOCSPResponse The ocspResponseType field of C509BasicOCSPResponse is 1, distinguishing it from C509ErrorOCSPResponse. It corresponds to BasicOCSPResponse in . TBSBasicOCSPResponse is the group of fields to be signed. The signatureValue field is the only field outside the signed group. Covering signatureAlgorithm and responderCerts within the signed content prevents algorithm-substitution and certificate-chain substitution attacks; this design goes beyond the protections offered by the DER-encoded BasicOCSPResponse defined in .

C509SimpleOCSPResponse C509SimpleOCSPResponse is a compact signed response for a single-certificate status query. It is the response counterpart to C509SimpleOCSPRequest (see ). Unlike C509BasicOCSPResponse, which uses a two-level PerIssuerOCSPResponses / SingleCertResponse grouping to carry status for multiple certificates across one or more issuers, C509SimpleOCSPResponse flattens the structure into a single signed CBOR array for the common case of a one-certificate response. TBSSimpleOCSPResponse is the group of fields to be signed. The signatureValue field is the only field outside the signed group. Covering signatureAlgorithm, responderCertHash, and responderCerts within the signed content prevents algorithm-substitution and certificate-chain substitution attacks.

• The ocspResponseType field MUST be 2, which discriminates C509SimpleOCSPResponse from C509ErrorOCSPResponse and C509BasicOCSPResponse.
• The signatureAlgorithm field specifies the signature algorithm, as defined in . It is part of TBSSimpleOCSPResponse and is therefore covered by the signature.
• The hashAlgorithm field specifies the hash algorithm used to compute responderCertHash, issuerCertHash, and serialNumberHash. The algorithm is encoded as specified in .
• The nonce field contains the request nonce, or MUST be null when no nonce is present. If present, it MUST have the same value as the nonce in the corresponding C509SimpleOCSPRequest.
• The responderCertHash field identifies the OCSP responder; see .
• The issuerCertHash field identifies the issuer of the queried certificate; see .
• The serialNumberHash field is the hash of the certificate serial number of the target certificate, computed as in .
• The certStatus field encodes the revocation status; see .
• The producedAt field is the time at which this response was produced, encoded as described in .
• The thisUpdate field is encoded as a non-positive integer (nint / 0) representing the number of seconds from producedAt at which the indicated status is known to be correct. It MUST be 0 or negative, since the status cannot be known at a time in the future relative to the time the response was produced.
• The nextUpdate field is encoded as a uint63 representing the number of seconds from producedAt until the next response update is expected, or null if the update time is unknown.
• The extensions field contains response-level extensions; see .
• The responderCerts field carries the certificate chain starting with the responder certificate identified by responderCertHash; see .
• The signatureValue field is the signature computed over the CBOR Sequence of the TBSSimpleOCSPResponse group.

nonce If present, this field MUST have the same value as the nonce in the corresponding request.

responderCertHash responderCertHash is a truncated hash over the responder's certificate, computed using the same hashAlgorithm as issuerCertHash. In X.509 OCSP (), the responder is identified by a ResponderID CHOICE that carries either a distinguished name or a public-key hash. C509 OCSP replaces this with a single hash over the entire responder certificate, which is consistent with the issuerCertHash design for issuer identification.

responderCerts When present, the responderCerts field carries the certificate chain starting with the responder certificate identified by responderCertHash. When the responder holds a C509 certificate chain, the value is COSE_C509. When the responder holds an X.509 certificate chain, the value is #6.121(COSE_X509), wrapping a COSE_X509 chain with CBOR tag 121 (alternative 0). The field is part of TBSBasicOCSPResponse or TBSSimpleOCSPResponse and is therefore covered by the signature, which prevents certificate-chain substitution attacks.

signatureAlgorithm and signatureValue

• signatureAlgorithm: the signature algorithm used to compute signatureValue, as defined in . It is part of the TBSBasicOCSPResponse or TBSSimpleOCSPResponse group and is therefore covered by the signature.
• signatureValue: the signature computed over the CBOR Sequence of the TBSBasicOCSPResponse or TBSSimpleOCSPResponse group.

producedAt, thisUpdate, nextUpdate The producedAt field is encoded as described in . The thisUpdate field is encoded as a non-positive integer (nint / 0) representing the number of seconds from producedAt at which the indicated status is known to be correct; it MUST be 0 or negative, since the status cannot be known at a time in the future relative to when the response was produced. The nextUpdate field is encoded as a uint63 representing the number of seconds from producedAt until the next update is expected to be available. nextUpdate may be null, which indicates an unknown update time.

extensions See .

PerIssuerOCSPResponses and PerIssuerOCSPResponse PerIssuerOCSPResponses is a list of PerIssuerOCSPResponse entries. For the same reason as on the request side (see ), the issuerCertHash field is encoded once per issuer and shared across all SingleCertResponse entries in the singleResponses list, avoiding the per-entry repetition that would occur if the issuer identity were embedded in every individual response entry. PerIssuerOCSPResponse groups single responses for certificates issued by the same issuer; the issuer is identified by issuerCertHash (see ). As on the request side, PerIssuerOCSPResponse and SingleCertResponse are CDDL groups whose fields are inlined in the enclosing array.

• The extensions field contains per-issuer extensions that apply to all single-certificate responses in this PerIssuerOCSPResponse entry; see .
• The singleResponses field contains one SingleCertResponse for each queried certificate issued by that issuer.

SingleCertResponse

serialNumberHash This field contains the truncated hash of the serial number of the certificate being queried, computed as in .

extensions See .

certStatus CertStatus is encoded either as an integer (for good, not-issued, and unknown) or as a RevokedInfo array:

• 0: good -- the certificate is not revoked.
• 1: not-issued -- the issuer is recognized but the serial number is unknown.
• 2: unknown -- the responder does not recognize the issuer identified by issuerCertHash.
• RevokedInfo: revoked -- an array carrying revocationTime and revocationReason. The revocationReason field is encoded as specified in . When the revocation reason is not known, revocationReason MUST be set to 0 (unspecified).

The integer values are chosen to align with the ASN.1 IMPLICIT tag numbers of CertStatus in : good uses ASN.1 tag 0 and unknown uses ASN.1 tag 2. The ASN.1 revoked alternative uses ASN.1 tag 1; since C509 represents the revoked status as the explicit RevokedInfo array, the integer value 1 becomes available. It is assigned to the not-issued status, which was introduced in to distinguish unrecognized serial numbers from unrecognized issuers, thereby maintaining a contiguous integer range for the non-revoked statuses.

Per-Issuer OCSP Extensions PerIssuerOCSPRequest.extensions and PerIssuerOCSPResponse.extensions carry per-issuer extensions. lists the per-issuer extensions defined in this document. Per-issuer OCSP extensions

Code	Extension	Applied in	Comments
(none defined)

OCSP Extensions describes the OCSP extensions defined in and and their mapping in this document. OCSP extensions and their mapping

Code	Extension	RFC Reference	Applied in	Replaced in this document
-	nonce		Request Extension, Response Extension	field nonce
-	CRL References		Single Response Extension	-
TBD2	Acceptable Response Types		Request Extension	-
-	Archive Cutoff		Response Extension	-
-	Service Locator		Request Extension	-
TBD3	Preferred Signature Algorithms		Request Extension	-
-	Extended Revoked Definition		Response Extension	cert status not-issued (for serial numbers not issued by a recognized issuer) and unknown (for unrecognized issuers)
TBD6	TN Query		Single Request Extension	-

This document defines the following extension values:

• Acceptable Response Types: The extension value MUST be encoded as follows.

The integers in AcceptableResponseTypes form a sorted list of preferred C509OCSPResponse types, in descending order of preference, that the requestor is willing to accept. This document defines types 0 (C509ErrorOCSPResponse), 1 (C509BasicOCSPResponse), and 2 (C509SimpleOCSPResponse). Type 0 (C509ErrorOCSPResponse) is always implicitly supported and does not need to be listed. When this extension is absent, an OCSP server responding to a C509UnsignedOCSPRequest or C509SignedOCSPRequest MUST reply with a C509BasicOCSPResponse (type 1); an OCSP server responding to a C509SimpleOCSPRequest MUST reply with a C509SimpleOCSPResponse (type 2). If AcceptableResponseTypes contains type 2 but not type 1, and the corresponding request contains entries for two or more certificates, the server SHALL return a C509ErrorOCSPResponse with responseStatus set to malformedRequest (1), since C509SimpleOCSPResponse can only carry status for a single certificate.

• Preferred Signature Algorithms: The extension value MUST be encoded as follows.

The sigIdentifier field carries the signature algorithm identifier. The pubKeyAlgIdentifiers field carries the public key algorithm identifier and MUST be one of:

• a CBOR array of two or more IntAlgorithmIdentifier values, sorted in descending order of preference, when the requestor is willing to accept any of the listed public key algorithms as a match for this signature algorithm preference (e.g., to express hybrid or multi-algorithm key policies); the first entry in the array represents the most preferred public key algorithm,
• a single IntAlgorithmIdentifier value, when exactly one public key algorithm is acceptable, or
• null, when the public key algorithm is unconstrained or implied by sigIdentifier.

PreferredSignatureAlgorithms MUST be sorted in descending order of preference; the first entry represents the most preferred algorithm combination. Since PreferredSignatureAlgorithm is a CDDL group, the fields of each entry are inlined in the array rather than wrapped in a nested array.

• TN Query: The extension value MUST be encoded as follows.

The TNQuery extension carries a telephone number string conforming to the TelephoneNumber ASN.1 type (). When included in single request extensions, it specifies the telephone number for which the OCSP query is being performed (typically the number from the "orig" field of a PASSporT being validated). This extension is allowed only in the single-request extensions per .

PEM Representation The CBOR-encoded C509 OCSP response is first Base64-encoded and then wrapped between "-----BEGIN C509 OCSP RESPONSE-----" and "-----END C509 OCSP RESPONSE-----", following the framework of .

C509 OCSP Response PEM Encoding

Certificate Type Interoperability C509 OCSP uses a single set of request and response structures that handles both C509 and X.509 certificates without modification. All participants (requestor, responder, issuer) are identified by a hash over their certificate rather than by type-specific fields such as a Subject distinguished name, SubjectKeyIdentifier, or the X.509 ResponderID CHOICE (byName or byKey). Because a hash applies uniformly regardless of the certificate encoding, the same OCSP structures accommodate C509 certificates (CBOR-encoded), X.509 certificates (DER-encoded), and any future certificate types. The only per-type differences are in how identity hashes are computed and how certificate chains are carried: Per-type differences in C509 OCSP identity fields

Field	C509 certificate	X.509 certificate
issuerCertHash	Hash of CBOR-encoded C509Certificate	Hash of DER-encoded X.509 certificate
requestorCertHash	Hash of CBOR-encoded C509Certificate	Hash of DER-encoded X.509 certificate
responderCertHash	Hash of CBOR-encoded C509Certificate	Hash of DER-encoded X.509 certificate
requestorCerts / responderCerts	COSE_C509	#6.121(COSE_X509)

In this table, "C509 certificate" refers to a natively signed C509 certificate (c509CertificateType = 2). A CBOR re-encoded X.509 certificate (c509CertificateType = 3) is treated as an X.509 certificate: its identity hash MUST be computed over the DER-encoded X.509 certificate. In a hybrid deployment where the responder holds an X.509 certificate, responderCertHash contains the hash of the DER-encoded X.509 certificate and responderCerts carries a #6.121(COSE_X509) chain. In a deployment using C509 certificates throughout, all identity hashes are computed over CBOR-encoded certificates and certificate chains are carried as COSE_C509. The hashAlgorithm field at the top level of each request or response structure governs all hashes within that structure.

OCSP Stapling in TLS In standard TLS certificate status stapling (see the status_request extension, ), the stapled OCSP response is a DER-encoded OCSPResponse. To allow C509 OCSP stapling, this document defines a new TLS CertificateStatusType value (see ): TLS CertificateStatusType for C509 OCSP

Value	Name	Reference
TBD1	c509_ocsp	This document

When CertificateStatusType is c509_ocsp, the status field contains a CBOR-encoded C509OCSPResponse instead of a DER-encoded OCSPResponse.

Implementation Status Note to RFC Editor: Please remove this section before publication. When deleting this section, please also delete RFC 7942 from the references of this document. (Boilerplate as per :) This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Implementation #1

• Organization: RISE AB
• Implementation: c509rev, available in the c509rev directory of the GitHub repository of this document (https://github.com/lijun-nio/idc509rev)
• Description: A reference implementation of the C509 CRL and C509 OCSP structures specified in this document, written in Rust.
• Implementation's level of maturity: Prototype. Intended for testing and reference purposes, not for production use.
• Coverage:
  • C509 CRL, including the compact revokedCertsList encoding with fixed-length revoked-certificate and removed-from-CRL entries.
  • C509 OCSP requests of all defined types (simple, unsigned, and signed). The signed-request variants carrying the requestor's certificate or certificate chain are supported only as an opaque pass-through.
  • C509 OCSP responses of all defined types (error, basic, and simple).
  • The hash algorithms SHA-256, SHA-384, and SHA-512, including truncated identity hashes.
  • Time encoding, including the delta encodings used in OCSP.
  • Signing and signature verification with Ed25519 and ECDSA with secp256r1 and SHA-256.
  • PEM textual representation of C509 CRLs and C509 OCSP messages, as specified in this document.
  • Names are supported only in the single common-name text form.
• Version compatibility: draft-liao-cose-c509-revocation-00
• Interoperability: The encoder output matches the examples in this document byte for byte (for signed objects, the to-be-signed part), and all examples successfully round-trip through decoding and re-encoding. No interoperability testing with independent implementations has been performed yet.
• Licensing: See the repository of this document.
• Contact: Joel Höglund (joel.hoglund@ri.se)

Implementation #2

• Organization: NIO Inc.
• Implementation: Internal project, not publicly available
• Description: An implementation of the C509 CRL and C509 OCSP structures specified in this document, written in Java.
• Implementation's level of maturity: Prototype.
• Coverage: All structures and features specified in this document.
• Version compatibility: draft-liao-cose-c509-revocation-00
• Interoperability: This implementation was used to produce the examples in the appendices of this document.
• Licensing: Internal use only.
• Contact: Lijun Liao (lijun.liao@nio.io)

Security Considerations The security considerations of , , , and apply. This section covers the considerations specific to this document.

Signature Verification The signatures of C509 CRLs and of signed C509 OCSP messages cover all fields except signatureValue, including signatureAlgorithm and requestorCerts or responderCerts. This prevents algorithm and certificate-chain substitution, but does not replace the validation of and : the verifier MUST check that signatureAlgorithm matches the signer's public key, MUST validate the signer's certificate chain (a transported chain is only a hint for path construction), and MUST verify that the signer is authorized, as specified in for OCSP responses and in for CRLs. The signature SHOULD be verified over the bytes as received rather than over a re-encoding. C509ErrorOCSPResponse and C509CRLInfo () are not signed. An error response MUST NOT be interpreted as status information about any certificate. A C509CRLInfo MUST NOT be used for revocation or freshness decisions unless it was obtained over a channel that authenticates the CRL issuer.

Truncated Hash Identifiers HashId8 () only selects a certificate and does not authenticate it; security relies on the signature verification in . A relying party MUST match a response to its request using hash values it has computed itself from the certificates it holds. A receiver that finds several certificates matching a HashId8 MUST NOT assume that a particular one is intended. An OCSP responder for which an issuerCertHash matches more than one of its issuers, or a serialNumberHash matches more than one serial number, MUST NOT return the status good for that entry. Since serial numbers are chosen by the CA, an attacker cannot mount a collision attack on serialNumberHash; making the status of one certificate appear as that of another requires a second preimage of about 2^160 operations. The serial number MUST be normalized as specified in before hashing; otherwise, a revoked certificate is not found.

Privacy serialNumberHash hides the queried certificate only from observers that do not know its serial number. Serial numbers are not secret, and the hash is unsalted, so an observer with a set of candidate serial numbers can identify the queried certificate and link repeated queries; issuerCertHash reveals the issuer. Where this matters, requests and responses SHOULD be protected, e.g., by DTLS or OSCORE, or OCSP stapling () SHOULD be used.

Freshness and Replay A relying party MUST check the validity interval of an OCSP response () and, if it sent a nonce, that the response carries the same nonce. Without a nonce, a response can be replayed until it expires; relying parties without a reliable clock SHOULD use nonces. The nonce is 16 to 32 bytes long (), whereas requires new clients to use 32 octets in the Nonce extension of . A replay succeeds only if the attacker has obtained, from the OCSP responder, a response for the nonce that the relying party later chooses. With N such responses and M requests, the probability is about N * M / 2^128 for a 16-byte nonce, i.e., about 2^-48 even for N = M = 2^40, and the attack can be neither performed offline nor accelerated by a quantum computer. A 32-byte nonce adds no practical security but 16 bytes to each request and response, which is significant on constrained links. A relying party MUST NOT use a CRL after thisUpdate + nextUpdate, SHOULD reject a CRL whose crlNumber is lower than that of a CRL previously accepted for the same scope, and MUST combine a delta CRL only with a full CRL whose crlNumber is at least baseCrlNumber ().

Completeness of CRLs

• Certificates whose serial number is not a positive integer of at most 20 bytes, as required by , are not supported by this document; C509 CRLs cannot list some of them, and relying parties MUST reject them.
• When dateLength is 0, no revocation date is available, and a listed certificate MUST be treated as revoked at all times.
• When bit 1 of flags is not set, no reason code is available, and the reason MUST be treated as unspecified.
• The issuer MUST be compared in the representation that matches the certificate type (Name or tag 121 with a DER-encoded name).

Implementations MUST reject a CRL in which the length of revokedCerts or removedFromCRLCerts is not a multiple of the entry length. An implementation that uses binary search based on bit 0 of flags MUST verify that the entries are sorted, since otherwise a revoked certificate can be missed.

Parsing and Denial of Service Messages are parsed before their signature is verified, and unsigned requests are never authenticated. Implementations MUST reject input that does not conform to the CDDL, SHOULD limit message sizes and the number of entries, and MUST reject input for which computing an absolute time from a base time and an offset overflows. Answering a request may require a signature, and responses are larger than requests, which exposes OCSP responders to resource exhaustion and to abuse for traffic amplification over UDP (). OCSP responders SHOULD rate-limit requests and MAY require signed requests. A stapled C509OCSPResponse () MUST be validated as if obtained directly from the OCSP responder.

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

C509 CRL Types Registry IANA is requested to create a new registry titled "C509 CRL Types" under the registry group "CBOR Encoded X.509 (C509)". The fields of the registry are Value, Description, and Reference, where Value is an integer in the interval [-32768, 32767], and the other columns are text strings. It is mandatory to specify content in all columns. For values in the interval [-24, 23], the registration procedure is "IETF Review with Expert Review", and for all other values, the registration procedure is "Expert Review". The initial contents of the registry are:

C509 CRL Types

C509 OCSP Request Types Registry IANA is requested to create a new registry titled "C509 OCSP Request Types" under the registry group "CBOR Encoded X.509 (C509)". The fields of the registry are Value, Description, and Reference, where Value is an integer in the interval [-32768, 32767], and the other columns are text strings. It is mandatory to specify content in all columns. For values in the interval [-24, 23], the registration procedure is "IETF Review with Expert Review", and for all other values, the registration procedure is "Expert Review". The initial contents of the registry are:

C509 OCSP Request Types

C509 OCSP Response Types Registry IANA is requested to create a new registry titled "C509 OCSP Response Types" under the registry group "CBOR Encoded X.509 (C509)". The fields of the registry are Value, Description, and Reference, where Value is an integer in the interval [-32768, 32767], and the other columns are text strings. It is mandatory to specify content in all columns. For values in the interval [-24, 23], the registration procedure is "IETF Review with Expert Review", and for all other values, the registration procedure is "Expert Review". The initial contents of the registry are:

C509 OCSP Response Types

Extension Identifiers Registry IANA is requested to assign the new values shown in in the "C509 Extensions" registry under the new registry group "CBOR Encoded X.509 (C509)" defined in .

C509 extension identifier allocation requests

TLS CertificateStatusType Registry IANA is requested to assign the value shown in in the "TLS Certificate Status Types" registry under "Transport Layer Security (TLS) Extensions": TLS CertificateStatusType allocation request

Value	Description	Reference	Comment
TBD1	c509_ocsp	[RFC-XXXX]	N/A

PEM Label Registry IANA is requested to register the following entries in the "Textual Encoding Label" registry under the registry group "PKIX Parameters" : PEM Label Registrations

Label	Reference
C509 CRL	[RFC-XXXX]
C509 OCSP REQUEST	[RFC-XXXX]
C509 OCSP RESPONSE	[RFC-XXXX]

Media Type Application Registry IANA is requested to assign the following entries in the "application" registry in the registry group "Media Types" with this document as reference.

Media Type application/c509-crl+cbor When the application/c509-crl+cbor media type is used, the data is a C509CRL structure. A stored file format is defined with "magic number" TBD11 using the reserved CBOR tag 55799 and the Content-Format TBD7, enveloped as described in . Subtype name: c509-crl+cbor Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: See of [RFC-XXXX]. Interoperability considerations: N/A Published specification: [RFC-XXXX] Applications that use this media type: Any MIME-compliant transport Fragment identifier considerations: N/A Additional information:

• Deprecated alias names for this type: N/A
• Magic number(s): TBD11
• File extension(s): .c509
• Macintosh file type code(s): N/A

Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: COSE WG Change controller: IETF

Media Type application/c509-crlinfo+cbor When the application/c509-crlinfo+cbor media type is used, the data is a C509CRLInfo structure. A stored file format is defined with "magic number" TBD12 using the reserved CBOR tag 55799 and the Content-Format TBD8, enveloped as described in . Subtype name: c509-crlinfo+cbor Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: See of [RFC-XXXX]. Interoperability considerations: N/A Published specification: [RFC-XXXX] Applications that use this media type: Any MIME-compliant transport Fragment identifier considerations: N/A Additional information:

• Deprecated alias names for this type: N/A
• Magic number(s): TBD12
• File extension(s): .c509
• Macintosh file type code(s): N/A

Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: COSE WG Change controller: IETF

Media Type application/c509-ocspreq+cbor When the application/c509-ocspreq+cbor media type is used, the data is a C509OCSPRequest structure. A stored file format is defined with "magic number" TBD13 using the reserved CBOR tag 55799 and the Content-Format TBD9, enveloped as described in . Subtype name: c509-ocspreq+cbor Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: See of [RFC-XXXX]. Interoperability considerations: N/A Published specification: [RFC-XXXX] Applications that use this media type: OCSP clients Fragment identifier considerations: N/A Additional information:

• Deprecated alias names for this type: N/A
• Magic number(s): TBD13
• File extension(s): .c509
• Macintosh file type code(s): N/A

Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: COSE WG Change controller: IETF

Media Type application/c509-ocspresp+cbor When the application/c509-ocspresp+cbor media type is used, the data is a C509OCSPResponse structure. A stored file format is defined with "magic number" TBD14 using the reserved CBOR tag 55799 and the Content-Format TBD10, enveloped as described in . Subtype name: c509-ocspresp+cbor Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: See of [RFC-XXXX]. Interoperability considerations: N/A Published specification: [RFC-XXXX] Applications that use this media type: OCSP servers Fragment identifier considerations: N/A Additional information:

• Deprecated alias names for this type: N/A
• Magic number(s): TBD14
• File extension(s): .c509
• Macintosh file type code(s): N/A

Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: COSE WG Change controller: IETF

CoAP Content-Formats Registry IANA is requested to add entries for "application/c509-crl+cbor", "application/c509-crlinfo+cbor", "application/c509-ocspreq+cbor" and "application/c509-ocspresp+cbor" to the "CoAP Content-Formats" registry in the registry group "Constrained RESTful Environments (CoRE) Parameters".

Expert Review Guidelines TODO

References Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK] This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents. This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. The Concise Data Definition Language (CDDL), as defined in RFCs 8610 and 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in Concise Binary Object Representation (CBOR) or JSON. This document updates RFC 8610 by addressing related errata reports and making other small fixes for the ABNF grammar defined for CDDL. This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO Inc. This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280 and common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. TransUnion, Inc. sn3rd When certificates are used as credentials to attest the assignment or ownership of telephone numbers, some mechanism is required to convey certificate freshness to relying parties. Certificate Revocation Lists (CRLs) are commonly used for this purpose, but for certain classes of certificates, including delegate certificates conveying their scope of authority by-reference in Secure Telephone Identity Revisited (STIR) systems, they may not be aligned with the needs of relying parties. This document specifies the use of the Online Certificate Status Protocol (OCSP) as a means of retrieving real-time status information about such certificates, defining new extensions to compensate for the dynamism of telephone number assignments. IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS-TRACK] The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. This document specifies the updated format of the Nonce extension in the Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updates RFC 6960. This document defines four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in NIST FIPS 202 and is meant to serve as a stable reference and an implementation guide. n.d. n.d. n.d. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Examples

Overview Size comparison in examples

Section	Description	size(X509)	size(C509)	Size Reduction
	CRL Example Without Revoked Certificates	147	120	18%
	CRL Example With Revoked Certificates	335	177	47%
	Delta CRL Example With Revoked Certificates	335	160	52%
	Indirect CRL Example With Revoked Certificates	409	202	51%
	Simple OCSP Request Example	150	51	66%
	Unsigned OCSP Request Example	475	132	72%
	Signed OCSP Request Example Without Requestor's Certificate	584	209	64%
	Signed OCSP Request Example With Requestor's Certificate	1035	420	59%
	Signed OCSP Request Example With Requestor's Certificate Chain	1371	625	54%
	Error OCSP Response Example	5	3	40%
	Simple OCSP Response Example	336	140	58%
	Basic OCSP Response Example Without Responder's Certificate	837	248	70%
	Basic OCSP Response Example With Responder's Certificate	1181	446	62%
	Basic OCSP Response Example With Responder's Certificate Chain	1517	651	57%

Helper Keys and Certificates

CA Private Key and Certificate

CA Private Key

CA Certificate

Plain Hex

Textual Representation

CRL Signer Private Key and Certificate

CRL Signer Private Key

CRL Signer Certificate

Plain Hex

Textual Representation

OCSP Requestor Private Key and Certificate

OCSP Requestor Private Key

OCSP Requestor Certificate

Plain Hex

Textual Representation

OCSP Responder Private Key and Certificate

OCSP Responder Private Key

OCSP Responder Certificate

Plain Hex

Textual Representation

CRL Examples

CRL Example Without Revoked Certificates

• Size reduction: 18%
• Verifiable with certificate in
• Direct CRL
• Full CRL
• No revoked certificates
• Note that the X.509 CRL and the C509 CRL are not convertible.

X.509 CRL PEM content (147 bytes):

C509 CRL Plain Hex (120 bytes): Textual Representation Extensions: revokedCertsList: Signature Value 13:83:4f:4e:38:aa:9f:0d:c5:b8:d2:1c:86:50:c7:76: a6:d9:61:c3:1c:89:4c:36:a7:1a:64:33:f5:ed:7d:30: e6:7f:78:7f:13:c7:e4:c3:49:b2:84:8a:18:1f:db:bc: e3:61:a1:4c:22:00:21:c4:a2:67:36:7a:d5:f1:d9:0d ]]> Annotated hex 52: 80 # [8]. crlExtensions=array[0] 53: F6 # [9]. revokedCertsList: 54: 58 40 # [10]. signature value=byte[64] 56: 13834F4E38AA9F0DC5B8D21C8650C776A6D961C31C894C36A71A6433F5 85: ED7D30E67F787F13C7E4C349B2848A181FDBBCE361A14C220021C4A267 114: 367AD5F1D90D ]]>

CRL Example With Revoked Certificates

• Size reduction: 47%
• Verifiable with certificate in
• Direct CRL
• Full CRL
• With revoked certificates
• With Per-Issuer Extension ExpiredCertsOnCRL
• Note that the X.509 CRL and the C509 CRL are not convertible.

X.509 CRL PEM content (335 bytes):

C509 CRL Plain Hex (177 bytes): Textual Representation Extensions: revokedCertsList: PerIssuerRevokedCerts[0] Issuer: RevokedCertsControl Flags: sorted, with reason (0x3) Serial number length: 2 Date length: 3 Base date: 2025-01-01T00:12:34Z Extensions ExpiredCertsOnCRL (87) 2025-01-01T00:00:00Z RevokedCerts: 0x1122, 2025-01-06T00:12:34Z, certificateHold 0x1234, 2025-01-01T00:12:34Z, keyCompromise 0x3344, 2025-01-04T00:12:34Z, certificateHold 0x5566, 2025-01-02T00:12:34Z, certificateHold 0x5678, 2025-01-05T00:12:34Z, unspecified 0x9ABC, 2025-01-03T00:12:34Z, unspecified RemovedFromCRLCerts: Signature Value 70:bb:7a:38:06:5f:bc:ab:fe:61:51:70:f0:5a:9a:9f: e8:3d:c8:92:d5:f7:35:81:2b:2a:05:3a:f4:b3:00:eb: 46:6b:ab:b4:f1:a3:87:cd:ce:90:d8:30:2c:68:0b:77: aa:61:56:64:23:d7:c2:35:f7:bd:31:34:4c:f7:f4:05 ]]> Annotated hex 52: 80 # [8]. crlExtensions=array[0] 53: 85 # [9]. revokedCertsList=array[5] #---PerIssuerRevokedCerts[0]--- 54: F6 # [0]. issuer= 55: 84 # [1]. revokedCertsControl=array[4] 56: 03 # [0]. flags: sorted, with reason (0x3) 57: 02 # [1]. serialNumberLength=2 58: 03 # [2]. dateLength=3 59: 1A 67748872 # [3]. baseDate=1735690354: # 2025-01-01T00:12:34Z 64: 82 # [2]. extensions=array[2] #---extension[0]--- 65: 18 57 # [0]. type=ExpiredCertsOnCRL (87) 67: 1A 67748580 # [1]. value=1735689600: # 2025-01-01T00:00:00Z 72: 58 24 # [3]. revokedCerts=byte[36], 6 entries #---entries[0]--- 74: 1122 # CSN=1122 76: 069780 # date=069780: 2025-01-06T00:12:34Z 79: 06 # reason=6: certificateHold #---entries[1]--- 80: 1234 # CSN=1234 82: 000000 # date=000000: 2025-01-01T00:12:34Z 85: 01 # reason=1: keyCompromise #---entries[2]--- 86: 3344 # CSN=3344 88: 03F480 # date=03F480: 2025-01-04T00:12:34Z 91: 06 # reason=6: certificateHold #---entries[3]--- 92: 5566 # CSN=5566 94: 015180 # date=015180: 2025-01-02T00:12:34Z 97: 06 # reason=6: certificateHold #---entries[4]--- 98: 5678 # CSN=5678 100: 054600 # date=054600: 2025-01-05T00:12:34Z 103: 00 # reason=0: unspecified #---entries[5]--- 104: 9ABC # CSN=9ABC 106: 02A300 # date=02A300: 2025-01-03T00:12:34Z 109: 00 # reason=0: unspecified 110: F6 # [4]. removedFromCRLCerts= 111: 58 40 # [10]. signature value=byte[64] 113: 70BB7A38065FBCABFE615170F05A9A9FE83DC892D5F735812B2A053AF4 142: B300EB466BABB4F1A387CDCE90D8302C680B77AA61566423D7C235F7BD 171: 31344CF7F405 ]]>

Delta CRL Example With Revoked Certificates

• Size reduction: 52%
• Verifiable with certificate in
• Direct CRL
• Delta CRL
• With revoked certificates
• With entries removed from the CRL since the last full CRL
• Note that the X.509 CRL and the C509 CRL are not convertible.

X.509 CRL PEM content (335 bytes):

C509 CRL Plain Hex (160 bytes): Textual Representation revokedCertsList: PerIssuerRevokedCerts[0] Issuer: RevokedCertsControl Flags: sorted, with reason (0x3) Serial number length: 2 Date length: 2 Base date: 2025-01-07T12:12:34Z Extensions: RevokedCerts: 0x3412, 2025-01-07T12:12:34Z, keyCompromise 0x7856, 2025-01-08T00:10:34Z, unspecified 0xBC9A, 2025-01-08T00:08:34Z, unspecified RemovedFromCRLCerts: 0x1122, 2025-01-07T13:12:34Z 0x3344, 2025-01-07T14:12:34Z 0x5566, 2025-01-07T15:12:34Z Signature Value 36:9c:3e:64:12:e9:d0:53:7c:d3:9e:a1:da:40:c6:8c: 32:b4:ec:0e:56:78:65:0d:6a:f7:36:77:a5:a0:cf:37: f1:cd:e7:5d:66:3d:e3:74:91:01:f4:35:4c:cd:6d:8d: 05:77:38:87:65:00:46:93:2b:58:3c:53:65:d7:eb:0b ]]> Annotated hex 55: 84 # [1]. revokedCertsControl=array[4] 56: 03 # [0]. flags: sorted, with reason (0x3) 57: 02 # [1]. serialNumberLength=2 58: 02 # [2]. dateLength=2 59: 1A 677D1A32 # [3]. baseDate=1736251954: # 2025-01-07T12:12:34Z 64: 80 # [2]. extensions=array[0] 65: 4F # [3]. revokedCerts=byte[15], 3 entries #---entries[0]--- 66: 3412 # CSN=3412 68: 0000 # date=0000: 2025-01-07T12:12:34Z 70: 01 # reason=1: keyCompromise #---entries[1]--- 71: 7856 # CSN=7856 73: A848 # date=A848: 2025-01-08T00:10:34Z 75: 00 # reason=0: unspecified #---entries[2]--- 76: BC9A # CSN=BC9A 78: A7D0 # date=A7D0: 2025-01-08T00:08:34Z 80: 00 # reason=0: unspecified 81: 4C # [4]. removedFromCRLCerts=byte[12], 3 # entries #---entries[0]--- 82: 1122 # CSN=1122 84: 0E10 # date=0E10: 2025-01-07T13:12:34Z #---entries[1]--- 86: 3344 # CSN=3344 88: 1C20 # date=1C20: 2025-01-07T14:12:34Z #---entries[2]--- 90: 5566 # CSN=5566 92: 2A30 # date=2A30: 2025-01-07T15:12:34Z 94: 58 40 # [10]. signature value=byte[64] 96: 369C3E6412E9D0537CD39EA1DA40C68C32B4EC0E5678650D6AF73677A5 125: A0CF37F1CDE75D663DE3749101F4354CCD6D8D05773887650046932B58 154: 3C5365D7EB0B ]]>

Indirect CRL Example With Revoked Certificates

• Size reduction: 51%
• Verifiable with certificate in
• Indirect CRL
• Full CRL
• With revoked certificates
• With two issuers
• Note that the X.509 CRL and the C509 CRL are not convertible.

X.509 CRL PEM content (409 bytes):

C509 CRL Plain Hex (202 bytes): Textual Representation Extensions: revokedCertsList: PerIssuerRevokedCerts[0] Issuer: CN=test crlocsp-ca RevokedCertsControl Flags: sorted, with reason (0x3) Serial number length: 2 Date length: 3 Base date: 2025-01-01T00:12:34Z Extensions: RevokedCerts: 0x1234, 2025-01-01T00:12:34Z, keyCompromise 0x5678, 2025-01-05T00:12:34Z, unspecified 0x9ABC, 2025-01-03T00:12:34Z, unspecified RemovedFromCRLCerts: PerIssuerRevokedCerts[1] Issuer: CN=example CA RevokedCertsControl Flags: sorted, with reason (0x3) Serial number length: 2 Date length: 3 Base date: 2025-01-02T00:12:34Z Extensions: RevokedCerts: 0x1122, 2025-01-06T00:12:34Z, certificateHold 0x3344, 2025-01-04T00:12:34Z, certificateHold 0x5566, 2025-01-02T00:12:34Z, certificateHold RemovedFromCRLCerts: Signature Value f0:0d:62:70:f9:14:86:a7:f3:78:d0:6f:01:a8:07:e6: 4e:08:6b:b3:66:be:3a:15:92:ce:4a:64:bf:fd:62:1f: 30:e2:ab:93:76:6b:4f:88:18:11:6a:b7:da:7b:ed:f7: c3:eb:cb:de:ac:6d:04:55:f5:f5:66:97:12:00:62:05 ]]> Annotated hex 47: 80 # [8]. crlExtensions=array[0] 48: 8A # [9]. revokedCertsList=array[10] #---PerIssuerRevokedCerts[0]--- 49: 6F # [0]. issuer=char[15] 50: 746573742063726C6F6373702D6361 # "test crlocsp-ca" 65: 84 # [1]. revokedCertsControl=array[4] 66: 03 # [0]. flags: sorted, with reason (0x3) 67: 02 # [1]. serialNumberLength=2 68: 03 # [2]. dateLength=3 69: 1A 67748872 # [3]. baseDate=1735690354: # 2025-01-01T00:12:34Z 74: 80 # [2]. extensions=array[0] 75: 52 # [3]. revokedCerts=byte[18], 3 entries #---entries[0]--- 76: 1234 # CSN=1234 78: 000000 # date=000000: 2025-01-01T00:12:34Z 81: 01 # reason=1: keyCompromise #---entries[1]--- 82: 5678 # CSN=5678 84: 054600 # date=054600: 2025-01-05T00:12:34Z 87: 00 # reason=0: unspecified #---entries[2]--- 88: 9ABC # CSN=9ABC 90: 02A300 # date=02A300: 2025-01-03T00:12:34Z 93: 00 # reason=0: unspecified 94: F6 # [4]. removedFromCRLCerts= #---PerIssuerRevokedCerts[1]--- 95: 6A # [5]. issuer=char[10] 96: 6578616D706C65204341 # "example CA" 106: 84 # [6]. revokedCertsControl=array[4] 107: 03 # [0]. flags: sorted, with reason (0x3) 108: 02 # [1]. serialNumberLength=2 109: 03 # [2]. dateLength=3 110: 1A 6775D9F2 # [3]. baseDate=1735776754: # 2025-01-02T00:12:34Z 115: 80 # [7]. extensions=array[0] 116: 52 # [8]. revokedCerts=byte[18], 3 entries #---entries[0]--- 117: 1122 # CSN=1122 119: 054600 # date=054600: 2025-01-06T00:12:34Z 122: 06 # reason=6: certificateHold #---entries[1]--- 123: 3344 # CSN=3344 125: 02A300 # date=02A300: 2025-01-04T00:12:34Z 128: 06 # reason=6: certificateHold #---entries[2]--- 129: 5566 # CSN=5566 131: 000000 # date=000000: 2025-01-02T00:12:34Z 134: 06 # reason=6: certificateHold 135: F6 # [9]. removedFromCRLCerts= 136: 58 40 # [10]. signature value=byte[64] 138: F00D6270F91486A7F378D06F01A807E64E086BB366BE3A1592CE4A64BF 167: FD621F30E2AB93766B4F8818116AB7DA7BEDF7C3EBCBDEAC6D0455F5F5 196: 669712006205 ]]>

OCSP Request Examples

Simple OCSP Request Example

• Size reduction: 66%
• Simple OCSP Request (C509SimpleOCSPRequest)
• Note that the X.509 OCSP Request and the C509 OCSP Request are not convertible.

X.509 OCSP Request PEM content (150 bytes):

C509 OCSP Request Plain Hex (51 bytes): Textual Representation ]]> Annotated hex

Unsigned OCSP Request Example

• Size reduction: 72%
• Unsigned OCSP Request (C509UnsignedOCSPRequest)
• Note that the X.509 OCSP Request and the C509 OCSP Request are not convertible.

X.509 OCSP Request PEM content (475 bytes):

C509 OCSP Request Plain Hex (132 bytes): Textual Representation singleRequests SingleCertRequest SerialNumberHash: 10:65:27:87:fa:05:27:bc:24:49:a1:bf:c5:ab:31:aa: 5a:6f:0d:8d Extensions: SingleCertRequest SerialNumberHash: 75:d8:bc:4f:ba:fc:66:94:46:76:41:e7:48:df:d5:3a: 8b:9d:17:6d Extensions: SingleCertRequest SerialNumberHash: d1:ac:13:5d:7d:a2:9b:dc:f4:dc:a0:d5:28:1a:51:60: 5b:67:84:00 Extensions: OcspPerIssuerRequest issuerCertHash 22:22:22:22:22:22:22:22 extensions: singleRequests SingleCertRequest SerialNumberHash: d3:a0:c1:e3:db:92:e8:f6:81:05:37:d4:5c:fa:ec:f6: ce:41:7e:3b Extensions: Extensions: ]]> Annotated hex

Signed OCSP Request Example Without Requestor's Certificate

• Size reduction: 64%
• Verifiable with certificate in
• Signed OCSP Request (C509SignedOCSPRequest) without requestor's certificate
• Note that the X.509 OCSP Request and the C509 OCSP Request are not convertible.

X.509 OCSP Request PEM content (584 bytes):

C509 OCSP Request Plain Hex (209 bytes): Textual Representation Requests OcspPerIssuerRequest issuerCertHash a0:1c:73:a5:f3:b0:63:34 extensions: singleRequests SingleCertRequest SerialNumberHash: 10:65:27:87:fa:05:27:bc:24:49:a1:bf:c5:ab:31:aa: 5a:6f:0d:8d Extensions: SingleCertRequest SerialNumberHash: 75:d8:bc:4f:ba:fc:66:94:46:76:41:e7:48:df:d5:3a: 8b:9d:17:6d Extensions: SingleCertRequest SerialNumberHash: d1:ac:13:5d:7d:a2:9b:dc:f4:dc:a0:d5:28:1a:51:60: 5b:67:84:00 Extensions: OcspPerIssuerRequest issuerCertHash 22:22:22:22:22:22:22:22 extensions: singleRequests SingleCertRequest SerialNumberHash: d3:a0:c1:e3:db:92:e8:f6:81:05:37:d4:5c:fa:ec:f6: ce:41:7e:3b Extensions: Requestor Certs: null Signature Value 7b:84:0f:ab:a2:17:9a:c5:64:a9:7b:a3:69:43:6f:05: 31:6f:e4:5f:fa:28:b7:73:fb:33:39:71:23:ba:7a:b1: 76:05:57:2d:7b:63:8b:26:12:7e:1b:86:fb:45:2c:5b: 4f:1f:ea:e1:63:8d:5d:32:8a:f8:93:b7:7a:7d:11:06 ]]> Annotated hex 143: 58 40 # [8]. signatureValue=byte[64] 145: 7B840FABA2179AC564A97BA369436F05316FE45FFA28B773FB33397123 174: BA7AB17605572D7B638B26127E1B86FB452C5B4F1FEAE1638D5D328AF8 203: 93B77A7D1106 ]]>

Signed OCSP Request Example With Requestor's Certificate

• Size reduction: 59%
• Verifiable with certificate in
• Signed OCSP Request (C509SignedOCSPRequest) with embedded requestor's certificate
• Note that the X.509 OCSP Request and the C509 OCSP Request are not convertible.

X.509 OCSP Request PEM content (1035 bytes):

C509 OCSP Request Plain Hex (420 bytes): Textual Representation singleRequests SingleCertRequest SerialNumberHash: 10:65:27:87:fa:05:27:bc:24:49:a1:bf:c5:ab:31:aa: 5a:6f:0d:8d Extensions: SingleCertRequest SerialNumberHash: 75:d8:bc:4f:ba:fc:66:94:46:76:41:e7:48:df:d5:3a: 8b:9d:17:6d Extensions: SingleCertRequest SerialNumberHash: d1:ac:13:5d:7d:a2:9b:dc:f4:dc:a0:d5:28:1a:51:60: 5b:67:84:00 Extensions: OcspPerIssuerRequest issuerCertHash 22:22:22:22:22:22:22:22 extensions: singleRequests SingleCertRequest SerialNumberHash: d3:a0:c1:e3:db:92:e8:f6:81:05:37:d4:5c:fa:ec:f6: ce:41:7e:3b Extensions: Requestor Certs C509Certificate 8b:02:42:12:36:0c:6f:74:65:73:74:20:63:72:6c:6f: 63:73:70:2d:63:61:1a:67:75:d7:00:1a:69:57:0a:80: 6e:6f:63:73:70:2d:72:65:71:75:65:73:74:6f:72:0c: 58:20:04:53:0b:17:64:ed:d4:b4:e3:3a:b4:4a:f0:f8: 38:96:1c:00:71:76:d7:4b:6a:35:46:ec:b7:fd:57:32: 0d:d3:86:01:54:dd:51:bd:b2:a2:c7:91:c0:62:d4:02: 78:56:db:ac:f5:26:07:f0:be:21:01:07:54:2f:45:e7: 8d:2c:ae:df:36:8c:df:53:c3:90:05:d4:92:45:0e:10: 56:58:40:f8:c6:18:3e:cf:8c:3e:fd:50:dd:49:42:d1: 72:81:4c:46:ec:0f:c0:1d:d5:86:a5:97:17:8d:f8:64: a0:d9:da:86:b7:ca:17:fc:9f:77:2f:f0:4c:80:e9:8b: 60:d5:b4:b6:24:08:a2:77:a5:b7:0d:0d:2a:3f:5e:d5: 44:2d:07 Signature Value 75:c6:5f:02:81:99:ff:c8:84:b6:a0:e3:e4:f9:ed:c3: 80:a0:37:b1:e9:b5:86:8c:74:f5:a0:ce:bc:cd:f6:c7: d0:c0:d6:9b:1b:b6:97:64:14:44:4e:15:6d:72:e1:2e: 2f:f9:36:78:25:13:51:6b:02:b4:a1:e4:0e:b1:3d:01 ]]> Annotated hex #---preferredSignatureAlgorithms[1]--- 41: 00 # [2]. sigIdentifier=ecdsa-with-sha256 (0) 42: 82 # [3]. pubKeyAlgIdentifiers=array[2] 43: 01 # [0]. pubKeyAlgIdentifier=EC public key # on curve secp256r1 (1) 44: 18 18 # [1]. pubKeyAlgIdentifier=EC public key # on curve brainpoolp256r1 (24) 46: 86 # [6]. requests=array[6] #---PerIssuerRequests[0]--- 47: 48 # [0]. issuerCertHash=byte[8] 48: A01C73A5F3B06334 56: 80 # [1]. extensions=array[0] 57: 86 # [2]. singleRequests=array[6] #---SingleCertRequests[0]--- 58: 54 # [0]. serialNumberHash=byte[20] 59: 10652787FA0527BC2449A1BFC5AB31AA5A6F0D8D 79: 80 # [1]. extensions=array[0] #---SingleCertRequests[1]--- 80: 54 # [2]. serialNumberHash=byte[20] 81: 75D8BC4FBAFC6694467641E748DFD53A8B9D176D 101: 80 # [3]. extensions=array[0] #---SingleCertRequests[2]--- 102: 54 # [4]. serialNumberHash=byte[20] 103: D1AC135D7DA29BDCF4DCA0D5281A51605B678400 123: 80 # [5]. extensions=array[0] #---PerIssuerRequests[1]--- 124: 48 # [3]. issuerCertHash=byte[8] 125: 2222222222222222 133: 80 # [4]. extensions=array[0] 134: 82 # [5]. singleRequests=array[2] #---SingleCertRequests[0]--- 135: 54 # [0]. serialNumberHash=byte[20] 136: D3A0C1E3DB92E8F6810537D45CFAECF6CE417E3B 156: 80 # [1]. extensions=array[0] 157: 58 C3 # [7]. requestorCerts(COSE_C509)=byte[195] 159: 8B024212360C6F746573742063726C6F6373702D63611A6775D7001A69 188: 570A806E6F6373702D726571756573746F720C582004530B1764EDD4B4 217: E33AB44AF0F838961C007176D74B6A3546ECB7FD57320DD3860154DD51 246: BDB2A2C791C062D4027856DBACF52607F0BE210107542F45E78D2CAEDF 275: 368CDF53C39005D492450E10565840F8C6183ECF8C3EFD50DD4942D172 304: 814C46EC0FC01DD586A597178DF864A0D9DA86B7CA17FC9F772FF04C80 333: E98B60D5B4B62408A277A5B70D0D2A3F5ED5442D07 354: 58 40 # [8]. signatureValue=byte[64] 356: 75C65F028199FFC884B6A0E3E4F9EDC380A037B1E9B5868C74F5A0CEBC 385: CDF6C7D0C0D69B1BB6976414444E156D72E12E2FF936782513516B02B4 414: A1E40EB13D01 ]]>

Signed OCSP Request Example With Requestor's Certificate Chain

• Size reduction: 54%
• Verifiable with certificate in
• Signed OCSP Request (C509SignedOCSPRequest) with embedded requestor's certificate chain (2 certificates)
• Note that the X.509 OCSP Request and the C509 OCSP Request are not convertible.

X.509 OCSP Request PEM content (1371 bytes):

C509 OCSP Request Plain Hex (625 bytes): Textual Representation singleRequests SingleCertRequest SerialNumberHash: 10:65:27:87:fa:05:27:bc:24:49:a1:bf:c5:ab:31:aa: 5a:6f:0d:8d Extensions: SingleCertRequest SerialNumberHash: 75:d8:bc:4f:ba:fc:66:94:46:76:41:e7:48:df:d5:3a: 8b:9d:17:6d Extensions: SingleCertRequest SerialNumberHash: d1:ac:13:5d:7d:a2:9b:dc:f4:dc:a0:d5:28:1a:51:60: 5b:67:84:00 Extensions: OcspPerIssuerRequest issuerCertHash 22:22:22:22:22:22:22:22 extensions: singleRequests SingleCertRequest SerialNumberHash: d3:a0:c1:e3:db:92:e8:f6:81:05:37:d4:5c:fa:ec:f6: ce:41:7e:3b Extensions: Requestor Certs C509Certificate 8b:02:42:12:36:0c:6f:74:65:73:74:20:63:72:6c:6f: 63:73:70:2d:63:61:1a:67:75:d7:00:1a:69:57:0a:80: 6e:6f:63:73:70:2d:72:65:71:75:65:73:74:6f:72:0c: 58:20:04:53:0b:17:64:ed:d4:b4:e3:3a:b4:4a:f0:f8: 38:96:1c:00:71:76:d7:4b:6a:35:46:ec:b7:fd:57:32: 0d:d3:86:01:54:dd:51:bd:b2:a2:c7:91:c0:62:d4:02: 78:56:db:ac:f5:26:07:f0:be:21:01:07:54:2f:45:e7: 8d:2c:ae:df:36:8c:df:53:c3:90:05:d4:92:45:0e:10: 56:58:40:f8:c6:18:3e:cf:8c:3e:fd:50:dd:49:42:d1: 72:81:4c:46:ec:0f:c0:1d:d5:86:a5:97:17:8d:f8:64: a0:d9:da:86:b7:ca:17:fc:9f:77:2f:f0:4c:80:e9:8b: 60:d5:b4:b6:24:08:a2:77:a5:b7:0d:0d:2a:3f:5e:d5: 44:2d:07 C509Certificate 8b:02:41:01:0c:73:74:65:73:74:20:63:72:6c:6f:63: 73:70:2d:72:6f:6f:74:63:61:1a:67:74:85:80:1a:6b: 36:ec:7f:6f:74:65:73:74:20:63:72:6c:6f:63:73:70: 2d:63:61:0c:58:20:5e:f8:a3:55:a0:01:a7:c5:0d:23: 49:47:01:20:81:31:a4:bb:2a:b9:20:d4:0b:fb:0e:e1: f6:ab:28:ff:74:00:88:01:54:2f:45:e7:8d:2c:ae:df: 36:8c:df:53:c3:90:05:d4:92:45:0e:10:56:21:18:60: 23:01:07:54:2d:a3:a4:03:f7:d2:f4:e0:b3:d8:03:1a: 73:ba:8a:83:9f:55:7f:0f:58:40:e5:04:65:d6:0c:02: a2:11:1e:f3:fc:6e:44:f2:a3:60:08:76:5b:55:23:51: f9:a3:f5:b2:aa:7c:76:f1:f0:5d:25:98:47:a4:f4:25: 0b:2e:4b:0a:e2:09:97:62:a2:59:6d:3c:c1:db:2c:cd: 18:0a:a0:a2:d0:e1:91:31:0b:0f Signature Value 8e:c4:d2:0a:1c:15:6b:2f:db:61:d8:2d:39:ef:9d:54: cc:bf:fe:42:ea:c1:ac:ad:de:cd:20:78:7d:97:9a:38: 82:3b:bb:1a:64:58:c2:2f:07:e6:48:70:73:76:9f:b9: b5:25:44:7a:43:b0:c9:c3:bc:de:79:04:55:de:c5:08 ]]> Annotated hex #---preferredSignatureAlgorithms[1]--- 41: 00 # [2]. sigIdentifier=ecdsa-with-sha256 (0) 42: 82 # [3]. pubKeyAlgIdentifiers=array[2] 43: 01 # [0]. pubKeyAlgIdentifier=EC public key # on curve secp256r1 (1) 44: 18 18 # [1]. pubKeyAlgIdentifier=EC public key # on curve brainpoolp256r1 (24) 46: 86 # [6]. requests=array[6] #---PerIssuerRequests[0]--- 47: 48 # [0]. issuerCertHash=byte[8] 48: A01C73A5F3B06334 56: 80 # [1]. extensions=array[0] 57: 86 # [2]. singleRequests=array[6] #---SingleCertRequests[0]--- 58: 54 # [0]. serialNumberHash=byte[20] 59: 10652787FA0527BC2449A1BFC5AB31AA5A6F0D8D 79: 80 # [1]. extensions=array[0] #---SingleCertRequests[1]--- 80: 54 # [2]. serialNumberHash=byte[20] 81: 75D8BC4FBAFC6694467641E748DFD53A8B9D176D 101: 80 # [3]. extensions=array[0] #---SingleCertRequests[2]--- 102: 54 # [4]. serialNumberHash=byte[20] 103: D1AC135D7DA29BDCF4DCA0D5281A51605B678400 123: 80 # [5]. extensions=array[0] #---PerIssuerRequests[1]--- 124: 48 # [3]. issuerCertHash=byte[8] 125: 2222222222222222 133: 80 # [4]. extensions=array[0] 134: 82 # [5]. singleRequests=array[2] #---SingleCertRequests[0]--- 135: 54 # [0]. serialNumberHash=byte[20] 136: D3A0C1E3DB92E8F6810537D45CFAECF6CE417E3B 156: 80 # [1]. extensions=array[0] 157: 82 # [7]. requestorCerts(COSE_C509)=array[2] 158: 58 C3 # [0]. C509CertData=byte[195] 160: 8B024212360C6F746573742063726C6F6373702D63611A6775D7001A 188: 69570A806E6F6373702D726571756573746F720C582004530B1764ED 216: D4B4E33AB44AF0F838961C007176D74B6A3546ECB7FD57320DD38601 244: 54DD51BDB2A2C791C062D4027856DBACF52607F0BE210107542F45E7 272: 8D2CAEDF368CDF53C39005D492450E10565840F8C6183ECF8C3EFD50 300: DD4942D172814C46EC0FC01DD586A597178DF864A0D9DA86B7CA17FC 328: 9F772FF04C80E98B60D5B4B62408A277A5B70D0D2A3F5ED5442D07 355: 58 CA # [1]. C509CertData=byte[202] 357: 8B0241010C73746573742063726C6F6373702D726F6F7463611A6774 385: 85801A6B36EC7F6F746573742063726C6F6373702D63610C58205EF8 413: A355A001A7C50D23494701208131A4BB2AB920D40BFB0EE1F6AB28FF 441: 74008801542F45E78D2CAEDF368CDF53C39005D492450E1056211860 469: 230107542DA3A403F7D2F4E0B3D8031A73BA8A839F557F0F5840E504 497: 65D60C02A2111EF3FC6E44F2A36008765B552351F9A3F5B2AA7C76F1 525: F05D259847A4F4250B2E4B0AE2099762A2596D3CC1DB2CCD180AA0A2 553: D0E191310B0F 559: 58 40 # [8]. signatureValue=byte[64] 561: 8EC4D20A1C156B2FDB61D82D39EF9D54CCBFFE42EAC1ACADDECD20787D 590: 979A38823BBB1A6458C22F07E6487073769FB9B525447A43B0C9C3BCDE 619: 790455DEC508 ]]>

OCSP Response Examples

Error OCSP Response Example

• Size reduction: 40%
• Error Response (C509ErrorOCSPResponse)

X.509 OCSP Response PEM content (5 bytes):

C509 OCSP Response Plain Hex (3 bytes): Textual Representation Annotated hex

Simple OCSP Response Example

• Size reduction: 58%
• Verifiable with certificate in
• Simple OCSP Response (C509SimpleOCSPResponse) without responder's certificate
• Note that the X.509 OCSP Response and the C509 OCSP Response are not convertible.

X.509 OCSP Response PEM content (336 bytes):

C509 OCSP Response Plain Hex (140 bytes): Textual Representation Responder Certs: null Signature Value 52:d9:f1:37:bc:08:e4:d1:7c:3c:1a:04:12:ef:70:f6: c4:ba:71:24:eb:99:8f:3b:0a:53:aa:f6:2f:84:fd:18: bf:9a:b2:4a:ec:7c:e9:c7:37:17:a8:16:bf:a1:e3:e9: b0:be:e6:fa:1d:d5:88:f0:a2:c8:38:df:de:d3:74:04 ]]> Annotated hex 74: 58 40 # [13]. signatureValue=byte[64] 76: 52D9F137BC08E4D17C3C1A0412EF70F6C4BA7124EB998F3B0A53AAF62F 105: 84FD18BF9AB24AEC7CE9C73717A816BFA1E3E9B0BEE6FA1DD588F0A2C8 134: 38DFDED37404 ]]>

Basic OCSP Response Example Without Responder's Certificate

• Size reduction: 70%
• Verifiable with certificate in
• Basic OCSP Response (C509BasicOCSPResponse) without responder's certificate
• Note that the X.509 OCSP Response and the C509 OCSP Response are not convertible.

X.509 OCSP Response PEM content (837 bytes):

C509 OCSP Response Plain Hex (248 bytes): Textual Representation Responses OcspPerIssuerResponse IssuerCertHash a0:1c:73:a5:f3:b0:63:34 Extensions: SingleResponses SingleCertResponse SerialNumberHash: 10:65:27:87:fa:05:27:bc:24:49:a1:bf:c5:ab:31:aa: 5a:6f:0d:8d Cert Status: good This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: SingleCertResponse SerialNumberHash: 75:d8:bc:4f:ba:fc:66:94:46:76:41:e7:48:df:d5:3a: 8b:9d:17:6d Cert Status: not-issued This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: SingleCertResponse SerialNumberHash: d1:ac:13:5d:7d:a2:9b:dc:f4:dc:a0:d5:28:1a:51:60: 5b:67:84:00 Cert Status: revoked (superseded) Revoked at 2025-03-01T16:00:00Z This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: OcspPerIssuerResponse IssuerCertHash 22:22:22:22:22:22:22:22 Extensions: SingleResponses SingleCertResponse SerialNumberHash: d3:a0:c1:e3:db:92:e8:f6:81:05:37:d4:5c:fa:ec:f6: ce:41:7e:3b Cert Status: unknown This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: Responder Certs: null Signature Value 1b:b7:e5:c6:5f:7d:65:26:0a:4f:b1:27:be:66:b1:db: 3e:7c:9f:16:dc:29:69:d5:f6:7d:fc:f2:5d:cc:f1:ee: 09:ed:28:44:1f:92:b5:24:2a:f6:0f:76:0a:e4:02:9e: c5:c7:4d:b7:c0:42:3a:94:1f:86:93:58:c7:1f:f8:00 ]]> Annotated hex 182: 58 40 # [9]. signature value=byte[64] 184: 1BB7E5C65F7D65260A4FB127BE66B1DB3E7C9F16DC2969D5F67DFCF25D 213: CCF1EE09ED28441F92B5242AF60F760AE4029EC5C74DB7C0423A941F86 242: 9358C71FF800 ]]>

Basic OCSP Response Example With Responder's Certificate

• Size reduction: 62%
• Verifiable with certificate in
• Basic OCSP Response (C509BasicOCSPResponse) with embedded responder's certificate
• Note that the X.509 OCSP Response and the C509 OCSP Response are not convertible.

X.509 OCSP Response PEM content (1181 bytes):

C509 OCSP Response Plain Hex (446 bytes): Textual Representation Responses OcspPerIssuerResponse IssuerCertHash a0:1c:73:a5:f3:b0:63:34 Extensions: SingleResponses SingleCertResponse SerialNumberHash: 10:65:27:87:fa:05:27:bc:24:49:a1:bf:c5:ab:31:aa: 5a:6f:0d:8d Cert Status: good This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: SingleCertResponse SerialNumberHash: 75:d8:bc:4f:ba:fc:66:94:46:76:41:e7:48:df:d5:3a: 8b:9d:17:6d Cert Status: not-issued This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: SingleCertResponse SerialNumberHash: d1:ac:13:5d:7d:a2:9b:dc:f4:dc:a0:d5:28:1a:51:60: 5b:67:84:00 Cert Status: revoked (superseded) Revoked at 2025-03-01T16:00:00Z This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: OcspPerIssuerResponse IssuerCertHash 22:22:22:22:22:22:22:22 Extensions: SingleResponses SingleCertResponse SerialNumberHash: d3:a0:c1:e3:db:92:e8:f6:81:05:37:d4:5c:fa:ec:f6: ce:41:7e:3b Cert Status: unknown This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: Responder Certs C509Certificate 8b:02:42:12:35:0c:6f:74:65:73:74:20:63:72:6c:6f: 63:73:70:2d:63:61:1a:67:75:d7:00:1a:69:57:0a:80: 6e:6f:63:73:70:2d:72:65:73:70:6f:6e:64:65:72:0c: 58:20:81:94:7b:bc:24:8a:ac:79:73:82:11:a8:d7:5b: f9:2c:b7:77:d9:94:07:3d:f2:3a:e0:63:80:ef:2c:57: 39:76:88:01:54:b5:b4:ca:f3:54:01:d0:61:51:df:96: 29:db:57:9d:c8:cc:a4:53:a8:21:01:07:54:2f:45:e7: 8d:2c:ae:df:36:8c:df:53:c3:90:05:d4:92:45:0e:10: 56:27:09:58:40:a0:1b:0c:bf:3e:34:a4:76:2d:05:40: 4f:d0:8a:7a:ec:10:30:35:35:83:14:68:6d:72:b6:15: 90:78:c7:6e:1d:88:59:7f:37:53:18:86:a3:f5:2f:25: 6f:d7:22:19:2b:28:9d:68:44:01:44:67:f1:f1:7f:05: ac:bb:7b:66:0a Signature Value c8:b1:c1:48:15:bd:49:60:4e:7a:99:43:9c:84:b5:50: fe:d5:f9:4c:ff:35:e8:23:8c:d5:3c:ea:91:d5:8a:0d: 46:27:d2:ea:08:00:eb:ea:3e:14:53:c0:e7:1b:17:5b: 44:14:66:e3:43:1f:b2:35:a1:bd:6e:43:03:10:9b:03 ]]> Annotated hex

Basic OCSP Response Example With Responder's Certificate Chain

• Size reduction: 57%
• Verifiable with certificate in
• Basic OCSP Response (C509BasicOCSPResponse) with embedded responder's certificate chain (2 certificates)
• Note that the X.509 OCSP Response and the C509 OCSP Response are not convertible.

X.509 OCSP Response PEM content (1517 bytes):

C509 OCSP Response Plain Hex (651 bytes): Textual Representation Responses OcspPerIssuerResponse IssuerCertHash a0:1c:73:a5:f3:b0:63:34 Extensions: SingleResponses SingleCertResponse SerialNumberHash: 10:65:27:87:fa:05:27:bc:24:49:a1:bf:c5:ab:31:aa: 5a:6f:0d:8d Cert Status: good This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: SingleCertResponse SerialNumberHash: 75:d8:bc:4f:ba:fc:66:94:46:76:41:e7:48:df:d5:3a: 8b:9d:17:6d Cert Status: not-issued This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: SingleCertResponse SerialNumberHash: d1:ac:13:5d:7d:a2:9b:dc:f4:dc:a0:d5:28:1a:51:60: 5b:67:84:00 Cert Status: revoked (superseded) Revoked at 2025-03-01T16:00:00Z This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: OcspPerIssuerResponse IssuerCertHash 22:22:22:22:22:22:22:22 Extensions: SingleResponses SingleCertResponse SerialNumberHash: d3:a0:c1:e3:db:92:e8:f6:81:05:37:d4:5c:fa:ec:f6: ce:41:7e:3b Cert Status: unknown This Update: -28800, 2025-03-02T16:00:00Z Next Update: 25200, 2025-03-03T07:00:00Z Extensions: Responder Certs C509Certificate 8b:02:42:12:35:0c:6f:74:65:73:74:20:63:72:6c:6f: 63:73:70:2d:63:61:1a:67:75:d7:00:1a:69:57:0a:80: 6e:6f:63:73:70:2d:72:65:73:70:6f:6e:64:65:72:0c: 58:20:81:94:7b:bc:24:8a:ac:79:73:82:11:a8:d7:5b: f9:2c:b7:77:d9:94:07:3d:f2:3a:e0:63:80:ef:2c:57: 39:76:88:01:54:b5:b4:ca:f3:54:01:d0:61:51:df:96: 29:db:57:9d:c8:cc:a4:53:a8:21:01:07:54:2f:45:e7: 8d:2c:ae:df:36:8c:df:53:c3:90:05:d4:92:45:0e:10: 56:27:09:58:40:a0:1b:0c:bf:3e:34:a4:76:2d:05:40: 4f:d0:8a:7a:ec:10:30:35:35:83:14:68:6d:72:b6:15: 90:78:c7:6e:1d:88:59:7f:37:53:18:86:a3:f5:2f:25: 6f:d7:22:19:2b:28:9d:68:44:01:44:67:f1:f1:7f:05: ac:bb:7b:66:0a C509Certificate 8b:02:41:01:0c:73:74:65:73:74:20:63:72:6c:6f:63: 73:70:2d:72:6f:6f:74:63:61:1a:67:74:85:80:1a:6b: 36:ec:7f:6f:74:65:73:74:20:63:72:6c:6f:63:73:70: 2d:63:61:0c:58:20:5e:f8:a3:55:a0:01:a7:c5:0d:23: 49:47:01:20:81:31:a4:bb:2a:b9:20:d4:0b:fb:0e:e1: f6:ab:28:ff:74:00:88:01:54:2f:45:e7:8d:2c:ae:df: 36:8c:df:53:c3:90:05:d4:92:45:0e:10:56:21:18:60: 23:01:07:54:2d:a3:a4:03:f7:d2:f4:e0:b3:d8:03:1a: 73:ba:8a:83:9f:55:7f:0f:58:40:e5:04:65:d6:0c:02: a2:11:1e:f3:fc:6e:44:f2:a3:60:08:76:5b:55:23:51: f9:a3:f5:b2:aa:7c:76:f1:f0:5d:25:98:47:a4:f4:25: 0b:2e:4b:0a:e2:09:97:62:a2:59:6d:3c:c1:db:2c:cd: 18:0a:a0:a2:d0:e1:91:31:0b:0f Signature Value 8a:e4:aa:b9:1f:e2:32:b3:6a:e8:74:ce:31:0b:e7:64: 49:62:6b:17:7c:2e:59:6a:21:e3:de:cd:a9:e7:b9:dc: 70:22:91:c6:da:f1:9a:f5:ad:e2:36:ee:34:b3:89:96: cf:48:03:bc:65:69:03:74:92:eb:41:f7:ad:e8:d5:05 ]]> Annotated hex

Document Updates

Version -00 to -01

• Added the section "Alternative Certificate Status Checking Mechanisms".
• Constrained the value ranges of integer fields in the CDDL.
• Replaced the "C509 Hash Algorithms" registry with the "COSE Algorithms" registry.
• Specified the PEM representation of C509 CRL and C509 OCSP messages.
• Added the registries for C509 CRL types and C509 OCSP request and response types.
• Added the section "Implementation Status".
• Added the section "Security Considerations".
• Clarifications and editorial improvements.

Acknowledgments The authors thank xxx for reviewing and commenting on intermediate versions of the draft.