Skip to main content

Manifests for the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-rpki-manifests-16

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6486.
Authors Matt Lepinski , Stephen Kent , Geoff Huston , Rob Austein
Last updated 2015-10-14 (Latest revision 2011-07-07)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 6486 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Stewart Bryant
IESG note
Send notices to (None)
draft-ietf-sidr-rpki-manifests-16
Secure Inter-Domain Routing                                   R. Austein
Internet-Draft                                                       ISC
Intended status: Standards Track                               G. Huston
Expires: January 9, 2012                                           APNIC
                                                                 S. Kent
                                                             M. Lepinski
                                                                     BBN
                                                            July 8, 2011

          Manifests for the Resource Public Key Infrastructure
                 draft-ietf-sidr-rpki-manifests-16.txt

Abstract

   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.

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 http://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."

   This Internet-Draft will expire on January 9, 2012.

Copyright Notice

Austein, et al.          Expires January 9, 2012                [Page 1]
Internet-Draft               RPKI Manifests                    July 2011

   Copyright (c) 2011 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Manifest Signing . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Manifest Definition  . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  eContentType . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  eContent . . . . . . . . . . . . . . . . . . . . . . . . .  5
       4.2.1.  Manifest . . . . . . . . . . . . . . . . . . . . . . .  5
     4.3.  ContentType Attribute  . . . . . . . . . . . . . . . . . .  7
     4.4.  Manifest Validation  . . . . . . . . . . . . . . . . . . .  7
   5.  Manifest Generation  . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Manifest Generation Procedure  . . . . . . . . . . . . . .  7
     5.2.  Considerations for Manifest Generation . . . . . . . . . .  9
   6.  Relying Party Use of Manifests . . . . . . . . . . . . . . . .  9
     6.1.  Tests for Determining Manifest State . . . . . . . . . . . 10
     6.2.  Missing Manifests  . . . . . . . . . . . . . . . . . . . . 11
     6.3.  Invalid Manifests  . . . . . . . . . . . . . . . . . . . . 12
     6.4.  Stale Manifests  . . . . . . . . . . . . . . . . . . . . . 12
     6.5.  Mismatch between Manifest and Publication Point  . . . . . 13
     6.6.  Hash Values Not Matching Manifests . . . . . . . . . . . . 14
   7.  Publication Repositories . . . . . . . . . . . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

Austein, et al.          Expires January 9, 2012                [Page 2]
Internet-Draft               RPKI Manifests                    July 2011

1.  Introduction

   The Resource Public Key Infrastructure (RPKI) [ID.ietf-sidr-arch]
   makes use of a distributed repository system
   [ID.ietf-sidr-repos-struct] 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 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 detection of 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).

1.1.  Terminology

   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 RFC 2119.

Austein, et al.          Expires January 9, 2012                [Page 3]
Internet-Draft               RPKI Manifests                    July 2011

2.  Manifest Scope

   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 [I-D.sidr-res-certs], issued by this CA.

   Every RPKI signed object includes, in the Cryptographic Message
   Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used
   to verify it [ID.sidr-signed-object].  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
   [ID.sidr-keyroll], 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.

3.  Manifest Signing

   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 this EE certificate is also valid.  This form of use of a EE
   certificate is termed a "sequential-use" EE certificate.

Austein, et al.          Expires January 9, 2012                [Page 4]
Internet-Draft               RPKI Manifests                    July 2011

4.  Manifest Definition

   A manifest is an RPKI signed object, as specified in
   [ID.sidr-signed-object].  The RPKI signed object template requires
   specification of the following data elements in the context of the
   manifest structure.

4.1.  eContentType

   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.

     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-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }

4.2.  eContent

   The content of a Manifest is defined as follows:

     Manifest ::= SEQUENCE {
      version     [0] INTEGER DEFAULT 0,
      manifestNumber  INTEGER (0..MAX),
      thisUpdate      GeneralizedTime,
      nextUpdate      GeneralizedTime,
      fileHashAlg     OBJECT IDENTIFIER,
      fileList        SEQUENCE SIZE (0..MAX) OF FileAndHash
      }

    FileAndHash ::=     SEQUENCE {
      file            IA5String,
      hash            BIT STRING
      }

4.2.1.  Manifest

   The manifestNumber, thisUpdate, and nextUpdate fields are modeled
   after the corresponding fields in X.509 CRLs (see [RFC5280]).
   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 an validity period that coincides with
   the interval from thisUpdate to nextUpdate, to prevent needless

Austein, et al.          Expires January 9, 2012                [Page 5]
Internet-Draft               RPKI Manifests                    July 2011

   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 Section 6.4.

   The data elements of the Manifest structure are defined as follows:

   version:
      The version number of this version of the manifest specification
      MUST be 0.

   manifestNumber:
      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
      [RFC5280] 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

   thisUpdate:
      This field contains the time when the manifest was created.  This
      field has the same format constraints as specified in [RFC5280]
      for the CRL field of the same name.

   nextUpdate:
      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

Austein, et al.          Expires January 9, 2012                [Page 6]
Internet-Draft               RPKI Manifests                    July 2011

      the EE certificate corresponding to the old manifest.

   fileHashAlg:
      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 [ID.ietf-sidr-rpki-algs].

   fileList:
      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.

4.3.  ContentType Attribute

   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.

4.4.  Manifest Validation

   To determine whether a manifest is valid, the RP MUST perform the
   following checks in addition to those specified in
   [ID.sidr-signed-object]:

   1.  The eContentType in the EncapsulatedContentInfo is id-ad-
       rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).

   2.  The version of the rpkiManifest is 0.

   3.  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.

5.  Manifest Generation

5.1.  Manifest Generation Procedure

   For a CA publication point in the RPKI repository system, a CA MUST
   perform the following steps to generate a manifest:

Austein, et al.          Expires January 9, 2012                [Page 7]
Internet-Draft               RPKI Manifests                    July 2011

   1.  If no key pair exists, or if using a "one-time-use" EE
       certificate with a new key pair, generate a key pair.

   2.  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 which will expire before the intended nextUpdate time
       of this manifest, issue a 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 [RFC3779]).

          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.

   3.  The EE certificate MUST NOT be published in the authority's
       repository publication point.

   4.  Construct the manifest content.

       The manifest content is described in Section 4.2.1.  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.

   5.  Encapsulate the manifest content using the CMS SignedData content
       type (as specified Section 4), sign the manifest using the
       private key corresponding to the subject key contained in the EE
       certificate, and publish the manifest in repository system

Austein, et al.          Expires January 9, 2012                [Page 8]
Internet-Draft               RPKI Manifests                    July 2011

       publication point that is described by the manifest.

   6.  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.

5.2.  Considerations for Manifest Generation

   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).

6.  Relying Party Use of Manifests

   The goal of an RP is to determine which signed objects to use for
   validating assertions about INRs and their use (e.g., which ROAs to
   use in the construction of route filters).  Ultimately, this
   selection is a matter of local policy.  However, in the following
   sections, we describe a sequence of tests that the RP SHOULD perform
   to determine the manifest state of the given publication point.  We
   then discuss the risks associated with using signed objects in the
   publication point, given the manifest state; we also provide suitable
   warning text that SHOULD be placed in a user-accessible log file.  It

Austein, et al.          Expires January 9, 2012                [Page 9]
Internet-Draft               RPKI Manifests                    July 2011

   is the responsibility of the RP to weigh these risks against the risk
   of routing failure that could occur if valid data is rejected, and to
   implement a suitable local policy.  Note that if a certificate is
   deemed unfit for use due to local policy, then any signed object that
   is validated using this certificate also SHOULD be deemed unfit for
   use (regardless of the status of the manifest at its own publication
   point).

6.1.  Tests for Determining Manifest State

   For a given publication point, the RP SHOULD perform the following
   tests to determine the manifest state of the publication point:

   1.  For each CA using this publication point, select the CA's current
       manifest (The "current" manifest is the manifest issued by this
       CA having highest manifestNumber among all valid manifests, and
       where manifest validity is defined in Section 4.4).

       If the publication point does not contain a valid manifest, see
       Section 6.2.  Lacking a valid manifest, the following tests
       cannot be performed.

   2.  To verify completeness, an RP MAY check that every file at each
       publication point appears in one and only one current manifest,
       and that every file listed in a current manifest that is
       published at the same publication point as the manifest.

       If there exist files at the publication point that do not appear
       on any manifest, or files listed in a manifest that do not appear
       at the publication point then see Section 6.5, but still continue
       with the following test.

   3.  Check that the current time (translated to UTC) is between
       thisUpdate and nextUpdate.

       If the current time does not lie within this interval then see
       Section 6.4, but still continue with the following tests.

   4.  Verify that listed hash value of every file listed in each
       manifest matches the value obtained by hashing the file at 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 see
       Section 6.6.

Austein, et al.          Expires January 9, 2012               [Page 10]
Internet-Draft               RPKI Manifests                    July 2011

   5.  An RP MAY check that the contents of each current manifest
       conforms to the manifest's scope constraints, as specified in
       Section 2.

   6.  If a current manifest contains entries for objects that are not
       within the scope of the manifest, then the out-of-scope entries
       SHOULD be disregarded in the context of this manifest.  If there
       is no other current manifest that describes these objects within
       that other manifest's scope, then see Section 6.2.

   For each signed object, if all of the following conditions hold:

      *  the manifest for its publication, and the associated
         publication point, pass all of the above checks;

      *  the signed object is valid; and

      *  the manifests for every certificate on the certification path
         used to validate the signed object, and the associated
         publication points, pass all of the above checks;

   then the RP can conclude that no attack against the repository system
   has compromised the given signed object, and the signed object MUST
   be treated as valid (relative to manifest checking).

6.2.  Missing Manifests

   The absence of a current manifest at a publication point could occur
   due to an error by the publisher or due to (malicious or accidental)
   deletion or corruption of all valid manifests.

   When no valid manifest is available, there is no protection against
   attacks that delete signed objects or replay old versions of signed
   objects.  All signed objects at the publication point, and all
   descendant objects that are validated using a certificate at this
   publication point SHOULD be viewed as suspect, but MAY be used by the
   RP, as per local policy.

   The primary risk in using signed objects at this publication point is
   that a superseded (but not stale) CRL would cause an RP to improperly
   accept a revoked certificate as valid (and thus rely upon signed
   objects that are validated using that certificate).  This risk is
   somewhat mitigated if the CRL for this publication point has a short
   time between thisUpdate and nextUpdate (and the current time is
   within this interval).  The risk in discarding signed objects at this
   publication point is that an RP may incorrectly discard a large
   number of valid objects.  This gives significant power to an

Austein, et al.          Expires January 9, 2012               [Page 11]
Internet-Draft               RPKI Manifests                    July 2011

   adversary that is able to delete a manifest at the publication point.

   Regardless of whether signed objects from this publication are deemed
   fit for use by an RP, this situation SHOULD result in a warning to
   the effect that: "No manifest is available for <pub point name>, and
   thus there may have been undetected deletions or replay substitutions
   from the publication point."

   In the case where an RP has access to a local cache of previously
   issued manifests that are valid, the RP MAY use the most recently
   previously issued valid manifests for this RPKI repository
   publication collection in this case for each entity that publishes at
   this publication point.

6.3.  Invalid Manifests

   The presence of an invalid manifest at a publication point could
   occur due to an error by the publisher or due to (malicious or
   accidental) corruption of a valid manifest.  An invalid manifest MUST
   never be used, even if th manifestNumber of the invalid manifest is
   greater that that of other (valid) manifests.

   There are no risks associated with using signed objects at a
   publication point containing an invalid manifest, provided that valid
   manifests that collectively cover all the signed objects are also
   present.

   If an invalid manifest is present at a publication point that also
   contains one or more valid manifests, this situation SHOULD result in
   a warning to the effect that: "An invalid manifest was found at <pub
   point name>, this indicates an attack against the publication point
   or an error by the publisher.  Processing for this publication point
   will continue using the most recent valid manifest(s)."

   In the case where the RP has access to a local cache of previously
   issued (valid) manifests, an RP MAY make use of that locally cached
   data.  Specifically, the RP MAY use the locally cached, most recent,
   previously issued. valid manifest issued by the entity that (appears
   to have) issued the invalid manifest.

6.4.  Stale Manifests

   A manifest is considered stale if the current time is after the
   nextUpdate time for the manifest.  This could be due to publisher
   failure to promptly publish a new manifest, or due to (malicious or
   accidental) corruption or suppression of a more recent manifest.

   All signed objects at the publication point issued by the entity that

Austein, et al.          Expires January 9, 2012               [Page 12]
Internet-Draft               RPKI Manifests                    July 2011

   has published the stale manifest, and all descendant signed objects
   that are validated using a certificate issued by the entity that has
   published the stale manifest at this publication point SHOULD be
   viewed as somewhat suspect, but MAY be used by the RP as per local
   policy.

   The primary risk in using such signed objects is that a newer
   manifest exists that, if present, would indicate that certain objects
   are have been removed or replaced.  (For example, the new manifest
   might show the existence of a newer CRL and the removal of one or
   more revoked certificates).  Thus, the use of objects from a stale
   manifest may cause an RP to incorrectly treat invalid objects as
   valid.  The risk is that the CRL covered by the stale manifest has
   been superseded, and thus an RP will to improperly treat improperly
   treat a revoked certificate as valid.  This risk is somewhat
   mitigated if the time between the nextUpdate field of the manifest
   and the current time is short.  The risk in discarding signed objects
   at this publication point is that the RP may incorrectly discard a
   large number of valid objects.  This gives significant power to an
   adversary that is able to prevent the publication of a new manifest
   at a given publication point.

   Regardless of whether signed objects from this publication are deemed
   fit for use by an RP, this situation SHOULD result in a warning to
   the effect that: "A manifest found at <pub point name> is no longer
   current.  It is possible that undetected deletions have occurred at
   this publication point."

   Note that there is also the potential for the current time to be
   before the thisUpdate time for the manifest.  This case could be due
   to publisher error, or a local clock error, and in such a case this
   situation SHOULD result in a warning to the effect that: "A manifest
   found at <pub point name> has an incorrect thisUpdate field.  This
   could be due to publisher error, or a local clock error, and
   processing for this publication point will continue using this
   otherwise valid manifest."

6.5.  Mismatch between Manifest and Publication Point

   If there exist valid signed objects that do not appear in any
   manifest, then, provided the manifest is not stale (see Section 6.4)
   it is likely that their omission is an error by the publisher.  It is
   also possible that this state could be the result of a (malicious or
   accidental) replacement of a current manifest with an older, but
   still valid manifest.  However, regarding the appropriate
   interpretation such objects, it remains the case that if the objects
   were intended to be invalid, then they should have been revoked using
   whatever revocation mechanism is appropriate for the signed object in

Austein, et al.          Expires January 9, 2012               [Page 13]
Internet-Draft               RPKI Manifests                    July 2011

   question.)  Therefore, there is little risk in using such signed
   objects.  If the publication point contains a stale manifest, then
   there is a greater risk that the objects in question were revoked,
   along with a missing Certificate Revocation List (CRL), the absence
   of which is undetectable since the manifest is stale.  In any case,
   the use of signed objects not present on a manifest, or descendant
   objects that are validated using such signed objects, is a matter of
   local policy.

   Regardless of whether objects not appearing on a manifest are deemed
   fit for use by the RP, this situation SHOULD result in a warning to
   the effect that: "The following files are present in the repository
   at <pub point name>, but are not listed on any manifest <file list>
   for <pub point name>."

   If there exists files listed on the manifest that do not appear in
   the repository, then these objects are likely to have been improperly
   (via malice or accident) deleted from the repository.  A primary
   purpose of manifests is to detect such deletions.  Therefore, in such
   a case this situation SHOULD result in a warning to the effect that:
   "The following files that should have been present in the repository
   at <pub point name>, are missing <file list>.  This indicates an
   attack against this publication point, or the repository, or an error
   by the publisher."

6.6.  Hash Values Not Matching Manifests

   A file appearing on a manifest with an incorrect hash value could
   occur because of publisher error, but it also may indicate that an
   attack has occurred.

   If an object appeared on a previous valid manifest with a correct
   hash value, and it now appears with an invalid hash value, then it is
   likely that the object has been superseded by a new (unavailable)
   version of the object.  If the object is used, there is a risk that
   the RP will be treating a stale object as valid.  This risk is more
   significant if the object in question is a CRL.  If the object can be
   validated using the RPKI, the use of these objects is a matter of
   local policy.

   If an object appears on a manifest with an invalid hash and has never
   previously appeared on a manifest, then it is unclear whether the
   available version of the object is more or less recent than the
   version indicated by the manifest.  If the manifest is stale (see
   Section 6.4), then it becomes more likely that the available version
   is more recent that the version indicated on the manifest, but this
   is never certain.  Whether to use such objects is a matter of local
   policy.  However, in general, it is better to use a possibly outdated

Austein, et al.          Expires January 9, 2012               [Page 14]
Internet-Draft               RPKI Manifests                    July 2011

   version of the object than to discard the object completely.

   While it is a matter of local policy, in the case of CRLs, an RP
   SHOULD endeavor to use the most recently issued valid CRL, even where
   the hash value in the manifest matches an older CRL, or does not
   match any available CRL for a CA instance.  The thisUpdate field of
   the CRL can be used to establish the most recent CRL in the case
   where an RP has more than one valid CRL for a CA instance.

   Regardless of whether objects with incorrect hashes are deemed fit
   for use by the RP, this situation SHOULD result in a warning to the
   effect that: "The following files at the repository <pub point name>
   appear on a manifest with incorrect hash values <file list>.  It is
   possible that these objects have been superseded by a more recent
   version.  It is very likely that this problem is due to an attack on
   the publication point, although it also could be due to a publisher
   error."

7.  Publication Repositories

   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.  [ID.ietf-sidr-repos-struct].

   Every published signed object in the RPKI [ID.sidr-signed-object] 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.

8.  Security Considerations

   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

Austein, et al.          Expires January 9, 2012               [Page 15]
Internet-Draft               RPKI Manifests                    July 2011

   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 is 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 .

9.  IANA Considerations

   This document registers the following RPKI Signed Object in the
   registry created by [ID.sidr-signed-object]:

     Name: Manifest
     OID: 1.2.840.113549.1.9.16.1.26
     Reference: [RFCxxxx] (this document)

   This document registers the following three-letter filename extension
   for RPKI repository objects in the registry created by
   [ID.ietf-sidr-repos-struct]:

     Filename extensionL mft
     RPKI Object : Manifest
     Reference: [RFCxxxx] (this document)

10.  Acknowledgements

   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 Sean
   Turner for his helpful review of this document.

11.  References

11.1.  Normative References

   [I-D.sidr-res-certs]
              Huston, G., Michaelson, G., and R. Loomans, "A Profile for

Austein, et al.          Expires January 9, 2012               [Page 16]
Internet-Draft               RPKI Manifests                    July 2011

              X.509 PKIX Resource Certificates",
              draft-ietf-sidr-res-certs-16.txt (work in progress),
              February 2009.

   [ID.ietf-sidr-repos-struct]
              Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure",
              draft-ietf-sidr-repos-struct-04.txt (work in progress),
              May 2010.

   [ID.ietf-sidr-rpki-algs]
              Huston, G., "A Profile for Algorithms and Key Sizes for
              use in the Resource Public Key Infrastructure",
              draft-ietf-sidr-rpki-algs-05.txt (work in progress),
              April 2011.

   [ID.sidr-signed-object]
              Lepinski, M., Chi, A., and S. Kent, "Signed Object
              Template for the Resource Public Key Infrastructure",
              draft-ietf-sidr-signed-object-01.txt (work in progress),
              October 2010.

   [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.

11.2.  Informative References

   [ID.ietf-sidr-arch]
              Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", draft-ietf-sidr-arch-11.txt
              (work in progress), September 2010.

   [ID.sidr-keyroll]
              Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover
              in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in
              progress), October 2010.

   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
              Algorithms", RFC 3370, August 2002.

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779, June 2004.

Austein, et al.          Expires January 9, 2012               [Page 17]
Internet-Draft               RPKI Manifests                    July 2011

Appendix A.  ASN.1 Module

   RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs9(9) smime(16) mod(0) 60 }

   DEFINITIONS EXPLICIT TAGS ::=

   BEGIN

   -- EXPORTS ALL --

   -- IMPORTS NOTHING --

   -- Manifest Content Type: OID

   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-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }

   -- Manifest Content Type: eContent

   Manifest ::= SEQUENCE {
   version        [0] INTEGER DEFAULT 0,
   manifestNumber     INTEGER (0..MAX),
   thisUpdate         GeneralizedTime,
   nextUpdate         GeneralizedTime,
   fileHashAlg        OBJECT IDENTIFIER,
   fileList           SEQUENCE SIZE (0..MAX) OF FileAndHash
   }

   FileAndHash ::= SEQUENCE {
   file  IA5String,
   hash  BIT STRING
   }

   END

Austein, et al.          Expires January 9, 2012               [Page 18]
Internet-Draft               RPKI Manifests                    July 2011

Authors' Addresses

   Rob Austein
   Internet Systems Consortium
   950 Charter St.
   Redwood City, CA  94063
   USA

   Email: sra@isc.org

   Geoff Huston
   Asia Pacific Network Information Centre
   6 Cordelia St
   South Brisbane, QLD  4101
   Australia

   Email: gih@apnic.net
   URI:   http://www.apnic.net

   Stephen Kent
   BBN Technologies
   10 Moulton St.
   Cambridge, MA  02138
   USA

   Email: kent@bbn.com

   Matt Lepinski
   BBN Technologies
   10 Moulton St.
   Cambridge, MA  02138
   USA

   Email: mlepinski@bbn.com

Austein, et al.          Expires January 9, 2012               [Page 19]