idnits 2.17.1 draft-ietf-sidr-rpki-manifests-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors 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 (December 6, 2009) is 5249 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 564 -- Looks like a reference, but probably isn't: '1' on line 560 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-08 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.sidr-arch') == Outdated reference: A later version (-09) exists of draft-ietf-sidr-repos-struct-02 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-16 ** Downref: Normative reference to an Informational draft: draft-huston-sidr-rpki-algs (ref. 'I-D.sidr-rpki-algs') ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: June 9, 2010 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 December 6, 2009 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-06.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 9, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the BSD License. 52 Abstract 54 This document defines a "manifest" for use in the Resource Public Key 55 Infrastructure. A manifest is a signed object that contains a 56 listing of all the signed objects in the repository publication point 57 associated with an authority responsible for publishing in the 58 repository. For each certificate, CRL, or other type of signed 59 objects issued by the authority that are published at this repository 60 publication point, the manifest contains both the name of the file 61 containing the object, and a hash of the file content. Manifests are 62 intended to enable a relying party to detect certain forms of attacks 63 against a repository. Specifically, a relying party that checks a 64 manifest against the signed objects retrieved from a repository 65 publication point can detect "stale" (valid) data and deletion of 66 signed objects. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Manifest Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 6 76 4.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 6 77 4.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 6 78 4.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 7 79 4.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 9 80 4.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . 9 82 4.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 14 84 5.1. CA Manifest Generation . . . . . . . . . . . . . . . . . . 14 85 5.2. End Entity Manifest Generation . . . . . . . . . . . . . . 15 86 5.3. Common Considerations for Manifest Generation . . . . . . 16 87 6. Processing Certificate Requests . . . . . . . . . . . . . . . 17 88 7. Manifest Validation . . . . . . . . . . . . . . . . . . . . . 18 89 8. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 19 90 8.1. Tests for Determining Manifest State . . . . . . . . . . . 19 91 8.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 21 92 8.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 22 93 8.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 22 94 8.5. Mismatch between Manifest and Publication Point . . . . . 23 95 8.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 24 96 9. Publication Repositories . . . . . . . . . . . . . . . . . . . 25 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 98 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 99 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 100 13. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 13.1. Changes in the draft from -04 to -05 . . . . . . . . . . . 26 102 13.2. Changes in the draft from -05 to -06 . . . . . . . . . . . 26 103 14. Normative References . . . . . . . . . . . . . . . . . . . . . 26 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 The Resource Public Key Infrastructure (RPKI) [I-D.sidr-arch] makes 109 use of a distributed repository system [I-D.sidr-repos-struct] to 110 make available a variety of objects needed by relying parties (RPs) 111 such as Internet service providers (ISPs). Because all of the 112 objects stored in the repository system are digitally signed by the 113 entities that created them, attacks that modify these objects are 114 detectable by RPs. However, digital signatures provide no protection 115 against attacks that substitute "stale" versions of signed objects 116 (i.e., objects that were valid and have not expired, but have since 117 been superseded) or attacks that remove an object that should be 118 present in the repository. To assist in the detection of such 119 attacks, the RPKI repository system will make use of a signed object 120 called a "manifest". 122 A manifest is a signed object that contains a listing of all the 123 signed objects in the repository publication point associated with an 124 authority responsible for publishing in the repository. For each 125 signed object issued by an authority, the authority's manifest 126 contains both the name of the file containing the object, and a hash 127 of the file content. Manifests allow a RP to obtain sufficient 128 information to detect whether the retrieval of objects from an RPKI 129 repository has been compromised by unauthorized object removal, or by 130 the substitution of "stale" versions of objects. Manifests are 131 designed to be used both for Certification Authority (CA) publication 132 points in repositories, that contain subordinate certificates, CRLs 133 and other signed objects, and End Entity (EE) publication points in 134 repositories that contain signed objects. 136 Manifests are modeled on CRLs, as the issues involved in detecting 137 stale manifests, and detection of potential attacks using manifest 138 replays, etc are similar to those for CRLs. The syntax of the 139 manifest payload differs from CRLs, since RPKI repositories can 140 contain objects not covered by CRLs, such as digitally signed 141 objects, such as ROAs. 143 1.1. Terminology 145 It is assumed that the reader is familiar with the terms and concepts 146 described in "Internet X.509 Public Key Infrastructure Certificate 147 and Certificate Revocation List (CRL) Profile" [RFC5280]> and "X.509 148 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119. 154 2. Manifest Scope 156 In the case of a CA's manifest for it's associated repository 157 publication point, the manifest contains the current published 158 certificates issued by this CA, the most recent CRL issued by this 159 CA, and all objects that are signed using a "single-use" EE 160 certificate (i.e., the SIA extension of the EE certificate has an 161 accessMethod OID of id-ad-signedObject), where the EE certificate was 162 issued by this CA. 164 In the case where multiple CAs share a common publication point, as 165 may be the case when an entity performs a staged key-rollover 166 operation, the repository publication point will contain multiple 167 manifests. In such a scenario, each manifest describes only the 168 collection of published products of its associated CA. 170 In the case of a "multi-use" EE certificate, where an EE has a 171 defined repository publication point (i.e., the SIA extension of the 172 EE certificate has an accessMethod OID of id-ad- 173 signedObjectRepository), the EE's manifest contains all published 174 objects that have been signed by the EE's key, and the accessMethod 175 id-as-rpkiManifest points to the publication point of the EE's 176 manifest. 178 3. Manifest Signing 180 A CA's manifest is verified using an EE certificate that is 181 designated in [I-D.sidr-res-certs] as a "single-use" EE certificate. 182 The SIA field of the "single-use" EE certificate contains the access 183 method OID of id-ad-signedObject. 185 The CA MAY chose to sign only one manifest with the private key of 186 the EE certificate, and generate a new EE certificate for each new 187 version of the manifest. This form of use of a "single-use" EE 188 certificate is termed a "one-time-use" EE certificate. 190 Alternatively the CA MAY chose to use the same EE certificate's 191 private key to sign a sequence of manifests. Because only a single 192 manifest is current at any point in time, the EE certificate is used 193 only to verify a single object at a time. As long as the sequence of 194 objects signed by this EE certificate's private key are published as 195 the same named object, so that the SIA accessMethod id-ad- 196 signedObject value can refer to the current instance of the sequence 197 of such objects, then this sequential multiple use of this "single- 198 use" EE certificate is also valid. This form of use of a "single- 199 use" EE certificate is termed a "sequential-use" EE certificate. 201 A "multi-use" EE's manifest of it's publication repository is signed 202 with the private key of the EE certificate. 204 4. Manifest Syntax 206 A manifest is a Cryptographic Message Syntax (CMS) [RFC5652] signed- 207 data object. The general format of a CMS object is: 209 ContentInfo ::= SEQUENCE { 210 contentType ContentType, 211 content [0] EXPLICIT ANY DEFINED BY contentType } 213 ContentType ::= OBJECT IDENTIFIER 215 The ContentType is the signed-data type of id-data, namely the id- 216 signedData OID, 1.2.840.113549.1.7.2. [RFC5652] 218 4.1. Signed-Data Content Type 220 According to the CMS specification, signed-data content types have 221 the ASN.1 type SignedData: 223 SignedData ::= SEQUENCE { 224 version CMSVersion, 225 digestAlgorithms DigestAlgorithmIdentifiers, 226 encapContentInfo EncapsulatedContentInfo, 227 certificates [0] IMPLICIT CertificateSet OPTIONAL, 228 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 229 signerInfos SignerInfos } 231 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 233 SignerInfos ::= SET OF SignerInfo 235 4.1.1. version 237 The version is the syntax version number. It MUST be 3, 238 corresponding to the signerInfo structure having version number 3. 240 4.1.2. digestAlgorithms 242 The digestAlgorithms set contains a set of OIDs of the algorithms 243 used to sign the data. The algorithms used to sign the data MUST 244 conform to the RPKI Algorithms and Key Size Profile specification 245 [I-D.sidr-rpki-algs]. 247 4.1.3. encapContentInfo 249 encapContentInfo is the signed content, consisting of a content type 250 identifier and the content itself. 252 EncapsulatedContentInfo ::= SEQUENCE { 253 eContentType ContentType, 254 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 256 ContentType ::= OBJECT IDENTIFIER 258 4.1.3.1. eContentType 260 The eContentType for a Manifest is defined as id-ct-rpkiManifest, and 261 has the numerical value of 1.2.840.113549.1.9.16.1.26. 263 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 264 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 266 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 268 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 270 4.1.3.2. eContent 272 The content of a Manifest is defined as follows: 274 Manifest ::= SEQUENCE { 275 version [0] INTEGER DEFAULT 0, 276 manifestNumber INTEGER, 277 thisUpdate GeneralizedTime, 278 nextUpdate GeneralizedTime, 279 fileHashAlg OBJECT IDENTIFIER, 280 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash 281 } 283 FileAndHash ::= SEQUENCE { 284 file IA5String 285 hash BIT STRING 286 } 288 4.1.3.2.1. Manifest 290 The manifestNumber, thisUpdate, and nextUpdate fields are modeled 291 after the corresponding fields in X.509 CRLs (see [RFC5280]). 292 Analogous to CRLS, a manifest is nominally current until the time 293 specified in nextUpdate or until a manifest is issued with a greater 294 manifest number, whichever comes first. The revoked EE certificate 295 for the previous manifest's signature will be removed from the CRL 296 when it expires. 298 If a "one-time-use" EE certificate is employed to verify a manifest, 299 the EE certificate MUST have an validity period that coincides with 300 the interval from thisUpdate to nextUpdate, to prevent needless 301 growth of the CA's CRL. 303 If a "sequential-use EE certificate is employed to verify a manifest, 304 the EE certificate's validity period needs to be no shorter than the 305 nextUpdate time of the current manifest. The extended validity time 306 raises the possibility of a substitution attack using a stale 307 manifest, as described in Section 8.4. 309 4.1.3.2.1.1. version 311 The version number of this version of the manifest specification is 312 0. 314 4.1.3.2.1.2. manifestNumber 316 The manifestNumber field is a sequence number that is incremented 317 each time a new manifest is issued for a given publication point. 318 This field is used to allow a RP to detect gaps in a sequence of 319 published manifest. 321 4.1.3.2.1.3. thisUpdate 323 The thisUpdate field contains the time when the manifest was created. 325 4.1.3.2.1.4. nextUpdate 327 The nextUpdate field contains the time at which the next scheduled 328 manifest will be issued. The value of nextUpdate MUST be later than 329 the value of thisUpdate. If the authority alters any of the items in 330 the repository publication point, then the authority MUST issue a new 331 manifest before the nextUpdate time. If a manifest encompasses a 332 CRL, the nextUpdate field of the manifest MUST match that of the CRL, 333 as the manifest will be reissued when a new CRL is published. If a 334 "one-time-use" EE certificate is used to verify the manifest, then 335 when a new manifest is issued before the time specified in nextUpdate 336 of the current manifest, the CA MUST also issue a new CRL that 337 includes the EE certificate corresponding to the old manifest. 339 4.1.3.2.1.5. fileHashAlg 341 The fileHashAlg field contains the OID of the hash algorithm used to 342 hash the files that the authority has placed into the repository. 344 The hash algorithm used MUST conform to the RPKI Algorithms and Key 345 Size Profile specification [I-D.sidr-rpki-algs]. 347 4.1.3.2.1.6. fileList 349 The fileList field is a sequence of FileAndHash objects. There is 350 one FileAndHash entry for each currently valid signed object that has 351 been issued by the authority. Each FileAndHash is an ordered pair 352 consisting of the name of the file in the repository that contains 353 the object in question, and a hash of the file's contents. 355 4.1.4. certificates 357 The certificates field MUST be included, and MUST contain the RPKI EE 358 certificate needed to validate this manifest in the context of the 359 RPKI. 361 4.1.5. crls 363 This field MUST be omitted. 365 4.1.6. signerInfos 367 Signer Infos is defined as a SignerInfo, which is defined under CMS 368 as: 370 SignerInfo ::= SEQUENCE { 371 version CMSVersion, 372 sid SignerIdentifier, 373 digestAlgorithm DigestAlgorithmIdentifier, 374 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 375 signatureAlgorithm SignatureAlgorithmIdentifier, 376 signature SignatureValue, 377 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 379 4.1.6.1. version 381 The version number MUST be 3, corresponding with the choice of 382 SubjectKeyIdentifier for the sid. 384 4.1.6.2. sid 386 The sid is defined as: 388 SignerIdentifier ::= CHOICE { 389 issuerAndSerialNumber IssuerAndSerialNumber, 390 subjectKeyIdentifier [0] SubjectKeyIdentifier } 392 For a Manifest, the sid MUST be a SubjectKeyIdentifier. 394 4.1.6.3. digestAlgorithm 396 The digestAlgorithm field contains the OIDs of the algorithm used to 397 sign the data. The algorithm used to sign the data MUST conform to 398 the RPKI Algorithms and Key Size Profile specification 399 [I-D.sidr-rpki-algs]. 401 4.1.6.4. signedAttrs 403 The signedAttrs is defined as signedAttributes: 405 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 407 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 409 Attribute ::= SEQUENCE { 410 attrType OBJECT IDENTIFIER, 411 attrValues SET OF AttributeValue } 413 AttributeValue ::= ANY 415 The signedAttr element MUST be present and MUST include the content- 416 type and message-digest attributes. The signer MAY also include the 417 signing-time signed attribute, the binary-signing-time signed 418 attribute, or both signing-time attributes. Other signed attributes 419 that are deemed appropriate MAY also be included. The intent is to 420 allow additional signed attributes to be included if a future need is 421 identified. This does not cause an interoperability concern because 422 unrecognized signed attributes are ignored by the relying party. 424 The signedAttr MUST include only a single instance of any particular 425 attribute. Additionally, even though the syntax allows for a SET OF 426 AttributeValue, in a Manifest the attrValues MUST consist of only a 427 single AttributeValue. 429 4.1.6.4.1. Content-Type Attribute 431 The ContentType attribute MUST be present. The attrType OID for the 432 ContentType attribute is 1.2.840.113549.1.9.3. 434 The attrValues for the ContentType attribute in a Manifest MUST be 435 1.2.840.113549.1.9.16.1.26, matching the eContentType in the 436 EncapsulatedContentInfo. 438 4.1.6.4.2. Message-Digest Attribute 440 The MessageDigest Attribute MUST be present. The attrType OID for 441 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 443 The attrValues for the MessageDigest attribute contains the output of 444 the digest algorithm applied to the content being signed, as 445 specified in Section 11.1 of [RFC5652]. 447 4.1.6.4.3. SigningTime Attribute 449 The SigningTime attribute MAY be present. The presence of absence of 450 the SigningTime attribute in no way affects the validation of the 451 Manifest (as specified in Section Section 7). 453 The attrType OID for the SigningTime attribute is 454 1.2.840.113549.1.9.5. 456 The attrValues for the SigningTime attribute is defined as: 458 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 459 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 461 SigningTime ::= Time 463 Time ::= CHOICE { 464 utcTime UTCTime, 465 generalizedTime GeneralizedTime } 467 The Time element specifies the time, based on the local system clock, 468 at which the digital signature was applied to the content. 470 4.1.6.4.4. BinarySigningTime Attribute 472 The signer MAY include a BinarySigningTime attribute, specifying the 473 time at which the digital signature was applied to the content. If 474 both the BinarySigningTime and SigningTime attributes are present, 475 the time that is represented by the binary-signing-time attribute 476 MUST represent the same time value as the signing-time attribute. 477 The presence or absence of the Binary-SigningTime attribute in no way 478 affects the validation of the Manifest (as specified in Section 479 Section 7). 481 The binary-signing-time attribute is defined in [RFC4049] as: 483 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 484 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 485 smime(16) aa(2) 46 } 487 BinarySigningTime ::= BinaryTime 489 BinaryTime ::= INTEGER (0..MAX) 491 4.1.6.5. signatureAlgorithm 493 The signatureAlgorithm MUST conform to the RPKI Algorithms and Key 494 Size Profile specification [I-D.sidr-rpki-algs]. 496 4.1.6.6. signature 498 The signature value is defined as: 500 SignatureValue ::= OCTET STRING 502 The signature characteristics are defined by the digest and signature 503 algorithms. 505 4.1.6.7. unsignedAttrs 507 unsignedAttrs MUST be omitted. 509 4.2. ASN.1 511 The following is the ASN.1 specification of the CMS-signed Manifest. 513 ContentInfo ::= SEQUENCE { 514 contentType ContentType, 515 content [0] EXPLICIT ANY DEFINED BY contentType } 517 ContentType ::= OBJECT IDENTIFIER 519 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 520 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 522 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 524 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 526 Manifest ::= SEQUENCE { 527 version [0] INTEGER DEFAULT 0, 528 manifestNumber INTEGER, 529 thisUpdate GeneralizedTime, 530 nextUpdate GeneralizedTime, 531 fileHashAlg OBJECT IDENTIFIER, 532 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash} 534 FileAndHash ::= SEQUENCE { 535 file IA5String 536 hash BIT STRING} 538 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 539 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 541 SignedData ::= SEQUENCE { 542 version CMSVersion, 543 digestAlgorithms DigestAlgorithmIdentifiers, 544 encapContentInfo EncapsulatedContentInfo, 545 certificates [0] IMPLICIT CertificateSet OPTIONAL, 546 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 547 signerInfos SignerInfos } 549 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 551 SignerInfos ::= SET OF SignerInfo 553 SignerInfo ::= SEQUENCE { 554 version CMSVersion, 555 sid SignerIdentifier, 556 digestAlgorithm DigestAlgorithmIdentifier, 557 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 558 signatureAlgorithm SignatureAlgorithmIdentifier, 559 signature SignatureValue, 560 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 562 SignerIdentifier ::= CHOICE { 563 issuerAndSerialNumber IssuerAndSerialNumber, 564 subjectKeyIdentifier [0] SubjectKeyIdentifier } 566 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 568 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 570 Attribute ::= SEQUENCE { 571 attrType OBJECT IDENTIFIER, 572 attrValues SET OF AttributeValue } 574 AttributeValue ::= ANY 576 SignatureValue ::= OCTET STRING 578 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 579 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 581 ContentType ::= OBJECT IDENTIFIER 583 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 584 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 586 MessageDigest ::= OCTET STRING 588 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 589 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 591 SigningTime ::= Time 593 Time ::= CHOICE { 594 utcTime UTCTime, 595 generalizedTime GeneralizedTime } 597 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 598 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 599 smime(16) aa(2) 46 } 601 BinarySigningTime ::= BinaryTime 603 BinaryTime ::= INTEGER (0..MAX) 605 5. Manifest Generation 607 5.1. CA Manifest Generation 609 Each CA in the RPKI publishes the certificates and CRLs it issues at 610 a publication point in the RPKI repository system. To create a 611 manifest, each CA MUST perform the following steps: 613 1. If no key pair exists, or if using a "one-time-use" EE 614 certificate with a new key pair, generate a key pair. 616 2. If using a "one-time-use" EE certificate, or if a key pair was 617 generated in step 1, issue a "single-use" EE certificate for this 618 key pair. 620 * This EE certificate has an SIA extension access description 621 field with an accessMethod OID value of id-ad-signedobject 622 where the associated accessLocation references the publication 623 point of the manifest as an object URL. 625 * This EE certificate MUST describe its IP number resources 626 using the "inherit" attribute, rather than explicit 627 description of a resource set. 629 * In the case of a "one-time-use" EE certificate, the validity 630 times of the EE certificate SHOULD exactly match the 631 thisUpdate and nextUpdate times of the manifest, and MUST 632 encompass the interval from thisUpdate to nextUpdate. 634 * In the case of a "sequential-use" EE certificate the validity 635 times of the EE certificate MUST encompass the time interval 636 from thisUpdate to nextUpdate. 638 3. The EE certificate SHOULD NOT be published in the authority's 639 repository publication point. 641 4. Construct the manifest content. Note that the manifest does not 642 include a self reference (i.e., its own file name and hash), 643 since it would be impossible to compute the hash of the manifest 644 itself prior to it being signed. The manifest content is 645 described in Section 4.1.3.2.1. The manifest's fileList includes 646 the file names and hash pair for each object issued by this CA 647 that has been published at this CA's repository publication 648 point. The collection of objects to be included in the manifest 649 includes all certificates issued by this CA that are published at 650 the CA's repository publication point, the most recent CRL issued 651 by the CA, and all objects verified by "single-use" EE 652 certificates that were issued by this CA that are published at 653 the CA's repository publication point. 655 5. Encapsulate the Manifest content using the CMS SignedData content 656 type (as specified in Section Section 4), sign the manifest using 657 the private key corresponding to the EE certificate, and publish 658 the manifest in repository system publication point that is 659 described by the manifest. 661 6. In the case of a key pair that is to be used only once, in 662 conjunction with a "one-time-use" EE certificate, the private key 663 associated with this key pair SHOULD now be destroyed. 665 5.2. End Entity Manifest Generation 667 EE repository publication points are used only in conjunction with 668 "multi-use" EE Certificates. In this case the EE Certificate has two 669 accessMethods specified in its SIA field. The id-ad- 670 signedObjectRepository accessMethod has an associated accessLocation 671 that points to the repository publication point of the objects signed 672 by this EE certificate, as specified in [I-D.sidr-res-certs]. The 673 id-ad-rpkiManifest accessMethod has an associated access location 674 that points to the manifest object as an object URL, that is 675 associated with this repository publication point. This manifest 676 describes all the signed objects that are to be found in that 677 publication point that have been signed by this EE certificate, and 678 the hash value of each product (excluding the manifest itself). 680 To create a manifest, each "multi-use" EE MUST perform the following 681 steps:. 683 o Construct the Manifest content. Note that the manifest does not 684 include a self reference (i.e., its own file name and hash), since 685 it would be impossible to compute the hash of the manifest itself 686 prior to it being signed. The manifest content is described in 687 Section 4.1.3.2.1. The manifest's fileList includes the file 688 names and hash pair for each object verified using that EE 689 certificate that has been published at the EE's repository 690 publication point. 692 o Encapsulate the Manifest content using the CMS SignedData content 693 type (as specified in Section Section 4), sign the manifest using 694 the private key corresponding to the public key in the EE 695 certificate, and publish the manifest in repository system 696 publication point that is described by the manifest. 698 "Single Use" EE certificates (EE certificates with an SIA 699 accessMethod OID of id-as-signedObject) do not have repository 700 publication points. The object verified by the "Single Use" EE 701 certificate is published in the repository publication point of the 702 CA certificate that issued the EE certificate, and is listed in the 703 corresponding manifest for this CA certificate. 705 5.3. Common Considerations for Manifest Generation 707 o A new manifest MUST be issued on or before the nextUpdate time. 709 o An authority MUST issue a new manifest in conjunction with the 710 finalization of changes made to objects in the publication point. 711 An authority MAY perform a number of object operations on a 712 publication repository within the scope of a repository change 713 before issuing a single manifest that covers all the operations 714 within the scope of this change. Repository operators SHOULD 715 implement some form of synchronization function on the repository 716 to ensure that relying parties who are performing retrieval 717 operations on the repository are not exposed to intermediate 718 states during changes to the repository and the associated 719 manifest. 721 o Since the manifest object URL is included in the SIA of issued 722 certificates then a new manifest MUST NOT invalidate the manifest 723 object URL of previously issued certificates. This implies that 724 the manifest's publication name in the repository, in the form of 725 an object URL, is one that is unchanged across manifest generation 726 cycles. 728 o In the case of a CA publication point manifest, when the entity is 729 performing a key rollover the entity MAY chose to have multiple 730 CAs publishing at the same publication point. In this case there 731 will be one manifest associated with each active CA that is 732 publishing into the common repository publication point. 734 o In the case of an EE publication point the manifest lists all 735 published objects verified using that EE certificate. Multiple 736 EEs may share a common repository publication point, in which case 737 there will be one manifest associated with each active EE that is 738 publishing into the common repository publication point. 740 6. Processing Certificate Requests 742 When an EE certificate is intended for use in verifying multiple 743 objects, the certificate request for the EE certificate MUST include 744 in the SIA of the request an access method OID of id-ad- 745 signedObjectRepository where the associated access location refers to 746 the publication point for objects signed by this EE certificate, and 747 MUST include in the SIA of the request an access method OID of id-ad- 748 rpkiManifest, where the associated access location refers to the 749 publication point of the manifest that is associated with published 750 objects that are verified using this EE certificate 751 [I-D.sidr-res-certs]. 753 When an EE certificate is used to sign a single object, the 754 certificate request for the EE certificate MUST include in the SIA of 755 the request an access method OID of id-ad-signedObject, where the 756 associated access location refers to the publication point of the 757 single object that is verified using this EE certificate. The 758 certificate request MUST NOT include in the SIA of the request the 759 access method OID of id-ad-rpkiManifest. 761 In accordance with the provisions of [I-D.sidr-res-certs], all 762 certificate issuance requests for a CA certificate SHOULD include in 763 the SIA of the request the id-ad-caRepository access method, and also 764 the id-ad-rpkiManifest access method that references the intended 765 publication point of the manifest in the associated access location 766 in the request. 768 The issuer MUST either honor these values in the issued certificate 769 or reject the request entirely. 771 7. Manifest Validation 773 To determine whether a manifest is valid, the relying party must 774 perform the following checks: 776 1. Verify that the Manifest complies syntactically with this 777 specification. In particular, verify the following: 779 a. The contentType of the CMS object is SignedData (OID 780 1.2.840.113549.1.7.2) 782 b. The version of the SignedData object is 3. 784 c. The digestAlgorithm in the SignedData object conforms to the 785 RPKI Algorithms and Key Size Profile specification 786 [I-D.sidr-rpki-algs]. 788 d. The certificates field in the SignedData object is present 789 and contains one EE certificate whose Subject Key Identifier 790 (SKI) field matches the sid field of the SignerInfo object. 792 e. The crls field in the SignedData object is omitted. 794 f. The eContentType in the EncapsulatedContentInfo is id-ad- 795 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 797 g. The version of the rpkiManifest is 0. 799 h. In the rpkiManifest, thisUpdate precedes nextUpdate. 801 i. The version of the SignerInfo is 3. 803 j. The digestAlgorithm in the SignerInfo object conforms to the 804 RPKI Algorithms and Key Size Profile specification 805 [I-D.sidr-rpki-algs]. 807 k. The signatureAlgorithm in the SignerInfo object conforms to 808 the RPKI Algorithms and Key Size Profile specification 809 [I-D.sidr-rpki-algs]. 811 l. The signedAttrs field in the SignerInfo object is present and 812 contains both the ContentType attribute (OID 813 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 814 1.2.840.113549.1.9.4). 816 m. The unsignedAttrs field in the SignerInfo object is omitted. 818 2. Use the public key in the EE certificate to verify the signature 819 on the Manifest. 821 3. Verify that the EE certificate is a valid end-entity certificate 822 in the resource PKI by constructing a valid certificate path to a 823 trust anchor. (See [I-D.sidr-res-certs] for more details.) 825 If the above procedure indicates that the manifest is invalid, then 826 the manifest MUST be discarded and treated as though no manifest were 827 present. 829 8. Relying Party Use of Manifests 831 The goal of a relying party is to determine which signed objects to 832 use for validating assertions about IP number resources and their use 833 (For example, which ROAs to use in the construction of route 834 filters). Ultimately, this selection is a matter of local policy. 835 However, in the following sections, we describe a sequence of tests 836 that the relying party SHOULD perform to determine the manifest state 837 of the given publication point. We then discuss the risks associated 838 with using signed objects in the publication point, given the 839 manifest state; and provide suitable warning text that should placed 840 in a user-accessible log file. It is the responsibility of the 841 relying party to weigh these risks against the risk of routing 842 failure that could occur if valid data is rejected, and construct a 843 suitable local policy. Note that if a certificate is deemed unfit 844 for use do to local policy, then any descendant object that is 845 validated using this certificate should also be deemed unfit for use 846 (regardless of the status of the manifest at its own publication 847 point). 849 8.1. Tests for Determining Manifest State 851 For a given publication point, the relying party should perform the 852 following tests to determine the manifest state of the publication 853 point: 855 1. For each entity using this publication point, select the entity's 856 current manifest (where the "current" manifest is the manifest 857 issued by this CA having highest manifestNumber among all valid 858 manifests, and where manifest validity is defined in Section 7). 860 * If the publication point does not contain a valid manifest, 861 see Section Section 8.2. Lacking a valid manifest, the 862 following tests cannot be performed. 864 2. Check that the current time (translated to UTC) is between 865 thisUpdate and nextUpdate. 867 * If the current time does not lie within this interval then see 868 Section 8.4, but still continue with the following tests. 870 3. Check that every file at the publication point appears in one and 871 only one current manifest, and that every file listed in each 872 current manifest that is published at this publication point also 873 is published at the publication point. 875 * If there exist files at the publication point that do not 876 appear on any manifest, or files listed in a manifest that do 877 not appear at the publication point then see Section 8.5, but 878 still continue with the following test. 880 4. Check that listed hash value of every file listed in each current 881 manifest matches the value obtained by hashing the file at the 882 publication point. 884 * If there exist files at the publication point whose hash does 885 not match the hash value listed in the manifest, then see 886 Section 8.6. 888 5. Check that the contents of each current manifest conforms to the 889 manifest's scope constraints, as specified in Section 2. 891 * If a current manifest contains entries for objects that are 892 not within the scope of the manifest, then the out-of-scope 893 entries should be disregarded in the context of this manifest. 894 If there is no other current manifest that describes these 895 objects within that other manifest's scope, then see 896 Section 8.2. 898 For a particular signed object, if all of the following conditions 899 hold: 901 * the manifest for its publication, and the associated 902 publication point, pass all of the above checks; 903 * the signed object is valid; and 904 * the manifests for every certificate on the certificate path 905 used to validate the signed object, and the associated 906 publication points, pass all of the above checks; 907 then the relying party can conclude that no attack against the 908 repository system has compromised the given signed object, and the 909 signed object MUST be treated as valid. 911 8.2. Missing Manifests 913 The absence of a current manifest at a publication point could occur 914 due to an error by the publisher or due to (malicious or accidental) 915 deletion or corruption of all valid manifests. 917 When no valid manifest is available, there is no protection against 918 attacks that delete signed objects or replay old versions of signed 919 objects. All signed objects at the publication point, and all 920 descendant objects that are validated using a certificate at this 921 publication point should be viewed as somewhat suspect, but may be 922 used by the relying party, as per local policy. 924 The primary risk in using signed objects at this publication point is 925 that a deleted CRL would cause the relying party to improperly accept 926 a revoked certificate as valid (and thus rely upon signed objects 927 that are validated using that certificate). This risk is somewhat 928 mitigated if the CRL for this publication point has a short time 929 between thisUpdate and nextUpdate (and the current time is within 930 this interval). The risk in discarding signed objects at this 931 publication point is that a relying party may incorrectly discard a 932 large number of valid objects. This gives significant power to an 933 adversary that is able to delete all manifests at the publication 934 point. 936 Regardless of whether signed objects from this publication are deemed 937 fit for use by the relying party, this situation should result in a 938 warning to the effect that: "No manifest is available for , and thus there may have been undetected deletions or replay 940 substitutions from the publication point." 942 In the case where the relying party has access to a local cache of 943 previously issued manifests that are valid, the relying party MAY use 944 the most recently previously issued valid manifests for this RPKI 945 repository publication collection in this case for each entity that 946 publishes at his publication point. 948 8.3. Invalid Manifests 950 The presence of invalid manifests at a publication point could occur 951 due to an error by the publisher or due to (malicious or accidental) 952 corruption of a valid manifest. An invalid manifest MUST never be 953 used even if the manifestNumber is greater than that of valid 954 manifests. 956 There are no risks associated with using signed objects at a 957 publication point containing an invalid manifest, provided that valid 958 manifests that collectively cover all the signed objects are also 959 present. 961 If an invalid manifest is present at a publication point that also 962 contains one or more valid manifests, this situation should result in 963 a warning to the effect that: "An invalid manifest was found at , this indicates an attack against the publication point 965 or an error by the publisher. Processing for this publication point 966 will continue using the most recent valid manifest." 968 In the case where the relying party has access to a local cache of 969 previously issued manifests that are valid, the relying party MAY use 970 the locally cached most recently previously issued valid manifest 971 issued by the entity that issued the invalid manifest in this case. 973 8.4. Stale Manifests 975 A manifest is considered stale if the current time is after the 976 nextUpdate time for the manifest. This could be due to publisher 977 failure to promptly publish a new manifest, or due to (malicious or 978 accidental) corruption of a more recent manifest. 980 All signed objects at the publication point, and all descendant 981 objects that are validated using a certificate at this publication 982 point should be viewed as somewhat suspect, but may be used by the 983 relying party as per local policy. 985 The primary risk in using signed objects at this publication point is 986 that a newer manifest exists that, if present, would indicate that 987 certain objects are have been removed or replaced. (For example, the 988 new manifest might show the existence of a newer CRL and the removal 989 of one or more revoked certificates). This use of objects from a 990 stale manifest may cause the relying party to incorrectly treat 991 invalid objects as valid. The risk is that a stale CRL causes the 992 relying party to improperly treat a revoked certificate as valid. 993 This risk is somewhat mitigated if the time between the nextUpdate 994 field of the manifest and the current time is short. The risk in 995 discarding signed objects at this publication point is that the 996 relying party may incorrectly discard a large number of valid 997 objects. This gives significant power to an adversary that is able 998 to prevent the publication of a new manifest at a given publication 999 point. 1001 Regardless of whether signed objects from this publication are deemed 1002 fit for use by the relying party, this situation should result in a 1003 warning to the effect that: "The manifest for is no 1004 longer current. It is possible that undetected deletions have 1005 occurred at this publication point." 1007 Note that there is also a less common case where the current time is 1008 before the thisUpdate time for the manifest. This case could be due 1009 to publisher error, or a local clock error, and in such a case this 1010 situation should result in a warning to the effect that: "The 1011 manifest found at has an incorrect thisUpdate field. 1012 This could be due to publisher error, or a local clock error, and 1013 processing for this publication point will continue using this 1014 otherwise valid manifest." 1016 8.5. Mismatch between Manifest and Publication Point 1018 If there exist otherwise valid signed objects that do not appear in 1019 any manifest, then provided the manifest is not stale (see 1020 Section 8.4) it is likely that their omission is an error by the 1021 publisher. It is also possible that this state could be the result 1022 of a (malicious or accidental) replacement of a current manifest with 1023 an older, but still valid manifest. However, regarding the 1024 appropriate interpretation such objects, it remains the case that if 1025 the objects were intended to be invalid, then they should have been 1026 revoked using whatever revocation mechanism is appropriate for the 1027 signed object in question.) Therefore, there is little risk in using 1028 such signed objects. If the manifest in question is stale, then 1029 there is a greater risk that the objects in question were revoked 1030 with a missing CRL, whose absence is undetectable since the manifest 1031 is stale. In any case, the use of signed objects not present on a 1032 manifest, or descendant objects that are validated using such signed 1033 objects, is a matter of local policy. 1035 Regardless of whether objects not appearing on a manifest are deemed 1036 fit for use by the relying party, this situation should result in a 1037 warning to the effect that: "The following files are present in the 1038 repository at , but are not on the manifest ." 1041 If there exist files listed on the manifest that do not appear in the 1042 repository, then these objects are likely to have been improperly 1043 (via malice or accident) deleted from the repository. A primary 1044 purpose of manifests is to detect such deletions. Therefore, in such 1045 a case this situation should result in a warning to the effect that: 1046 "The following files that should have been present in the repository 1047 at , are missing . This indicates an 1048 attack against this publication point, or the repository, or an error 1049 by the publisher." 1051 8.6. Hash Values Not Matching Manifests 1053 A file appearing on a manifest with an incorrect hash value could 1054 occur because of publisher error, but it also may indicate that an 1055 attack has occurred. 1057 If an object appeared on a previous valid manifest with a correct 1058 hash value, and now appears with an invalid hash value, then it is 1059 likely that the object has been superseded by a new (unavailable) 1060 version of the object. If the object is used there is a risk that 1061 the relying party will be treating a stale object as valid. This 1062 risk is more significant if the object in question is a CRL. 1063 Assuming that the object is validated in the RPKI, the use of these 1064 objects is a matter of local policy. 1066 If an object appears on a manifest with an invalid hash and has never 1067 previously appeared on a manifest, then it is unclear whether the 1068 available version of the object is more or less recent than the 1069 version whose hash appears in the manifest. If the manifest is stale 1070 (see Section 8.4) then it becomes more likely that the available 1071 version is more recent that the version indicated on the manifest, 1072 but this is never certain. Whether to use such objects is a matter 1073 of local policy. However, in general, it is better to use a possibly 1074 outdated version of the object than to discard the object completely. 1076 While it is a matter of local policy, in the case of CRLs, a relying 1077 party should endeavor to use the most recently issued valid CRL even 1078 where the hash value in the manifest matches an older CRL, or does 1079 not match any CRL hand. The thisUpdate field of the CRL can be used 1080 to establish the most recent CRL in the case where a relying party 1081 has more than one valid CRL at hand. 1083 Regardless of whether objects with incorrect hashes are deemed fit 1084 for use by the relying party, this situation should result in a 1085 warning to the effect that: "The following files at the repository 1086 appear on a manifest with incorrect hash values 1087 . It is possible that these objects have been superseded 1088 by a more recent version. It is very likely that this problem is due 1089 to an attack on the publication point, although it could also be due 1090 to a publisher error." 1092 9. Publication Repositories 1094 The RPKI publication system model requires that every publication 1095 point be associated with one or more CAs or one or more EEs, and be 1096 non-empty. Upon creation of the publication point associated with a 1097 CA, the CA MUST create and publish a manifest as well as a CRL. The 1098 manifest will contain at least one entry, the CRL issued by the CA 1099 upon repository creation. Upon the creation of the publication point 1100 associated with an EE, the EE MUST create and publish a manifest. 1101 The manifest in an otherwise empty repository publication point 1102 associated with an EE will contain no entries in the manifest's 1103 fileList sequence (i.e., the ASN.1 SEQUENCE will have a length of 1104 zero). [I-D.sidr-repos-struct] 1106 For each signed object, the EE certificate used to verify the object 1107 is either a single-use certificate, used to verify a single signed 1108 object, or a multiple-use certificate. In the case of a single-use 1109 EE certificate, the signed object is published in the repository 1110 publication point of the CA that issued the single use EE 1111 certificate, and is listed in the manifest associated with that CA 1112 certificate. In the case where an EE certificate is used to verify 1113 multiple objects, each signed object is published in the EE 1114 certificate's repository publication point and listed in the manifest 1115 associated with the EE certificate. 1117 10. Security Considerations 1119 Manifests provide an additional level of protection for relying 1120 parties of the repository system. Manifests can assist a relying 1121 party to determine if repository objects have been occluded or other 1122 removed from view, and to determine if an older version of an object 1123 has been substituted for the current object. 1125 Manifests cannot repair the effects of such forms of corruption of 1126 repository retrieval operations, but are capable of allowing a 1127 relying party to determine if a locally maintained copy of a 1128 repository is a complete and up to date copy, even when the 1129 repository retrieval operation is conduction over an insecure 1130 channel. In those cases where the manifest and the retrieved 1131 repository contents differ, the manifest can assist in determining 1132 which repository objects form the difference set in terms of missing, 1133 extraneous or older objects . 1135 The signing structure of a manifest and the use of the nextUpdate 1136 value allows the relying party to determine if the manifest itself is 1137 the subject of attempted alteration. The requirement for every 1138 repository publication point to contain at least one manifest allows 1139 a relying party to determine is the manifest itself has been occluded 1140 from view. Such attacks against the manifest are detectable within 1141 the time frame of the regular schedule of manifest updates. Forms of 1142 replay attack within finer-grained time frames are not necessarily 1143 detectable by the manifest structure . 1145 11. IANA Considerations 1147 [Note to IANA, to be removed prior to publication: there are no IANA 1148 considerations stated in this version of the document.] 1150 12. Acknowledgements 1152 The authors would like to acknowledge the contributions from George 1153 Michelson and Randy Bush in the preparation of the manifest 1154 specification. Additionally, the authors would like to thank Mark 1155 Reynolds and Christopher Small for assistance in clarifying manifest 1156 validation and relying party behavior. 1158 13. Notes 1160 [Note to Reviewers: These notes are part of the working group draft 1161 document, and will be removed prior to publication.] 1163 13.1. Changes in the draft from -04 to -05 1165 Removed references to RSA and SHA-256 from the specification of the 1166 DigestAlgorithms field of CMS SignedData, the SignatureAlgorithm and 1167 digestAlgorithm fields of the SignerInfo field and from the 1168 fileHashAlg field of the Manifest, replacing them with a reference to 1169 the RPKI Algorithm and Hash Profile, to allow for RPKI-wide algorithm 1170 agility. 1172 13.2. Changes in the draft from -05 to -06 1174 Corrected a minor typo in section 8.5, and clarified the text 1175 relating to the version number. A number of grammatical nits were 1176 corrected. 1178 14. Normative References 1180 [I-D.sidr-arch] 1181 Lepinski, M. and S. Kent, "An Infrastructure to Support 1182 Secure Internet Routing", draft-ietf-sidr-arch-08.txt 1183 (work in progress), July 2009. 1185 [I-D.sidr-repos-struct] 1186 Huston, G., Loomans, R., and G. Michaleson, "A Profile for 1187 Resource Certificate Repository Structure", 1188 draft-ietf-sidr-repos-struct-02.txt (work in progress), 1189 August 2009. 1191 [I-D.sidr-res-certs] 1192 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 1193 X.509 PKIX Resource Certificates", 1194 draft-ietf-sidr-res-certs-16.txt (work in progress), 1195 February 2009. 1197 [I-D.sidr-rpki-algs] 1198 Huston, G., "A Profile for Algorithms and Key Sizes for 1199 use in the Resource Public Key Infrastructure", 1200 draft-huston-sidr-rpki-algs-00.txt (work in progress), 1201 July 2009. 1203 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1204 Addresses and AS Identifiers", RFC 3779, June 2004. 1206 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 1207 Representing Date and Time in ASN.1", RFC 4049, 1208 April 2005. 1210 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1211 Housley, R., and W. Polk, "Internet X.509 Public Key 1212 Infrastructure Certificate and Certificate Revocation List 1213 (CRL) Profile", RFC 5280, May 2008. 1215 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 1216 RFC 5652, September 2009. 1218 Authors' Addresses 1220 Rob Austein 1221 Internet Systems Consortium 1222 950 Charter St. 1223 Redwood City, CA 94063 1224 USA 1226 Email: sra@isc.org 1227 Geoff Huston 1228 Asia Pacific Network Information Centre 1229 33 Park Rd. 1230 Milton, QLD 4064 1231 Australia 1233 Email: gih@apnic.net 1234 URI: http://www.apnic.net 1236 Stephen Kent 1237 BBN Technologies 1238 10 Moulton St. 1239 Cambridge, MA 02138 1240 USA 1242 Email: kent@bbn.com 1244 Matt Lepinski 1245 BBN Technologies 1246 10 Moulton St. 1247 Cambridge, MA 02138 1248 USA 1250 Email: mlepinski@bbn.com