200 lines
9.9 KiB
Markdown
200 lines
9.9 KiB
Markdown
|
|
---
|
|
|
|
**Internet-Draft** Yirong Yu
|
|
**Intended status: Standards Track** Zhongguancun Labortary
|
|
**Expires: [Date, e.g., October 2026]** April 2026
|
|
|
|
# A Profile for Resource Public Key Infrastructure (RPKI) Canonical Input Representation (CIR)
|
|
## draft-yirong-sidrops-rpki-cir-00
|
|
|
|
### Abstract
|
|
|
|
This document specifies a Canonical Input Representation (CIR) content type for use with the Resource Public Key Infrastructure (RPKI). While the Canonical Cache Representation (CCR) profiles the *validated* output state of a Relying Party (RP), CIR is a DER-encoded data interchange format used to represent the exact, *unvalidated* raw input data fetched by an RP at a particular point in time. The CIR profile provides a deterministic "world view" snapshot, enabling advanced operational capabilities such as differential testing, failure path debugging, and highly accurate historical black-box replay of RPKI validation logic.
|
|
|
|
### Status of This Memo
|
|
|
|
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
|
|
|
|
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at [https://datatracker.ietf.org/drafts/current/](https://datatracker.ietf.org/drafts/current/).
|
|
|
|
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
|
|
|
|
### Table of Contents
|
|
|
|
1. Introduction
|
|
1.1. Requirements Language
|
|
2. Motivation and Architecture
|
|
3. The Canonical Input Representation Content Type
|
|
4. The Canonical Input Representation Content
|
|
4.1. version
|
|
4.2. metaInfo
|
|
4.3. BaseCIR Fields
|
|
4.4. DeltaCIR Fields
|
|
5. Operational Considerations
|
|
5.1. Differential Testing and Historical Replay
|
|
5.2. Delta Compression for Archival
|
|
6. Security Considerations
|
|
7. IANA Considerations
|
|
8. References
|
|
|
|
---
|
|
|
|
### 1. Introduction
|
|
|
|
This document specifies a Canonical Input Representation (CIR) content type for use with the Resource Public Key Infrastructure (RPKI).
|
|
|
|
A Relying Party (RP) fetches RPKI objects from publication points using protocols such as rsync [RFC5781] or RRDP [RFC8182] prior to executing cryptographic validation. While the Canonical Cache Representation (CCR) [draft-ietf-sidrops-rpki-ccr] accurately describes the subset of objects that successfully passed validation, it inherently omits objects that were rejected due to format errors, invalid signatures, or expired timestamps (survivorship bias).
|
|
|
|
CIR records the precise mapping of object URIs to their cryptographic hashes *before* validation occurs. By decoupling the network transport layer from the validation layer, CIR allows researchers and operators to reconstruct the exact physical file tree (the "dirty inputs") perceived by an observation point.
|
|
|
|
#### 1.1. Requirements Language
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
|
|
|
|
### 2. Motivation and Architecture
|
|
|
|
CIR is designed to solve the "time paradox" and "state desynchronization" problems inherent to RPKI historical archiving. It defines two distinct operational modes:
|
|
|
|
* **Base CIR**: A complete snapshot of all fetched Trust Anchor Locators (TALs) and RPKI objects, typically generated by an RP immediately after a synchronization cycle.
|
|
* **Delta CIR**: A compressed representation generated by offline archival processes, describing the additions, modifications, and deletions between two chronological Base CIR snapshots.
|
|
|
|
### 3. The Canonical Input Representation Content Type
|
|
|
|
The content of a CIR file is an instance of `ContentInfo`.
|
|
|
|
The `contentType` for a CIR is defined as `id-ct-rpkiCanonicalInputRepresentation`, with Object Identifier (OID) `[TBD-OID]`.
|
|
|
|
The content is an instance of `RpkiCanonicalInputRepresentation`.
|
|
|
|
### 4. The Canonical Input Representation Content
|
|
|
|
The content of a Canonical Input Representation is formally defined using ASN.1. To ensure absolute deterministic serialization, CIR MUST be encoded using Distinguished Encoding Rules (DER, [X.690]).
|
|
|
|
```asn.1
|
|
RpkiCanonicalInputRepresentation-2026
|
|
{ iso(1) member-body(2) us(840) rsadsi(113549)
|
|
pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiCIR-2026(TBD) }
|
|
|
|
DEFINITIONS EXPLICIT TAGS ::=
|
|
BEGIN
|
|
|
|
IMPORTS
|
|
CONTENT-TYPE, Digest
|
|
FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
|
|
;
|
|
|
|
ContentInfo ::= SEQUENCE {
|
|
contentType CONTENT-TYPE.&id({ContentSet}),
|
|
content [0] EXPLICIT CONTENT-TYPE.&Type({ContentSet}{@contentType}) }
|
|
|
|
ContentSet CONTENT-TYPE ::= {
|
|
ct-rpkiCanonicalInputRepresentation, ... }
|
|
|
|
ct-rpkiCanonicalInputRepresentation CONTENT-TYPE ::=
|
|
{ TYPE RpkiCanonicalInputRepresentation
|
|
IDENTIFIED BY id-ct-rpkiCanonicalInputRepresentation }
|
|
|
|
id-ct-rpkiCanonicalInputRepresentation OBJECT IDENTIFIER ::=
|
|
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
|
|
pkcs-9(9) id-smime(16) id-ct(1) cir(TBD) }
|
|
|
|
RpkiCanonicalInputRepresentation ::= CHOICE {
|
|
baseCIR [0] BaseCIR,
|
|
deltaCIR [1] DeltaCIR
|
|
}
|
|
|
|
BaseCIR ::= SEQUENCE {
|
|
version INTEGER DEFAULT 0,
|
|
metaInfo CIRMetaInfo,
|
|
talList SEQUENCE OF URIAndHash,
|
|
objectList SEQUENCE OF URIAndHash
|
|
}
|
|
|
|
DeltaCIR ::= SEQUENCE {
|
|
version INTEGER DEFAULT 0,
|
|
metaInfo CIRMetaInfo,
|
|
talChanges [0] DeltaChanges OPTIONAL,
|
|
objectChanges [1] DeltaChanges
|
|
}
|
|
|
|
DeltaChanges ::= SEQUENCE {
|
|
upserted [0] SEQUENCE OF URIAndHash OPTIONAL,
|
|
removed [1] SEQUENCE OF IA5String OPTIONAL
|
|
}
|
|
|
|
CIRMetaInfo ::= SEQUENCE {
|
|
validationTime GeneralizedTime,
|
|
rpSoftware [0] UTF8String OPTIONAL,
|
|
rpVersion [1] UTF8String OPTIONAL,
|
|
observerID [2] UTF8String OPTIONAL
|
|
}
|
|
|
|
URIAndHash ::= SEQUENCE {
|
|
uri IA5String,
|
|
hash OCTET STRING,
|
|
source [0] SourceType OPTIONAL
|
|
}
|
|
|
|
SourceType ::= ENUMERATED {
|
|
rsync (0),
|
|
rrdp (1),
|
|
https (2),
|
|
erik (3),
|
|
cache (4),
|
|
other (5)
|
|
}
|
|
|
|
END
|
|
```
|
|
|
|
#### 4.1. version
|
|
|
|
The version field contains the format version for the structure. In this version of the specification, it MUST be `0`.
|
|
|
|
#### 4.2. metaInfo
|
|
|
|
The `metaInfo` structure provides crucial temporal and environmental context:
|
|
* **validationTime**: Contains a `GeneralizedTime` indicating the moment the synchronization concluded. This timestamp is REQUIRED, as it is strictly necessary to freeze the system clock when replaying RPKI validation logic to evaluate time-sensitive object expiration.
|
|
* **rpSoftware / rpVersion / observerID**: OPTIONAL metadata to identify the specific software and observation vantage point generating the CIR.
|
|
|
|
#### 4.3. BaseCIR Fields
|
|
|
|
* **talList**: A sequence of `URIAndHash` representing the Trust Anchor Locators used as the root of validation.
|
|
* **objectList**: A sequence of `URIAndHash` representing every raw file fetched by the RP. The `uri` MUST be the absolute logical address (e.g., `rsync://...`), and the `hash` MUST be the SHA-256 digest of the raw file.
|
|
* **source**: An OPTIONAL enumerated value indicating the network transport or cache layer from which the file was successfully obtained (e.g., `rrdp`, `rsync`).
|
|
|
|
#### 4.4. DeltaCIR Fields
|
|
|
|
To support compact archival, `DeltaCIR` describes changes relative to a preceding `BaseCIR` or `DeltaCIR`:
|
|
* **upserted**: A sequence of `URIAndHash` for newly discovered objects or objects where the URI remained identical but the cryptographic Hash changed.
|
|
* **removed**: A sequence of `IA5String` containing URIs that were present in the previous snapshot but are no longer observed.
|
|
|
|
### 5. Operational Considerations
|
|
|
|
#### 5.1. Differential Testing and Historical Replay
|
|
|
|
Because CIR captures the global input state *regardless* of object validity, it allows operators to construct an isolated physical sandbox matching the exact network state at `validationTime`. By injecting this state into different RP software implementations (using native functionality like `--disable-rrdp` coupled with local rsync wrappers), operators can perform deterministic differential testing. Discrepancies in the resulting CCR outputs indicate implementation bugs or vulnerabilities in boundary-case handling.
|
|
|
|
#### 5.2. Delta Compression for Archival
|
|
|
|
Given that the global RPKI repository experiences relatively low churn within short timeframes (e.g., 10-minute intervals), `DeltaCIR` significantly reduces storage overhead. Archival systems SHOULD compute `DeltaCIR` sequences from raw `BaseCIR` outputs to facilitate efficient streaming historical replays.
|
|
|
|
### 6. Security Considerations
|
|
|
|
Unlike RPKI signed objects, CIR objects are not cryptographically signed by CAs. They are observational records.
|
|
|
|
CIR explicitly permits the indexing of corrupted, malicious, or malformed ASN.1 objects. Parsers ingesting CIR to reconstruct sandboxes MUST NOT attempt to cryptographically decode or execute the objects referenced by the hashes, but simply treat them as opaque binary blobs to be placed in the file system for the target RP to evaluate.
|
|
|
|
### 7. IANA Considerations
|
|
|
|
IANA is requested to register the media type `application/rpki-cir`, the file extension `.cir`, and the necessary SMI Security for S/MIME Module Identifiers (OIDs), modeled identically to the IANA considerations defined in the CCR specification.
|
|
|
|
### 8. References
|
|
|
|
*[Standard IETF references for RFC 2119, RFC 8174, RFC 6488, RFC 8182, etc. to be populated]*
|
|
|
|
---
|
|
|
|
**Next Step Guidance**:
|
|
If you plan to officially submit this to the IETF SIDROPS working group, you'll need to allocate the `[TBD]` OID placeholders and potentially run the ASN.1 syntax through an official compiler (like `asn1c`) to ensure there are no implicit tagging ambiguities in the `CHOICE` and `OPTIONAL` fields. Would you like me to refine the ASN.1 tagging strategy further? |