diff --git a/draft-ymbk-sidrops-6486bis.xml b/draft-ymbk-sidrops-6486bis.xml deleted file mode 100644 index 000e472..0000000 --- a/draft-ymbk-sidrops-6486bis.xml +++ /dev/null @@ -1,974 +0,0 @@ - - - - - - - - - - - - - - - - - Manifests for the Resource Public Key Infrastructure (RPKI) - - - Arrcus, Inc. -
- sra@hactrn.net -
- - - - APNIC -
- - 6 Cordelia St - South Brisbane - QLD 4101 - Australia - - gih@apnic.net -
- - - - Independent -
- kkent@alum.mit.edu -
- - - - New College Florida -
- - 5800 Bay Shore Rd. - Sarasota, FL - 34243 - USA - - mlepinski@ncf.edu -
- - - - - - - - This document defines a "manifest" for use in the Resource Public - Key Infrastructure (RPKI). A manifest is a signed object (file) - that contains a listing of all the signed objects (files) in the - repository publication point (directory) associated with an - authority responsible for publishing in the repository. For each - certificate, Certificate Revocation List (CRL), or other type of - signed objects issued by the authority that are published at this - repository publication point, the manifest contains both the name - of the file containing the object and a hash of the file content. - Manifests are intended to enable a relying party (RP) to detect - certain forms of attacks against a repository. Specifically, if - an RP checks a manifest's contents against the signed objects - retrieved from a repository publication point, then the RP can - detect "stale" (valid) data and deletion of signed objects. - - - - - - - - -
- - - The Resource Public Key Infrastructure (RPKI) makes use of a distributed repository system - to make available a variety of objects - needed by relying parties (RPs). Because all of the objects - stored in the repository system are digitally signed by the - entities that created them, attacks that modify these published - objects are detectable by RPs. However, digital signatures - provide no protection against attacks that substitute "stale" - versions of signed objects (i.e., objects that were valid and have - not expired, but have since been superseded) or attacks that - remove an object that should be present in the repository. To - assist in the detection of such attacks, the RPKI repository - system can make use of a signed object called a "manifest". - - - - A manifest is a signed object that enumerates all the signed - objects (files) in the repository publication point (directory) - that are associated with an authority responsible for publishing - at that publication point. Each manifest contains both the name - of the file containing the object and a hash of the file content, - for every signed object issued by an authority that is published - at the authority's repository publication point. A manifest is - intended to allow an RP to detect unauthorized object removal or - the substitution of stale versions of objects at a publication - point. A manifest also is intended to allow an RP to detect - similar outcomes that may result from a man-in-the-middle attack - on the retrieval of objects from the repository. Manifests are - intended to be used in Certification Authority (CA) publication - points in repositories (directories containing files that are - subordinate certificates and Certificate Revocation Lists (CRLs) - issued by this CA and other signed objects that are verified by - end-entity (EE) certificates issued by this CA). - - - - Manifests are modeled on CRLs, as the issues involved in detecting - stale manifests and potential attacks using manifest replays, - etc., are similar to those for CRLs. The syntax of the manifest - payload differs from CRLs, since RPKI repositories contain objects - not covered by CRLs, e.g., digitally signed objects, such as Route - Origination Authorizations (ROAs). - - -
- - - 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 when, and only when, they appear in all - capitals, as shown here. - - -
- -
- -
- - - A manifest associated with a CA's repository publication point - contains a list of: - - - - - - - the set of (non-expired, non-revoked) certificates issued and - published by this CA, - - - - the most recent CRL issued by this CA, and - - - - all published signed objects that are verifiable using EE - certificates issued by this CA. - - - - - - - - Every RPKI signed object includes, in the Cryptographic Message - Syntax (CMS) wrapper of the object, the - EE certificate used to verify it . Thus, - there is no requirement to separately publish that EE certificate - at the CA's repository publication point. - - - - Where multiple CA instances share a common publication point, as - can occur when an entity performs a key-rollover operation , the repository publication point will contain - multiple manifests. In this case, each manifest describes only - the collection of published products of its associated CA - instance. - - -
- -
- - - A CA's manifest is verified using an EE certificate. The - SubjectInfoAccess (SIA) field of this EE certificate contains the - access method OID of id-ad-signedObject. - - - - The CA MAY choose to sign only one manifest with each generated - private key, and generate a new key pair for each new version of - the manifest. This form of use of the associated EE certificate - is termed a "one-time-use" EE certificate. - - - - Alternatively, the CA MAY elect to use the same private key to - sign a sequence of manifests. Because only a single manifest - (issued under a single CA instance) is current at any point in - time, the associated EE certificate is used to verify only a - single object at a time. As long as the sequence of objects - verified by this EE certificate are published using the same file - name, then this sequential, multiple use of the EE certificate is - also valid. This form of use of an EE certificate is termed a - "sequential-use" EE certificate. - - -
- -
- - - A manifest is an RPKI signed object, as specified in . The RPKI signed object template requires - specification of the following data elements in the context of the - manifest structure. - - -
- - - The eContentType for a manifest is defined as id-ct-rpkiManifest - and has the numerical value of 1.2.840.113549.1.9.16.1.26. - - -
- - - -
-
- -
- - - The content of a manifest is ASN.1 encoded using the - Distinguished Encoding Rules (DER) . The - content of a manifest is defined as follows: - - -
- - - -
- -
- - - The manifestNumber, thisUpdate, and nextUpdate fields are - modeled after the corresponding fields in X.509 CRLs (see - ). Analogous to CRLs, a manifest is - nominally current until the time specified in nextUpdate or - until a manifest is issued with a greater manifest number, - whichever comes first. - - - - If a "one-time-use" EE certificate is employed to verify a - manifest, the EE certificate MUST have a validity period that - coincides with the interval from thisUpdate to nextUpdate, to - prevent needless growth of the CA's CRL. - - - - If a "sequential-use" EE certificate is employed to verify a - manifest, the EE certificate's validity period needs to be no - shorter than the nextUpdate time of the current manifest. - The extended validity time raises the possibility of a - substitution attack using a stale manifest, as described in - . - - - - The data elements of the manifest structure are defined as - follows: - - - - - - - The version number of this version of the manifest - specification MUST be 0. - - - - This field is an integer that is incremented each time a - new manifest is issued for a given publication point. - This field allows an RP to detect gaps in a sequence of - published manifests. - - As the manifest is modeled on the CRL specification, the - ManifestNumber is analogous to the CRLNumber, and the - guidance in for CRLNumber values - is appropriate as to the range of number values that can - be used for the manifestNumber. Manifest numbers can be - expected to contain long integers. Manifest verifiers - MUST be able to handle number values up to 20 octets. - Conforming manifest issuers MUST NOT use number values - longer than 20 octets. - - - - This field contains the time when the manifest was - created. This field has the same format constraints as - specified in for the CRL field of - the same name. - - - - - This field contains the time at which the next scheduled - manifest will be issued. The value of nextUpdate MUST be - later than the value of thisUpdate. The specification of - the GeneralizedTime value is the same as required for the - thisUpdate field. - - If the authority alters any of the items that it has - published in the repository publication point, then the - authority MUST issue a new manifest before the nextUpdate - time. If a manifest encompasses a CRL, the nextUpdate - field of the manifest MUST match that of the CRL's - nextUpdate field, as the manifest will be re-issued when a - new CRL is published. If a "one-time-use" EE certificate - is used to verify the manifest, then when a new manifest - is issued before the time specified in nextUpdate of the - current manifest, the CA MUST also issue a new CRL that - includes the EE certificate corresponding to the old - manifest. - - - - This field contains the OID of the hash algorithm used to - hash the files that the authority has placed into the - repository. The hash algorithm used MUST conform to the - RPKI Algorithms and Key Size Profile specification . - - - - - This field is a sequence of FileAndHash objects. There is - one FileAndHash entry for each currently valid signed - object that has been published by the authority (at this - publication point). Each FileAndHash is an ordered pair - consisting of the name of the file in the repository - publication point (directory) that contains the object in - question and a hash of the file's contents. - - - - -
-
- -
- - - The mandatory content-type attribute MUST have its attrValues - field set to the same OID as eContentType. This OID is - id-ct-rpkiManifest and has the numerical value of - 1.2.840.113549.1.9.16.1.26. - - -
- -
- - - To determine whether a manifest is valid, the RP MUST perform - the following checks in addition to those specified in : - - - - - - - The eContentType in the EncapsulatedContentInfo is - id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). - - - - The version of the rpkiManifest is 0. - - - - In the rpkiManifest, thisUpdate precedes nextUpdate. - - - - - - - - If the above procedure indicates that the manifest is invalid, - then the manifest MUST be discarded and treated as though no - manifest were present. - - -
- -
- - -
- -
- - - For a CA publication point in the RPKI repository system, a CA - MUST perform the following steps to generate a manifest: - - - - - - - If no key pair exists, or if using a "one-time-use" EE - certificate with a new key pair, generate a key pair. - - - - If using a "one-time-use" EE certificate, or if a key pair - was generated in step 1, or if using a "sequential-use" EE - certificate that will expire before the intended nextUpdate - time of this manifest, issue an EE certificate for this key - pair. This EE certificate MUST have - an SIA extension access description field with an - accessMethod OID value of id-ad-signedobject, where the - associated accessLocation references the publication point - of the manifest as an object URL. - - This EE certificate MUST describe its Internet Number - Resources (INRs) using the "inherit" attribute, rather than - explicit description of a resource set (see ). - - In the case of a "one-time-use" EE certificate, the validity - times of the EE certificate MUST exactly match the - thisUpdate and nextUpdate times of the manifest. - - In the case of a "sequential-use" EE certificate, the - validity times of the EE certificate MUST encompass the time - interval from thisUpdate to nextUpdate. - - - - The EE certificate MUST NOT be published in the authority's - repository publication point. - - - - Construct the manifest content. The - manifest content is described in . The manifest's fileList includes the - file name and hash pair for each object issued by this CA - that has been published at this repository publication point - (directory). The collection of objects to be included in - the manifest includes all certificates issued by this CA - that are published at the CA's repository publication point, - the most recent CRL issued by the CA, and all objects - verified by EE certificates that were issued by this CA that - are published at this repository publication point. - - Note that the manifest does not include a self reference - (i.e., its own file name and hash), since it would be - impossible to compute the hash of the manifest itself prior - to it being signed. - - - - Encapsulate the manifest content using the CMS SignedData - content type (as specified ), sign - the manifest using the private key corresponding to the - subject key contained in the EE certificate, and publish the - manifest in the repository system publication point that is - described by the manifest. - - - - In the case of a key pair that is to be used only once, in - conjunction with a "one-time-use" EE certificate, the - private key associated with this key pair MUST now be - destroyed. - - - - - -
- -
- - - A new manifest MUST be issued and published on or before the - nextUpdate time. - - - - An authority MUST issue a new manifest in conjunction with the - finalization of changes made to objects in the publication - point. An authority MAY perform a number of object operations - on a publication repository within the scope of a repository - change before issuing a single manifest that covers all the - operations within the scope of this change. Repository - operators SHOULD implement some form of repository update - procedure that mitigates, to the extent possible, the risk that - RPs that are performing retrieval operations on the repository - are exposed to inconsistent, transient, intermediate states - during updates to the repository publication point (directory) - and the associated manifest. - - - - Since the manifest object URL is included in the SIA of issued - certificates, a new manifest MUST NOT invalidate the manifest - object URL of previously issued certificates. This implies that - the manifest's publication name in the repository, in the form - of an object URL, is unchanged across manifest generation - cycles. - - - - When a CA entity is performing a key rollover, the entity MAY - choose to have two CA instances simultaneously publishing into - the same repository publication point. In this case, there will - be one manifest associated with each active CA instance that is - publishing into the common repository publication point - (directory). - - -
- -
- -
- - - Each RP must determine which signed objects it will use for - validating assertions about INRs and their use (e.g., which ROAs - to use in the construction of route filters). As noted earlier, - manifests are designed to allow an RP to detect manipulation of - repository data, errors by a CA or repository manager, and/or - active attacks on the communication channel between an RP and a - repository. Unless all of the files enumerated in a manifest can - be obtained by an RP during a fetch operation, the fetch is - considered to have failed and the RP MUST retry the fetch later. - - - - suggests (but does not mandate) that the - RPKI model employ fetches that are incremental, e.g., an RP - transfers files from a publication point only if they are - new/changed since the previous, successful, fetch represented in - the RP's local cache. This document avoids language that relies on - details of the underlying file transfer mechanism employed by an - RP and a publication point to effect this operation. Thus the term - "fetch" refers to an operation that attempts to acquire the full - set of files at a publication point, consistent with the - id-ad-rpkiManifest URI extracted from a CA certificate's SIA (see - below). - - - - If a fetch fails, it is assumed that a subsequent fetch will - resolve problems encountered during the fetch. Until such time as - a successful fetch is executed, an RP SHOULD use cached data from - a previous, successful fetch. This response is intended to prevent - an RP from misinterpreting data associated with a publication - point, and thus possibly treating invalid routes as valid, or vice - versa. - - - - The processing described below is designed to cause all RPs with - access to the same local cache and RPKI repository data to achieve - the same results with regard to validation of RPKI data. However, - in operation, different RPs will access repositories at different - times, and some RPs may experience local cache failures, so there - is no guarantee that all RPs will achieve the same results with - regard to validation of RPKI data. - - - - Note that there is a "chicken and egg" relationship between the - manifest and the CRL for a given CA instance. If the EE - certificate for the current manifest is revoked, i.e., it appears - in the current CRL, then the CA or publication point manager has - made a serious error. In this case the fetch has failed; proceed - to . Similarly, if the CRL is not listed - on a valid, current manifest, acquired during a fetch, the fetch - has failed; proceed to , because the CRL - is considered missing. - - - - Note that if a CA and its associated publication point are - operating properly, there will always be exactly one manifest and - one associated CRL at the publication point identified in the CA's - SIA (see below). - - -
- - - For a given publication point, an RP MUST perform a series of - tests to determine which signed object files at the publication - point are acceptable. The tests described below ( to ) are to - be performed using the manifest identified by the - id-ad-rpkiManifest URI extracted from a CA certificate's - SIA. All of the files referenced by the manifest MUST be be - located at the publication point specified by the - id-ad-caRepository URI from the (same) CA certificate's SIA. The - manifest and the files it references MUST reside at the same - publication point. If an RP encounters any files that appear on - a manifest but do not reside at the same publication point as - the manifest the RP MUST treat the fetch as failed, and a - warning MUST be issued (see below). - - - - A manifest SHOULD contain exactly one CRL (.crl) file and it - MUST be at the location specified in the CRLDP in the manifest's - EE certificate. If more than one .crl file appears in the - manifest, the fetch has failed and the RP MUST proceed to ; otherwise proceed to . - - - - Note that, during CA key rollover , - signed objects for two or more different CA instances will - appear at the same publication point. Manifest processing is to - be performed separately for each CA instance, guided by the SIA - id-ad-rpkiManifest URI in each CA certificate. - -
- -
- - - The RP MUST fetch the manifest identified by the SIA - id-ad-rpkiManifest URI in the CA certificate. If an RP cannot - retrieve a manifest using this URI, or if the manifest is not - valid (), an RP MUST treat this as a - failed fetch and, proceed to ; - otherwise proceed to . - -
- -
- - - The RP MUST check that the current time (translated to UTC) is - between thisUpdate and nextUpdate. If the current time lies - within this interval, proceed to . If - the current time is earlier than thisUpdate, the CA has made an - error; this is a failed fetch and the RP MUST proceed to . If the current time is later than - nextUpdate, then the manifest is stale; this is a failed fetch - and RP MUST proceed to ; otherwise - proceed to . - -
- -
- - - The RP MUST acquire all of the files enumerated in the manifest - (fileList) from the publication point. This includes the CRL, - each object containing an EE certificate issued by the CA, and - any subordinate CA and EE certificates. If there are files - listed in the manifest that cannot be retrieved from the - publication point, or if they fail the validity tests specified - in , the fetch has failed and the RP - MUST proceed to ; otherwise, proceed to - . - -
- -
- - - The RP MUST verify that the hash value of each file listed in - the manifest matches the value obtained by hashing the file - acquired from the publication point. If the computed hash value - of a file listed on the manifest does not match the hash value - contained in the manifest, then the fetch has failed and the RP - MUST proceed to ; otherwise proceed to - . - -
- -
- - - If a current manifest contains entries for objects that are not - within the scope of the manifest (), - the fetch has failed and the RP SHOULD proceed to ; otherwise the fetch is deemed successful - and the RP will process the fetched objects. - -
- -
- - - If an RP does not acquire a current valid manifest, or does not - acquire current valid instances of all of the objects enumerated - in a current valid manifest as a result of a fetch, then - processing of the signed objects associated with the CA instance - has failed for this fetch cycle. The RP MUST issue a warning - indicating the reason(s) for termination of processing with - regard to this CA instance. It is RECOMMENDED that a human - operator be notified of this warning. - - - - Termination of processing means that the RP SHOULD continue to - use cached versions of the objects associated with this CA - instance, until such time as they become stale or they can be - replaced by objects from a successful fetch. This implies that - the RP MUST not try to acquire and validate subordinate signed - objects, e.g., subordinate CA certificates, until the next - interval when the RP is scheduled to fetch and process data for - this CA instance. - -
- -
- -
- - - The RPKI publication system model requires that every publication - point be associated with one or more CAs, and be non-empty. Upon - creation of the publication point associated with a CA, the CA - MUST create and publish a manifest as well as a CRL. A CA's - manifest will always contain at least one entry, namely, the CRL - issued by the CA upon repository creation . - - - - Every published signed object in the RPKI - is published in the repository publication point of the CA that - issued the EE certificate, and is listed in the manifest - associated with that CA certificate. - - -
- -
- - - Manifests provide an additional level of protection for RPKI RPs. - Manifests can assist an RP to determine if a repository object has - been deleted, occluded, or otherwise removed from view, or if a - publication of a newer version of an object has been suppressed - (and an older version of the object has been substituted). - - - - Manifests cannot repair the effects of such forms of corruption of - repository retrieval operations. However, a manifest enables an - RP to determine if a locally maintained copy of a repository is a - complete and up-to-date copy, even when the repository retrieval - operation is conducted over an insecure channel. In cases where - the manifest and the retrieved repository contents differ, the - manifest can assist in determining which repository objects form - the difference set in terms of missing, extraneous, or superseded - objects. - - - - The signing structure of a manifest and the use of the nextUpdate - value allows an RP to determine if the manifest itself is the - subject of attempted alteration. The requirement for every - repository publication point to contain at least one manifest - allows an RP to determine if the manifest itself has been occluded - from view. Such attacks against the manifest are detectable - within the time frame of the regular schedule of manifest updates. - Forms of replay attack within finer-grained time frames are not - necessarily detectable by the manifest structure. - - -
- -
- - - As created and populated the registries - "RPKI Signed Object" and three-letter filename extensions for - "RPKI Repository Name Schemes," no new action is requested of the - IANA. - - - - -
- -
- - - The authors would like to acknowledge the contributions from - George Michelson and Randy Bush in the preparation of the manifest - specification. Additionally, the authors would like to thank Mark - Reynolds and Christopher Small for assistance in clarifying - manifest validation and RP behavior. The authors also wish to - thank Job Snijders, Oleg Muravskiy, and Sean Turner for their - helpful review of this document. - - -
- - - - - - - - - - - - - - - - ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER) - - International International Telephone and Telegraph Consultative Committee - - - - - - - - - - - - - - - -
- -
- - - -
-
- - - -