A Protocol for Provisioning Resource Certificates
Extracted elements (28)
Strict per-client serialization (one outstanding request at a time) was chosen to reduce the potential for subject and issuer to lose synchronization over issued certificate state, rather than allowing more efficient parallel operation.
The signing-time need not be precisely aligned to a real-time clock; arbitrarily large clock skew is permitted as long as signing times are monotonically non-decreasing between the same originator/recipient pair. This relaxes interoperability requirements for systems with poor clock synchronization.
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; clients should generate an error when receiving such a response.
Errors in message checks 1–6 (CMS well-formedness through signing time) MUST cause the server to generate an HTTP 400 Bad Request response. A version error (check 7) MUST cause the server to generate a Request-Not-Performed error response.
For certificate issuance requests, the client MUST use different key pairs for each distinct resource class. If the server detects that a request uses a key pair already assigned to another resource class, it MUST return error code 1204.
If both the signing-time and binary-signing-time attributes are present, they MUST both represent the same underlying time value. The signing-time attribute may use UTCTime or GeneralizedTime per RFC 5652 Section 11.3.
If the client's certificate has a validity notAfter time different from the resource_set_notafter value in the list response, the client SHOULD request a new certificate for that resource class.
If the resource class is not defined, the server MUST return error 1201. If the client holds no resources in the class, the server MUST return error 1202. Badly formed certificate requests MUST yield error 1203. Offline issuers that cannot respond immediately MUST return error 1104 and SHOULD respond 1101 to repeated requests while processing.
The cert_url in both class and certificate elements MUST include at least one rsync URI. Any comma characters within a URI MUST be escaped as '%2C'.
The certificates field MUST be present and MUST contain the single EE certificate whose private key signed the CMS. This MUST NOT be an RPKI certificate, and SHOULD be a certificate that attests to the identity of the creator. The field MAY also contain CA certificates for path validation.
The crls field MUST be present and MUST contain the current CRL issued by the same CA that issued the EE certificate used to sign the CMS. This field MAY contain CRLs for other CAs covering included CA certificates, but MUST NOT contain any other CRLs.
The protocol requires strictly sequential operation per client: the server MUST NOT accept a client's request unless it has already generated and sent a response to the client's previous request. Parallel requests sharing a common sender attribute MUST be detected and rejected with error code 1101.
The signedAttrs element MUST be present and MUST include the content-type and message-digest attributes. Either the signing-time attribute or the binary-signing-time attribute, or both, MUST be present. Other signed attributes MUST NOT be included, and unsignedAttrs MUST be omitted.
The SignedData version field MUST be 3. The digestAlgorithms set MUST contain exactly one digest algorithm OID selected from those specified in RFC 6485. The SignerInfos set MUST contain only a single SignerInfo object.
The SignerInfo version number MUST be 3, corresponding to the use of SubjectKeyIdentifier for the sid. The sid MUST be the SubjectKeyIdentifier that appears in the EE certificate carried in the CMS certificates field.
When a client receives an 1104 (request scheduled) response, it MAY periodically resubmit the certificate issuance request, but SHOULD limit the frequency to no more than one request per 24-hour interval.
The Certificate Issuance Request (type='issue') carries a PKCS#10 certificate request (Base64-encoded DER) along with optional req_resource_set_as, req_resource_set_ipv4, and req_resource_set_ipv6 attributes specifying the desired resource span. Omitting all req_resource_set attributes requests the full allocated set.
The Certificate Revocation Request (type='revoke') identifies the key pair to retire using class_name and ski (the Base64url-encoded 160-bit SHA-1 hash of the client's public key per RFC 5280 Section 4.2.1.2). The server revokes all matching certificates and withdraws them from the publication repository.
The Request-Not-Performed response (type='error_response') carries a numeric status code and an optional human-readable description element. Error codes range from 1101–1104 (protocol errors), 1201–1204 (issuance errors), 1301–1302 (revocation errors), and 2001 (internal server error).
The Resource Class List Query (type='list') carries no payload and asks the server to return all resources allocated to the client across all resource classes, along with currently issued certificates. The response (type='list_response') includes one class element per resource class where the client holds allocations.
The RPKI certificate provisioning protocol is a simple request/response interaction carried over HTTP POST with content type 'application/rpki-updown'. Both requests and responses are DER-encoded CMS SignedData objects wrapping XML payloads.
IANA registered the 'application/rpki-updown' media type for use exclusively as the content type of RPKI Provisioning Protocol message objects carried over HTTP, as defined in RFC 6492.
The protocol assumes that issuer and subject have exchanged credentials by prior arrangement to establish mutual recognition of digital signatures. The mechanisms for credential exchange and trust anchor establishment are explicitly out of scope for this specification.
The protocol enforces monotonically non-decreasing signing-time values per originator/recipient pair to prevent replay attacks. A message with a signing time in the future creates a permanent lower bound; subsequent valid messages must have signing times at or after the erroneous future value. Resetting signing time requires out-of-band coordination not defined in this specification.
CMS object validation proceeds through five ordered checks: (1) well-formedness of the signed object syntax, (2) signature verification using the EE certificate public key, (3) valid certification path from trust anchor to EE certificate, (4) EE certificate not revoked per the embedded CRL, and (5) signing-time is monotonically non-decreasing relative to prior valid messages from the same originator.
All protocol messages share a common XML envelope with attributes: version (currently '1'), sender (agreed name of sender), recipient (agreed name of recipient), and type ('list', 'list_response', 'issue', 'issue_response', 'revoke', 'revoke_response', or 'error_response').
The CMS content-type is id-signedData (OID 1.2.840.113549.1.7.2). The encapsulated content type (eContentType) is id-ct-xml with OID 1.2.840.113549.1.9.16.1.28, and the eContent field carries the XML protocol message as an OCTET STRING.
The list_response class element includes attributes: class_name (issuer-assigned identifier), cert_url (comma-separated URIs of issuer's CA cert; at least one MUST be an rsync URI), resource_set_as (AS numbers in canonical RFC 3779 form), resource_set_ipv4 (IPv4 prefixes/ranges), resource_set_ipv6 (IPv6 prefixes/ranges in RFC 5952 format), and resource_set_notafter (ISO 8601 UTC datetime).