]> NIO

lijun.liao@nio.io

RISE AB

marco.tiloca@ri.se

RISE AB

joel.hoglund@ri.se

RISE AB

rikard.hoglund@ri.se

University of Glasgow

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. 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 -- 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. OCSP responses as defined in 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.
• 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, and 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.
  See the field encoding sections of this document for details. The request and response 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 .

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 .

Imported Definitions The following types are imported from :

• Name: no limitation.
• Extensions: only the ( extensionID: int, extensionValue: Defined ) choice of Extension is permitted.
• COSE_C509: no limitation.
• AlgorithmIdentifier: no limitation.

The following type is imported from :

• COSE_X509: no limitation.

This document further defines the following constrained alias for use in all CDDL definitions: IntAlgorithmIdentifier is the int-only instantiation of AlgorithmIdentifier from . It is used throughout this document wherever an algorithm identifier appears in the wire encoding.

Encoding of Time Fields Time fields are encoded as unwrapped CBOR epoch-based date/time (~time). The tag content 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 freshness information (crlType, signature algorithm, issuer identity, CRL number, validity window, extensions) without the potentially large revocation list. TBSCertList embeds CRLInfoData and adds revokedCertsList.

crlType The crlType field serves as the type discriminator for C509CRL, following the same extensibility pattern as ocspRequestType and ocspResponseType. This document defines only type 0, corresponding to the C509CRL structure. 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), where the byte string contains the DER-encoded Name from the subject field of the issuing X.509 CA certificate (). 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 an unsigned integer (uint). 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 uint 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.

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: (1) it is implicit and positional, making it difficult to parse correctly and error-prone to implement; and (2) 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: the serial number length differs between certificates, the revocation date uses different encodings depending on whether the date falls before or after 2050, and 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 of 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. 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 (value 0x01) indicates whether entries in revokedCerts are sorted in ascending order by the integer value of the certificate serial number; bit 1 (value 0x02) 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 SHOULD be 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 or 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. Only the (extensionID: int, extensionValue: Defined) choice is permitted. If no per-issuer extensions are present, this field MUST be encoded as an empty CBOR array.
• 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. Only the (extensionID: int, extensionValue: Defined) choice is permitted. 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)	field sorted (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. Only the (extensionID: int, extensionValue: Defined) choice is permitted. 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 now expired. 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	field 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 ).

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 unsigned integer that identifies the structure type. This document defines types 0, 1, and 2. 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.

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 SHA‑3‑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.

C509 OCSP Request

CDDL

CDDL for C509OCSPRequest

Field Encodings

ocspRequestType The ocspRequestType field serves as the discriminator for C509OCSPRequest:

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 CBOR-encoded issuer C509 certificate, or over the DER-encoded issuer X.509 certificate (). 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.

• The extensions field contains per-issuer extensions that apply to all single-certificate requests in this PerIssuerOCSPRequest entry; see . If no per-issuer extensions are present, this field MUST be encoded as an empty CBOR array.
• 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, which discriminates C509UnsignedOCSPRequest from C509SignedOCSPRequest.
• The hashAlgorithm field specifies the hash algorithm used to compute issuerCertHash and serialNumberHash. The algorithm is encoded as an integer from the "C509 Hash Algorithms" registry defined in .
• The nonce field contains the request nonce, or MUST be null when no nonce is present.
• 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, which discriminates C509SignedOCSPRequest from C509UnsignedOCSPRequest.
• 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 an integer from the "C509 Hash Algorithms" registry defined in .
• The nonce field is as defined for C509UnsignedOCSPRequest ().
• The requestorCertHash field is a hash of the signer's certificate, computed using hashAlgorithm. requestorCerts MUST carry 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, which discriminates C509SimpleOCSPRequest from C509UnsignedOCSPRequest and C509SignedOCSPRequest.
• The nonce field contains the request nonce, or MUST be null when no nonce is present.
• 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 using the hashAlgorithm from C509SimpleOCSPRequest. The serial number is encoded in big-endian byte order without a leading zero byte 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 request-level extensions; see . If no extensions are present, this field MUST be encoded as an empty CBOR array.

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: 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 an integer from the "C509 Hash Algorithms" registry defined in .
• The responderCertHash field identifies the OCSP responder; see .
• 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 issuerCertHash field identifies the issuer of the queried certificate; see .
• The serialNumberHash field is the hash of the certificate serial number of the queried certificate, computed using hashAlgorithm. The serial number is encoded in big-endian byte order without a leading zero byte before hashing; 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 uint representing the number of seconds from producedAt until the next response update is expected, or null if the update time is unknown.
• The certStatus field encodes the revocation status; see .
• The extensions field contains response-level extensions; see . If no extensions are present, this field MUST be encoded as an empty CBOR array.
• 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 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 group and is therefore covered by the signature.
• signatureValue: the signature computed over the CBOR Sequence of the TBSBasicOCSPResponse 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 uint 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 ).

• The extensions field contains per-issuer extensions that apply to all single-certificate responses in this PerIssuerOCSPResponse entry; see . If no per-issuer extensions are present, this field MUST be encoded as an empty CBOR array.
• 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. It is computed using the hashAlgorithm from the enclosing TBSBasicOCSPResponse and contains the first 20 bytes. The serial number is encoded in big-endian byte order without a leading zero byte 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. In X.509 OCSP (), the CertID structure carries the plain serialNumber directly. C509 OCSP replaces this with a hash to preserve privacy: an observer cannot determine which certificate was queried without already knowing the serial number.

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 -- a fixed-length 2-element 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 [0] (value 0) and unknown uses [2] (value 2). The ASN.1 revoked alternative uses [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. Only the (extensionID: int, extensionValue: Defined) choice of Extensions is permitted. If no per-issuer extensions are present, the field MUST be encoded as an empty CBOR array []. 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 their mapping in this document. OCSP extensions defined in RFC 6960

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 responder 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.

• 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). Clients MUST include this extension in the single-request extensions per .

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, and 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 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 : 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.

C509 Hash Algorithms This document defines the following hash algorithms.

C509 Hash Algorithms

Security Considerations TODO

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.

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

C509 Hash Algorithms Registry IANA is requested to create a new registry "C509 Hash Algorithms" under the registry group "CBOR Encoded X.509 (C509)" defined in . The registration policy is either "Private Use", "IETF Review with Expert Review", or "Expert Review" per . "Expert Review" guidelines are provided in . All assignments according to "IETF Review with Expert Review" are made on an "IETF Review" basis per , with Expert Review additionally required per . The procedure for early IANA allocation of Standards Track code points defined in also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in . The columns of this registry are:

• Value: This field contains the value used to identify the C509 hash algorithm. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies . Integer values from -24 to 23 are designated as "IETF Review with Expert Review". Integer values greater than 32767 are marked as "Private Use". All other integer values are designated as "Expert Review". This field MUST NOT be empty.
• Name: This field contains the name of the C509 hash algorithm. This field MUST NOT be empty.
• Identifiers: This field contains additional identifiers of the C509 hash algorithm, if any is available.
• OID: This field contains the OID corresponding to the C509 hash algorithm. This field MUST NOT be empty.
• Parameters: This field contains the parameters of the C509 hash algorithm. This field MUST NOT be empty. If the C509 hash algorithm has no parameters, this field contains the string "absent".
• DER: This field contains the DER encoding of the ASN.1 value of type DigestInfo for the C509 hash algorithm. This field MUST NOT be empty.
• Comments: This field contains any optional comment about the C509 hash algorithm.
• Reference: This field contains a pointer to the public specification for the C509 hash algorithm, if one is available.

This registry has been initially populated with the entries defined in .

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	This document	N/A

Media Type Application Registry IANA is requested to assign the following entries into 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. Subtype name: c509-crl+cbor Required 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): N/A
• 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. Subtype name: c509-crlinfo+cbor Required 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): N/A
• 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. Subtype name: c509-ocspreq+cbor Required 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): N/A
• 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. Subtype name: c509-ocspresp+cbor Required 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): N/A
• 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. 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. 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 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 updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. 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) 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. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO 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. 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 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. n.d.

Examples

Overview Size comparison in examples (TODO: update the percent data)

Section	Description	size(C509)	size(X509)	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	152	51	66%
	Unsigned OCSP Request Example	483	132	73%
	Signed OCSP Request Example Without Requestor's Certificate	592	209	65%
	Signed OCSP Request Example With Requestor's Certificate	1043	420	60%
	Signed OCSP Request Example With Requestor's Certificate Chain	1379	625	55%
	Error OCSP Response Example	5	3	40%
	Simple OCSP Response Example	338	140	59%
	Basic OCSP Response Example Without Responder's Certificate	845	248	71%
	Basic OCSP Response Example With Responder's Certificate	1189	446	62%
	Basic OCSP Response Example With Responder's Certificate Chain	1525	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] #---PerIssuedRevokedCerts[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 CRL since 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] #---PerIssuedRevokedCerts[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= #---PerIssuedRevokedCerts[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 (152 bytes):

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

Unsigned OCSP Request Example

• Size reduction: 73%
• 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 (483 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: 65%
• Verifiable with certificate in
• Signed OCSP Request (C509UnsignedOCSPRequest) 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 (592 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 7d:a7:0b:e7:0d:8c:88:f5:15:02:18:b2:f6:0a:21:32: 0d:26:fa:f8:dc:19:8f:16:65:4d:54:cb:61:7a:1c:3c: 3f:42:0b:3f:2f:bf:74:c9:b1:07:d8:1d:18:15:c2:ce: 09:b2:2e:af:49:13:13:00:3c:49:d4:3a:ab:8d:97:0b ]]> Annotated hex 143: 58 40 # [8]. signatureValue=byte[64] 145: 7DA70BE70D8C88F5150218B2F60A21320D26FAF8DC198F16654D54CB61 174: 7A1C3C3F420B3F2FBF74C9B107D81D1815C2CE09B22EAF491313003C49 203: D43AAB8D970B ]]>

Signed OCSP Request Example With Requestor's Certificate

• Size reduction: 60%
• Verifiable with certificate in
• Signed OCSP Request (C509UnsignedOCSPRequest) 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 (1043 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 eb:f9:5f:92:81:2c:9d:f3:db:c7:c1:96:99:d5:25:44: 85:ad:dc:93:06:95:23:9d:1d:68:bf:79:88:f3:f1:b0: c7:6a:58:8b:f4:2f:4f:cf:f3:73:c3:70:5a:eb:56:fc: 3b:6c:de:aa:f6:6d:a0:f5:bb:b7:35:f4:a1:cd:b0:04 ]]> 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: EBF95F92812C9DF3DBC7C19699D5254485ADDC930695239D1D68BF7988 385: F3F1B0C76A588BF42F4FCFF373C3705AEB56FC3B6CDEAAF66DA0F5BBB7 414: 35F4A1CDB004 ]]>

Signed OCSP Request Example With Requestor's Certificate Chain

• Size reduction: 55%
• Verifiable with certificate in
• Signed OCSP Request (C509UnsignedOCSPRequest) 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 (1379 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 71:d3:9c:bd:66:11:fd:5b:0c:30:92:fc:e5:80:16:b9: 66:23:28:51:ac:31:67:cd:0c:de:f4:7d:f0:f0:bc:73: 86:16:eb:65:bb:2b:a5:09:c8:cf:45:ed:bc:9b:78:4a: 4a:70:92:5e:97:ae:15:28:71:e9:d6:65:c4:77:50:0e ]]> 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: 71D39CBD6611FD5B0C3092FCE58016B966232851AC3167CD0CDEF47DF0 590: F0BC738616EB65BB2BA509C8CF45EDBC9B784A4A70925E97AE152871E9 619: D665C477500E ]]>

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: 59%
• 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 (338 bytes):

C509 OCSP Response Plain Hex (140 bytes): Textual Representation Responder Certs: null Signature Value e3:41:99:55:ae:b3:d7:4a:d5:bc:7d:32:26:4e:89:76: c3:ab:6f:68:64:3c:6b:f6:6c:c2:f9:35:2f:f3:e8:61: a0:bd:15:06:c7:8b:09:d3:fa:e8:69:d1:fd:3c:87:ef: 46:1c:f6:d2:09:6e:a0:ac:11:fc:ff:5e:bc:0f:a7:0c ]]> Annotated hex 74: 58 40 # [13]. signatureValue=byte[64] 76: E3419955AEB3D74AD5BC7D32264E8976C3AB6F68643C6BF66CC2F9352F 105: F3E861A0BD1506C78B09D3FAE869D1FD3C87EF461CF6D2096EA0AC11FC 134: FF5EBC0FA70C ]]>

Basic OCSP Response Example Without Responder's Certificate

• Size reduction: 71%
• 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 (845 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 e4:86:9c:57:a6:6b:ab:50:1a:ca:eb:7e:50:24:10:52: 53:d7:2f:45:d3:49:ae:21:fb:94:1a:be:44:35:f8:a6: c9:d1:ca:5d:27:84:ab:30:cf:17:7f:f0:75:b5:50:2a: ea:ee:09:c1:14:6c:f4:90:66:3e:ae:d9:24:3a:76:0d ]]> Annotated hex 182: 58 40 # [9]. signature value=byte[64] 184: E4869C57A66BAB501ACAEB7E5024105253D72F45D349AE21FB941ABE44 213: 35F8A6C9D1CA5D2784AB30CF177FF075B5502AEAEE09C1146CF490663E 242: AED9243A760D ]]>

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 (1189 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 00:85:ea:27:96:9e:5a:16:2e:a3:1d:37:15:22:f6:2f: 0d:f2:78:27:22:25:de:ad:6f:17:3c:42:d5:48:21:42: a3:f0:32:87:28:50:a4:e2:c2:d9:a7:59:a0:f4:60:e1: 25:0b:6f:de:bb:66:36:b3:67:2c:a0:2e:fb:88:0a:04 ]]> 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 (1525 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 b6:33:c9:59:80:73:e3:92:08:76:fe:12:b8:6a:d3:24: 22:e7:f2:c2:36:11:77:a6:d5:90:f2:0b:eb:ba:a1:ef: df:94:a0:a9:44:ac:8c:a6:76:79:ca:04:ce:af:32:7c: 12:cb:9f:1c:2d:ca:ca:9d:2e:94:9b:fe:a7:55:c4:05 ]]> Annotated hex

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