RFC 6492
A Protocol for Provisioning Resource Certificates
RFC 6492: A Protocol for Provisioning Resource Certificates 🎀
Okay bestie, let's get into it 💖. This is RFC 6492, from the IETF, and it's a Standards Track doc, so it's the real deal ✨. It was written by G. Huston, R. Loomans, and B. Ellacott, with B. Ellacott at APNIC and R. Austein at ISC. It came out in February 2012, and its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🦋.
Abstract 🌸
So this doc is all about how an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") manage their certificate stuff. They do it through a protocol they use to talk to each other 💌. The subject sends requests, and the issuer sends back responses covering certificate issuance, certificate revocation, and certificate status information reports. It's meant to stay limited to Internet Number Resource certificate management, and it's not meant to be part of a bigger, general certificate management framework. Keep it focused, queen 👑.
Status of This Memo
This is an Internet Standards Track document. ✨
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6492 🔗.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document 🧾. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Scope ...........................................................4
3. Protocol Specification ..........................................4
3.1. CMS Profile ................................................5
3.1.1. SignedData Content Type .............................5
3.1.2. CMS Object Validation ..............................10
3.1.3. ASN.1 Specification of the CMS Signed Object .......12
3.2. Common Message Format .....................................14
3.3. Control - Resource Class Query ............................16
3.3.1. Resource Class List Query ..........................16
3.3.2. Resource Class List Response .......................17
3.4. CA - Certificate Issuance .................................21
3.4.1. Certificate Issuance Request .......................21
3.4.2. Certificate Issuance Response ......................24
3.5. Certificate Revocation ....................................24
3.5.1. Certificate Revocation Request .....................25
3.5.2. Certificate Revocation Response ....................26
3.6. Request-Not-Performed Response ............................26
3.7. XML Schema ................................................27
4. Security Considerations ........................................29
5. IANA Considerations ............................................30
5.1. application/rpki-updown ...................................30
6. Acknowledgements ...............................................30
7. References .....................................................31
7.1. Normative References ......................................31
7.2. Informative References ....................................321. Introduction ✨
This doc sets up a framework for certificate management between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject"). The way it works is through a protocol the two parties use to interact 🤝. The subject sends requests, and the issuer answers with responses covering certificate issuance, certificate revocation, and certificate status information reports. The protocol is meant to stay limited to Internet Number Resource certificate management, and it's not designed to be used as part of a more general certificate management framework 💅.
1.1. Terminology
Here's the vocab you need 📖:
- "Internet Number Resource" (or "resource"): what this doc means by Autonomous System (AS) numbers, IP version 4 addresses, and IP version 6 addresses.
- "issuer": an entity taking on the role of resource issuer. An issuer is a Certification Authority (CA), and it can issue resource certificates.
- "subject": an entity taking on the role of resource recipient, meaning it's the subject of a resource certificate. A subject may be issued a CA-enabled certificate, which lets the entity also take on the role of an issuer 🧚.
- "resource class": a collection of resources that an issuer can certify together in a single resource certificate.
- "server": in this client/server protocol, the issuer plays the "server" role.
- "client": in this client/server protocol, the subject plays the "client" role.
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]. Yes, these words are the special ones, so pay attention 🙈.
2. Scope 🦋
This Resource Public Key Infrastructure (RPKI) certificate provisioning protocol gives you a basic set of interactions. A subject can request certificate issuance, revocation, and status information from the issuer, and the issuer keeps its set of issued certificates lined up with the allocation records for each subject. The issuer's resource allocation database is the authoritative source for which resource allocations the issuer may certify for a subject 📂.
A resource recipient (subject) can also take on the role of a resource issuer (issuer) 🔄.
This protocol does not cover:
- signing of objects with keys that are certified by resource certificates, nor the issuance of end-entity certificates.
- the specification of interaction with the issuer's resource allocation database, nor the specification of a protocol to manage the publication repository.
- the interactions between client and server that establish identities, or the exchange of the certificates and validation Public Key Infrastructure (PKI) contexts used in the Cryptographic Message Syntax (CMS) [RFC5652] message exchange.
- the interactions between client and server that allow respective local CMS signing time values to be reset to mutually recognized values.
3. Protocol Specification 💜
This RPKI certificate provisioning protocol is a simple request/response interaction. The client sends a request to the server, and the server generates a matching response 💌.
The protocol runs as an exchange of messages.
Messages go over an HTTP [RFC2616] end-to-end connection. A message exchange starts when the client makes an HTTP POST with a content type of "application/rpki-updown" and the message object as the body. The server's response is also an HTTP response, with the message object in the response body and a response content type of "application/rpki-updown" 🎀. The content of the POST and the server's response are "well-formed" CMS [RFC5652] objects, encoded using the Distinguished Encoding Rules (DER) for ASN.1 [X.509-88], and formatted according to the CMS profile in the next section. CMS is the signing format used to sign the message object. The CMS message includes an end-entity (EE) certificate that's used to validate the CMS digital signature (see Section 3.1.1.4). The certificate chain used to validate the EE certificate MAY be included in the CMS message. If it isn't there, it's assumed the two entities communicated it through mechanisms that this specification doesn't define 🕵️.
The protocol's request/response interaction is assumed to be reliable, which means all requests MUST generate a matching response ✅. The protocol requires sequential operation for each distinct client. The server MUST NOT accept a client's request unless it has generated and sent a response to the client's previous request 🚦. If the client tries to start multiple requests in parallel (that is, multiple concurrent requests with a common sender attribute (see Section 3.2) in the request), the server MUST detect that and reject it with an error response (an error code 1101 response) 🙅♀️.
3.1. CMS Profile 🧁
The format of the CMS object is:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIERThe content-type is the signed-data type of id-data, namely id-signedData, OID = 1.2.840.113549.1.7.2. [RFC5652] 🔢
3.1.1. SignedData Content Type
According to the CMS standard [RFC5652], signed-data content types are the ASN.1 type SignedData:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfoAlso, the SignerInfos set MUST contain only a single SignerInfo object. One signer, one vibe 💅.
3.1.1.1. version
The version is the syntax version number. It MUST be 3, which corresponds to the signerInfo structure having version number 3 🔥.
3.1.1.2. digestAlgorithms
The digestAlgorithms set contains the Object Identifiers (OID)s of the digest algorithm(s) used when signing the encapsulated content. This set MUST contain exactly one digest algorithm OID, and that OID MUST be selected from those specified in [RFC6485]. Exactly one, no more, no less 🌈.
3.1.1.3. encapContentInfo 💌
okay so encapContentInfo is the signed content 🎀 It's a content type identifier paired with the content itself, and it carries the payload of the RPKI certificate provisioning protocol 💖
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER3.1.1.3.1. eContentType 🦋
the eContentType for the RPKI Protocol Message object is id-ct-xml, and its numerical value is 1.2.840.113549.1.9.16.1.28 ✨ the OID is built up in layers, so here's the whole family tree 🌳
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }3.1.1.3.2. eContent 📜
the content of an RPKI XML Protocol Object is a single protocol message, structured according to a defined XML schema. the schema shows up in later sections of this document 🫶 the eContent field of the CMS object is formally defined in ASN.1 like this:
RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message3.1.1.4. certificates 🔐
this field MUST be present, and it MUST contain the single EE certificate for the key pair whose private key was used to sign the CMS 💅 this MUST NOT be an RPKI certificate! it SHOULD be a certificate that's recognized as proving who created the CMS object, so it's giving identity check 🪪
this field MAY contain CA certificates that a relying party MAY use to validate the EE certificate 🌸
3.1.1.5. crls 📃
this field MUST be present 💖 the contents are specified in [RFC5652]. the current Certificate Revocation List (CRL) issued by the same CA that issued the EE certificate of the key pair whose private key was used to sign the CMS MUST be present in this field ✨ this field MAY contain CRLs issued by other CAs covering CA certificates included in the certificates field of the CMS object (see Section 3.1.1.4). but this field MUST NOT contain any other CRLs, no exceptions 🙅♀️
3.1.1.6. SignerInfo 🖊️
SignerInfo is defined in CMS like this:
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }3.1.1.6.1. version 🔢
the version number MUST be 3, which matches the choice of SubjectKeyIdentifier for the sid 🎀
3.1.1.6.2. sid 🆔
the sid is defined as:
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }in this profile, the sid MUST be the SubjectKeyIdentifier that appears in the EE certificate carried in the CMS certificates field 💜
3.1.1.6.3. digestAlgorithm 🧮
the digestAlgorithm MUST consist of the OID of a digest algorithm that conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485] ✨
3.1.1.6.4. signedAttrs 🎀
the signedAttrs field is defined as:
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANYthe signedAttr element MUST be present, and it MUST include the content-type and message-digest attributes [RFC5652]. if either the signing-time [RFC5652] attribute or the binary-signing-time attribute [RFC6019], or both, are present, they MUST also be included as the SignedAttributes. other signed attributes MUST NOT be included 🚫
the signedAttr MUST include only a single instance of any particular attribute. even though the syntax allows for a SET OF AttributeValue, in this profile the attrValues MUST consist of only a single AttributeValue 🫠
3.1.1.6.4.1. Content-Type Attribute 🏷️
the content-type attribute MUST be present. its attrType OID is 1.2.840.113549.1.9.3 💖
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
ContentType ::= OBJECT IDENTIFIERthe attrValues for the content-type attribute MUST match the eContentType in the EncapsulatedContentInfo. this OID value is defined as id-ct-xml and has the numerical value 1.2.840.113549.1.9.16.1.28 🌈
3.1.1.6.4.2. Message-Digest Attribute 🧾
the message-digest attribute MUST be present. its attrType OID is 1.2.840.113549.1.9.4 ✨
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
MessageDigest ::= OCTET STRINGthe attrValues for the message-digest attribute contains the output of the digest algorithm applied to the content being signed, as specified in Section 5.4 of [RFC5652] 🫶
3.1.1.6.4.3. Signing-Time Attribute ⏰
the signing-time attribute MAY be present. its attrType OID is 1.2.840.113549.1.9.5 🦋
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }the signing-time attribute specifies the time, based on the local system clock, when the digital signature was applied to the content 🕰️
guidelines on using UTCTime and GeneralizedTime in the signing-time attribute are in Section 11.3 of [RFC5652] 📚
either the signing-time attribute or the binary-signing-time attribute, or both, MUST be present. if both the signing-time and binary-signing-time attributes are present, they MUST both represent the same underlying time value 👑
3.1.1.6.4.4. Binary-Signing-Time Attribute ⏱️
the binary-signing-time attribute MAY be present. its attrType OID is 1.2.840.113549.1.9.16.2.46 💜
id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 46 }
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)this attribute specifies the time, based on the local system clock, when the digital signature was applied to the content. its precise definition is in [RFC6019] 🧠
either the signing-time or the binary-signing-time attribute, or both, MUST be present. if both the signing-time and binary-signing-time attributes are present, they MUST both represent the same underlying time value 🌸
3.1.1.6.5. signatureAlgorithm Attribute 🔏
the signatureAlgorithm MUST conform to the RPKI Algorithms and Key Size Profile specification [RFC6485] 💅
3.1.1.6.6. signature Attribute ✍️
the signature value is defined as:
SignatureValue ::= OCTET STRINGthe signature characteristics are defined by the digest and signature algorithms 🌈
3.1.1.6.7. UnsignedAttributes Attribute 🚷
unsignedAttrs MUST be omitted. bye bye, unsigned attributes 👋
3.1.2. CMS Object Validation 🕵️♀️
okay bestie, before a recipient of a CMS signed object can use its content, the recipient MUST validate the signed object by verifying that all of the following conditions hold 🫶 a recipient may perform these checks in any order, so no pressure on the sequence 🦋
- the CMS object is well formed, so the signed object syntax complies with this specification. in particular, each of the following must be true 💖
- a. the content-type of the CMS object is SignedData (OID 1.2.840.113549.1.7.2)
- b. the version of the SignedData object is 3.
- c. the certificates field in the SignedData object is present and contains one EE certificate, the SubjectKeyIdentifier field of which matches the sid field of the SignerInfo object.
- d. the crls field in the SignedData object is present.
- e. the version of the SignerInfo is 3.
- f. the signedAttrs field in the SignerInfo object is present and contains one each of the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attribute (OID 1.2.840.113549.1.9.4), and either or both of a single instance of the signing-time attribute (OID 1.2.840.113549.1.9.5) and the binary-signing-time attribute (OID 1.2.840.113549.1.9.16.2.46), and no other attributes.
- g. the eContentType in the EncapsulatedContentInfo is an OID that matches the attrValue in the content-type attribute and has the attrValue of id-ct-xml.
- h. the unsignedAttrs field in the SignerInfo object is omitted.
- i. if both the signing-time attribute and the binary-signing-time attribute are present, then their values represent the same time.
- j. the digestAlgorithm in the SignedData and SignerInfo objects conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
- k. the signatureAlgorithm in the SignerInfo object conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
- l. the signed object is DER encoded.
- the public key of the EE certificate (contained within the CMS signed-data object) can be used to successfully verify the signature on the signed object 🔑
- the EE certificate (contained within the CMS signed-data object) is a valid EE certificate. in particular, there exists a valid certification path from a trust anchor selected by the recipient to this EE certificate 🛤️
- at the current time, the EE certificate is not revoked. this can be determined by confirming that the CRL contained in the crls field of the CMS signed data object is a current valid CRL, issued by the same CA that issued the EE certificate, and the CRL does not list the serial number of the EE certificate 💀
- the time represented by the signing-time attribute or the binary-signing-time attribute is greater than or equal to the time value passed in previously valid CMS objects that were passed from the same originator to this recipient. this signing time value MAY lie within the Validity Time of the EE certificate, but the EE certificate SHOULD NOT be considered invalid if this is not the case when all other checks listed here are passed 🌷
3.1.3. ASN.1 Specification of the CMS Signed Object 💅
okay bestie, here's the ASN.1 spec for the CMS signed object that the RPKI provisioning protocol uses 🎀
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
SignatureValue ::= OCTET STRING
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
ContentType ::= OBJECT IDENTIFIER
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
MessageDigest ::= OCTET STRING
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 46 }
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)3.2. Common Message Format 🦋
the XML template for all messages is kinda described like this (the RELAX NG compact form schema that formally describes the protocol message objects is in Section 3.7) 💅
---------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<message xmlns="http://www.apnic.net/specs/rescerts/up-down/"
version="1"
sender="sender name"
recipient="recipient name"
type="message type">
[payload]
</message>
---------------------------------------------------------------here's what each attribute is about 🌸
version: the value of this attribute is the version of this protocol. This document describes version 1.sender: the value of this attribute is the agreed name of the message sender, as determined between the client and the server by prior arrangement.recipient: the value of this attribute is the agreed name of the message recipient, as determined between the client and the server by prior arrangement.type: the possible values of this attribute are"list","list_response","issue","issue_response","revoke","revoke_response", and"error_response".
conforming parsers MUST reject any document with a version number they do not understand or with any elements or attributes they do not understand. servers must generate an error response when they get a request like that. clients should generate an error when they get a response like that 😭
the encapsulated content of the CMS wrapping is an XML document. the rest of this protocol spec skips the CMS wrapper and only talks about the XML document 🧚
messages get checked with these tests, in this order:
- Check that the CMS is well-formed (see test 1 of Section 3.1.2).
- Check that the XML is well-formed.
- Check that the XML sender and recipient attributes reference a known client and this server's system respectively for a query, and the previously addressed server and this client for a response.
- Verify the digital signature using the public key provided in the certificate carried in the CMS wrapper (see test 2 of Section 3.1.2).
- Validate the CMS-provided certificate using the PKI that has been determined by prior arrangement between the client and server (see test 3 of Section 3.1.2).
- Check that the signing time of the CMS is equal to or greater than the signing time provided in the most recent previous message that this recipient has received from this sender (see test 4 of Section 3.1.2).
- Check that the value of the version number of the message is 1.
these checks SHOULD be applied in the order specified here. ✨
okay the big rules for errors 🔥
any errors encountered while checking items 1 through 7 MUST cause a server to generate an "HTTP 400 Bad Request" response to the HTTP POST operation. an error in step 7 MUST cause the server to generate a "Request-Not-Performed" error response. any errors encountered in these tests by a client SHOULD cause the client to generate an error. 💀
and about rate limits 🍓
a server MAY perform flow control on the rate of processed requests. requests not processed because of that flow control constraint MAY cause the server to generate an "HTTP 503 Service Unavailable" response. an HTTP 503 response MAY include an HTTP Retry-After: header as a hint to the client. 🌈
3.3. Control - Resource Class Query 🌸
this query is how a client asks a server for a list of every resource the server has allocated or assigned to it. bonus: the server's response also includes a copy of the current certificates its CA issued where this client is the certificate's subject 👑
3.3.1. Resource Class List Query 💜
the value of the message "type" attribute for this query is:
type="list"
---------------------------------------------------------------
Payload:
[No message payload is defined for this query]
---------------------------------------------------------------3.3.2. Resource Class List Response 🧚
okay so this is the response, and it's giving very structured 💅 The type value for it is type="list_response".
Payload:
<class class_name="class name"
cert_url="url"
resource_set_as="as resource set"
resource_set_ipv4="ipv4 resource set"
resource_set_ipv6="ipv6 resource set"
resource_set_notafter="datetime"
suggested_sia_head="[directory uri]" >
<certificate cert_url="url"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set" >
[certificate]
</certificate>
...
(repeated for each current certificate where the client
is the certificate's subject)
<issuer>[issuer's certificate]</issuer>
</class>
...
(repeated for each of the issuer's resource class where the
client has been allocated resources)Okay bestie, if the client has been given resources from more than one resource class, the response MUST contain multiple class elements that cover the complete set of the issuer's resource classes where the client actually holds allocated resources 🫶. Any of the issuer's resource classes where the client has nothing allocated MUST NOT be included in the response. Not doing that one 🙅♀️
Quick plot twist: if the issuer has issued several certificates in one resource class signed with different keys (this can happen during a staged issuer-key rollover 👀), only the most recent certificate issued with the currently "active" issuer's key gets listed in the response. Main character energy for the active key only ✨
Each class element describes a set of resources that are certified within the scope of a single certificate. It refers to one resource class and has a common validation path 🦋
class_name: the value here is the issuer-assigned name of the issuer's resource class 🎀
cert_url: in a class element, this is a pointer to the issuer's CA certificate. Basically it's a reference to the immediate superior certificate, which is the CA-enabled certificate where the issuer is the certificate's subject 🌸 The value is a comma-separated list of URIs, and at least one of them MUST be an rsync URI [RFC5781]. Any comma values inside a URI MUST be escaped (%2C). The order of the list can be read by the client as a relative preference for access methods, as expressed by the publisher of this certificate 💜
resource_set_as: in a class element, this is the set of AS numbers and AS number ranges that the issuer has allocated to the client within the scope of this resource class. It's presented in ASCII as a comma-separated list 🍓 The list elements are decimal integer values, and ranges are written as the lowest and highest values with a hyphen in between. Everything uses the canonical order described in [RFC3779], with no leading zeros and no white space or punctuation besides the comma and the hyphen range designator. Example: resource_set_as="123,456-789,123456". If there are no AS numbers in this resource class, the empty AS set is shown as a null string, (""), for this attribute 🙈
resource_set_ipv4: in a class element, this is the set of IPv4 addresses the issuer has allocated to the client within this resource class. It's presented in ASCII as a comma-separated list of elements. Each element is either an address prefix written as <dotted quad>/mask length, or a range written as the lowest and highest values in dotted quad notation with a hyphen delimiter. The list is in canonical order, as described in [RFC3779]. The dotted quad notation has no leading zeros, and the list has no white space or punctuation other than the period, forward slash, hyphen, and comma. Example: resource_set_ipv4="192.0.2.0/26,192.0.2.66-192.0.2.76". If there are no IPv4 addresses in this resource class, the empty IPv4 address set is a null string, ("") 🌈
resource_set_ipv6: in a class element, this is the set of IPv6 addresses the issuer has allocated to the client within this resource class. It's presented in ASCII as a comma-separated list too. Each element is either an address prefix written as <hex nibble sequence>/mask length, or a range written as the lowest and highest values in hex nibble notation with a hyphen delimiter. Trailing zero nibbles get truncated and represented by ::. The list is in canonical order, as described in [RFC3779]. The hex nibble sequence has no leading zeros, and the list has no white space or punctuation other than the colon, forward slash, hyphen, and comma. It also conforms to the canonical format of [RFC5952]. Example: resource_set_ipv6="2001:db8::/48,2001:db8:2::-2001:db8:5::". The XML Schema data type is "http://www.w3.org/TR/xmlschema-2/#hexBinary", and the value is case insensitive, with lower case as the canonical form. If there are no IPv6 addresses in this resource class, the empty IPv6 address set is a null string, ("") 🦋
resource_set_notafter: this value is the date and time that would go into the Validity notAfter field of any new certificate issued for this particular client within this resource class, if the client asks for a new certificate ⏰ The time format follows ISO 8601 [ISO.8601:2004], and it MUST use UTC time written as YYYY-MM-DDThh:mm:ssZ (example: 2007-11-29T04:40:00Z). If the client's certificate has a validity notAfter time that's different from this time, then the client SHOULD request a new certificate to be issued for this resource class. Little reminder to keep your certs fresh, bestie 🫶
suggested_sia_head: (OPTIONAL) 💖 If this field is present, its value is a directory URI pointing to a repository publication point that the server has made available for the client to use when collecting its published products. This specification doesn't cover the protocols the client might use with the operator of that repository publication point to publish objects there, so that's a whole other story 📚
[issuer's certificate]: this is the Base64 encoding of the DER-encoded issuer's CA certificate, which is the CA-enabled certificate where the issuer is the certificate's subject 🎀
Each certificate element describes the most recently issued current certificate where the certificate's subject refers to the client, for each active client key pair. A "current" certificate is one that is non-expired and non-revoked 🌟 If no current certificate has been issued, then no certificate element is to be included in the response.
cert_url: inside a certificate element, this is a pointer to the location where the certificate issuer has published this certificate. It's the issuer's suggestion for the Authority Information Access (AIA) field that the subject should use in subordinate certificates it issues. According to the Resource Certificate Profile [RFC6487], the AIA field is a non-empty list (at least 1 element) of URIs, and one of them MUST be an rsync URI [RFC5781]. The order of URIs in the AIA field can be read as the publisher's relative preference for access methods for this certificate. This cert_url follows that AIA specification. Its value is a comma-separated list of URIs, and one of them MUST be an rsync URI. Any comma values within a URI MUST be escaped (%2C) 🌸
req_resource_set_as: this is the set of AS numbers that were specified in the original certificate request that defined the maximal requested span of the certified AS number set, following the syntax described above. If this attribute was present in the certificate request, then it MUST be present in this response. Otherwise, it MUST NOT be present 🙃
req_resource_set_ipv4: this is the set of IPv4 addresses that were specified in the original certificate request that defined the maximal requested span of the certified IPv4 address set, following the syntax described above. If this attribute was present in the certificate request, then it MUST be present in this response. Otherwise, it MUST NOT be present 🍓
req_resource_set_ipv6: this is the set of IPv6 addresses that were specified in the original certificate request that defined the maximal requested span of the certified IPv6 address set, following the syntax described above. If this attribute was present in the certificate request, then it MUST be present in this response. Otherwise, it MUST NOT be present 💜
[certificate]: this is the Base64 encoding of the DER-encoded certificate 🫧
3.4. CA - Certificate Issuance 🌷
okay this one is the big moment 😭 This query is how the client asks the server's CA to issue a resource certificate for the resources that have been allocated or assigned to the client. If the request gets processed successfully, the server's response includes the issued certificate 🎉
3.4.1. Certificate Issuance Request ✨
okay so this is the request where the client asks for a certificate 🎀 the type is:
type="issue"
Payload:
<request
class_name="class name"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set">
[Certificate request]
</request>bestie, the client MUST use different key pairs for each distinct resource class 🔑 no reusing the same keys across classes, that's a hard rule 🙅♀️
the req_resource_set attributes are optional in the request 🌸
if none of the req_resource_set attributes show up, the request is basically saying "give me everything that matches my current resource allocation" 👑 all of it, the whole vibe
but if you DO include any of them, then any attribute you left out gets read as "the complete set of that resource type that matches my current allocation" ✨ so leaving one out isn't "nothing", it's "everything of that type"
and here's the twist 💀: if an included req_resource_set attribute has the null value (""), that means "no resources of that type, please" 🙈 the empty string is a real answer, not a typo
the issuer keeps a local record of the requested resource sets, tied to the resource class and the client's public key 📝 every new Certificate Issuance Request with the same resource class and the same public key will (re)set that record to the newest values. the latest one wins, periodt 💅
class_name: the value is the server's identifier of a resource class 🧚
req_resource_set_as: (OPTIONAL) the set of AS numbers that define the maximal requested span of the certified AS number set, formatted as per the resource_set_as attribute of the resource class list response 🦋
req_resource_set_ipv4: (OPTIONAL) the set of IPv4 addresses that define the maximal requested span of the certified IPv4 address set, formatted as per the resource_set_ipv4 attribute of the resource class list response 🌈
req_resource_set_ipv6: (OPTIONAL) the set of IPv6 addresses that define the maximal requested span of the certified IPv6 address set, formatted as per the resource_set_ipv6 attribute of the resource class list response 💜
[Certificate request]: the value is the certificate request 📜 it's a Base64 encoded DER version of a request formatted using PKCS#10 [RFC2986]. the certificate request is signed using the private key part of the key pair whose public part is the subject key value in the certification request. the signing algorithm is specified in [RFC6485]. (this signature component is intended to demonstrate proof of possession of the private key, so it's basically the client going "yes I really own this key" 🔐)
the response is a Certificate Issuance Response if the request can be processed online ⚡ but if it can't be handled right away, the server MUST respond with a "Request-Not-Performed" message, using the right error code 🚫 here's the breakdown:
- if the resource class is not defined by the server, then the server MUST return error code 1201 🙃
- if the client holds no resources in a defined resource class, then the server MUST return error code 1202 and not proceed with the request 🛑
- if the certificate request payload is badly formed, then the server MUST return error code 1203 🤒
- if the public key used in the certificate request implies that the client is attempting to use identical key pairs for multiple resource classes, then the server MUST respond with a 1204 error code 🙅♀️ (this is the same no-reuse rule from up top, bestie)
- if the certificate issuer uses an off-line process to undertake certificate issuance, and the server cannot directly respond to the certificate issuance request with an issued certificate, then the certificate issuer MUST respond to the first instance of this request with an error code 1104 to indicate that the request is being processed asynchronously ⏳ subsequent repetitions of this request while the off-line actions are being undertaken SHOULD cause a response with error code 1101 🌀
- in this off-line context, if the certificate issuer figures out during processing that the issued certificate would be identical in all respects to the most recently issued certificate for this client (other than the certificate's serial number), the issuer may choose to respond with the most recently issued certificate and not initiate an off-line certificate issuance request 🧠 no need to redo the whole thing, lowkey smart
note that a client, when receiving a 1104 response to a certificate issuance request, MAY periodically resubmit the request 🔁 if it does, the client MUST receive an error code 1101 response while the request is being processed, and a Certificate Issuance Response once the certificate issuance process has completed ✨ and honestly? a client SHOULD limit the frequency of those repeated requests to no more than 1 request in each 24-hour interval 😭 pls be chill about it
3.4.2. Certificate Issuance Response 🎀
the value of the message type element for this response is:
type="issue_response"
Payload:
<class class_name="class name"
cert_url="url"
resource_set_as="as resource set"
resource_set_ipv4="ipv4 resource set"
resource_set_ipv6="ipv6 resource set" >
<certificate cert_url="url"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set" >
[certificate]
</certificate>
<issuer>[issuer's certificate]</issuer>
</class>if the certificate issuer determines that the issued certificate would be identical in all respects to the most recently issued certificate for this client (other than the certificate's serial number), the issuer may choose to respond with the most recently issued certificate and not issue a new certificate for this request 🦋 same cert, no drama
the definition of the attributes and syntax is the same as the resource class list response ✨ the difference is that this response only references the one named resource class, plus the single certificate issued against the client's public key from the matching certificate request 💅
3.5. Certificate Revocation 💔
this request "retires" a client's key pair 🪦 it asks the server's CA to revoke all certificates for this client (aka where this client is the subject) that contain the matching public key, within the scope of one named resource class. individual certificates CANNOT be revoked within this protocol, so it's all or nothing per key 🙃
3.5.1. Certificate Revocation Request 🌙
the value of the message type element for this request is:
type="revoke"
Payload:
<key class_name="class name"
ski="[encoded hash of the subject public key]" />this command tells the server's CA to immediately mark all issued valid certificates within the named resource class, issued by this issuer with this client's subject name and the provided SKI value, as revoked 🚫 those certs get withdrawn from the publication repository and listed in the server's later CRLs within this resource class. the issuer MUST ensure that all certificates to be revoked were issued with the requesting client as the certificate's subject 🔍 no revoking someone else's stuff, obviously
class_name: the value is the issuer-assigned name of the issuer's resource class 🧚
ski: the value is the encoded hash of the client's public key that is to be revoked. the algorithm for the encoding is to generate the 160-bit SHA-1 hash of the client's public key, as defined in method (1) of Section 4.2.1.2 of [RFC5280], and encode this value using the Base 64 encoding with URL and Filename Safe Alphabet, as defined in Section 5 of [RFC4648] 🔐
3.5.2. Certificate Revocation Response 🌸
the value of the message type element for this response is:
type="revoke_response"
Payload:
<key class_name="class name"
ski="[encoded hash of the subject public key]" />class_name: the value is the issuer-assigned name of the server's resource class 🌈
ski: the value is the encoded hash of the client's public key that is to be revoked. the algorithm for the encoding is to generate the 160-bit SHA-1 hash of the client's public key, as defined in method (1) of Section 4.2.1.2 of [RFC5280], and encode this value using the Base 64 encoding with URL and Filename Safe Alphabet, as defined in Section 5 of [RFC4648] 💜 same recipe as the request, so it matches up
3.6. Request-Not-Performed Response 🚨
the value of the message type element for this response is:
type="error_response"
Payload:
<status>[Code]</status>
<description xml:lang="en-US">[Readable text]</description>every state where an error response is supposed to be generated gets a Request-Not-Performed response 🙅♀️ that covers both detected errors or inconsistencies in the content of the request, and server-side states that stop the request from being performed 💀
description: the value is a text field 📝 this element MAY be present. its value has no defined meaning within the scope of this protocol, and implementations may assume that some form of human-readable text may be used here 🫶 if the HTTP request that triggered this error response includes an Accept-Language header as defined in Section 14.4 of the HTTP/1.1 specification [RFC2616], then the server MAY include a second description element using the highest ranked preferred language of the client 🌍 the en-US description MUST always be included if the element is present, no exceptions 🇺🇸
the error code set is:
Code Value Description
1101 already processing request
1102 version number error
1103 unrecognized request type
1104 request scheduled for processing
1201 request - no such resource class
1202 request - no resources allocated in resource class
1203 request - badly formed certificate request
1204 request - already used key in request
1301 revoke - no such resource class
1302 revoke - no such key
2001 Internal Server Error - Request not performedthe error codes are the whole story here, so bookmark this table 🔖💖
3.7. XML Schema 🎀
okay so the spec drops a RELAX NG compact form schema for version 1 of this protocol, and it's giving very precise 💅. Before the schema, there's a note from [XML] that I need you to see, bestie. It's about the namespace name:
Note: As discussed in [XML], "the namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists)".
So the namespace is basically a unique, stable label, and it's not supposed to be something you can fetch a schema from. Here's the schema itself 🧚
default namespace = "http://www.apnic.net/specs/rescerts/up-down/"
grammar {
resource_set_as = xsd:string { maxLength="512000"
pattern="[\-,0-9]*" }
resource_set_ip4 = xsd:string { maxLength="512000"
pattern="[\-,/.0-9]*" }
resource_set_ip6 = xsd:string { maxLength="512000"
pattern="[\-,/:0-9a-fA-F]*" }
class_name = xsd:token { minLength="1" maxLength="1024" }
ski = xsd:token { minLength="27" maxLength="1024" }
label = xsd:token { minLength="1" maxLength="1024" }
cert_url = xsd:string { minLength="10" maxLength="4096" }
base64_binary = xsd:base64Binary { minLength="4"
maxLength="512000" }
start = element message {
attribute version { xsd:positiveInteger {
maxInclusive="1" } },
attribute sender { label },
attribute recipient { label },
payload
}
payload |= attribute type { "list" }, list_request
payload |= attribute type { "list_response"}, list_response
payload |= attribute type { "issue" }, issue_request
payload |= attribute type { "issue_response"}, issue_response
payload |= attribute type { "revoke" }, revoke_request
payload |= attribute type { "revoke_response"}, revoke_response
payload |= attribute type { "error_response"}, error_response
list_request = empty
list_response = class*
class = element class {
attribute class_name { class_name },
attribute cert_url { cert_url },
attribute resource_set_as { resource_set_as },
attribute resource_set_ipv4 { resource_set_ip4 },
attribute resource_set_ipv6 { resource_set_ip6 },
attribute resource_set_notafter { xsd:dateTime },
attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
pattern="rsync://.+"} }?,
element certificate {
attribute cert_url { cert_url },
attribute req_resource_set_as { resource_set_as }?,
attribute req_resource_set_ipv4 { resource_set_ip4 }?,
attribute req_resource_set_ipv6 { resource_set_ip6 }?,
base64_binary
}*,
element issuer { base64_binary }
}
issue_request = element request {
attribute class_name { class_name },
attribute req_resource_set_as { resource_set_as }?,
attribute req_resource_set_ipv4 { resource_set_ip4 }?,
attribute req_resource_set_ipv6 { resource_set_ip6 }?,
base64_binary
}
issue_response = class
revoke_request = revocation
revoke_response = revocation
revocation = element key {
attribute class_name { class_name },
attribute ski { ski }
}
error_response =
element status { xsd:positiveInteger { maxInclusive="9999" } },
element description { attribute xml:lang { xsd:language },
xsd:string { maxLength="1024" } }*
}4. Security Considerations 🔒
this part is serious, bestie, so pay attention 🙈
okay so this protocol is what keeps resource certificates maintained. The issuer hands them to a subject for resources the issuer has allocated or assigned to that subject [RFC6480]. The protocol assumes the issuer and subject already know each other and have swapped credentials, so they can trust each other's digital signatures on the CMS messages. How that credential exchange actually happens is NOT covered in this spec, so go look elsewhere for that part.
The protocol is a minimal query/response thing. Every query/response transaction has strict serialization, which lowkey helps stop the subject and the issuer from falling out of sync about the state of the issued certificates. Main character energy for keeping things in order 👑
Now the signing-time stuff, which is kinda tricky. Validating protocol objects (Section 3.1.2) means the CMS signing-time value has to be greater than or equal to the time value in the previously valid protocol objects that came from the same originator to the same recipient. If a party accidentally sends a valid message (protocol object) with a signing time in the future, later messages from that party in the same client/server context can use a signing-time value that still follows this rule. So the signing times in later messages are greater than or equal to the signing-time value of the previous valid message. ✨ (Also, it's not a normative requirement that the signing time line up with a time-of-day clock, so arbitrarily large clock skew values are allowed in this protocol message exchange. Wild, right? 🫠) If the client and server want to reset the signing time to a value they've agreed on, then, as noted in Section 2, the interactions needed to do that are NOT part of this protocol.
5. IANA Considerations 📋
IANA has registered the following media type, and it's a very official moment 🎀
application/rpki-updown
5.1. application/rpki-updown 🦋
Here's the registration template, exactly as it's written:
Type name: application
Subtype name: rpki-updown
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI Provisioning Protocol
Message, as defined in this document.
Interoperability considerations: None
Published specification: This document
Applications that use this media type: HTTP [RFC5652]
Additional information:
Magic number(s): None
File extension(s):
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Restrictions on usage: Only to be used as an RPKI Provisioning
Protocol message object type, as defined in this document.
Author: Geoff Huston <gih@apnic.net>
Change controller: Geoff Huston <gih@apnic.net>6. Acknowledgements 🫶
the authors want to give a huge shoutout to Russ Housley, Steve Kent, Randy Bush, George Michaelson, Robert Kisteleki, Tim Bruijnzeels, and Carsten Bormann for their valued contributions to the protocol in this document. Iconic supporting cast 🌈
7. References 📚
7.1. Normative References 🔥
[ISO.8601:2004]
ISO, "ISO 8601:2004 Representation of dates and Times",
2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[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.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for
Representing Date and Time in ASN.1", RFC 6019, September
2010.
[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-88] CCITT, "Recommendation X.509: The Directory-
Authentication Framework", 1988.7.2. Informative References 💜
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, February
2012.
[XML] Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", World
Wide Web Consortium Recommendation REC-xml-names-20091208,
December 2009, <http://www.w3.org/TR/2009/REC-xml-
names-20091208/>.Authors' Addresses 🧚
Geoff Huston
APNIC
EMail: gih@apnic.net
URI: http://www.apnic.net
Robert Loomans
APNIC
EMail: robertl@apnic.net
URI: http://www.apnic.net
Byron Ellacott
APNIC
EMail: bje@apnic.net
URI: http://www.apnic.net
Rob Austein
Internet Systems Consortium
EMail: sra@hactrn.net📦 where this page comes from
- ietf: rfc6492 2012-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms