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]