[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 6486

Individual Submission                                         R. Austein
Internet-Draft                                                       ISC
Intended status: Standards Track                               G. Huston
Expires: July 5, 2008                                              APNIC
                                                                 S. Kent
                                                             M. Lepinski
                                                                     BBN
                                                         January 2, 2008


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 5, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document defines a "manifest" for use in the Resource Public Key
   Infrastructure.  A "manifest" is a signed object that contains a
   listing of all the signed objects in the repository publication point
   associated with an authority responsible for publishing in the



Austein, et al.           Expires July 5, 2008                  [Page 1]

Internet-Draft               RPKI Manifests                 January 2008


   repository.  For each certificate, or other forms 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 expose potential threats to relying parties of the
   results of a man-in-the middle withholding attack on repository
   retrieval operations.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Manifests  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Manifest Syntax  . . . . . . . . . . . . . . . . . . . . .  4
   3.  Manifest Signing and Verification  . . . . . . . . . . . . . .  6
   4.  Using CMS SignedData to protect a Manifest . . . . . . . . . .  7
   5.  Manifest Generation  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Certificate Requests . . . . . . . . . . . . . . . . . . . . . 10
   7.  Publication Repositories . . . . . . . . . . . . . . . . . . . 11
   8.  Relying Parties  . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Manifest Processing  . . . . . . . . . . . . . . . . . . . 13
       8.1.1.  Warning List . . . . . . . . . . . . . . . . . . . . . 15
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19






















Austein, et al.           Expires July 5, 2008                  [Page 2]

Internet-Draft               RPKI Manifests                 January 2008


1.  Introduction

   The Resource PKI (RPKI) [ID.SIDR-ARCH] makes use of a distributed
   repository system [ID.SIDR-REPOSITORY] to make available a variety of
   objects needed by relying parties (RPs) such as Internet service
   providers (ISPs).  Because all of the objects stored in the
   repository system are digitally signed by the entities that created
   them, attacks that modify these objects are detectable by RPs.
   However, attacks that substitute "stale" versions of signed objects
   (i.e., objects that were valid but have since been superceded) are
   not automatically detected just by validation of digital signatures.
   Attacks that remove an object also are not detectable by verification
   of digital signatures, unless an RP is able to predict that the
   object should be present.  To help address these vulnerabilities, the
   RPKI repository system will make use of a new data structure call a
   "manifest."

   A manifest is a signed object listing of all of the signed objects
   issued by an authority responsible for a publication point in the
   repository system.  For each certificate, Certificate Revocation List
   (CRL), or other signed object, such as a Route Origination Authority
   (ROA), issued by the authority, the manifest contains both the name
   of the file containing the object, and a hash of the file content.
   Manifests are intended to allow an RP to obtain sufficient
   information so as to be able to detect if the retrieval of objects
   from an RPKI repository has been compromised by unauthorized removal,
   or by substitution of "stale" versions of objects.  Manifests are
   designed to be used for Certification Authority (CA) publication
   points in repositories, points that contain subordinate certificates,
   CRLs and other signed objects, and End Entity (EE) publication points
   in repositories (that contain signed objects).


      [Note 1.  This text assumes that CRLs are included in manifests.
      As a signed product of an issuing authority that is published in
      the authority's publication repository this would be consistent
      with the definition of manifests in the text.  However, if
      manifests are intended to list all objects in a publication
      repository that relying parties would otherwise not know to exist,
      then is not logically necessary to include CRLs in a manifest, as
      the CRL is already a requrement for CAs to publish.  It is an
      option to strike CRLs from the list of objects to inlude in a
      manifest.  This may reduce to some extent the amount of manifest
      activity in a repository for an otherse largely static CA.  On the
      other hand listing the CRL in the manifest has some utility in
      being able to detect some forms of substitution of a "stale" but
      otherwise valid CRL.  A later note highlights a similar issue over
      inclusion of the manifest-signing EE certificate in the manifest.



Austein, et al.           Expires July 5, 2008                  [Page 3]

Internet-Draft               RPKI Manifests                 January 2008


      It is suggested that the text be left as is and that CRLs be
      included in manifests.]

      [Note 2.  This draft assumes that it is possible for an EE to sign
      and publish multiple objects and, accordingly, a manifest for the
      signed object publication repository is necessary.  Accordingly,
      the document implicitly refers to both CA and EE manifests.  An
      alternate option is to apply a restriction in the RPKI that an EE
      can sign a single object, in which case the signed object can be
      referenced directly in the SIA of the AA and no manifest of EE-
      signed objects is necessary.  It is suggested that the text be
      left as is, leaving the option for CA and EE manifests to be
      permitted within this specification.]


1.1.  Terminology

   It is assumed that the reader is familiar with the terms and concepts
   described in "Internet X.509 Public Key Infrastructure Certificate
   and Certificate Revocation List (CRL) Profile" [RFC3280]and "X.509
   Extensions for IP Addresses and AS Identifiers" [RFC3779].

   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.


2.  Manifests

   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 can
   contain objects not covered by CRLs, e.g. digitally signed objects,
   such as ROAs.  The Cryptographic Message Syntax (CMS) [RFC3852]
   signature format is employed to encapsulate the manifest payload.  It
   also provides a vehicle to carry the EE certificate needed to verify
   a manifest.

   The scope of a manifest is the entire collection objects in a
   publication point in a repository, where each object has been signed
   by the same CA or EE that is the authority for this repository
   publication point.

2.1.  Manifest Syntax

   A manifest is a CMS signed-data object whose content is defined as
   follows:



Austein, et al.           Expires July 5, 2008                  [Page 4]

Internet-Draft               RPKI Manifests                 January 2008


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

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

   The version of this Manifest format is 1, and the value of this field
   is therefore 0.

   The manifestNumber field is a sequence number that is incremented
   each time a new manifest is issued for the repository.  This field is
   used to allow a RP to detect gaps in a sequence of published
   manifest.

   The thisUpdate field contains the time when the manifest was created
   and the nextUpdate 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.  If the authority alters any of
   the items in the repository publication point, then the authority
   MUST issue a new manifest before nextUpdate.  In such a case, when
   the authority issues the new manifest, it MUST also issue a new CRL
   that includes the EE certificate corresponding to the old manifest.
   A manifest is nominally valid until the time specified in nextUpdate
   or until a manifest is issued with a greater manifest number,
   whichever comes first.  The revoked EE certificate for the previous
   manifest's signature will be removed from the CRL when it expires.

   The fileHashAlg field contains the OID of the hash algorithm used to
   hash the files that the authority has placed into the repository.
   The mandatory to implement hash algorithm is SHA-256 and its OID is
   2.16.840.1.101.3.4.2.1.  [RFC4055].

   The fileList field contains a sequence of FileAndHash pairs, one for
   each currently valid signed object that has been issued by the
   authority.  Each FileAndHash pair contains the name of the file in
   the repository that contains the object in question, and a hash of
   the file's contents.






Austein, et al.           Expires July 5, 2008                  [Page 5]

Internet-Draft               RPKI Manifests                 January 2008


3.  Manifest Signing and Verification

   A manifest for a CA's repository publication point is signed by a
   private key, for which the corresponding public key appears in an EE
   certificate signed by the CA in question.

   A manifest for a EE's repository publication point is signed by a
   private key, for which the corresponding public key appears in an EE
   certificate signed by the same CA that signed the public key of the
   publishing EE.  This, for an EE-managed publication point, exactly
   one level of indirection is allowed in validation of the manifest
   certificate.

   Validation of a manifest's CMS digital signature is performed in the
   context of the RPKI, and is validated using the algorithm described
   in [ID.SIDR-CERTPROFILE].


      [Note 3.  This draft assumes that each EE uses a unique repository
      publication point.  This is not an explicit constraint of the
      Resource PKI.  For the sake of the efficiency of the relying
      parties' repository synchronization operations it is possible that
      a CA may choose to place all signed objects that are verified
      using EE certificates that are subordinates to this CA in a common
      single repository publication point.  In this case the above
      manifest signature description still holds, namely that the
      manifest of this common repository publication point is a single
      manifest that is signed by a private key, for which the
      corresponding public key appears in an EE certificate signed by
      this CA.  It is suggested that the text note that this validation
      method allows both the model that each EE uses a dedicated
      repository publication point, or that all subordinate EEs of a
      single CA share a common repository publication point, and note
      that it CAs may elect to use a dedicated per-EE repository, or a
      single shared EE repository.]

      [Note 4.  In the (possibly degenerate) case of a multi-signed
      object it would appear that the simplest case is to apply a
      restriction that the EE certificates used in this context be one-
      off use EE certificates and each EE certificate reference the
      common multi-signed object's repository publication point.  The
      collection of CAs that generated EE certificates to sign this
      object would also need to agree on a common repository publication
      point in this case.  As the issue of a multi-signed object is
      still unresolved for this RPKI no resolution is suggested here
      (see draft-ietf-smime-multisig-03.txt for a multi-signing
      approach).]




Austein, et al.           Expires July 5, 2008                  [Page 6]

Internet-Draft               RPKI Manifests                 January 2008


   Two models for managing the EE certificates used to verify manifests
   are permitted.  A publication point authority may create an EE
   certificate for manifest verification and use the corresponding
   private key to sign a series of manifests over tiome.  Alternatively,
   an EE certificate may be used to verify a single instance of a
   manifest and the private key corresponding to the certificate may be
   deleted after it is used to sign that manifest instance.  To avoid
   needless CRL growth, the EE certificate used to validate a manifest
   in this second case SHOULD expire at the same time that the manifest
   expires, i.e., the notAfter value in the EE certificate should be the
   same as the nextUpdate value in the manifest.  In contrast, when an
   EE certificate is used to verify a series of manifests, the validity
   of that certificate has to encompass the validity intervals for all
   corresponding manifests.


4.  Using CMS SignedData to protect a Manifest

   It is intended that the manifest will be processed by an RP in the
   context of assembling a local copy of the entire RPKI repository.
   Thus, the certificates and CRLs required to validate the certificate
   path for the EE certificate used to varify the manifest's signature
   will be at hand for the RP.  AS a result, this specification
   recommends that only the EE certificate needed to verify the
   signature on the manifest be included in the CMS DignedData.  CA
   certificates and CRLs SHOULD NOT be included in the CMS SignedData.
   The CMS timestamp field SHOULD NOT be included in the CMS Signed
   Data.


      [Note 5.  This section needs to be expanded to precisely specify
      which optional CMS fields MUST be present, which ones MUST be
      omitted and which (if any) MAY be present at the discretion of
      themanifest signed.  It is also suggested that the default
      algorithms to be used also be specified here.]



5.  Manifest Generation

   Each CA in the RPKI publishes the certificates and CRLs it issues at
   a publication point in the RPKI repository system.  To create a
   manifest, each CA MUST:


   1.  Generate a key pair.





Austein, et al.           Expires July 5, 2008                  [Page 7]

Internet-Draft               RPKI Manifests                 January 2008


   2.  Issue an EE certificate for this key pair to enable relying
       parties to verify the signature on the manifest.

       *  This EE certificate has 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 SHOULD describe its IP number resources
          using the "inherit" attribute rather than explicit description
          of a resource set.

       *  The validity times of the EE certificate MUST either exactly
          match the thisUpdate and nextUpdate times of the manifest, or
          encompass the validity intervals for the series of manifests
          that are expected to be verified using the EE certificate.

   3.  Publish this certificate in the authority's repository
       publication point.


          [Note 6.  This assumes that the EE certificate used to sign
          manifests is published in the CA's repository publication
          point in the same manner as all other subordinate certificates
          issued by this CA.  It is potentially an option to omit the
          publication step on the basis that the EE certificate is also
          contained in the CMS SignedData field of the manifest.  It is
          suggested that these EE certificates by treated in the same
          manner as all other certificates in the RPKI and be published
          in the appropriate repository as well as being reproduced in
          the CMS SignedData section of the manifest, leaving the above
          text as is.]


   4.  The manifest is then constructed.  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.  The manifest is encapsulated using the CMS SignedData content
       type and published in the publication point in the repository
       system that is described by the manifest.

   6.  If a single use EE certificate is associated with a single use
       key pair the private key may now be destroyed.


   An authority MUST issue a new manifest on or before the nextUpdate



Austein, et al.           Expires July 5, 2008                  [Page 8]

Internet-Draft               RPKI Manifests                 January 2008


   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
   synchronization function on the repository to ensure that replying
   parties who are performing retrieval operations on the repository are
   not exposed to intermediate states during changes to the repository
   and the associated manifest.

   Since the manifest object URL is included in the SIA of issued
   certificates then 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 one that is unchanged across manifest generation
   cycles.

   As the manifest scope is all signed objects associated with an
   authority responsible for a pubnlication point, the manifest must
   persist across key rollover events.  This implies that this
   persistent repository publication name cannot be derived from the
   authority's current public key value in any way.

   In the case of a CA publication point manifest, when the CA is
   performing a key rollover, the CA will use its new private key to
   sign an EE certificate for a new manifest.  It will sign the manifest
   and publish it at the point in the key rollover sequence following
   the publication of the new CA certificate by the superior CA (i.e.
   the point at which objects signed with the new key may be validated
   by relying parties).  The previous EE certificate used to sign
   manifests will be revoked by the CRL that is associated with the
   retiring private key (as the scope of CRLs in the RPKI is that of CA
   plus private key value).  The new instance of the manifest, and
   successive manifests, will describe all the files in the CA
   publication point that were signed with both the retiring key and the
   new key.  The manifest number will continue to be incremented and
   MUST NOT be reset.

   In the case of a EE publication point manifest, when the EE
   certificate is rekeyed, a new publication point is established.  A
   new EE certificate for manifest validation will be generated by the
   CA that issues the new EE certificate assocaited with the new
   publication point.  In this case there is no manifest overlap, as the
   new repository publication point will have a distinct manifest.




Austein, et al.           Expires July 5, 2008                  [Page 9]

Internet-Draft               RPKI Manifests                 January 2008


   In the case of a common publication point for all subordinate EE
   authorities of a CA the same still holds, and each batched update
   operation on the shared repository would entail a new generation of
   the manifest being produced.


6.  Certificate Requests

   A request for a CA certificate MUST include in the SIA of the request
   an accessMethod OID of id-ad-rpkiManifest, where the associated
   accessLocation refers to the subject's published manifest object as
   an object URL.

   When an EE certificate is intended for use in verifying multiple
   objects, the certificate request for the EE certificate MUST include
   in the SIA of the request an access method OID of id-ad-rpkiManifest,
   where the associated access location refers to the publication point
   of the objects that are verified using this EE certificate.


      [Note 7.  This draft assumes that it is possible for an EE to sign
      and publish multiple objects as noted earlier.  The above
      constraint me be removed if this is not the case.  It is suggested
      that the multiple object provision be left in the text.]


   When an EE certificate is used to sign a single object, the
   certificate request for the EE certificate MUST include in the SIA of
   the request an access method OID of id-ad-signedObject, where the
   associated access location refers to the publication point of the
   single object that is verified using this EE certificate.

   In accordance with the provisions of [ID.SIDR-CERTPROFILE], all
   certificate issuance requests for a CA certificate SHOULD include the
   id-ad-caRepository access method, and also the id-ad-rpkiManifest
   access method that references the intended publication point of the
   manifest in the associated access location in the request.  The
   issuer SHOULD honor these values in the issued certificate or MUST
   reject the Certificate Request.

   Similarly, a request for an EE certificate SHOULD include either the
   id-ad-signedObjectRepository and the id-ad-rpkiManifest access
   method, or, in the case of single-use EE certificates, include the
   id-ad-signedObject access method and omit the id-ad-rpkiManifest
   access method.






Austein, et al.           Expires July 5, 2008                 [Page 10]

Internet-Draft               RPKI Manifests                 January 2008


7.  Publication Repositories

   The RPKI publication system model requires that every publication
   point be associated with a CA or an EE, 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.  The manifest will
   contain at least two entries, the CRL issued by the CA upon
   repository creation and the EE certificate used to sign the manifest.
   Upon the creation of the publication point associated with an AA, the
   EE MUST create and puiblish a manifest.  The manifest in an otherwise
   empty repository publication point associated with an EE will contain
   no entries in the manifest's fileList sequence (i.e. a sequence of 0
   length).


      [Note 8.  This description of the initial state of a CA's
      repository publication point assumes that the EE certificate used
      to sign manifests is published in the CA's repository publication
      point in the same manner as all other subordinate certificates
      issued by this CA, as noted in a previous comment.  It is
      suggested that this remain the case and that this text be
      retained.]


   For signed objects EE certificate used in the verification of such
   objects is either a single-use certificate, used to verify a single
   signed object, or a multiple-use certificate.  In the case of a
   single-use EE certificate, the id-ad-signedObject SIA access method
   is to refer to the signed object itself, and the signed object is not
   covered by a manifest.  In the case where the EE certificate is used
   to verify multiple objects, the id-ad-signedObjectRepository SIA
   access method points to the repository publication point where signed
   objects that are verified using this EE certificate are published and
   the id-ad-rpkiManifest SIA access methos points to the manifest for
   this repository publication point.  A CA MAY use a common repository
   publication point for the collection of signed objects that are
   verified using any of the CA's subordinate EE certificates.


8.  Relying Parties

   All RPKI repository publication points SHOULD should contain a valid
   manifest.

   A valid manifest is one where:






Austein, et al.           Expires July 5, 2008                 [Page 11]

Internet-Draft               RPKI Manifests                 January 2008


   o  the manifest conforms to the defined syntax for manifests

   o  the digital signature can be verified by using the public key
      specified in the attached EE certificate

   o  the current time is no earlier than the thisUpdate time of the
      manifest and no later than the nextUpdate time of the manifest

   o  the EE certificate conforms to the profile as specified in
      [ID.SIDR-CERTPROFILE]

   o  the EE certificate has not been revoked

   o  the EE certificate has not expired

   o  the EE certificate can be validated according to the procedure
      described in section 7 of [ID.SIDR-CERTPROFILE]


   The absence of a manifest from a RPKI repository publication point
   may indicate a possible attack on the repository retrieval function,
   and this situation should generate some form of operational warning.
   If the relying party has retained one or more previously retrieved
   manifests then the relying party should use most recent (highest
   manifestNumber value) verified manifest for the publication point in
   question.  If no prior manifest for this publication point is
   available, there is no basis for detecting missing files, so the
   relying party should just process the repository contents in any
   case.  All objects retrieved from a repository whose manifest is in
   this state are still potentially useable by relying parties, and
   validated objects should be regarded with the same level of trust
   that is used for validated objects that have been retrieved from
   repositories with valid manifests.

   If the signature on a manifest cannot be verified, or the manifest
   cannot be parsed according to the manifest syntax specification, it
   must be disregarded by a relying party.  Since this case entailed
   retrieval of what purports to be a manifest, a warning SHOULD be
   issued, but the RP should proceed with processing the publication
   point objects.

   Where a manifest is present, and the signature can be verified using
   the attached EE certificate, but the EE certificate itself cannot be
   validated, then it is possible that the manifest is bogus.  In this
   case the manifest should be disregarded by the RP and a warning
   SHOULD be issued, but the RP should proceed with processing the
   publication point objects as if no manifest had been provided.




Austein, et al.           Expires July 5, 2008                 [Page 12]

Internet-Draft               RPKI Manifests                 January 2008


   Where a manifest is present, and the signature can be verified using
   the attached EE certificate, but the EE certificate itself has been
   revoked, then it is possible that the manifest is a replay.  In this
   case the manifest should be disregarded by the RP and a warning
   SHOULD be issued, but the RP should proceed with processing the
   publication point objects as if no manifest had been provided.

   When processing a valid manifest, if an RP encounters a signed object
   that is not listed in the manifest, or that has a different hash
   value from the one specified in the manifest, then the object SHOULD
   be ignored and a warning SHOULD be issued.  The object should not be
   trusted as it may be part of a replay attack.


      [Note 9.  An alternative approach is that such objects that are
      not in the manifest or fail to match the hash algorithm but still
      validate in the RPKI should still be used because they do indeed
      validate within the scope of the RPKI.  The issue here appears to
      be one of judgment about what form of replay attack is occurring
      in such a situation, assuming that the authority's manifest
      generation process was correct and the discrepancy has arisen
      during the repository synchronization operation.  The default
      approach, or ignoring everything not in the manifest and ignoring
      everything that fails to match the manifest's hash value assumes
      that the attack is one of replay of the object.  The alternative
      is that the replay attack is a replay of the manifest, in which
      case the relying party has been forced to discard valid objects
      because of the manifest replay.  This requires further
      consideration as to which scenario presents the lesser risk to
      relying parties.  No suggestion is made here, and further advice
      is sought on this topic.]


   If a valid manifest lists files that are not visible in the
   publication point, then the RP should assume that these objects have
   been deleted, potentially without authorization, and a warning SHOULD
   be issued.

   A semi-formal description of the recommended relying party manifest
   processing algorithm follows.

8.1.  Manifest Processing

   The error-free case is:

      A manifest is present in the repository, is current (i.e., the
      current time is bounded by the manifest validity interval), and
      its signature can be verified using a valid certificate



Austein, et al.           Expires July 5, 2008                 [Page 13]

Internet-Draft               RPKI Manifests                 January 2008


      [ID.SIDR-CERTPROFILE].  All files found in the publication point
      are listed in the manifest, all files listed in the manifest are
      found in the publication point, and the hashes match.

   The cases that SHOULD generate various manifest validation warnings
   are:

   1.  No manifest is found in the repository at the publication point.
       In this case, the relying party cannot use the manifest in
       question.

       A.  If the relying party has a prior manifest for this
           publication point, then the relying party should use most
           recent, verified manifest for the publication point in
           question and generate warning A.

       B.  If no prior manifest for this publication point is available
           to the relying party, there is no basis for detecting missing
           files, so just process certificate, CRL, and other signed
           object files and generate warning B.

   2.  The signature on manifest fetched from the repository cannot be
       verified (or the format of the manifest is bad).  In this case,
       the relying party cannot use the manifest in question.

       A.  If the relying party has a prior manifest for this
           publication point, then the relying party should use most
           recent, verified manifest for the publication point in
           question and generate warning A.

       B.  If no prior manifest for this publication point is available
           to the relying party, there is no basis for detecting missing
           files, so just process certificate, CRL, and other signed
           object files and generate warning B.

   3.  The manifest is present and current and its signature can be
       verified using the CMS enclosed EE certificate.

       A.  If the EE certificate is valid (current and not revoked) and
           all files in the repository are listed in the manifest, and
           all files listed in the manifest are found in the repository,
           and the hashes match, then the relying party should use the
           manifest, as this is the validated case.

       B.  If the EE certificate is valid and one or more files listed
           in the manifest have hashes that do not match the files in
           the repository with the indicates names, then the
           corresponding files are likely to be old and intended to be



Austein, et al.           Expires July 5, 2008                 [Page 14]

Internet-Draft               RPKI Manifests                 January 2008


           replaced, and thus SHOULD NOT be used.  The relying party
           should generate Warning C.

       C.  If the EE certificate is valid and one or more files listed
           in the manifest are missing, the relying party should
           Generate Warning D.

       D.  If the EE certificate is expired, an indication that the EE
           certificate valid times and the manifest times are not
           aligned, then the relying party should generate warning E,
           but proceed with processing.

       E.  If the EE certificate is revoked but not expired, then the
           manifest SHOULD be ignored.  The relying party should
           generate warning F and proceed with processing as if no
           manifest is available, as the CA has explicitly revoked the
           certificate for the manifest.

   4.  The manifest is present but expired.  If the signature cannot be
       verified, then treat this in the same manner as case 1 or 2.  If
       the manifest signature can be verified using a matching EE
       certificate:

       A.  If the EE certificate is valid (current and not revoked),
           then generate warning A and proceed.

       B.  If the EE certificate is expired, then generate warning G and
           proceed.

       C.  If EE certificate is revoked but not expired, the manifest
           SHOULD be ignored.  Generate warning F and proceed with
           processing as if no manifest is available (since the CA
           explicitly revoked the certificate for the manifest.)


8.1.1.  Warning List

   Warning A:  A current manifest is not available for <pub point name>.
      An older manifest for this publication point will be used, but
      there may be undetected deletions from the publication point.

   Warning B:  No manifest is available for <pub point name>, and thus
      there may have been undetected deletions from the publication
      point.







Austein, et al.           Expires July 5, 2008                 [Page 15]

Internet-Draft               RPKI Manifests                 January 2008


   Warning C:  The following files at <pub point nam> appear to be
      superceded and are NOT being processed.

   Warning D:  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.

   Warning E:  EE certificate for manifest verification for <pub point
      name> is expired.  This indicates an error by the publisher, but
      processing for this publication point will proceed using the
      current manifest.

   Warning F:  The EE certificate for <pub point name> has been revoked.
      The manifest will be ignored and all files found at this
      publication point will be processed.

   Warning G:  EE certificate for manifest verification for <pub point
      name> is expired.  This indicates an error by the publisher, but
      processing for this publication point will proceed using the the
      most recent (but expired) manifest.



9.  Security Considerations

   [To be defined]


10.  IANA Considerations

   [Note to IANA, to be removed prior to publication: there are no IANA
   considerations stated in this version of the document.]


11.  Acknowledgements

   The authors would like to acknowledge the contributions from George
   Michaelson and Randy Bush in the preparation of the manifest
   specification.


12.  Normative References

   [ID.SIDR-ARCH]
              Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure
              to Support Secure Internet Routing", Work in progress:
              Internet Drafts draft-ietf-sidr-arch-02.txt,



Austein, et al.           Expires July 5, 2008                 [Page 16]

Internet-Draft               RPKI Manifests                 January 2008


              November 2007.

   [ID.SIDR-CERTPROFILE]
              Huston, G., Michaleson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", Work in progress:
              Internet Drafts draft-ietf-sidr-res-certs-09.txt,
              November 2007.

   [ID.SIDR-REPOSITORY]
              Huston, G. and G. Michaleson, "A Distributed Repository
              System for the Resource PKI", Work in progress: Internet
              Drafts draft-ietf-sidr-repository-00.txt, November 2007.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

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

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography for use in
              the Internet X.509 Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile", RFC 4055,
              June 2005.


Authors' Addresses

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

   Email: sra@isc.org











Austein, et al.           Expires July 5, 2008                 [Page 17]

Internet-Draft               RPKI Manifests                 January 2008


   Geoff Huston
   Asia Pacific Network Information Centre
   33 park Rd.
   Milton, QLD  4064
   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 July 5, 2008                 [Page 18]

Internet-Draft               RPKI Manifests                 January 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Austein, et al.           Expires July 5, 2008                 [Page 19]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/