Secure Inter-Domain Routing (sidr) R. Austein Internet Draft ISC Expires: January 2009 G. Huston Intended Status: Proposed Standard APNIC S. Kent M. Lepinski BBN Technologies July 2008 Manifests for the Resource Public Key Infrastructure draft-ietf-sidr-rpki-manifest-01.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 January 8, 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 a given certification authority. For each certificate, certificate revocation list, and other signed object issued by the authority that is 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 attacks against relying parties of the Austien, et al. Expires January 2009 [Page 1] Internet-Draft RPKI Manifests July 2008 RPKI such as a man-in-the middle withholding repository data or replaying stale data. Table of Contents 1. Introduction...................................................3 1.1. Terminology...............................................3 2. Manifest Syntax................................................4 2.1. Signed-Data Content Type..................................4 2.1.1. version..............................................4 2.1.2. digestAlgorithms.....................................4 2.1.3. encapContentInfo.....................................4 2.1.3.1. eContentType....................................5 2.1.3.2. eContent........................................5 2.1.4. certificates.........................................6 2.1.5. crls.................................................6 2.1.6. signerInfos..........................................6 2.1.6.1. version.........................................7 2.1.6.2. sid.............................................7 2.1.6.3. digestAlgorithm.................................7 2.1.6.4. signedAttrs.....................................7 2.1.6.4.1. ContentType Attribute......................8 2.1.6.4.2. MessageDigest Attribute....................8 2.1.6.4.3. SigningTime Attribute......................8 2.1.6.4.4. BinarySigningTimeAttribute.................9 2.1.6.5. signatureAlgorithm..............................9 2.1.6.6. signature.......................................9 2.1.6.7. unsignedAttrs...................................9 3. Manifest Generation............................................9 4. Certificate Requests..........................................11 5. Manifest Validation...........................................12 6. Relying Party Use of Manifests................................13 6.1. Tests for Determining Manifest State.....................14 6.2. Missing Manifests........................................15 6.3. Invalid Manifests........................................15 6.4. Stale Manifests..........................................16 6.5. Files Not on Manifests (or Missing from a Publication Point) ..............................................................17 6.6. Hash Values Not Matching Manifests.......................17 7. Publication Repositories......................................18 8. Security Considerations.......................................19 9. IANA Considerations...........................................19 10. Acknowledgments..............................................19 11. References...................................................19 11.1. Normative References....................................19 11.2. Informative References..................................20 Austien, et al. Expires January 2009 [Page 2] Internet-Draft RPKI Manifests July 2008 Authors' Addresses...............................................21 Intellectual Property Statement..................................21 Disclaimer of Validity...........................................22 Copyright Statement..............................................22 1. Introduction The Resource PKI (RPKI) [ID.ARCH] makes use of a distributed repository system [ID.REPOS] 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, digital signatures provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid but have since been superceded) or attacks that remove an object that should be present in the repository. To aid in the detection of such attacks, the RPKI repository system will make use of a new signed object called a "manifest." A manifest is an object that lists all of the other signed objects issued by an authority responsible for the repository system publication point containing the manifest. 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 allow a RP to obtain sufficient information to to detect whether the retrieval of objects from an RPKI repository has been compromised by unauthorized object removal, or by the substitution of "stale" versions of objects. Manifests are designed to be used both for Certification Authority (CA) publication points in repositories (points that contain subordinate certificates, CRLs and other signed objects), as well as End Entity (EE) publication points in repositories (that contain signed objects but not certificates). For more information on the structure of the repository system, see [ID.REPOS] 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. Austien, et al. Expires January 2009 [Page 3] Internet-Draft RPKI Manifests July 2008 2. Manifest Syntax A Manifest is a CMS [RFC3852] signed-data object. The general format of a CMS object is: ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType } ContentType ::= OBJECT IDENTIFIER As a Manifest is a signed-data object, it uses the corresponding OID, 1.2.840.113549.1.7.2. [RFC3852] 2.1. Signed-Data Content Type According to the CMS standard, the signed-data content type is defined as follows: SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier SignerInfos ::= SET OF SignerInfo 2.1.1. version The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3. 2.1.2. digestAlgorithms The digestAlgorithms set MUST include only SHA-256, the OID for which is 2.16.840.1.101.3.4.2.1. [RFC4055] It MUST NOT contain any other algorithms. 2.1.3. encapContentInfo encapContentInfo is the signed content, consisting of a content type identifier and the content itself. Austien, et al. Expires January 2009 [Page 4] Internet-Draft RPKI Manifests July 2008 EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } ContentType ::= OBJECT IDENTIFIER 2.1.3.1. eContentType The ContentType 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 INDENTIFIER ::= { id-smime 1 } id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 2.1.3.2. eContent The content of a Manifest is defined as follows: rpkiManifest ::= 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 number of the rpkiManifest MUST be 0. The manifestNumber field is a sequence number that is incremented each time a new manifest is issued for a given publication point. This field is used to allow a RP to detect gaps in a sequence of published manifests. 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 Austien, et al. Expires January 2009 [Page 5] Internet-Draft RPKI Manifests July 2008 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. To prevent needless growth of CRLs, it is RECOMMENDED that the EE certificate used to issue a manifest have an validity period that coincides with the interval from thisUpdate to nextUpdate. The manifestNumber, thisUpdate, and nextUpdate fields are modeled after the corresponding fields in X.509 CRLs (see [RFC3280]). In analogy to CRLS, 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. 2.1.4. certificates The certificates field MUST be included and MUST contain only the end entity certificate needed to validate this Manifest. 2.1.5. crls The crls field MUST be omitted. 2.1.6. signerInfos SignerInfo is defined under CMS as: Austien, et al. Expires January 2009 [Page 6] Internet-Draft RPKI Manifests July 2008 SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 2.1.6.1. version The version number MUST be 3, corresponding with the choice of SubjectKeyIdentifier for the sid. 2.1.6.2. sid The sid is defined as: SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier } For a Manifest, the sid MUST be a SubjectKeyIdentifier. 2.1.6.3. digestAlgorithm The digestAlgorithm MUST be SHA-256, the OID for which is 2.16.840.1.101.3.4.2.1. [RFC4055] 2.1.6.4. signedAttrs The signedAttrs is defined as: SignedAttributes ::= SET SIZE (1..MAX) OF Attribute Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY The signedAttr element MUST be present and MUST include the content- type and message-digest attributes. The signer MAY also include the signing-time signed attribute, the binary-signing-time signed attribute, or both signed attributes. Other signed attributes that are deemed appropriate MAY also be included. The intent is to allow Austien, et al. Expires January 2009 [Page 7] Internet-Draft RPKI Manifests July 2008 additional signed attributes to be included if a future need is identified. This does not cause an interoperability concern because unrecognized signed attributes are ignored by the relying party. The signedAttr MUST include only a single instance of any particular attribute. Additionally, even though the syntax allows for a SET OF AttributeValue, in a Manifest the attrValues must consist of only a single AttributeValue. 2.1.6.4.1. ContentType Attribute The ContentType attribute MUST be present. The attrType OID for the ContentType attribute is 1.2.840.113549.1.9.3. The attrValues for the ContentType attribute in a Manifest MUST be 1.2.840.113549.1.9.16.1.26 (matching the eContentType in the EncapsulatedContentInfo). 2.1.6.4.2. MessageDigest Attribute The MessageDigest Attribute MUST be present. The attrType OID for the MessageDigest Attribute is 1.2.840.113549.1.9.4. The attrValues for the MessageDigest attribute contains the output of the digest algorithm applied to the content being signed, as specified in Section 11.1 of RFC 3852. 2.1.6.4.3. SigningTime Attribute The SigningTime Attribute MAY be present. If it is present it MUST be ignored by the relying party. The presence of absence of the SigningTime attribute in no way affects the validation of the Manifest (as specified in Section 5). The attrType OID for the SigningTime attribute is 1.2.840.113549.1.9.5. The attrValues for the SigningTime attribute is defined as: SigningTime ::= Time Time ::= CHOICE { utcTime UTCTime, generalizedTime GeneralizedTime } The Time element specifies the time, based on the local system clock, at which the digital signature was applied to the content. Austien, et al. Expires January 2009 [Page 8] Internet-Draft RPKI Manifests July 2008 2.1.6.4.4. BinarySigningTimeAttribute The BinarySigningTime Attribute MAY be present. If it is present it MUST be ignored by the relying party. The presence of absence of the BinarySigningTime attribute in no way affects the validation of the Manifest (as specified in Section 5). The attrType OID for the SigningTime attribute is 1.2.840.113549.1.9.16.2.46. The attrValues for the SigningTime attribute is defined as: BinarySigningTime ::= BinaryTime BinaryTime ::= INTEGER (0..MAX) The BinaryTime element specifies the time, based on the local system clock, at which the digital signature was applied to the content. 2.1.6.5. signatureAlgorithm The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which is 1.2.840.113549.1.1.1. 2.1.6.6. signature The signature value is defined as: SignatureValue ::= OCTET STRING The signature characteristics are defined by the digest and signature algorithms. 2.1.6.7. unsignedAttrs unsignedAttrs MUST be omitted. 3. 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 perform the following steps: 1. Generate a key pair. 2. Issue an EE certificate for this key pair to enable relying parties to verify the signature on the manifest. Austien, et al. Expires January 2009 [Page 9] Internet-Draft RPKI Manifests July 2008 o 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. o This EE certificate SHOULD describe its IP number resources using the "inherit" attribute rather than explicit description of a resource set. o The validity times of the EE certificate SHOULD exactly match the thisUpdate and nextUpdate times of the manifest, and MUST encompass the interval from thisUPdate to nextUpdate. 3. This EE certificate SHOULD NOT be published in the authority's repository publication point. 4. Construct the Manifest content. Note that the manifest does not include a self-reference (i.e., its own file name and hash), since it is 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 in Section 2) and publish in the repository- system publication point that is described by the manifest. 6. The private key associated with the EE certificate may now be destroyed. An authority MUST issue a new manifest 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 single 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, MUST remain unchanged across successive manifests. Austien, et al. Expires January 2009 [Page 10] Internet-Draft RPKI Manifests July 2008 As the manifest scope is all signed objects issued by an authority responsible for a given pubnlication point, the manifest must persist across key rollover events. This implies that the 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 issue the prior manifest will be revoked by the CRL that is associated with the certificate containing the retiring public key. The new instance of the manifest, and all successive manifests, will describe all the files in the CA publication point that were signed both with the retiring key and the new key. The manifest number will continue to be incremented and MUST NOT be reset upon key rollover. In the case of an EE publication point manifest, when the EE certificate is re-keyed, 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. In the case of a common publication point for all subordinate EE certificates of a given CA, the situation is the same as that described above. That is, each batched update operation on the shared publication point would entail generation of a completely new manifest. 4. 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. Austien, et al. Expires January 2009 [Page 11] Internet-Draft RPKI Manifests July 2008 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.RESCERT], 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. 5. Manifest Validation To determine whether a manifest is valid, the relying party must perform the following checks: 1. Verify that the ROA syntax complies with this specification. In particular, verify the following: a) The contentType of the CMS object is SignedData (OID 1.2.840.113549.1.7.2) b) The version of the SignedData object is 3. c) The digestAlgorithm in the SignedData object is SHA-256 (OID 2.16.840.1.101.3.4.2.1). d) The certificates field in the SignedData object is present and contains an EE certificate whose Subject Key Identifier (SKI) matches the sid field of the SignerInfo object. e) The crls field in the SignedData object is omitted. f) The eContentType in the EncapsulatedContentInfo is routeOriginAttestation (OID 1.2.840.113549.1.9.16.1.24) g) The version of the rpkiManifest is 0. Austien, et al. Expires January 2009 [Page 12] Internet-Draft RPKI Manifests July 2008 h) In the rpkiManifest, thisUpdate precedes nextUpdate. i) The version of the SignerInfo is 3. j) The digestAlgorithm in the SignerInfo object is SHA-256 (OID 2.16.840.1.101.3.4.2.1). k) The signatureAlgorithm in the SignerInfo object is RSA (OID 1.2.840.113549.1.1.1). l) The signedAttrs field in the SignerInfo object is present and contains both the ContentType attribute (OID 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 1.2.840.113549.1.9.4). m) The unsignedAttrs field in the SignerInfo object is omitted. 2. Use the public key in the EE certificate to verify the signature on the Manifest. 3. Verify that the EE certificate is a valid end-entity certificate in the resource PKI by constructing a valid certificate path to a trust anchor. (See [ID.RESCERT] for more details.) If the above procedure indicates that the manifest is invalid, then the manifest MUST be discarded and treated as though no manifest were present. 6. Relying Party Use of Manifests The goal of the relying party is to determine which signed objects to use for routing-related tasks, (e.g. which ROAs to use in the construction of route filters). Ultimately, this is a matter of local policy. However, in the following sections, we describe a sequence of tests that the relying party 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; and provide suitable warning text that should placed in a user-accessible log file. It is the responsibility of the relying party to weigh these risks against the risk of routing failure that could occur if valid data is rejected, and construct a suitable local policy. Note that if a certificate is deemed unfit for use do to local policy, then any descendent object that is validated using this certificate should also be deemed unfit for use (regardless of the status of the manifest at its own publication point). Austien, et al. Expires January 2009 [Page 13] Internet-Draft RPKI Manifests July 2008 6.1. Tests for Determining Manifest State For a given publication point, the relying party should perform the following tests to determine the manifest state of the publication point: 1. Consider the manifest having highest manifestNumber among all valid manifests (where manifest validity is defined in Section 5). o If the publication point does not contain a valid manifest, see Section 6.2. (Lacking a valid manifest, the following tests cannot be performed). o If the publication point contains also contains one or more invalid manifests then see Section 6.3 (but still continue with the following tests). 2. Check that the current time is between thisUpdate and nextUpdate. o If the current time does not lie in this interval then see Section 6.4 (but still continue with the following tests). 3. Check that every file at the publication point appears on the manifest, and that every file on the manifest appears at the publication point. o If there exist files at the publication point that do not appear on the manifest, or files on the manifest that do not appear at the publication point then see Section 6.5 (but still continue with the following test). 4. Check that the hash of every file listed on the manifest matches the value obtained by hashing the file in at the publication point. o If there exist files at the publication point whose hash does not match the hash value listed in the manifest, then see Section 6.6. For a particular signed object, if (A) the manifest for its publication passes all of the above checks; (B) the signed object is valid; and (C) the manifests for every certificate on the certificate path used to validate the signed object pass all of the above checks; then the relying party can conclude that no attack against the repository system has compromised the given signed object and the signed object MUST be treated as valid. Austien, et al. Expires January 2009 [Page 14] Internet-Draft RPKI Manifests July 2008 6.2. Missing Manifests The absence of a valid manifest at a publication 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 descendent objects that are validated using a certificate at this publication point should be viewed as somewhat suspect, but may be used by the relying party as per local policy. The primary risk in using signed objects at this publication point is that a deleted CRL causes the relying party to improperly treat a revoked certificate as valid. 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 the relying party may incorrectly discard a large number of valid objects. This gives significant power to an adversary that is able to corrupt all manifests at the publication point. Regardless of whether signed objects from this publication are deemed fit for use by the relying party, the following warning message MUST be generated: "No manifest is available for , and thus there may have been undetected deletions from the publication point." 6.3. Invalid Manifests The presence of invalid manifests 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 the manifestNumber is greater than that on valid manifests. There are no risks associated with using signed objects at a publication point containing an invalid manifest, provided that a valid manifest is also present. If an invalid manifest is present at a publication point that also contains one or more valid manifests, the following warning SHOULD be generated: Austien, et al. Expires January 2009 [Page 15] Internet-Draft RPKI Manifests July 2008 "An invalid manifest was found at , 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." 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 of a more recent manifest. All signed objects at the publication point, and all descendent objects that are validated using a certificate at this publication point should be viewed as somewhat suspect, but may be used by the relying party as per local policy. The primary risk in using signed objects at this publication point is that a newer manifest exists that, if present, would indicate that certain objects are have been removed or replaced. (E.g. the new manifest if present might show the existence of a newer CRL and the removal of several revoked certificates). Thus use of objects on a stale manifest may cause the relying party to incorrectly treat several invalid objects as valid. The risk is CRL causes the relying party to 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 relying party 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 the relying party, the following warning message MUST be generated: "The manifest for is no longer current. It is possible that undetected deletions have occurred at this publication point." Note that there is also a less common case where the current time is before the thisUpdate time for the manifest. This case is necessarily due to publisher error and in such a case the following warning should be generated: Austien, et al. Expires January 2009 [Page 16] Internet-Draft RPKI Manifests July 2008 "The manifest found at has an incorrect thisUpdate field. This is due to publisher error, and processing for this publication point will continue using this otherwise valid manifest." 6.5. Files Not on Manifests (or Missing from a Publication Point) If there exist otherwise valid signed objects that do not appear on 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. (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 question.) Therefore, there is little risk in using such signed objects. If the manifest in question is stale, then there is a greater risk that the objects in question were revoked with a missing CRL (whose absence is undetectable since the manifest is stale). In any case, the use of signed objects not present on a manifest (or descendent 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 relying party, the following warning message MUST be generated: "The following files are present in the repository at , but are not on the manifest ." If there exist 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 manifest. A primary purpose of manifests is to detect such deletions. Therefore, in such a case the following warning MUST be generated: "The following files that should have been present in the repository at , are missing . 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 is likely to indicate that a serious error has occurred. If an object appeared on a previous valid manifest with a correct hash value and now appears with an invalid hash value, then it is likely that the object has been superceded by a new (unavailable) version of the object. If the object is used there is a significant Austien, et al. Expires January 2009 [Page 17] Internet-Draft RPKI Manifests July 2008 risk that the relying party will be treating an invalid object as valid (this risk is greater if one of the objects in question is a CRL). The use of these objects is a matter of local policy, but this situation should be viewed as strong evidence of an attack against the publication point. 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 whose hash appears in 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 version of the object, then to discard the object completely. Regardless of whether objects with incorrect hashes are deemed fit for use by the relying party, the following warning message MUST be generated: "The following files at the repository appear on a manifest with incorrect hash values . It is likely 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 could be due to a publisher error." 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 length zero). 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 Austien, et al. Expires January 2009 [Page 18] Internet-Draft RPKI Manifests July 2008 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. Security Considerations [To be defined] 9. IANA Considerations None. 10. Acknowledgments The authors would like to acknowledge the contributions from George Michaelson 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 relying party behavior. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3852] Housley, R., "Cryptographic Message Syntax", RFC 3852, July 2004. [RFC4055] Schaad, J., Kaliski, B., and Housley, R., "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. [RFC3779] Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. Austien, et al. Expires January 2009 [Page 19] Internet-Draft RPKI Manifests July 2008 11.2. Informative References [RSA] Rivest, R., Shamir, A., and Adelman, L. M. 1978. A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM 21, 2 (Feb.), 120-126. [ID.ARCH] Lepinski, M., Kent, S., and Barnes, R., "An Infrastructure to Support Secure Internet Routing," draft-ietf-sidr-arch- 03.txt, February, 2008 (work in progress). [ID.RESCERT] Huston, G., Michaelson, G., and Loomans, R., "A Profile for X.509 PKIX Resource Certificates," draft-ietf- sidr-res-certs-09.txt, November, 2007 (work in progress). [ID.REPOS] Huston, G., Loomans, R., and Michaelson, G., "A Profile for Resource Certificate Repository Structure," draft-huston-sidr-repos-struct-02, June 2008 (work in progress). Austien, et al. Expires January 2009 [Page 20] Internet-Draft RPKI Manifests July 2008 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 33 Park Rd. Milton, QLD 4064 Australia Email: gih@apnic.net Matt Lepinski BBN Technologies 10 Moulton Street Cambridge MA 02138 USA Email: mlepinski@bbn.com Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138 Email: skent@bbn.com Intellectual Property Statement 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. Austien, et al. Expires January 2009 [Page 21] Internet-Draft RPKI Manifests July 2008 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. Disclaimer of Validity 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. 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. Austien, et al. Expires January 2009 [Page 22]