idnits 2.17.1 draft-ietf-sidr-rpki-manifests-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1114. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1132. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1138. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 6, 2008) is 5735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 495 -- Looks like a reference, but probably isn't: '1' on line 491 == Missing Reference: 'ID.RESCERT' is mentioned on line 736, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'ID.SIDR-ARCH') == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-10 ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing R. Austein 3 Internet-Draft ISC 4 Intended status: Standards Track G. Huston 5 Expires: February 7, 2009 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 August 6, 2008 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on February 7, 2009. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document defines a "manifest" for use in the Resource Public Key 46 Infrastructure. A "manifest" is a signed object that contains a 47 listing of all the signed objects in the repository publication point 48 associated with an authority responsible for publishing in the 49 repository. For each certificate, or other forms of signed objects 50 issued by the authority that are published at this repository 51 publication point, the manifest contains both the name of the file 52 containing the object, and a hash of the file content. Manifests are 53 intended to expose potential attacks against relying parties of the 54 RPKI, such as a man-in-the middle withholding repository data or 55 replaying stale repository data. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Manifest Scope and Syntax . . . . . . . . . . . . . . . . . . 4 62 2.1. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Manifest Syntax . . . . . . . . . . . . . . . . . . . . . 4 64 2.2.1. Signed-Data Content Type . . . . . . . . . . . . . . . 4 65 2.2.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 12 67 3.1. CA Manifest Generation . . . . . . . . . . . . . . . . . . 12 68 3.2. End Entity Manifest Generation . . . . . . . . . . . . . . 13 69 3.3. Common Considerations for Manifest Generation . . . . . . 14 70 4. Processing Certificate Requests . . . . . . . . . . . . . . . 15 71 5. Manifest Validation . . . . . . . . . . . . . . . . . . . . . 16 72 6. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 17 73 6.1. Tests for Determining Manifest State . . . . . . . . . . . 17 74 6.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 18 75 6.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 19 76 6.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 19 77 6.5. Files Not on Manifests (or Missing from a Publication 78 Point) . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 6.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 21 80 7. Publication Repositories . . . . . . . . . . . . . . . . . . . 21 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 84 11. Normative References . . . . . . . . . . . . . . . . . . . . . 23 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 86 Intellectual Property and Copyright Statements . . . . . . . . . . 25 88 1. Introduction 90 The Resource PKI (RPKI) [ID.SIDR-ARCH] makes use of a distributed 91 repository system [ID.SIDR-REPOSITORY] to make available a variety of 92 objects needed by relying parties (RPs) such as Internet service 93 providers (ISPs). Because all of the objects stored in the 94 repository system are digitally signed by the entities that created 95 them, attacks that modify these objects are detectable by RPs. 96 However, digital signatures provide no protection against attacks 97 that substitute "stale" versions of signed objects (i.e., objects 98 that were valid but have since been superceded) or attacks that 99 remove an object that should be present in the repository. To assist 100 in the detection of such attacks, the RPKI repository system will 101 make use of a new signed object called a "manifest." 103 A manifest is an object that lists of all of the other signed objects 104 issued by the authority responsible for a publication point in the 105 repository system. For each certificate, Certificate Revocation List 106 (CRL), or other signed object, such as a Route Origination Authority 107 (ROA), issued by the authority, the manifest contains both the name 108 of the file containing the object, and a hash of the file content. 109 Manifests allow a RP to obtain sufficient information to detect 110 whether the retrieval of objects from an RPKI repository has been 111 compromised by unauthorized object removal, or by the substitution of 112 "stale" versions of objects. Manifests are designed to be used both 113 for Certification Authority (CA) publication points in repositories, 114 that contain subordinate certificates, CRLs and other signed objects, 115 and End Entity (EE) publication points in repositories that contain 116 signed objects. 118 Manifests are modelled on CRLs, as the issues involved in detecting 119 stale manifests, and detection of potential attacks using manifest 120 replays, etc are similar to those for CRLs. The syntax of the 121 manifest payload differs from CRLs, since RPKI repositories can 122 contain objects not covered by CRLs, such as digitally signed 123 objects, such as ROAs. 125 1.1. Terminology 127 It is assumed that the reader is familiar with the terms and concepts 128 described in "Internet X.509 Public Key Infrastructure Certificate 129 and Certificate Revocation List (CRL) Profile" [RFC5280]and "X.509 130 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119. 136 2. Manifest Scope and Syntax 138 2.1. Manifest Scope 140 In the case of a CA's manifest of its associated publication 141 repository in the scope of the Resource Certificate PKI (RPKI), the 142 manifest contains the current published certificates issued by this 143 CA, the most recent CRLs that are associated with the CA's non- 144 revoked keypairs, and all objects that are signed using a "single- 145 use" EE certificate, where the EE certificate was issued by this CA. 147 In the case where an EE has a defined publication repository, the 148 EE's manifest contains all published objects that have been signed by 149 the EE's key pair. 151 2.2. Manifest Syntax 153 A manifest is a Cryptographic Message Syntax (CMS) [RFC3852] signed- 154 data object. The general format of a CMS object is: 156 ContentInfo ::= SEQUENCE { 157 contentType ContentType, 158 content [0] EXPLICIT ANY DEFINED BY contentType } 160 ContentType ::= OBJECT IDENTIFIER 162 A Manifest is a signed-data object. The ContentType used is the 163 signed-data type of id-data, namely the id-signedData OID, 164 1.2.840.113549.1.7.2. [RFC3852] 166 2.2.1. Signed-Data Content Type 168 According to the CMS specification, signed-data content types shall 169 have the ASN.1 type SignedData: 171 SignedData ::= SEQUENCE { 172 version CMSVersion, 173 digestAlgorithms DigestAlgorithmIdentifiers, 174 encapContentInfo EncapsulatedContentInfo, 175 certificates [0] IMPLICIT CertificateSet OPTIONAL, 176 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 177 signerInfos SignerInfos } 179 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 181 SignerInfos ::= SET OF SignerInfo 183 2.2.1.1. version 185 The version is the syntax version number. It MUST be 3, 186 corresponding to the signerInfo structure having version number 3. 188 2.2.1.2. digestAlgorithms 190 The digestAlgorithms set MUST include only SHA-256, the OID for which 191 is 2.16.840.1.101.3.4.2.1 [RFC4055]. It MUST NOT contain any other 192 algorithms. 194 2.2.1.3. encapContentInfo 196 encapContentInfo is the signed content, consisting of a content type 197 identifier and the content itself. 199 EncapsulatedContentInfo ::= SEQUENCE { 200 eContentType ContentType, 201 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 203 ContentType ::= OBJECT IDENTIFIER 205 2.2.1.3.1. eContentType 207 The eContentType for a Manifest is defined as id-ct-rpkiManifest, and 208 has the numerical value of 1.2.840.113549.1.9.16.1.26. 210 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 211 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 213 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 215 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 217 2.2.1.3.2. eContent 219 The content of a Manifest is defined as follows: 221 Manifest ::= SEQUENCE { 222 version [0] INTEGER DEFAULT 0, 223 manifestNumber INTEGER, 224 thisUpdate GeneralizedTime, 225 nextUpdate GeneralizedTime, 226 fileHashAlg OBJECT IDENTIFIER, 227 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash 228 } 230 FileAndHash ::= SEQUENCE { 231 file IA5String 232 hash BIT STRING 233 } 235 2.2.1.3.2.1. Manifest 237 The manifestNumber, thisUpdate, and nextUpdate fields are modelled 238 after the corresponding fields in X.509 CRLs (see [RFC5280]). 239 Analogous to CRLS, a manifest is nominally valid until the time 240 specified in nextUpdate or until a manifest is issued with a greater 241 manifest number, whichever comes first. The revoked EE certificate 242 for the previous manifest's signature will be removed from the CRL 243 when it expires. 245 To prevent needless growth of CRLs, it is RECOMMENDED that the EE 246 certificate used to issue a manifest have an validity period that 247 coincides with the interval from thisUpdate to nextUpdate. 249 2.2.1.3.2.1.1. version 251 The version number of the rpkiManifest MUST be 0. 253 2.2.1.3.2.1.2. manifestNumber 255 The manifestNumber field is a sequence number that is incremented 256 each time a new manifest is issued for a given publication point. 257 This field is used to allow a RP to detect gaps in a sequence of 258 published manifest. 260 2.2.1.3.2.1.3. thisUpdate 262 The thisUpdate field contains the time when the manifest was created. 264 2.2.1.3.2.1.4. nextUpdate 266 The nextUpdate field contains the time at which the next scheduled 267 manifest will be issued. The value of nextUpdate MUST be later than 268 the value of thisUpdate. If the authority alters any of the items in 269 the repository publication point, then the authority MUST issue a new 270 manifest before the nextUpdate time. In such a case, when the 271 authority issues the new manifest, it MUST also issue a new CRL that 272 includes the EE certificate corresponding to the old manifest. 274 2.2.1.3.2.1.5. fileHashAlg 276 The fileHashAlg field contains the OID of the hash algorithm used to 277 hash the files that the authority has placed into the repository. 278 The mandatory to implement hash algorithm is SHA-256 and its OID is 279 2.16.840.1.101.3.4.2.1. [RFC4055]. 281 2.2.1.3.2.1.6. fileList 283 The fileList field contains a sequence of FileAndHash pairs, one for 284 each currently valid signed object that has been issued by the 285 authority. Each FileAndHash pair contains the name of the file in 286 the repository that contains the object in question, and a hash of 287 the file's contents. 289 2.2.1.4. certificates 291 The certificates field MUST be included, and MUST contain the RPKI 292 end entity certificate needed to validate this Manifest in the 293 context of the RPKI. 295 2.2.1.5. crls 297 This field MUST be omitted. 299 2.2.1.6. signerInfos 301 Signer Infos is defined as a SignerInfo, which is defined under CMS 302 as: 304 SignerInfo ::= SEQUENCE { 305 version CMSVersion, 306 sid SignerIdentifier, 307 digestAlgorithm DigestAlgorithmIdentifier, 308 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 309 signatureAlgorithm SignatureAlgorithmIdentifier, 310 signature SignatureValue, 311 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 313 2.2.1.6.1. version 315 The version number MUST be 3, corresponding with the choice of 316 SubjectKeyIdentifier for the sid. 318 2.2.1.6.2. sid 320 The sid is defined as: 322 SignerIdentifier ::= CHOICE { 323 issuerAndSerialNumber IssuerAndSerialNumber, 324 subjectKeyIdentifier [0] SubjectKeyIdentifier } 326 For a Manifest, the sid MUST be a SubjectKeyIdentifier. 328 2.2.1.6.3. digestAlgorithm 330 The digestAlgorithm MUST be SHA-256, the OID for which is 331 2.16.840.1.101.3.4.2.1. [RFC4055] 333 2.2.1.6.4. signedAttrs 335 The signedAttrs is defined as signedAttributes: 337 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 339 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 341 Attribute ::= SEQUENCE { 342 attrType OBJECT IDENTIFIER, 343 attrValues SET OF AttributeValue } 345 AttributeValue ::= ANY 347 The signedAttr element MUST be present and MUST include the content- 348 type and message-digest attributes. The signer MAY also include the 349 signing-time signed attribute, the binary-signing-time signed 350 attribute, or both signing-time attributes. Other signed attributes 351 that are deemed appropriate MAY also be included. The intent is to 352 allow additional signed attributes to be included if a future need is 353 identified. This does not cause an interoperability concern because 354 unrecognized signed attributes are ignored by the relying party. 356 The signedAttr MUST include only a single instance of any particular 357 attribute. Additionally, even though the syntax allows for a SET OF 358 AttributeValue, in a Manifest the attrValues MUST consist of only a 359 single AttributeValue. 361 2.2.1.6.4.1. Content-Type Attribute 363 The ContentType attribute MUST be present. The attrType OID for the 364 ContentType attribute is 1.2.840.113549.1.9.3. 366 The attrValues for the ContentType attribute in a Manifest MUST be 367 1.2.840.113549.1.9.16.1.26, matching the eContentType in the 368 EncapsulatedContentInfo. 370 2.2.1.6.4.2. Message-Digest Attribute 372 The MessageDigest Attribute MUST be present. The attrType OID for 373 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 375 The attrValues for the MessageDigest attribute contains the output of 376 the digest algorithm applied to the content being signed, as 377 specified in Section 11.1 of [RFC3852]. 379 2.2.1.6.4.3. SigningTime Attribute 381 The SigningTime attribute MAY be present. The presence of absence of 382 the SigningTime attribute in no way affects the validation of the 383 Manifest (as specified in Section 5). 385 The attrType OID for the SigningTime attribute is 386 1.2.840.113549.1.9.5. 388 The attrValues for the SigningTime attribute is defined as: 390 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 391 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 393 SigningTime ::= Time 395 Time ::= CHOICE { 396 utcTime UTCTime, 397 generalizedTime GeneralizedTime } 399 The Time element specifies the time, based on the local system clock, 400 at which the digital signature was applied to the content. 402 2.2.1.6.4.4. BinarySigningTime Attribute 404 The signer MAY include a BinarySigningTime attribute, specifying the 405 time at which the digital signature was applied to the content. If 406 both the BinarySigningTime and SigningTime attributes are present, 407 the time that is represented by the binary-signing-time attribute 408 MUST represent the same time value as the signing-time attribute. 410 The presence or absence of the Binary-SigningTime attribute in no way 411 affects the validation of the Manifest (as specified in Section 5). 413 The binary-signing-time attribute is defined in [RFC4049] as: 415 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 416 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 417 smime(16) aa(2) 46 } 419 BinarySigningTime ::= BinaryTime 421 BinaryTime ::= INTEGER (0..MAX) 423 2.2.1.6.5. signatureAlgorithm 425 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which 426 is 1.2.840.113549.1.1.1. 428 2.2.1.6.6. signature 430 The signature value is defined as: 432 SignatureValue ::= OCTET STRING 434 The signature characteristics are defined by the digest and signature 435 algorithms. 437 2.2.1.6.7. unsignedAttrs 439 unsignedAttrs MUST be omitted. 441 2.2.2. ASN.1 443 The following is the ASN.1 specification of the CMS-signed Manifest. 445 ContentInfo ::= SEQUENCE { 446 contentType ContentType, 447 content [0] EXPLICIT ANY DEFINED BY contentType } 449 ContentType ::= OBJECT IDENTIFIER 451 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 452 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 454 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 456 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 457 Manifest ::= SEQUENCE { 458 version [0] INTEGER DEFAULT 0, 459 manifestNumber INTEGER, 460 thisUpdate GeneralizedTime, 461 nextUpdate GeneralizedTime, 462 fileHashAlg OBJECT IDENTIFIER, 463 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash} 465 FileAndHash ::= SEQUENCE { 466 file IA5String 467 hash BIT STRING} 469 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 470 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 472 SignedData ::= SEQUENCE { 473 version CMSVersion, 474 digestAlgorithms DigestAlgorithmIdentifiers, 475 encapContentInfo EncapsulatedContentInfo, 476 certificates [0] IMPLICIT CertificateSet OPTIONAL, 477 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 478 signerInfos SignerInfos } 480 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 482 SignerInfos ::= SET OF SignerInfo 484 SignerInfo ::= SEQUENCE { 485 version CMSVersion, 486 sid SignerIdentifier, 487 digestAlgorithm DigestAlgorithmIdentifier, 488 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 489 signatureAlgorithm SignatureAlgorithmIdentifier, 490 signature SignatureValue, 491 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 493 SignerIdentifier ::= CHOICE { 494 issuerAndSerialNumber IssuerAndSerialNumber, 495 subjectKeyIdentifier [0] SubjectKeyIdentifier } 497 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 499 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 501 Attribute ::= SEQUENCE { 502 attrType OBJECT IDENTIFIER, 503 attrValues SET OF AttributeValue } 505 AttributeValue ::= ANY 507 SignatureValue ::= OCTET STRING 509 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 510 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 512 ContentType ::= OBJECT IDENTIFIER 514 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 515 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 517 MessageDigest ::= OCTET STRING 519 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 520 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 522 SigningTime ::= Time 524 Time ::= CHOICE { 525 utcTime UTCTime, 526 generalizedTime GeneralizedTime } 528 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 529 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 530 smime(16) aa(2) 46 } 532 BinarySigningTime ::= BinaryTime 534 BinaryTime ::= INTEGER (0..MAX) 536 3. Manifest Generation 538 3.1. CA Manifest Generation 540 Each CA in the RPKI publishes the certificates and CRLs it issues at 541 a publication point in the RPKI repository system. To create a 542 manifest, each CA MUST perform the following steps: 544 1. Generate a key pair. 546 2. Issue a "single use" EE certificate for this key pair to enable 547 relying parties to verify the signature on the manifest. 549 * This EE certificate has an SIA extension access description 550 field with an accessMethod OID value of id-ad-signedobject 551 where the associated accessLocation references the publication 552 point of the manifest as an object URL. 554 * This EE certificate SHOULD describe its IP number resources 555 using the "inherit" attribute rather than explicit description 556 of a resource set. 558 * The validity times of the EE certificate SHOULD exactly match 559 the thisUpdate and nextUpdate times of the manifest, and MUST 560 encompass the interval from thisUpdate to nextUpdate. 562 3. The EE certificate SHOULD NOT be published in the authority's 563 repository publication point. 565 4. Construct the Manifest content. Note that the manifest does not 566 include a self reference (i.e., its own file name and hash), 567 since it would be impossible to compute the hash of the manifest 568 itself prior to it being signed. 570 5. Encapsulate the Manifest content using the CMS SignedData content 571 type (as specified in Section 2), sign the manifest using the EE 572 certificate, and publish the manifest in repository system 573 publication point that is described by the manifest. 575 6. The private key associated with the EE certificate SHOULD now be 576 destroyed. 578 3.2. End Entity Manifest Generation 580 EE repository publication points are only used in conjunction with 581 "multi-use" EE Certificates. In this case the EE Certificate has two 582 accessMethods specified in its SIA field. The id-ad- 583 signedObjectRepository accessMethod has an associated accessLocation 584 that points to the repository publication point of the objects signed 585 by this EE certificate, as specified in [ID.SIDR-CERTPROFILE]. The 586 id-ad-rpkiManifest accessMethod has an associated access location 587 that points to the manifest object as an object URL, that is 588 associated with this repository publication point. This manifest 589 describes all the signed objects that are to be found in that 590 publication point that have been signed by this EE certificate, and 591 the hash value of each product (excluding the manifest itself). 593 To create a manifest, each "multi-use" EE MUST perform the following 594 steps:. 596 o Construct the Manifest content. Note that the manifest does not 597 include a self reference (i.e., its own file name and hash), since 598 it would be impossible to compute the hash of the manifest itself 599 prior to it being signed. 601 o Encapsulate the Manifest content using the CMS SignedData content 602 type (as specified in Section 2), sign the manifest using the EE 603 certificate, and publish the manifest in repository system 604 publication point that is described by the manifest. 606 "Single Use" EE certificates do not have repository publication 607 points. The object signed by the "Single Use" EE certificate is 608 published in the repository publication point of the CA certificate 609 that issued the EE certificate, and is listed in the corresponding 610 manifest for this CA certificate. 612 3.3. Common Considerations for Manifest Generation 614 o A new manifest MUST be issued on or before the nextUpdate time. 615 o An authority MUST issue a new manifest in conjunction with the 616 finalization of changes made to objects in the publication point. 617 An authority MAY perform a number of object operations on a 618 publication repository within the scope of a repository change 619 before issuing a single manifest that covers all the operations 620 within the scope of this change. Repository operators SHOULD 621 implement some form of synchronization function on the repository 622 to ensure that relying parties who are performing retrieval 623 operations on the repository are not exposed to intermediate 624 states during changes to the repository and the associated 625 manifest. 626 o Since the manifest object URL is included in the SIA of issued 627 certificates then a new manifest MUST NOT invalidate the manifest 628 object URL of previously issued certificates. This implies that 629 the manifest's publication name in the repository, in the form of 630 an object URL, is one that is unchanged across manifest generation 631 cycles. 632 o As the manifest scope is all signed objects associated with an 633 authority responsible for a publication point, the manifest must 634 persist across key rollover events. This implies that this 635 persistent repository publication name cannot be derived from the 636 authority's current public key value in any way. 637 o In the case of a CA publication point manifest, when the CA is 638 performing a key rollover, the CA will use its new private key to 639 sign an EE certificate for a new manifest. The new manifest will 640 list all products of the CA that have been signed with the new 641 private key. The new manifest will start a new serial number 642 sequence. As long as there are published products that have been 643 signed with the to-be-retired key, the old CA associated with this 644 to-be-retired key will continue to generate manifests that 645 describe all published products of the to-be-retired key and 646 associated CA certificate. There is no manifest overlap. 647 o In the case of a EE publication point manifest, when the EE 648 certificate is re-keyed, a new publication point is established. 649 A new EE certificate for manifest validation will be generated by 650 the CA that issues the new EE certificate associated with the new 651 publication point. In this case there is no manifest overlap, as 652 the new repository publication point will have a distinct 653 manifest. 655 4. Processing Certificate Requests 657 When an EE certificate is intended for use in verifying multiple 658 objects, the certificate request for the EE certificate MUST include 659 in the SIA of the request an access method OID of id-ad- 660 signedObjectRepository where the associated access location refers to 661 the publication point for objects signed by this EE certificate, and 662 MUST include in the SIA of the request an access method OID of id-ad- 663 rpkiManifest, where the associated access location refers to the 664 publication point of the manifest that is associated with published 665 objects that are verified using this EE certificate 666 [ID.SIDR-CERTPROFILE]. The issuer SHOULD honour these values in the 667 issued certificate or MUST reject the Certificate Request. 669 When an EE certificate is used to sign a single object, the 670 certificate request for the EE certificate MUST include in the SIA of 671 the request an access method OID of id-ad-signedObject, where the 672 associated access location refers to the publication point of the 673 single object that is verified using this EE certificate. The 674 certificate request MUST NOT include in the SIA of the request the 675 access method OID of id-ad-rpkiManifest. The issuer SHOULD honour 676 these values in the issued certificate or MUST reject the Certificate 677 Request. 679 In accordance with the provisions of [ID.SIDR-CERTPROFILE], all 680 certificate issuance requests for a CA certificate SHOULD include in 681 the SIA of the request the id-ad-caRepository access method, and also 682 the id-ad-rpkiManifest access method that references the intended 683 publication point of the manifest in the associated access location 684 in the request. The issuer SHOULD honour these values in the issued 685 certificate or MUST reject the Certificate Request. 687 5. Manifest Validation 689 To determine whether a manifest is valid, the relying party must 690 perform the following checks: 692 1. Verify that the Manifest complies with this specification. In 693 particular, verify the following: 695 A. The contentType of the CMS object is SignedData (OID 696 1.2.840.113549.1.7.2) 698 B. The version of the SignedData object is 3. 700 C. The digestAlgorithm in the SignedData object is SHA-256 (OID 701 2.16.840.1.101.3.4.2.1). 703 D. The certificates field in the SignedData object is present 704 and contains an EE certificate whose Subject Key Identifier 705 (SKI) matches the sid field of the SignerInfo object. 707 E. The crls field in the SignedData object is omitted. 709 F. The eContentType in the EncapsulatedContentInfo is id-ad- 710 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 712 G. The version of the rpkiManifest is 0. 714 H. In the rpkiManifest, thisUpdate precedes nextUpdate. 716 I. The version of the SignerInfo is 3. 718 J. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 719 2.16.840.1.101.3.4.2.1). 721 K. The signatureAlgorithm in the SignerInfo object is RSA (OID 722 1.2.840.113549.1.1.1). 724 L. The signedAttrs field in the SignerInfo object is present and 725 contains both the ContentType attribute (OID 726 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 727 1.2.840.113549.1.9.4). 729 M. The unsignedAttrs field in the SignerInfo object is omitted. 731 2. Use the public key in the EE certificate to verify the signature 732 on the Manifest. 734 3. Verify that the EE certificate is a valid end-entity certificate 735 in the resource PKI by constructing a valid certificate path to a 736 trust anchor. (See [ID.RESCERT] for more details.) 738 If the above procedure indicates that the manifest is invalid, then 739 the manifest MUST be discarded and treated as though no manifest were 740 present. 742 6. Relying Party Use of Manifests 744 The goal of the relying party is to determine which signed objects to 745 use for routing-related tasks, (e.g. which ROAs to use in the 746 construction of route filters). Ultimately, this is a matter of 747 local policy. However, in the following sections, we describe a 748 sequence of tests that the relying party should perform to determine 749 the manifest state of the given publication point. We then discuss 750 the risks associated with using signed objects in the publication 751 point, given the manifest state; and provide suitable warning text 752 that should placed in a user-accessible log file. It is the 753 responsibility of the relying party to weigh these risks against the 754 risk of routing failure that could occur if valid data is rejected, 755 and construct a suitable local policy. Note that if a certificate is 756 deemed unfit for use do to local policy, then any descendent object 757 that is validated using this certificate should also be deemed unfit 758 for use (regardless of the status of the manifest at its own 759 publication point). 761 6.1. Tests for Determining Manifest State 763 For a given publication point, the relying party should perform the 764 following tests to determine the manifest state of the publication 765 point: 767 1. Select the manifest having highest manifestNumber among all valid 768 manifests (where manifest validity is defined in Section 5). 770 * If the publication point does not contain a valid manifest, 771 see Section 6.2. (Lacking a valid manifest, the following 772 tests cannot be performed). 774 2. Check that the current time is between thisUpdate and nextUpdate. 776 * If the current time does not lie in this interval then see 777 Section 6.4 (but still continue with the following tests). 779 3. Check that every file at the publication point appears on the 780 manifest, and that every file on the manifest appears at the 781 publication point. 783 * If there exists files at the publication point that do not 784 appear on the manifest, or files on the manifest that do not 785 appear at the publication point then see Section 6.5 (but 786 still continue with the following test). 788 4. Check that the hash of every file listed on the manifest matches 789 the value obtained by hashing the file in at the publication 790 point. 792 * If there exist files at the publication point whose hash does 793 not match the hash value listed in the manifest, then see 794 Section 6.6. 796 For a particular signed object, if (A) the manifest for its 797 publication passes all of the above checks; (B) the signed object is 798 valid; and (C) the manifests for every certificate on the certificate 799 path used to validate the signed object pass all of the above checks; 800 then the relying party can conclude that no attack against the 801 repository system has compromised the given signed object and the 802 signed object MUST be treated as valid. 804 6.2. Missing Manifests 806 The absence of a valid manifest at a publication could occur due to 807 an error by the publisher or due to (malicious or accidental) 808 deletion or corruption of all valid manifests. 810 When no valid manifest is available, there is no protection against 811 attacks that delete signed objects or replay old versions of signed 812 objects. All signed objects at the publication point, and all 813 descendent objects that are validated using a certificate at this 814 publication point should be viewed as somewhat suspect, but may be 815 used by the relying party as per local policy. 817 The primary risk in using signed objects at this publication point is 818 that a deleted CRL causes the relying party to improperly treat a 819 revoked certificate as valid. This risk is somewhat mitigated if the 820 CRL for this publication point has a short time between thisUpdate 821 and nextUpdate (and the current time is within this interval). The 822 risk in discarding signed objects at this publication point is that 823 the relying party may incorrectly discard a large number of valid 824 objects. This gives significant power to an adversary that is able 825 to corrupt all manifests at the publication point. 827 Regardless of whether signed objects from this publication are deemed 828 fit for use by the relying party, this situation should result in a 829 warning to the effect that: "No manifest is available for , and thus there may have been undetected deletions from the 831 publication point." 833 6.3. Invalid Manifests 835 The presence of invalid manifests at a publication point could occur 836 due to an error by the publisher or due to (malicious or accidental) 837 corruption of a valid manifest. An invalid manifest MUST never be 838 used even if the manifestNumber is greater than that on valid 839 manifests. 841 There are no risks associated with using signed objects at a 842 publication point containing an invalid manifest, provided that a 843 valid manifest is also present. 845 If an invalid manifest is present at a publication point that also 846 contains one or more valid manifests, this situation should result in 847 a warning to the effect that: "An invalid manifest was found at , this indicates an attack against the publication point 849 or an error by the publisher. Processing for this publication point 850 will continue using the most recent valid manifest." 852 6.4. Stale Manifests 854 A manifest is considered stale if the current time is after the 855 nextUpdate time for the manifest. This could be due to publisher 856 failure to promptly publish a new manifest, or due to (malicious or 857 accidental) corruption of a more recent manifest. 859 All signed objects at the publication point, and all descendent 860 objects that are validated using a certificate at this publication 861 point should be viewed as somewhat suspect, but may be used by the 862 relying party as per local policy. 864 The primary risk in using signed objects at this publication point is 865 that a newer manifest exists that, if present, would indicate that 866 certain objects are have been removed or replaced. (E.g. the new 867 manifest if present might show the existence of a newer CRL and the 868 removal of several revoked certificates). Thus use of objects on a 869 stale manifest may cause the relying party to incorrectly treat 870 several invalid objects as valid. The risk is that a stale CRL 871 causes the relying party to improperly treat a revoked certificate as 872 valid. This risk is somewhat mitigated if the time between the 873 nextUpdate field of the manifest and the current time is short. The 874 risk in discarding signed objects at this publication point is that 875 the relying party may incorrectly discard a large number of valid 876 objects. This gives significant power to an adversary that is able 877 to prevent the publication of a new manifest at a given publication 878 point. 880 Regardless of whether signed objects from this publication are deemed 881 fit for use by the relying party, this situation should result in a 882 warning to the effect that: "The manifest for is no 883 longer current. It is possible that undetected deletions have 884 occurred at this publication point." 886 Note that there is also a less common case where the current time is 887 before the thisUpdate time for the manifest. This case is 888 necessarily due to publisher error and in such a case this situation 889 should result in a warning to the effect that: "The manifest found at 890 has an incorrect thisUpdate field. This is due to 891 publisher error, and processing for this publication point will 892 continue using this otherwise valid manifest." 894 6.5. Files Not on Manifests (or Missing from a Publication Point) 896 If there exist otherwise valid signed objects that do not appear on 897 any manifest, then provided the manifest is not stale (see Section 898 6.4) it is likely that their omission is an error by the publisher. 899 (If the objects were intended to be invalid, then they should have 900 been revoked using whatever revocation mechanism is appropriate for 901 the signed object in question.) Therefore, there is little risk in 902 using such signed objects. If the manifest in question is stale, 903 then there is a greater risk that the objects in question were 904 revoked with a missing CRL (whose absence is undetectable since the 905 manifest is stale). In any case, the use of signed objects not 906 present on a manifest (or descendent objects that are validated using 907 such signed objects) is a matter of local policy. 909 Regardless of whether objects not appearing on a manifest are deemed 910 fit for use by the relying party, this situation should result in a 911 warning to the effect that: "The following files are present in the 912 repository at , but are not on the manifest ." 915 If there exist files listed on the manifest that do not appear in the 916 repository, then these objects are likely to have been improperly 917 (via malice or accident) deleted from the manifest. A primary 918 purpose of manifests is to detect such deletions. Therefore, in such 919 a case this situation should result in a warning to the effect that: 920 "The following files that should have been present in the repository 921 at , are missing . This indicates an 922 attack against this publication point, or the repository, or an error 923 by the publisher." 925 6.6. Hash Values Not Matching Manifests 927 A file appearing on a manifest with an incorrect hash value could 928 occur because of publisher error, but it is likely to indicate that a 929 serious error has occurred. 931 If an object appeared on a previous valid manifest with a correct 932 hash value and now appears with an invalid hash value, then it is 933 likely that the object has been superceded by a new (unavailable) 934 version of the object. If the object is used there is a risk that 935 the relying party will be treating a stale object as valid. This 936 risk is more significant if the object in question is a CRL. 937 Assuming that the object is validated in the RPKI, the use of these 938 objects is a matter of local policy. 940 If an object appears on a manifest with an invalid hash and has never 941 previously appeared on a manifest, then it is unclear whether the 942 available version of the object is more or less recent than the 943 version whose hash appears in the manifest. If the manifest is stale 944 (see Section 6.4) then it becomes more likely that the available 945 version is more recent that the version indicated on the manifest, 946 but this is never certain. Whether to use such objects is a matter 947 of local policy. However, in general, it is better to use a possibly 948 outdated version of the object, then to discard the object 949 completely. 951 Regardless of whether objects with incorrect hashes are deemed fit 952 for use by the relying party, this situation should result in a 953 warning to the effect that: "The following files at the repository 954 appear on a manifest with incorrect hash values 955 . It is likely that these objects have been superseded by 956 a more recent version. It is very likely that this problem is due to 957 an attack on the publication point, although it could be due to a 958 publisher error." 960 7. Publication Repositories 962 The RPKI publication system model requires that every publication 963 point be associated with a CA or an EE, and be non-empty. Upon 964 creation of the publication point associated with a CA, the CA MUST 965 create and publish a manifest as well as a CRL. The manifest will 966 contain at least one entry, the CRL issued by the CA upon repository 967 creation. Upon the creation of the publication point associated with 968 an EE, the EE MUST create and publish a manifest. The manifest in an 969 otherwise empty repository publication point associated with an EE 970 will contain no entries in the manifest's fileList sequence (i.e. a 971 sequence of length zero). [ID.SIDR-REPOSITORY] 973 For signed objects EE certificate used in the verification of such 974 objects is either a single-use certificate, used to verify a single 975 signed object, or a multiple-use certificate. In the case of a 976 single-use EE certificate, the signed object is published in the 977 repository publication point of the CA that issued the single use EE 978 certificate, and is listed in the manifest associated with that CA 979 certificate. In the case where the EE certificate is used to verify 980 multiple objects, signed object is published in the EE certificate's 981 repository publication point and listed in the manifest associated 982 with the EE certificate. 984 8. Security Considerations 986 Manifests provide an additional level of protection for users of the 987 repository system. Manifests can assist the user to determine if 988 repository objects have been occluded or other removed from view, and 989 to determine if an older version of an object has been substituted 990 for the current object. 992 Manifests cannot repair the effects of such forms of attempted 993 corruption of repository retrieval operations, but are capable of 994 allowing the user to determine if a locally maintained copy of a 995 repository is a complete and up to date copy, even when the 996 repository retrieval operation is conduction over an insecure 997 channel. In those cases where the manifest and the retrieved 998 repository contents differ, the manifest can assist in determining 999 which repository objects form the difference set in terms of missing, 1000 extraneous or older objects. 1002 The signing structure of a manifest and the use of next update times 1003 allows the user to determine if the manifest itself is the subject of 1004 attempted alteration. The requirement for all repositories to 1005 contain manifests allows the user to determine is the manifest itself 1006 has been occluded from view. Such attacks against the manifest are 1007 detectable within the timeframe of the regular schedule of manifest 1008 updates. Forms of replay attack within finer-grained timeframes are 1009 not necessarily detectable by the manifest structure. 1011 9. IANA Considerations 1013 [Note to IANA, to be removed prior to publication: there are no IANA 1014 considerations stated in this version of the document.] 1016 10. Acknowledgements 1018 The authors would like to acknowledge the contributions from George 1019 Michaelson and Randy Bush in the preparation of the manifest 1020 specification. Additionally, the authors would like to thank Mark 1021 Reynolds and Christopher Small for assistance in clarifying manifest 1022 validation and relying party behavior. 1024 11. Normative References 1026 [ID.SIDR-ARCH] 1027 Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure 1028 to Support Secure Internet Routing", Work in progress: 1029 Internet Drafts draft-ietf-sidr-arch-03.txt, 1030 February 2008. 1032 [ID.SIDR-CERTPROFILE] 1033 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 1034 X.509 PKIX Resource Certificates", Work in progress: 1035 Internet Drafts draft-ietf-sidr-res-certs-10.txt, 1036 June 2008. 1038 [ID.SIDR-REPOSITORY] 1039 Huston, G., Loomans, R., and G. Michaleson, "A Profile for 1040 Resource Certificate Repository Structure", Work in 1041 progress: Internet 1042 Drafts draft-huston-sidr-repos-struct-02.txt, June 2008. 1044 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1045 Addresses and AS Identifiers", RFC 3779, June 2004. 1047 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1048 RFC 3852, July 2004. 1050 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 1051 Representing Date and Time in ASN.1", RFC 4049, 1052 April 2005. 1054 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1055 Algorithms and Identifiers for RSA Cryptography for use in 1056 the Internet X.509 Public Key Infrastructure Certificate 1057 and Certificate Revocation List (CRL) Profile", RFC 4055, 1058 June 2005. 1060 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1061 Housley, R., and W. Polk, "Internet X.509 Public Key 1062 Infrastructure Certificate and Certificate Revocation List 1063 (CRL) Profile", RFC 5280, May 2008. 1065 Authors' Addresses 1067 Rob Austein 1068 Internet Systems Consortium 1069 950 Charter St. 1070 Redwood City, CA 94063 1071 USA 1073 Email: sra@isc.org 1075 Geoff Huston 1076 Asia Pacific Network Information Centre 1077 33 park Rd. 1078 Milton, QLD 4064 1079 Australia 1081 Email: gih@apnic.net 1082 URI: http://www.apnic.net 1084 Stephen Kent 1085 BBN Technologies 1086 10 Moulton St. 1087 Cambridge, MA 02138 1088 USA 1090 Email: kent@bbn.com 1092 Matt Lepinski 1093 BBN Technologies 1094 10 Moulton St. 1095 Cambridge, MA 02138 1096 USA 1098 Email: mlepinski@bbn.com 1100 Full Copyright Statement 1102 Copyright (C) The IETF Trust (2008). 1104 This document is subject to the rights, licenses and restrictions 1105 contained in BCP 78, and except as set forth therein, the authors 1106 retain all their rights. 1108 This document and the information contained herein are provided on an 1109 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1110 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1111 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1112 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1113 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1114 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1116 Intellectual Property 1118 The IETF takes no position regarding the validity or scope of any 1119 Intellectual Property Rights or other rights that might be claimed to 1120 pertain to the implementation or use of the technology described in 1121 this document or the extent to which any license under such rights 1122 might or might not be available; nor does it represent that it has 1123 made any independent effort to identify any such rights. Information 1124 on the procedures with respect to rights in RFC documents can be 1125 found in BCP 78 and BCP 79. 1127 Copies of IPR disclosures made to the IETF Secretariat and any 1128 assurances of licenses to be made available, or the result of an 1129 attempt made to obtain a general license or permission for the use of 1130 such proprietary rights by implementers or users of this 1131 specification can be obtained from the IETF on-line IPR repository at 1132 http://www.ietf.org/ipr. 1134 The IETF invites any interested party to bring to its attention any 1135 copyrights, patents or patent applications, or other proprietary 1136 rights that may cover technology that may be required to implement 1137 this standard. Please address the information to the IETF at 1138 ietf-ipr@ietf.org. 1140 Acknowledgment 1142 Funding for the RFC Editor function is provided by the IETF 1143 Administrative Support Activity (IASA).