RFC 6487

A Profile for X.509 PKIX Resource Certificates

📅 published February 2012, from ietf

A Profile for X.509 PKIX Resource Certificates 🎀

RFC 6487 🦋 is by G. Huston, G. Michaelson, and R. Loomans, all from APNIC. It's a Standards Track doc, ISSN 2070-1721, dated February 2012. The header doesn't list any Obsoletes or Updates entries, so nothing is marked as replaced or amended. 💅

Part 1 of 6 💖 more parts are coming!

Abstract

okay so this doc sets up a standard profile for X.509 certificates 🔥 the goal is checking "right-of-use" claims for Internet Number Resources (INRs). a cert made under this profile says the issuer lets the subject be seen as the current holder of the INRs listed in it. it's the normative spec for Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI), and it also covers certificate request formats and the Relying Party RPKI certificate path validation procedure ✨

Status of This Memo

this is an Internet Standards Track document 👑

it's a product of the Internet Engineering Task Force (IETF), it reflects IETF community consensus, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). more on Internet Standards is in Section 2 of RFC 5741 📚

for the current status, errata, and where to send feedback, check http://www.rfc-editor.org/info/rfc6487 🌸

Copyright Notice

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. please actually read them, because they explain your rights and restrictions for this doc 🫶 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes ⭐

Table of Contents 🧚

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Describing Resources in Certificates . . . . . . . . . . . . .  5
   3.  End-Entity (EE) Certificates and Signing Functions in the RPKI  5
   4.  Resource Certificates  . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Version  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Serial Number  . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Signature Algorithm  . . . . . . . . . . . . . . . . . . .  6
     4.4.  Issuer . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.5.  Subject  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.6.  Validity . . . . . . . . . . . . . . . . . . . . . . . . .  7
       4.6.1.  notBefore  . . . . . . . . . . . . . . . . . . . . . .  8
       4.6.2.  notAfter . . . . . . . . . . . . . . . . . . . . . . .  8
     4.7.  Subject Public Key Info  . . . . . . . . . . . . . . . . .  8
     4.8.  Resource Certificate Extensions  . . . . . . . . . . . . .  8
       4.8.1.  Basic Constraints  . . . . . . . . . . . . . . . . . .  8
       4.8.2.  Subject Key Identifier . . . . . . . . . . . . . . . .  9
       4.8.3.  Authority Key Identifier . . . . . . . . . . . . . . .  9
       4.8.4.  Key Usage  . . . . . . . . . . . . . . . . . . . . . .  9
       4.8.5.  Extended Key Usage . . . . . . . . . . . . . . . . . .  9
       4.8.6.  CRL Distribution Points  . . . . . . . . . . . . . . . 10
       4.8.7.  Authority Information Access . . . . . . . . . . . . . 10
       4.8.8.  Subject Information Access . . . . . . . . . . . . . . 11
       4.8.9.  Certificate Policies . . . . . . . . . . . . . . . . . 12
       4.8.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 12
       4.8.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 12
   5.  Resource Certificate Revocation Lists  . . . . . . . . . . . . 13
   6.  Resource Certificate Requests  . . . . . . . . . . . . . . . . 13
     6.1.  PCKS#10 Profile  . . . . . . . . . . . . . . . . . . . . . 14
       6.1.1.  PKCS#10 Resource Certificate Request Template Fields . 14
     6.2.  CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 15
       6.2.1.  CRMF Resource Certificate Request Template Fields  . . 15
       6.2.2.  Resource Certificate Request Control Fields  . . . . . 16
     6.3.  Certificate Extension Attributes in Certificate Requests . 16
   7.  Resource Certificate Validation  . . . . . . . . . . . . . . . 17
     7.1.  Resource Extension Validation  . . . . . . . . . . . . . . 17
     7.2.  Resource Certification Path Validation . . . . . . . . . . 18
   8.  Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  Operational Considerations for Profile Agility . . . . . . . . 22
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     12.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.  Example Resource Certificate  . . . . . . . . . . . . 27
   Appendix B.  Example Certificate Revocation List . . . . . . . . . 31

1. Introduction 💖

so this doc defines a standard profile for X.509 certificates [X.509] used in certifying Internet Number Resources (INRs), which means IP Addresses and Autonomous System (AS) numbers 🌈 these certs are called "resource certificates". a resource certificate is a PKIX-profile cert [RFC5280] that also follows the constraints in this profile. it says the issuer has granted the subject a "right-of-use" for a listed set of IP addresses and/or AS numbers ✨

this doc is referenced by Section 7 of the "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" [RFC6484] 🦋 it's an integral part of that policy and the normative spec for certificate and CRL syntax used in the RPKI. it also covers certificate request formats and the relying party (RP) RPKI certificate path validation procedure 🧁

resource certs should be used in a way that matches the RPKI Certificate Policy (CP) [RFC6484] 💅 they're issued by the entities that assign and/or allocate public INRs, so the RPKI lines up with how public INRs get handed out. when a number registry allocates or assigns an INR to an entity, a resource certificate can describe that allocation. the registry issues the cert, and it binds the subject's key to the INRs listed in it. one or two critical extensions, the IP Address Delegation or AS Identifier Delegation Extensions [RFC3779], list the INRs the issuer allocated or assigned to the subject 🔥

RP validation of a resource cert follows the steps in Section 7.1 🌸 this differs from Section 6 of [RFC5280] in these ways:

additional validation processing imposed by the INR extensions is required,
a confirmation of a public key match between the CRL issuer and the resource certificate issuer is required, and
the resource certificate is required to conform to this profile.

this profile lists the fields a resource cert MUST have present to be valid 👑 any extension that isn't explicitly mentioned MUST be absent 🙈 the same goes for the CRLs used in the RPKI, which this doc also profiles. a Certification Authority (CA) that conforms to the RPKI CP MUST issue certificates and CRLs consistent with this profile 🫶

1.1. Terminology 🎀

you should already know the terms and concepts in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779] 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 💜

2. Describing Resources in Certificates 🌷

the framework for linking a cert's subject to the INRs they currently control is in [RFC3779] 🦋 this profile adds these requirements, bestie:

Every resource certificate MUST contain either the IP Address Delegation or the Autonomous System Identifier Delegation extension, or both.
These extensions MUST be marked as critical.
The sorted canonical format for describing INRs, with maximal spanning ranges and maximal spanning prefix masks as defined in [RFC3779], MUST be used for the resource extension field, except where the "inherit" construct is used instead.

when an RP validates a resource cert, it MUST verify that the INRs in the issuer's resource cert encompass the INRs of the cert being validated 🔥 here "encompass" means the issuer's INRs can be the same as the subject's, or a strict superset of them. no shrinking allowed 🙅‍♀️✨

3. End-Entity (EE) Certificates and Signing Functions in the RPKI 💅

as noted in [RFC6480], the main job of end-entity (EE) certificates in the RPKI is verifying signed objects that use the INRs listed in the cert, like Route Origin Authorizations (ROAs) and manifests 🌈

the private key tied to an EE cert signs a single RPKI signed object 💖 so the EE cert only validates one object. the EE cert is embedded in the object as part of a Cryptographic Message Syntax (CMS) signed-data structure [RFC6488]. since it's one-to-one between the EE cert and the signed object, revoking the cert effectively revokes the signed object too 😭

an EE cert can also validate a sequence of signed objects 🧚 each new one overwrites the previous instance in the repository publication point, so only one instance is published at any moment (for example, an EE cert MAY be used to sign a sequence of manifests [RFC6486]). these are called "sequential use" EE certificates 🦋

EE certs that validate only one instance of a signed object, and aren't used after that or in any other validation context, are called "one-time-use" EE certificates 🌸

4. Resource Certificates ✨

okay bestie, so a resource certificate is a valid X.509 public key certificate that follows the PKIX profile [RFC5280] 💅 and it has to contain the fields in this section. we're only gonna talk about the differences from [RFC5280], so no panic 🫶

unless a field is specifically noted as being OPTIONAL, all the fields listed here MUST be present, and any other fields MUST NOT appear in a conforming resource certificate 😭 no extra fields, babe. and wherever a field value is spelled out here, that value MUST be used in conforming resource certificates 🎀

4.1. Version

as resource certificates are X.509 version 3 certificates, the version MUST be 3 (i.e., the value of this field is 2) 🦋

RPs need not process version 1 or version 2 certificates (in contrast to [RFC5280]). ngl that's a whole glow-up from the usual 🌈

4.2. Serial Number

the serial number is a positive integer that's unique for each certificate a given CA issues 🔢✨

4.3. Signature Algorithm

the algorithm used in this profile is specified in [RFC6485] 🖋️

4.4. Issuer

the value of this field is a valid X.501 distinguished name 💜

an issuer name MUST contain one instance of the CommonName attribute and MAY contain one instance of the serialNumber attribute. if both attributes are present, it is RECOMMENDED that they appear as a set. the CommonName attribute MUST be encoded using the ASN.1 type PrintableString [X.680]. issuer names are not meant to describe who the issuer actually is 🙈

the RPKI doesn't rely on issuer names being globally unique, for security reasons. still, it is RECOMMENDED that issuer names get generated in a way that makes collisions unlikely 🍓 see Section 8 for (non-normative) name-generation ideas that fulfill this recommendation. main character energy 👑

4.5. Subject

the value of this field is a valid X.501 distinguished name [RFC4514], and it has the same constraints as the issuer name 🧚

in the RPKI, the issuer decides the subject name, not the subject [RFC6481]. every distinct subordinate CA and EE certified by the issuer MUST be identified with a subject name that's unique per issuer. here "distinct" means an entity paired with a given public key. an issuer SHOULD use a different subject name if the subject's key pair has changed (i.e., when the CA issues a certificate as part of re-keying the subject.) subject names are not meant to describe who the subject is either 💅

4.6. Validity

the validity period is a SEQUENCE of two dates: when it begins (notBefore) and when it ends (notAfter) 📅

a CA is usually advised NOT to... wait, correction bestie: a CA is typically advised against issuing a certificate whose validity period runs longer than the validity period of the CA's own certificate that will validate it. but in this profile, a CA MAY have valid grounds to issue a subordinate certificate with a validity period that goes past the CA's certificate validity period 🦋

4.6.1. notBefore

the "notBefore" time SHOULD be no earlier than the time the certificate was generated ⏰

in the RPKI, it's totally valid for this field to pre-date the same field in any superior certificate 🌸 relying parties SHOULD NOT try to infer from this time that a certificate was valid at some point in the past, or that it will be valid in the future. an RP's validity test is about validity at the current time, period 💀

4.6.2. notAfter

the "notAfter" time represents the anticipated lifetime of the current resource allocation or assignment arrangement between the issuer and the subject 🎀

it's valid for this field to post-date the same field in any superior certificate too. the same caveats apply to RP assumptions about validity at any time other than the current time ✨

4.7. Subject Public Key Info

the algorithm used in this profile is specified in [RFC6485] 🖋️

4.8. Resource Certificate Extensions

the following X.509 v3 extensions MUST be present in a conforming resource certificate, except where explicitly noted otherwise. every extension in a resource certificate is marked as either critical or non-critical 🔥 a certificate-using system MUST reject the certificate if it runs into a critical extension it doesn't recognize. a non-critical extension, though, MAY be ignored if it isn't recognized [RFC5280] 🫶

4.8.1. Basic Constraints

the Basic Constraints extension is a critical extension in the resource certificate profile. it MUST be present when the subject is a CA, and it MUST NOT be present otherwise 🧱

the issuer decides whether the "cA" boolean is set 👑

the Path Length Constraint is not specified for RPKI certificates, and it MUST NOT be present 🙅‍♀️

4.8.2. Subject Key Identifier

this extension MUST appear in all resource certificates. it's non-critical 🌈

the Key Identifier used for resource certificates is the 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the Subject Public Key, as described in Section 4.2.1.2 of [RFC5280] 🔐

4.8.3. Authority Key Identifier

this extension MUST appear in all resource certificates, except for a CA that issues a "self-signed" certificate. in a self-signed certificate, a CA MAY include this extension and set it equal to the Subject Key Identifier 🪞 the authorityCertIssuer and authorityCertSerialNumber fields MUST NOT be present. it's non-critical too 💜

the Key Identifier used for resource certificates is the 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the issuer's public key, as described in Section 4.2.1.1 of [RFC5280] 🔑

4.8.4. Key Usage

this extension is critical and MUST be present 🔥

in certificates issued to certification authorities only, the keyCertSign and CRLSign bits are set to TRUE, and these MUST be the only bits set to TRUE 🎀

in EE certificates, the digitalSignature bit MUST be set to TRUE and MUST be the only bit set to TRUE ✍️

4.8.5. Extended Key Usage

the Extended Key Usage (EKU) extension MUST NOT appear in any CA certificate in the RPKI. this extension also MUST NOT appear in EE certificates used to verify RPKI objects (e.g., ROAs or manifests. and it MUST NOT be marked critical 🚫💅

the EKU extension MAY appear in EE certificates issued to routers or other devices 🤖 permitted EKU OIDs will be specified in Standards Track RFCs from other IETF working groups that adopt the RPKI profile and identify the application-specific requirements that motivate using those EKUs 🦋

4.8.6. CRL Distribution Points

this extension MUST be present, except in "self-signed" certificates, and it is non-critical. in a self-signed certificate, this extension MUST be omitted 🙈

in this profile, the scope of the CRL is specified to be all certificates issued by this CA issuer 📜

the CRL Distribution Points (CRLDP) extension identifies the location(s) of the CRL(s) associated with certificates issued by this issuer. the RPKI uses the URI [RFC3986] form of object identification. the preferred URI access mechanism is a single rsync URI (rsync://) [RFC5781] that references a single inclusive CRL for each issuer 🌸

in this profile, the certificate issuer is also the CRL issuer. that means the CRLIssuer field MUST be omitted, and the distributionPoint field MUST be present. the Reasons field MUST be omitted 🧚

the distributionPoint MUST contain the fullName field, and MUST NOT contain a nameRelativeToCRLIssuer. the form of the generalName MUST be of type URI 🔗

the sequence of distributionPoint values MUST contain only a single DistributionPoint. the DistributionPoint MAY contain more than one URI value. an rsync URI [RFC5781] MUST be present in the DistributionPoint and MUST reference the most recent instance of this issuer's CRL 💖 other access form URIs MAY be used alongside the rsync URI, representing alternate access mechanisms for this CRL 🌈

4.8.7. Authority Information Access

in the context of the RPKI, this extension identifies the publication point of the certificate of the issuer of the certificate the extension appears in 🗂️ in this profile, a single reference to the publication point of the immediate superior certificate MUST be present, except for a "self-signed" certificate, where the extension MUST be omitted. it's non-critical 💅

this profile uses a URI form of object identification. the preferred URI access mechanism is "rsync", and an rsync URI [RFC5781] MUST be specified with an accessMethod value of id-ad-caIssuers. the URI MUST reference the point of publication of the certificate where this issuer is the subject (the issuer's immediate superior certificate) 📍 other accessMethod URIs referencing the same object MAY also be included in the value sequence of this extension 🦋

a CA MUST use a persistent URL name scheme for the CA certificates it issues [RFC6481]. this means a reissued certificate overwrites a previously issued certificate (to the same subject) in the publication repository 🔁 that way, certificates subordinate to the reissued (CA) certificate can keep a constant Authority Information Access (AIA) extension pointer, so they don't need reissuing when the parent certificate gets reissued 🥹✨

4.8.8. Subject Information Access

in the context of the RPKI, this Subject Information Access (SIA) extension identifies the publication point of products signed by the subject of the certificate 📦

4.8.8.1. SIA for CA Certificates

this extension MUST be present and MUST be marked non-critical 💜

this extension MUST have an instance of an accessMethod of id-ad-caRepository, with an accessLocation in the form of a URI that MUST specify an rsync URI [RFC5781]. this URI points to the directory holding everything this CA published: all valid CA certificates, published EE certificates, the current CRL, the manifest, and signed objects validated via EE certificates issued by this CA [RFC6481] 📂 other accessDescription elements with an accessMethod of id-ad-caRepository MAY be present. in that case, the accessLocation values describe alternate supported URI access mechanisms for the same directory. the order of URIs in this accessDescription sequence reflects the CA's relative preferences for access methods RPs should use, with the first element being the CA's most preferred 🥇

this extension MUST have an instance of an AccessDescription with an accessMethod of id-ad-rpkiManifest,

      id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

      id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 }

with an rsync URI [RFC5781] form of accessLocation. the URI points to the CA's manifest of published objects [RFC6486] as an object URL 📜 other accessDescription elements MAY exist for the id-ad-rpkiManifest accessMethod, where the accessLocation value indicates alternate access mechanisms for the same manifest object 🫶

4.8.8.2. SIA for EE Certificates ✨

okay bestie, this is the SIA for EE certificates 🦋 This extension MUST be present and MUST be marked non-critical 💅

This extension MUST have an instance of an accessMethod of id-ad-signedObject, 🫶

id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 }

with an accessLocation form of a URI that MUST include an rsync URI [RFC5781]. This URI points to the signed object that is verified using this EE certificate [RFC6481]. Other accessDescription elements may exist for the id-ad-signedObject accessMethod, where the accessLocation value indicates alternate URI access mechanisms for the same object, ordered in terms of the EE's relative preference for supported access mechanisms. ✨

Other AccessMethods MUST NOT be used for an EE certificates's SIA 🙈

4.8.9. Certificate Policies

this one is giving strict 👑 This extension MUST be present and MUST be marked critical. It MUST include exactly one policy, as specified in the RPKI CP [RFC6484]

4.8.10. IP Resources

Either the IP Resources extension, or the AS Resources extension, or both, MUST be present in all RPKI certificates, and if present, MUST be marked critical. 🌸

This extension contains the list of IP address resources as per [RFC3779]. The value may specify the "inherit" element for a particular Address Family Identifier (AFI) value. In the context of resource certificates describing public number resources for use in the public Internet, the Subsequent AFI (SAFI) value MUST NOT be used. 💜

This extension MUST either specify a non-empty set of IP address records, or use the "inherit" setting to indicate that the IP address resource set of this certificate is inherited from that of the certificate's issuer. 🍓

4.8.11. AS Resources

same energy as the IP one, just for AS numbers 🧚 Either the AS Resources extension, or the IP Resources extension, or both, MUST be present in all RPKI certificates, and if present, MUST be marked critical.

This extension contains the list of AS number resources as per [RFC3779], or it may specify the "inherit" element. Routing Domain Identifier (RDI) values are NOT supported in this profile and MUST NOT be used. 🚫

This extension MUST either specify a non-empty set of AS number records, or use the "inherit" setting to indicate that the AS number resource set of this certificate is inherited from that of the certificate's issuer. ✨

5. Resource Certificate Revocation Lists 📜

okay the CRL section is where it gets iconic 🔥 Each CA MUST issue a version 2 CRL that is consistent with [RFC5280]. RPs are NOT required to process version 1 CRLs (in contrast to [RFC5280]). The CRL issuer is the CA. CRLs conforming to this profile MUST NOT include Indirect or Delta CRLs. The scope of each CRL MUST be all certificates issued by this CA.

The issuer name is as in Section 4.4 above. 🎀

Where two or more CRLs are issued by the same CA, the CRL with the highest value of the "CRL Number" field supersedes all other CRLs issued by this CA. 👑

The algorithm used in CRLs issued under this profile is specified in [RFC6485]. 💅

The contents of the CRL are a list of all non-expired certificates that have been revoked by the CA. 🥀

An RPKI CA MUST include the two extensions, Authority Key Identifier and CRL Number, in every CRL that it issues. RPs MUST be prepared to process CRLs with these extensions. No other CRL extensions are allowed. 🫶

For each revoked resource certificate, only the two fields, Serial Number and Revocation Date, MUST be present, and all other fields MUST NOT be present. No CRL entry extensions are supported in this profile, and CRL entry extensions MUST NOT be present in a CRL. 🙈

6. Resource Certificate Requests 📨

A resource certificate request MAY use either of PKCS#10 or Certificate Request Message Format (CRMF). A CA MUST support certificate issuance in PKCS#10 and a CA MAY support CRMF requests. 🌈

Note that there is no certificate response defined in this profile. For CA certificate requests, the CA places the resource certificate in the repository, as per [RFC6484]. No response is defined for EE certificate requests. 🧚

6.1. PCKS#10 Profile 🦋

This profile refines the specification in [RFC2986], as it relates to resource certificates. A Certificate Request Message object, formatted according to PKCS#10, is passed to a CA as the initial step in issuing a certificate.

With the exception of the SubjectPublicKeyinfo and the SIA extension request, the CA is permitted to alter any field in the request when issuing a certificate. 🌸

6.1.1. PKCS#10 Resource Certificate Request Template Fields 📝

This profile applies the following additional requirements to fields that MAY appear in a CertificationRequestInfo:

Version: This field is mandatory and MUST have the value 0.
Subject: This field MAY be omitted. If present, the value of this field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its Certificate Practice Statement (CPS)) that permits reuse of names in these circumstances.
SubjectPublicKeyInfo: This field specifies the subject's public key and the algorithm with which the key is used. The algorithm used in this profile is specified in [RFC6485].
Attributes: [RFC2986] defines the attributes field as key-value pairs where the key is an OID and the value's structure depends on the key. The only attribute used in this profile is the extensionRequest attribute as defined in [RFC2985]. This attribute contains certificate extensions. The profile for extensions in certificate requests is specified in Section 6.3.

This profile applies the following additional constraint to fields that MAY appear in a CertificationRequest Object:

signatureAlgorithm: The signatureAlgorithm value is specified in [RFC6485]. ✨

6.2. CRMF Profile 🎀

This profile refines the Certificate Request Message Format (CRMF) specification in [RFC4211], as it relates to resource certificates. A Certificate Request Message object, formatted according to the CRMF, is passed to a CA as the initial step in certificate issuance.

With the exception of the SubjectPublicKeyinfo and the SIA extension request, the CA is permitted to alter any requested field when issuing the certificate. 💖

6.2.1. CRMF Resource Certificate Request Template Fields 🧾

This profile applies the following additional requirements to fields that may appear in a Certificate Request Template:

version: This field SHOULD be omitted. If present, it MUST specify a request for a version 3 Certificate.
serialNumber: This field MUST be omitted.
signingAlgorithm: This field MUST be omitted.
issuer: This MUST be omitted in this profile.
Validity: This field MAY be omitted. If omitted, the CA will issue a Certificate with Validity dates as determined by the CA. If specified, then the CA MAY override the requested values with dates as determined by the CA.
Subject: This field MAY be omitted. If present, the value of this field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its CPS) that permits the reuse of names in these circumstances.
PublicKey: This field MUST be present.
extensions: The profile for extensions in certificate requests is specified in Section 6.3.

6.2.2. Resource Certificate Request Control Fields 🎛️

The following control fields are supported in this profile:

Authenticator Control: The intended model of authentication of the subject is a "long term" model, and the guidance offered in [RFC4211] is that the Authenticator Control field be used. 🔐

6.3. Certificate Extension Attributes in Certificate Requests 🧩

The following extensions MAY appear in a PKCS#10 or CRMF Certificate Request. Any other extensions MUST NOT appear in a Certificate Request. This profile places the following additional constraints on these extensions:

BasicConstraints: If this is omitted, then the CA will issue an EE certificate (hence no BasicConstraints extension will be included).

The pathLengthConstraint is not supported in this profile, and this field MUST be omitted.

The CA MAY honor the cA boolean if set to TRUE (CA Certificate Request). If this bit is set, then it indicates that the subject is requesting a CA certificate.

The CA MUST honor the cA bit if set to FALSE (EE Certificate Request), in which case the corresponding EE certificate will not contain a Basic Constraints extension.

KeyUsage: The CA MAY honor KeyUsage extensions of keyCertSign and cRLSign if present, as long as this is consistent with the BasicConstraints SubjectType sub-field, when specified.
ExtendedKeyUsage: The CA MAY honor ExtendedKeyUsage extensions of keyCertSign and cRLSign if present, as long as this is consistent with the BasicConstraints SubjectType sub-field, when specified.
SubjectInformationAccess: This field MUST be present, and the field value SHOULD be honored by the CA if it conforms to the requirements set forth in Section 4.8.8. If the CA is unable to honor the requested value for this field, then the CA MUST reject the Certificate Request. 🙅‍♀️

7. Resource Certificate Validation ✅

This section describes the resource certificate validation procedure. This refines the generic procedure described in Section 6 of [RFC5280]. 🌟

7.1. Resource Extension Validation

okay so the IP Resources and AS Resources extensions [RFC3779] are where the actual goodies live 🎀 They're critical extensions for INRs, encoded in ASN.1. One is a representation of the IPv4 and IPv6 address ranges, and the other is a set of AS numbers. 🦋

Valid resource certificates MUST have a valid IP address and/or AS number resource extension. And to validate a resource certificate, you MUST also validate that resource extension. 💅 This check leans on three comparison words for resource sets, and they're the vibe check of the whole thing:

more specific: For two contiguous IP address ranges or two contiguous AS number ranges, A and B, A is "more specific" than B if range B includes every IP address or AS number described by range A, and range B is larger than range A. Basically, A is the smaller sibling tucked inside B's family tree 🌸
equal: For two contiguous IP address ranges or two contiguous AS number ranges, A and B, A is "equal" to B if range A describes exactly the same collection of IP addresses or AS numbers as range B. The "inheritance" definition in [RFC3779] is the same as this "equality" check, so no drama there 🫶
encompass: For two IP address and AS number sets, X and Y, X "encompasses" Y if, for every contiguous range element in set Y, that element is either "more specific" than or "equal" to a contiguous range element in set X. Think of X as the big umbrella that fully covers everything Y is holding ☂️

So when you validate a certificate's resource extension inside a certification path (see Section 7.2), here's the deal: for every adjacent pair of certificates (certificates x and x + 1), the number resources in certificate x have to "encompass" the number resources in certificate x + 1. ALSO, the resources in the trust anchor information have to "encompass" the resources in the first certificate of the path. No gaps allowed, periodt 👑

7.2. Resource Certification Path Validation

okay bestie, validating signed resource data with a target resource certificate is a two-part glow-up ✨ First, you check that the digital signature on the signed resource data is valid, using the public key from the target resource certificate. Second, you validate that resource certificate in the context of the RPKI, using the path validation process. That path validation process checks, among other things, that a prospective certification path (a sequence of n certificates) satisfies these conditions:

for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate (x + 1);
certificate 1 is issued by a trust anchor;
certificate n is the certificate to be validated; and
for all x in {1, ..., n}, certificate x is valid.

Certificate validation means verifying that ALL of the following hold, on top of the certification path validation criteria in Section 6 of [RFC5280] 🧚

The certificate can be verified using the issuer's public key and the signature algorithm.
The current time lies within the certificate's Validity From and To values.
The certificate contains all fields that MUST be present, as defined by this specification, and contains values for selected fields that are defined as allowable values by this specification.
No field, or field value, that this specification defines as MUST NOT be present is used in the certificate. 🙈
The issuer has not revoked the certificate. A revoked certificate is one whose serial number is listed on the issuer's current CRL (as identified by the certificate's CRLDP). The CRL itself has to be valid, AND the public key used to verify the CRL's signature has to be the same public key used to verify the certificate itself. Very strict, very iconic 💀
The resource extension data is "encompassed" by the resource extension data in a valid certificate where this issuer is the subject. That's the previous certificate in the ordered sequence of the certification path.
The certification path starts with a certificate issued by a trust anchor, and there's a signing chain across the whole path. The subject of certificate x has to match the issuer in certificate x + 1, AND the public key in certificate x has to be able to verify the signature value in certificate x+1 🔥

A certificate validation algorithm MAY perform these tests in any chosen order. Mix and match, no judgement 🌈

Certificates and CRLs used in this process MAY be found in a locally maintained cache. That cache gets kept fresh by regular synchronization across the distributed publication repository structure [RFC6481] 🍓

Now for the not-so-cute part. Certification paths can be arbitrarily long, or someone can try to build paths with loops, as a way to launch a potential denial-of-service (DOS) attack on an RP 😭 An RP running this procedure MAY apply further heuristics to halt the certification path validation process, so it avoids some of the trouble that comes with validating those malformed path structures. Implementations of resource certificate validation MAY also halt with a validation failure if the certification path length goes over a locally defined configuration parameter. Boundaries are good, bestie 💜

8. Design Notes 🌷

The following notes add some extra commentary on the reasoning behind some of the design choices in this certificate profile. These notes are non-normative, meaning this section of the document is NOT a formal part of the profile specification, and the interpretation of key words as defined in RFC 2119 doesn't apply here. It's just the backstory, babe 📖

Certificate Extensions

This profile doesn't allow any other critical or non-critical extensions. The reason is that the resource certificate profile is built for one specific, defined use. Having certificates with extra non-critical extensions that RPs might treat as valid, even though they can't understand those extensions, would be a mess. If the RP could understand the extensions, it would contradict or qualify that original judgment of validity somehow 🙅‍♀️ This profile picks minimalism over extensibility, no exceptions. The specific goal for the associated RPKI is to precisely match the INR allocation structure, using an aligned certificate structure that describes the allocation and its context within the INR distribution hierarchy. The profile defines a resource certificate that's structured to meet exactly those requirements 🧠

Certification Authorities and Key Values

This profile defines an instance of a CA as a combination of a named entity and a key pair. Within that definition, a CA instance cannot roll over a key pair. BUT the entity can generate a new instance of a CA with a new key pair, and roll all the signed subordinate products over to the new CA [RFC6489] 🔄 This has a bunch of implications for subject name management, CRL Scope, and repository publication point management, so stay tuned.

CRL Scope and Key Values

For CRL Scope, this profile says a CA issues a single CRL at a time, and that CRL's scope covers all certificates issued by that CA. Because the CA instance is bound to a single key pair, the CA's public key, the key used to validate the CA's CRL, and the key used to validate the certificates revoked by that CRL are all the same key value 🔑 Very neat, very tidy.

Repository Publication Point

The definition of a CA affects how the repository publication system is designed. To minimize forced re-certification on key rollover events, a repository publication regime can use the same publication point for all CA instances that refer to the same entity, even with different key values. That keeps re-generation of certificates limited to just the immediate subordinate certificates. This is described in [RFC6489] 📦

Subject Name

This profile says subject names must be unique per issuer, but it does NOT require subject names to be globally unique (in terms of assured uniqueness). That's because the RPKI is a distributed PKI. There's no easy way for certification authorities to coordinate one RPKI-wide unique name space without leaning on extra critical external dependencies 🌍 CAs are advised to use subject name generation procedures that minimize the potential for name clashes.

One way to do that is for a CA to use a subject name practice where the CommonName component of the Distinguished Name is a constant value for any given entity that is the subject of CA-issued certificates. Then it sets the serialNumber component of the Distinguished Name to a value derived from the hash of the subject public key value 🧁

If the CA chooses not to use the serialNumber component of the DistinguishedName, it's considered beneficial for the CA to generate CommonNames with a random component that includes significantly more than 40 bits of entropy. Some non-normative recommendations to get there:

Hash of the subject public key (encoded as ASCII HEX). Example: cn="999d99d564de366a29cd8468c45ede1848e2cc14"
A Universally Unique IDentifier (UUID) [RFC4122]. Example: cn="6437d442-6fb5-49ba-bbdb-19c260652098"
A randomly generated ASCII HEX encoded string of length 20 or greater. Example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"> (A string of 20 ASCII HEX digits would have 80-bits of entropy.) 🎲
An internal database key or subscriber ID combined with one of the above. Example: cn="<DBkey1> (6437d442-6fb5-49ba-bbdb-19c2606520980)" (The issuing CA may wish to be able to extract the database key or subscriber ID from the commonName. Since only the issuing CA would need to parse the commonName, the database key and the source of entropy (e.g., a UUID) could be separated in any way the CA wants, as long as it conforms to the rules for PrintableString. The separator could be a space character, parenthesis, hyphen, slash, question mark, etc.) 🫧

9. Operational Considerations for Profile Agility ✨

okay so this profile says relying parties (RPs) MUST reject certificates or CRLs that don't conform to it 🙅‍♀️ bestie, that includes certs with prohibited extensions even if they're otherwise valid under [RFC5280]. (For the rest of this section, "certificate" means both certificates and CRLs 💖) This means any change to the profile, like extensions, permitted attributes, optional fields, or field encodings, won't be backward compatible 😭 in a general PKI that would cause serious chaos, but the RPKI has a few things going for it that make changes way less painful 🫶

here's the big thing: every RP in the RPKI needs access to every certificate issued by the CAs in the system 👀 so any important update has to be supported by ALL CAs and RPs, or different RPs end up seeing different RPKI data 💀 which is not it. incremental changes need super careful coordination 🧚 and it would NOT be appropriate to add a new extension, or start using an existing standard extension, for a security-relevant purpose piece by piece 🙅‍♀️

you might think the "critical" flag in X.509 extensions could fix this, but nope 🥲 it isn't comprehensive and doesn't solve the problem of adding a new security-critical extension (since that extension still has to be supported universally). also, some standard extensions can be critical or non-critical at the issuer's discretion, but others are always non-critical, and there's no criticality concept for attributes inside a name or optional fields inside a field or extension. so the critical flag is not the answer 🙈

in typical PKI there are few CAs and tons of RPs 📊 but in the RPKI basically every CA is also an RP ✨ so the entities that have to change to issue certs in a new format are the same ones that have to change to accept them. CA/RP coordination is already tightly linked, literally 💅 there is one important exception though: small ISPs and holders of provider-independent allocations are expected to use managed CA services from Regional Internet Registries (RIRs) and maybe wholesale ISPs 🌸 that cuts down on how many CA implementations exist and makes issuance changes easier. those entities will also probably use RP software from their managed CA provider, which means fewer RP implementations too 🎀 and lots of small ISPs (and provider-independent holders) use default routes, so they don't need to do RP validation of RPKI data at all 🦋

widely available PKI RP software doesn't cache large numbers of certificates, which the RPKI really needs 😤 it also doesn't process manifest or ROA data structures, which are essential parts of the RPKI repository system 💔 experience shows it handles revocation status data poorly too. so existing RP software isn't adequate for the RPKI 🙅‍♀️ some open source tools (like OpenSSL and cryptlib) can be building blocks for an RPKI RP implementation though 🧱 so it's expected that RPs will use software designed specifically for the RPKI, available from a limited number of open sources. several RIRs and two companies are already providing that software 🔥 which makes it feasible to coordinate changes among a small number of developers/maintainers 👑

if the resource certificate profile ever changes, for example by adding a new extension or changing the allowed name attributes or their encoding, deployment will go through the following procedure 🗺️ the model is analogous to the one in [RPKI-ALG], just simpler ✨

a new document will be issued as an update to this RFC 📄 the CP for the RPKI [RFC6484] will be updated to reference the new certificate profile 💜 the new CP will define a new policy OID for certificates issued under the new profile, and it will also define a transition timeline to the new certificate (CRL) format 🗓️ that timeline has 3 phases, each with associated dates:

Phase 1. At the end of phase 1, all RPKI CAs MUST be capable of issuing certificates under the new profile, if a subject requests it 🙌 any certificate issued under the new format will contain the new policy OID 🏷️
Phase 2. During phase 2, CAs MUST issue certificates under the new profile, and these certificates MUST coexist with certificates issued under the old format 🤝 (CAs will keep issuing certificates under the old OID/format too 💅) the old and new certificates MUST be identical, except for the policy OID and any new extensions, encodings, etc. ✨ the new certificates and their associated signed objects will coexist in the RPKI repository system during this phase, similar to what an algorithm transition for the RPKI requires [RPKI-ALG] 🔄 during this phase, Relying parties MAY use either the old or the new certificate formats when processing signed objects retrieved from the RPKI repository system 🦋 an RP that chooses to process both formats will get the same values for all certificate fields that overlap between old and new 🫶 so if either certificate format is verifiable, the RP accepts the data from that certificate 🌈 this lets CAs start issuing new-format certs before every RP is ready to process them 🎀
Phase 3. At the beginning of phase 3, all relying parties MUST be capable of processing certificates under the new format 🙌 during this phase, CAs will issue new certificates only under the new format 🌸 certificates issued under the old OID will be replaced with certificates carrying the new policy OID 💖 and the repository system will no longer need to match old and new certificates under the different formats 🧹

at the end of phase 3, every certificate under the old OID will have been replaced 🥹 the resource certificate profile RFC will then be replaced to remove support for the old certificate format, and the CP will be replaced to remove the reference to the old policy OID and to the old resource certificate profile RFC 🧽 the system will have returned to a new, steady state 👑✨

10. Security Considerations 🔐

the Security Considerations of [RFC5280] and [RFC3779] apply to resource certificates 🛡️ and the Security Considerations of [RFC2986] and [RFC4211] apply to resource certificate certification requests 📝

⚠️ bestie, this part is serious. a resource certificate PKI cannot, on its own, resolve any ambiguity about uniqueness of assertions of rights of use when two or more valid certificates cover the same resource 😱 if certificate issuance is aligned with the status of resource allocations and assignments, then the info in a certificate is no better than the info in the allocation and assignment databases 💀

this profile requires that the key used to sign an issued certificate be the same key used to sign the CRL that can revoke that certificate 🔑 which implies the certification path used to validate the certificate's signature is the same one used to validate the CRL's signature 🛤️ this is a tighter constraint than in X.509 PKIs, and there may be risk in using a path validation implementation that can use separate validation paths for a certificate and its corresponding CRL 🙈 also, if subject name collisions happen in the RPKI because CAs didn't follow the guidelines here about ensuring sufficient entropy when building subject names 😬 and an RP uses a path validation construction implementation that doesn't conform to this RPKI profile, then those collisions can make the RP conclude that an otherwise valid certificate has been revoked 😭 that's a whole vibe of danger, so please be careful 🫠

11. Acknowledgements 🫶

the authors want to give a special shoutout to Stephen Kent 👑 for reviewing this document and proposing tons of the text that ended up in it 🌟 the authors also thank Sandy Murphy, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo Patara, and Rob Austein for their help preparing and reviewing this document 💜 and it also reflects review comments from Roque Gagliano, Sean Turner, and David Cooper 🎀 thank you all, you're iconic 🥰

12. References 📚

12.1. Normative References

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2986]   Nystrom, M. and B. Kaliski, "PKCS #10: Certification
            Request Syntax Specification Version 1.7", RFC 2986,
            November 2000.

[RFC3779]   Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
            Addresses and AS Identifiers", RFC 3779, June 2004.

[RFC4211]   Schaad, J., "Internet X.509 Public Key Infrastructure
            Certificate Request Message Format (CRMF)", RFC 4211,
            September 2005.

[RFC5280]   Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
            Housley, R., and W. Polk, "Internet X.509 Public Key
            Infrastructure Certificate and Certificate Revocation
            List (CRL) Profile", RFC 5280, May 2008.

[RFC5781]   Weiler, S., Ward, D., and R. Housley, "The rsync URI
            Scheme", RFC 5781, February 2010.

[RFC6484]   Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
            Policy (CP) for the Resource Public Key Infrastructure
            (RPKI)", BCP 173, RFC 6484, February 2012.

[RFC6485]   Huston, G., "The Profile for Algorithms and Key Sizes for
            Use in the Resource Public Key Infrastructure (RPKI)",
            RFC 6485, February 2012.

[X.509]     ITU-T, "Recommendation X.509: The Directory -
            Authentication Framework", 2000.

[X.680]     ITU-T, "Recommendation X.680 (2002) | ISO/IEC 8824-
            1:2002, Information technology - Abstract Syntax Notation
            One (ASN.1): Specification of basic notation", 2002.

12.2. Informative References 📚

[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
[RPKI-ALG] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for RPKI", Work in Progress, November 2011.

Appendix A. Example Resource Certificate 🎀

Okay, here's an example resource certificate so you can see what one actually looks like in the wild 👀✨

Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer

Data:
  Version: 3 (0x2)
  Serial: 1500 (0x5dc)
  Signature Algorithm: SHA256WithRSAEncryption
  Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s
  Validity
   Not Before: Oct 25 12:50:00 2008 GMT
    Not After : Jan 31 00:00:00 2010 GMT
  Subject: CN=A91872ED
  Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (2048 bit)
    Modulus (2048 bit):
      00:bb:fb:4a:af:a4:b9:dc:d0:fa:6f:67:cc:27:39:
      34:d1:80:40:37:de:88:d1:64:a2:f1:b3:fa:c6:7f:
      bb:51:df:e1:c7:13:92:c3:c8:a2:aa:8c:d1:11:b3:
      aa:99:c0:ac:54:d3:65:83:c6:13:bf:0d:9f:33:2d:
      39:9f:ab:5f:cd:a3:e9:a1:fb:80:7d:1d:d0:2b:48:
      a5:55:e6:24:1f:06:41:35:1d:00:da:1f:99:85:13:
      26:39:24:c5:9a:81:15:98:fb:5f:f9:84:38:e5:d6:
      70:ce:5a:02:ca:dd:61:85:b3:43:2d:0b:35:d5:91:
      98:9d:da:1e:0f:c2:f6:97:b7:97:3e:e6:fc:c1:c4:
      3f:30:c4:81:03:25:99:09:4c:e2:4a:85:e7:46:4b:
      60:63:02:43:46:51:4d:ed:fd:a1:06:84:f1:4e:98:
      32:da:27:ee:80:82:d4:6b:cf:31:ea:21:af:6f:bd:
      70:34:e9:3f:d7:e4:24:cd:b8:e0:0f:8e:80:eb:11:
      1f:bc:c5:7e:05:8e:5c:7b:96:26:f8:2c:17:30:7d:
      08:9e:a4:72:66:f5:ca:23:2b:f2:ce:54:ec:4d:d9:
      d9:81:72:80:19:95:57:da:91:00:d9:b1:e8:8c:33:
      4a:9d:3c:4a:94:bf:74:4c:30:72:9b:1e:f5:8b:00:
      4d:e3
    Exponent: 65537 (0x10001)
  X509v3 extensions:
    X509v3 Subject Key Identifier:
      F4:97:E0:00:47:2A:ED:0F:B8:EC:8C:0C:0B:90:89:
      20:9A:FA:10:9B

    X509v3 Authority Key Identifier:
      keyid:09:53:D0:4A:05:24:2F:2E:E9:39:77:4D:79:
      55:86:BE:71:57:FF:4B

    X509v3 Key Usage: critical
      Certificate Sign, CRL Sign

    X509v3 Basic Constraints: critical
      CA:TRUE

    X509v3 CRL Distribution Points:
      URI:rsync://rpki.apnic.net/repository/A3C38A24
          D60311DCAB08F31979BDBE39/CVPQSgUkLy7pOXdNe
          VWGvnFX_0s.crl

    Authority Information Access:
       CA Issuers - URI:rsync://rpki.apnic.net/repos
          itory/8BDFC7DED5FD11DCB14CF4B1A703F9B7/CVP
          QSgUkLy7pOXdNeVWGvnFX_0s.cer

    X509v3 Certificate Policies: critical
       Policy: 1.3.6.1.5.5.7.14.2

    Subject Information Access:
       CA Repository - URI:rsync://rpki.apnic.net/mem
           ber_repository/A91872ED/06A83982887911DD81
           3F432B2086D636/
       Manifest - URI:rsync://rpki.apnic.net/member_r
           epository/A91872ED/06A83982887911DD813F432
           B2086D636/9JfgAEcq7Q-47IwMC5CJIJr6EJs.mft

     sbgp-autonomousSysNum: critical
       Autonomous System Numbers:
         24021
         38610
         131072
         131074

     sbgp-ipAddrBlock: critical
       IPv4:
         203.133.248.0/22
         203.147.108.0/23

Signature Algorithm: sha256WithRSAEncryption
    51:4c:77:e4:21:64:80:e9:35:30:20:9f:d8:4b:88:60:b8:1f:
    73:24:9d:b5:17:60:65:6a:28:cc:43:4b:68:97:ca:76:07:eb:
    dc:bd:a2:08:3c:8c:56:38:c6:0a:1e:a8:af:f5:b9:42:02:6b:
    77:e0:b1:1c:4a:88:e6:6f:b6:17:d3:59:41:d7:a0:62:86:59:
    29:79:26:76:34:d1:16:2d:75:05:cb:b2:99:bf:ca:c6:68:1b:
    b6:a9:b0:f4:43:2e:df:e3:7f:3c:b3:72:1a:99:fa:5d:94:a1:
    eb:57:9c:9a:2c:87:d6:40:32:c9:ff:a6:54:b8:91:87:fd:90:
    55:ef:12:3e:1e:2e:cf:c5:ea:c3:4c:09:62:4f:88:00:a0:7f:
    cd:67:83:bc:27:e1:74:2c:18:4e:3f:12:1d:ef:29:0f:e3:27:
    00:ce:14:eb:f0:01:f0:36:25:a2:33:a8:c6:2f:31:18:22:30:
    cf:ca:97:43:ed:84:75:53:ab:b7:6c:75:f7:2f:55:5c:2e:82:
    0a:be:91:59:bf:c9:06:ef:bb:b4:a2:71:9e:03:b1:25:8e:29:
    7a:30:88:66:b4:f2:16:6e:df:ad:78:ff:d3:b2:9c:29:48:e3:
    be:87:5c:fc:20:2b:df:da:ca:30:58:c3:04:c9:63:72:48:8c:
    0a:5f:97:71

Appendix B. Example Certificate Revocation List 💜

And here's an example Certificate Revocation List, the little "these are the naughty ones" file 🙈

CRL Name: q66IrWSGuBE7jqx8PAUHAlHCqRw.crl
Data:
  Version: 2
  Signature Algorithm:
    Hash: SHA256, Encryption: RSA
  Issuer: CN=Demo Production APNIC CA - Not for real use,
    E=ca@apnic.net
  This Update: Thu Jul 27 06:30:34 2006 GMT
  Next Update: Fri Jul 28 06:30:34 2006 GMT
  Authority Key Identifier: Key Identifier:
    ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05:
    07:02:51:c2:a9:1c
  CRLNumber: 4
  Revoked Certificates: 1
    Serial Number: 1
    Revocation Date: Mon Jul 17 05:10:19 2006 GMT
    Serial Number: 2
    Revocation Date: Mon Jul 17 05:12:25 2006 GMT
    Serial Number: 4
    Revocation Date: Mon Jul 17 05:40:39 2006 GMT
  Signature:
    b2:5a:e8:7c:bd:a8:00:0f:03:1a:17:fd:40:2c:46:
    0e:d5:64:87:e7:e7:bc:10:7d:b6:3e:39:21:a9:12:
    f4:5a:d8:b8:d4:bd:57:1a:7d:2f:7c:0d:c6:4f:27:
    17:c8:0e:ae:8c:89:ff:00:f7:81:97:c3:a1:6a:0a:
    f7:d2:46:06:9a:d1:d5:4d:78:e1:b7:b0:58:4d:09:
    d6:7c:1e:a0:40:af:86:5d:8c:c9:48:f6:e6:20:2e:
    b9:b6:81:03:0b:51:ac:23:db:9f:c1:8e:d6:94:54:
    66:a5:68:52:ee:dd:0f:10:5d:21:b8:b8:19:ff:29:
    6f:51:2e:c8:74:5c:2a:d2:c5:fa:99:eb:c5:c2:a2:
    d0:96:fc:54:b3:ba:80:4b:92:7f:85:54:76:c9:12:
    cb:32:ea:1d:12:7b:f8:f9:a2:5c:a1:b1:06:8e:d8:
    c5:42:61:00:8c:f6:33:11:29:df:6e:b2:cc:c3:7c:
    d3:f3:0c:8d:5c:49:a5:fb:49:fd:e7:c4:73:68:0a:
    09:0e:6d:68:a9:06:52:3a:36:4f:19:47:83:59:da:
    02:5b:2a:d0:8a:7a:33:0a:d5:ce:be:b5:a2:7d:8d:
    59:a1:9d:ee:60:ce:77:3d:e1:86:9a:84:93:90:9f:
    34:a7:02:40:59:3a:a5:d1:18:fb:6f:fc:af:d4:02:
    d9

Authors' Addresses 🫶

Meet the APNIC crew who put this together 💖

Geoff Huston
APNIC

EMail: gih@apnic.net
URI:   http://www.apnic.net


George Michaelson
APNIC

EMail: ggm@apnic.net
URI:   http://www.apnic.net


Robert Loomans
APNIC

EMail: robertl@apnic.net
URI:   http://www.apnic.net

That's the whole RFC, bestie! 🌈✨ We made it through all six parts 😭💅

📦 where this page comes from

ietf: rfc6487 2012-02
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms