Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures
updates
Extracted elements (28)
Attributes that maintain referential integrity in the database (such as mnt-by, admin-c, tech-c) are excluded from mandatory signing sets because they can change without modification to the signed object. Including them would create a false sense of security; they should only be signed when full object integrity protection is explicitly desired.
Strict canonicalization rules are required because destination databases may transform submitted data after signing (e.g., notational changes to IP prefixes, auto-modification of "changed" attributes, different line endings across systems), which would otherwise cause signature verification to fail.
The signature format was adapted from DomainKeys Identified Mail (DKIM, RFC 6376) because an RPSL object closely resembles an SMTP header in structure. This made DKIM's per-attribute signing approach a natural fit for RPSL.
The specification allows the object maintainer to select which attributes are covered by the signature, enabling important attributes to be signed while excluding database-managed or operationally irrelevant ones. The object type determines only the minimum required set.
The certificate generated for RPSL signing omits the Subject Information Access (SIA) extension mandated by RFC 6487, because that extension requires an rsync URI for the accessLocation and RPSL does not currently support database access via rsync.
This specification has a limitation for route[6] objects: only a single signature per object is supported. This means route[6] objects where one resource holder holds the ASN and another holds the prefix cannot both be properly signed under this version of the specification.
While this mechanism mandates RPKI for certificate distribution, it is not dependent on RPKI for correct operation. Equivalent functionality can be achieved with a traditional CA using RFC 3779 extensions and appropriate trust anchor material.
Before signing or verifying, canonicalization MUST be applied: comments ('#') MUST be omitted; trailing whitespace MUST be omitted; multi-line attributes MUST be collapsed to single lines; tab characters MUST become spaces; multiple whitespaces MUST collapse to one space; all line endings MUST become '\n'.
Canonicalization requires that date/time fields be converted to UTC RFC 3339 format, AS numbers be represented in ASPLAIN syntax (RFC 5396), IPv6 addresses conform to RFC 5952 canonical form, and IPv4 addresses use the ipv4-address type from RPSL (RFC 2622). All IP prefixes MUST use CIDR notation (RFC 4632).
During signature creation, the signer MUST: select attributes to sign (at minimum the required set for the object type), arrange them per the "a" field order, construct the "signature" attribute with an empty "b" field, apply canonicalization, compute the signature, base64-encode it into "b", and append the attribute to the object.
During signature validation, the verifier MUST: check syntax of the "signature" attribute, fetch and validate the certificate per RFC 6487, verify the signed attribute list includes the minimum required set, apply canonicalization, then verify the cryptographic signature using the algorithm in "m", the public key from "c", and the value in "b".
If the signed attribute list in a signature does not include the mandatory minimum set for the object type, the verifier MUST reject the signature and treat the object as a regular, unsigned RPSL object.
The certificate reference field "c" MUST be a URL of type "rsync" (RFC 5781) or "http(s)" (RFC 7230) pointing to a specific resource certificate in an RPKI repository. Any non-URL-safe characters (including ";" and "+") must be URL encoded.
The certificate referenced in the "c" field MUST be an end-entity (non-CA) certificate, MUST conform to the X.509 PKIX Resource Certificate profile (RFC 6487), and MUST have RFC 3779 extensions that cover the Internet number resource in the signed attributes.
The newly constructed "signature" attribute is always included in the list of signed attributes. The signature under construction MUST NOT include signature attributes already present in the object (i.e., only one signature at a time is created).
The signature method field "m" MUST specify hash and signature algorithms following RFC 6485 (the RPKI algorithm profile). Algorithms are referenced by their ASCII names within the signature attribute.
The signature value field "b" MUST be the last field in the signature attribute, and its value is the base64-encoded (RFC 4648 Section 4) digital signature computed over the canonicalized object.
The signer of an RPSL object MUST possess a relevant resource certificate demonstrating them as the legitimate holder of the Internet number resource. The certificate's RFC 3779 extensions MUST cover the resources in the primary key of the signed object.
The time of signing field "t" and the optional expiration field "x" MUST use Internet Date/Time format (RFC 3339) in UTC (time-offset always "Z").
The version field "v" of the signature attribute MUST be set to "rpkiv1". This field MAY appear first to simplify parsing. All remaining attribute semantics are defined by the version field value.
Mandatory fields of the "signature" attribute are: version ("v"), certificate URL ("c"), signature method ("m"), time of signing ("t"), signed attributes list ("a"), and the signature value ("b"). The "b" field MUST be last. Optional field: expiration time ("x").
Signable object types are: as-block (must sign: as-block, signature), aut-num (must sign: aut-num, as-name, member-of, import, mp-import, export, mp-export, default, mp-default, signature), inet[6]num (must sign: inet[6]num, netname, country, status, signature), and route[6] (must sign: route[6], origin, holes, member-of, signature).
The digital signature associated with an RPSL object is stored as a new "signature" attribute consisting of mandatory and optional fields structured as name-value pairs separated by semicolons and whitespace. The "name" is a single ASCII character identifier; mandatory fields MUST appear exactly once, optional fields at most once.
The validity time interval of a signature is the intersection of: the certificate's own validity period, the "not before" time in field "t", and (if present) the "not after" time in field "x". When multiple signatures exist, these checks apply individually to each.
A maintainer may include attributes in the signature that reference resources not covered by the resource certificate used to sign — potentially asserting use of resources the maintainer is not authorized for. Verifiers should be aware this authorization gap exists.
RPSL objects in the IRR are public; no confidentiality is needed. Integrity and authenticity can be verified via the digital signature and referenced certificate. Implementers MUST follow certificate validation steps from RFC 6487, and RFC 3779 security considerations apply.
This digital signature mechanism does not preclude monkey-in-the-middle attacks: an adversary can intercept RPSL object transfers, delete the signature attribute, modify contents, or drop objects destined for the requester. Channel security must be provided separately.
A signed RPSL object contains a "signature" attribute with value of the form: "v=rpkiv1; c=<URL>; m=<algorithm>; t=<RFC3339-UTC>; a=<attr1>+<attr2>+...; b=<base64>". The "a" field separates attribute names with "+"; the "b" field carries the base64-encoded signature and is always last.