idnits 2.17.1 draft-ietf-sidr-rpki-manifests-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (August 5, 2009) is 5377 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 557 -- Looks like a reference, but probably isn't: '1' on line 553 == 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 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) Summary: 5 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: February 6, 2010 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 August 5, 2009 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-05.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 February 6, 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 in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document defines a "manifest" for use in the Resource Public Key 51 Infrastructure. A manifest is a signed object that contains a 52 listing of all the signed objects in the repository publication point 53 associated with an authority responsible for publishing in the 54 repository. For each certificate, or other forms of signed objects 55 issued by the authority that are published at this repository 56 publication point, the manifest contains both the name of the file 57 containing the object, and a hash of the file content. Manifests are 58 intended to expose potential attacks against relying parties of the 59 Resource Public Key Infrastructure, such as a man-in-the middle 60 attack of withholding repository data from relying party access, or 61 replaying stale repository data to a relying party's access request. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Manifest Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 6 71 4.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 6 73 4.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 7 74 4.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 9 75 4.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . 9 77 4.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 14 79 5.1. CA Manifest Generation . . . . . . . . . . . . . . . . . . 14 80 5.2. End Entity Manifest Generation . . . . . . . . . . . . . . 15 81 5.3. Common Considerations for Manifest Generation . . . . . . 16 82 6. Processing Certificate Requests . . . . . . . . . . . . . . . 17 83 7. Manifest Validation . . . . . . . . . . . . . . . . . . . . . 17 84 8. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 19 85 8.1. Tests for Determining Manifest State . . . . . . . . . . . 19 86 8.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 20 87 8.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 21 88 8.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 22 89 8.5. Mismatch between Manifest and Publication Point . . . . . 22 90 8.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 23 91 9. Publication Repositories . . . . . . . . . . . . . . . . . . . 24 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 95 13. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 13.1. Changes in the draft from -04 to -05 . . . . . . . . . . . 26 97 14. Normative References . . . . . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 100 1. Introduction 102 The Resource Public Key Infrastructure (RPKI) [I-D.sidr-arch] makes 103 use of a distributed repository system [I-D.sidr-repos-struct] to 104 make available a variety of objects needed by relying parties (RPs) 105 such as Internet service providers (ISPs). Because all of the 106 objects stored in the repository system are digitally signed by the 107 entities that created them, attacks that modify these objects are 108 detectable by RPs. However, digital signatures provide no protection 109 against attacks that substitute "stale" versions of signed objects 110 (i.e., objects that were valid and have not expired, but have since 111 been superseded) or attacks that remove an object that should be 112 present in the repository. To assist in the detection of such 113 attacks, the RPKI repository system will make use of a new signed 114 object called a "manifest". 116 A manifest is a signed object that contains a listing of all the 117 signed objects in the repository publication point associated with an 118 authority responsible for publishing in the repository. For each 119 certificate, Certificate Revocation List (CRL), or other signed 120 object, such as a Route Origination Authorization (ROA), issued by an 121 authority, the authority's manifest contains both the name of the 122 file containing the object, and a hash of the file content. 123 Manifests allow a RP to obtain sufficient information to detect 124 whether the retrieval of objects from an RPKI repository has been 125 compromised by unauthorized object removal, or by the substitution of 126 "stale" versions of objects. Manifests are designed to be used both 127 for Certification Authority (CA) publication points in repositories, 128 that contain subordinate certificates, CRLs and other signed objects, 129 and End Entity (EE) publication points in repositories that contain 130 signed objects. 132 Manifests are modeled on CRLs, as the issues involved in detecting 133 stale manifests, and detection of potential attacks using manifest 134 replays, etc are similar to those for CRLs. The syntax of the 135 manifest payload differs from CRLs, since RPKI repositories can 136 contain objects not covered by CRLs, such as digitally signed 137 objects, such as ROAs. 139 1.1. Terminology 141 It is assumed that the reader is familiar with the terms and concepts 142 described in "Internet X.509 Public Key Infrastructure Certificate 143 and Certificate Revocation List (CRL) Profile" [RFC5280]> and "X.509 144 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119. 150 2. Manifest Scope 152 In the case of a CA's manifest for its associated publication 153 repository, the manifest contains the current published certificates 154 issued by this CA, the most recent CRL issued by this CA, and all 155 objects that are signed using a "single-use" EE certificate (i.e., 156 the SIA extension of the EE certificate has an accessMethod OID of 157 id-ad-signedObject), where the EE certificate was issued by this CA. 159 In the case where multiple CAs share a common publication point, as 160 may be the case when an entity performs a staged key-rollover 161 operation, the repository publication will contain multiple 162 manifests. In such a scenario, each manifest describes only the 163 collection of published products of its associated CA. 165 In the case of a "multi-use" EE certificate, where an EE has a 166 defined publication repository (i.e., the SIA extension of the EE 167 certificate has an accessMethod OID of id-ad-signedObjectRepository), 168 the EE's manifest contains all published objects that have been 169 signed by the EE's key, and the accessMethod id-as-rpkiManifest 170 points to the publication point of the EE's manifest. 172 3. Manifest Signing 174 A CA's manifest is verified using an EE certificate that is 175 designated in [I-D.sidr-res-certs] as a "single-use" EE certificate. 176 The SIA field of the "single-use" EE certificate contains the access 177 method OID of id-ad-signedObject. 179 The CA MAY chose to sign only one manifest with the private key of 180 the EE certificate, and generate a new EE certificate for each new 181 version of the manifest. This form of use of a "single-use" EE 182 certificate is termed a "one-time-use" EE certificate. 184 Alternatively the CA MAY chose to use the same EE certificate's 185 private key to sign a sequence of manifests. Because only a single 186 manifest is current at any point in time, the EE certificate is used 187 only to verify a single object at a time. As long as the sequence of 188 objects signed by this EE certificate's private key are published as 189 the same named object, so that the SIA accessMethod id-ad- 190 signedObject value can refer to the current instance of the sequence 191 of such objects, then this sequential multiple use of this "single- 192 use" EE certificate is also valid. This form of use of a "single- 193 use" EE certificate is termed a "sequential-use" EE certificate. 195 A "multi-use" EE's manifest of it's publication repository is signed 196 with the private key of the EE certificate. 198 4. Manifest Syntax 200 A manifest is a Cryptographic Message Syntax (CMS) [RFC3852] signed- 201 data object. The general format of a CMS object is: 203 ContentInfo ::= SEQUENCE { 204 contentType ContentType, 205 content [0] EXPLICIT ANY DEFINED BY contentType } 207 ContentType ::= OBJECT IDENTIFIER 209 A Manifest is a signed-data object. The ContentType used is the 210 signed-data type of id-data, namely the id-signedData OID, 211 1.2.840.113549.1.7.2. [RFC3852] 213 4.1. Signed-Data Content Type 215 According to the CMS specification, signed-data content types shall 216 have the ASN.1 type SignedData: 218 SignedData ::= SEQUENCE { 219 version CMSVersion, 220 digestAlgorithms DigestAlgorithmIdentifiers, 221 encapContentInfo EncapsulatedContentInfo, 222 certificates [0] IMPLICIT CertificateSet OPTIONAL, 223 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 224 signerInfos SignerInfos } 226 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 228 SignerInfos ::= SET OF SignerInfo 230 4.1.1. version 232 The version is the syntax version number. It MUST be 3, 233 corresponding to the signerInfo structure having version number 3. 235 4.1.2. digestAlgorithms 237 The digestAlgorithms set contains a set of OIDs of the algorithms 238 used to sign the data. The algorithms used to sign the data MUST 239 conform to the RPKI Algorithms and Key Size Profile specification 240 [I-D.sidr-rpki-algs]. 242 4.1.3. encapContentInfo 244 encapContentInfo is the signed content, consisting of a content type 245 identifier and the content itself. 247 EncapsulatedContentInfo ::= SEQUENCE { 248 eContentType ContentType, 249 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 251 ContentType ::= OBJECT IDENTIFIER 253 4.1.3.1. eContentType 255 The eContentType for a Manifest is defined as id-ct-rpkiManifest, and 256 has the numerical value of 1.2.840.113549.1.9.16.1.26. 258 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 259 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 261 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 263 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 265 4.1.3.2. eContent 267 The content of a Manifest is defined as follows: 269 Manifest ::= SEQUENCE { 270 version [0] INTEGER DEFAULT 0, 271 manifestNumber INTEGER, 272 thisUpdate GeneralizedTime, 273 nextUpdate GeneralizedTime, 274 fileHashAlg OBJECT IDENTIFIER, 275 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash 276 } 278 FileAndHash ::= SEQUENCE { 279 file IA5String 280 hash BIT STRING 281 } 283 4.1.3.2.1. Manifest 285 The manifestNumber, thisUpdate, and nextUpdate fields are modeled 286 after the corresponding fields in X.509 CRLs (see [RFC5280]). 287 Analogous to CRLS, a manifest is nominally valid until the time 288 specified in nextUpdate or until a manifest is issued with a greater 289 manifest number, whichever comes first. The revoked EE certificate 290 for the previous manifest's signature will be removed from the CRL 291 when it expires. 293 If a "one-time-use" EE certificate is employed to verify a manifest, 294 the EE certificate MUST have an validity period that coincides with 295 the interval from thisUpdate to nextUpdate, to prevent needless 296 growth of the CA's CRL. 298 If a "sequential-use EE certificate is employed to verify a manifest, 299 the EE certificate's validity period needs to be no shorter than the 300 nextUpdate time of the current manifest. The extended validity time 301 raises the possibility of a substitution attack using a stale 302 manifest, as described in Section 8.4. 304 4.1.3.2.1.1. version 306 The version number of the rpkiManifest MUST be 0. 308 4.1.3.2.1.2. manifestNumber 310 The manifestNumber field is a sequence number that is incremented 311 each time a new manifest is issued for a given publication point. 312 This field is used to allow a RP to detect gaps in a sequence of 313 published manifest. 315 4.1.3.2.1.3. thisUpdate 317 The thisUpdate field contains the time when the manifest was created. 319 4.1.3.2.1.4. nextUpdate 321 The nextUpdate field contains the time at which the next scheduled 322 manifest will be issued. The value of nextUpdate MUST be later than 323 the value of thisUpdate. If the authority alters any of the items in 324 the repository publication point, then the authority MUST issue a new 325 manifest before the nextUpdate time. If a manifest encompasses a 326 CRL, the nextUpdate field of the manifest MUST match that of the CRL, 327 as the manifest will be reissued when a new CRL is published. When a 328 "one-time-use" EE certificate is being used to verify the manifest, 329 then when a new manifest is issued before the time specified in 330 nextUpdate of the current manifest, the CA MUST also issue a new CRL 331 that includes the EE certificate corresponding to the old manifest. 333 4.1.3.2.1.5. fileHashAlg 335 The fileHashAlg field contains the OID of the hash algorithm used to 336 hash the files that the authority has placed into the repository. 337 The hash algorithm used MUST conform to the RPKI Algorithms and Key 338 Size Profile specification [I-D.sidr-rpki-algs]. 340 4.1.3.2.1.6. fileList 342 The fileList field contains a sequence of FileAndHash pairs, one for 343 each currently valid signed object that has been issued by the 344 authority. Each FileAndHash pair contains the name of the file in 345 the repository that contains the object in question, and a hash of 346 the file's contents. 348 4.1.4. certificates 350 The certificates field MUST be included, and MUST contain the RPKI EE 351 certificate needed to validate this manifest in the context of the 352 RPKI. 354 4.1.5. crls 356 This field MUST be omitted. 358 4.1.6. signerInfos 360 Signer Infos is defined as a SignerInfo, which is defined under CMS 361 as: 363 SignerInfo ::= SEQUENCE { 364 version CMSVersion, 365 sid SignerIdentifier, 366 digestAlgorithm DigestAlgorithmIdentifier, 367 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 368 signatureAlgorithm SignatureAlgorithmIdentifier, 369 signature SignatureValue, 370 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 372 4.1.6.1. version 374 The version number MUST be 3, corresponding with the choice of 375 SubjectKeyIdentifier for the sid. 377 4.1.6.2. sid 379 The sid is defined as: 381 SignerIdentifier ::= CHOICE { 382 issuerAndSerialNumber IssuerAndSerialNumber, 383 subjectKeyIdentifier [0] SubjectKeyIdentifier } 385 For a Manifest, the sid MUST be a SubjectKeyIdentifier. 387 4.1.6.3. digestAlgorithm 389 The digestAlgorithm field contains the OIDs of the algorithm used to 390 sign the data. The algorithm used to sign the data MUST conform to 391 the RPKI Algorithms and Key Size Profile specification 392 [I-D.sidr-rpki-algs]. 394 4.1.6.4. signedAttrs 396 The signedAttrs is defined as signedAttributes: 398 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 400 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 402 Attribute ::= SEQUENCE { 403 attrType OBJECT IDENTIFIER, 404 attrValues SET OF AttributeValue } 406 AttributeValue ::= ANY 408 The signedAttr element MUST be present and MUST include the content- 409 type and message-digest attributes. The signer MAY also include the 410 signing-time signed attribute, the binary-signing-time signed 411 attribute, or both signing-time attributes. Other signed attributes 412 that are deemed appropriate MAY also be included. The intent is to 413 allow additional signed attributes to be included if a future need is 414 identified. This does not cause an interoperability concern because 415 unrecognized signed attributes are ignored by the relying party. 417 The signedAttr MUST include only a single instance of any particular 418 attribute. Additionally, even though the syntax allows for a SET OF 419 AttributeValue, in a Manifest the attrValues MUST consist of only a 420 single AttributeValue. 422 4.1.6.4.1. Content-Type Attribute 424 The ContentType attribute MUST be present. The attrType OID for the 425 ContentType attribute is 1.2.840.113549.1.9.3. 427 The attrValues for the ContentType attribute in a Manifest MUST be 428 1.2.840.113549.1.9.16.1.26, matching the eContentType in the 429 EncapsulatedContentInfo. 431 4.1.6.4.2. Message-Digest Attribute 433 The MessageDigest Attribute MUST be present. The attrType OID for 434 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 436 The attrValues for the MessageDigest attribute contains the output of 437 the digest algorithm applied to the content being signed, as 438 specified in Section 11.1 of [RFC3852]. 440 4.1.6.4.3. SigningTime Attribute 442 The SigningTime attribute MAY be present. The presence of absence of 443 the SigningTime attribute in no way affects the validation of the 444 Manifest (as specified in Section Section 7). 446 The attrType OID for the SigningTime attribute is 447 1.2.840.113549.1.9.5. 449 The attrValues for the SigningTime attribute is defined as: 451 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 452 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 454 SigningTime ::= Time 456 Time ::= CHOICE { 457 utcTime UTCTime, 458 generalizedTime GeneralizedTime } 460 The Time element specifies the time, based on the local system clock, 461 at which the digital signature was applied to the content. 463 4.1.6.4.4. BinarySigningTime Attribute 465 The signer MAY include a BinarySigningTime attribute, specifying the 466 time at which the digital signature was applied to the content. If 467 both the BinarySigningTime and SigningTime attributes are present, 468 the time that is represented by the binary-signing-time attribute 469 MUST represent the same time value as the signing-time attribute. 470 The presence or absence of the Binary-SigningTime attribute in no way 471 affects the validation of the Manifest (as specified in Section 472 Section 7). 474 The binary-signing-time attribute is defined in [RFC4049] as: 476 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 477 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 478 smime(16) aa(2) 46 } 480 BinarySigningTime ::= BinaryTime 482 BinaryTime ::= INTEGER (0..MAX) 484 4.1.6.5. signatureAlgorithm 486 The signatureAlgorithm MUST conform to the RPKI Algorithms and Key 487 Size Profile specification [I-D.sidr-rpki-algs]. 489 4.1.6.6. signature 491 The signature value is defined as: 493 SignatureValue ::= OCTET STRING 495 The signature characteristics are defined by the digest and signature 496 algorithms. 498 4.1.6.7. unsignedAttrs 500 unsignedAttrs MUST be omitted. 502 4.2. ASN.1 504 The following is the ASN.1 specification of the CMS-signed Manifest. 506 ContentInfo ::= SEQUENCE { 507 contentType ContentType, 508 content [0] EXPLICIT ANY DEFINED BY contentType } 510 ContentType ::= OBJECT IDENTIFIER 512 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 513 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 515 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 517 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 519 Manifest ::= SEQUENCE { 520 version [0] INTEGER DEFAULT 0, 521 manifestNumber INTEGER, 522 thisUpdate GeneralizedTime, 523 nextUpdate GeneralizedTime, 524 fileHashAlg OBJECT IDENTIFIER, 525 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash} 527 FileAndHash ::= SEQUENCE { 528 file IA5String 529 hash BIT STRING} 531 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 532 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 534 SignedData ::= SEQUENCE { 535 version CMSVersion, 536 digestAlgorithms DigestAlgorithmIdentifiers, 537 encapContentInfo EncapsulatedContentInfo, 538 certificates [0] IMPLICIT CertificateSet OPTIONAL, 539 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 540 signerInfos SignerInfos } 542 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 544 SignerInfos ::= SET OF SignerInfo 546 SignerInfo ::= SEQUENCE { 547 version CMSVersion, 548 sid SignerIdentifier, 549 digestAlgorithm DigestAlgorithmIdentifier, 550 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 551 signatureAlgorithm SignatureAlgorithmIdentifier, 552 signature SignatureValue, 553 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 555 SignerIdentifier ::= CHOICE { 556 issuerAndSerialNumber IssuerAndSerialNumber, 557 subjectKeyIdentifier [0] SubjectKeyIdentifier } 559 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 561 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 563 Attribute ::= SEQUENCE { 564 attrType OBJECT IDENTIFIER, 565 attrValues SET OF AttributeValue } 567 AttributeValue ::= ANY 569 SignatureValue ::= OCTET STRING 571 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 572 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 574 ContentType ::= OBJECT IDENTIFIER 576 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 577 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 579 MessageDigest ::= OCTET STRING 580 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 581 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 583 SigningTime ::= Time 585 Time ::= CHOICE { 586 utcTime UTCTime, 587 generalizedTime GeneralizedTime } 589 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 590 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 591 smime(16) aa(2) 46 } 593 BinarySigningTime ::= BinaryTime 595 BinaryTime ::= INTEGER (0..MAX) 597 5. Manifest Generation 599 5.1. CA Manifest Generation 601 Each CA in the RPKI publishes the certificates and CRLs it issues at 602 a publication point in the RPKI repository system. To create a 603 manifest, each CA MUST perform the following steps: 605 1. If no key pair exists, or if using a "one-time-use" EE 606 certificate with a new key pair, then generate a key pair. 608 2. If using a "one-time-use" EE certificate, or if a key pair was 609 generated in step 1, issue a "single-use" EE certificate for this 610 key pair to enable relying parties to verify the signature on the 611 manifest. 613 * This EE certificate has an SIA extension access description 614 field with an accessMethod OID value of id-ad-signedobject 615 where the associated accessLocation references the publication 616 point of the manifest as an object URL. 618 * This EE certificate MUST describe its IP number resources 619 using the "inherit" attribute, rather than explicit 620 description of a resource set. 622 * In the case of a "one-time-use" EE certificate, the validity 623 times of the EE certificate SHOULD exactly match the 624 thisUpdate and nextUpdate times of the manifest, and MUST 625 encompass the interval from thisUpdate to nextUpdate. 627 * In the case of a "sequential-use" EE certificate the validity 628 times of the EE certificate MUST encompass the time interval 629 from thisUpdate to nextUpdate. 631 3. The EE certificate SHOULD NOT be published in the authority's 632 repository publication point. 634 4. Construct the manifest content. Note that the manifest does not 635 include a self reference (i.e., its own file name and hash), 636 since it would be impossible to compute the hash of the manifest 637 itself prior to it being signed. The manifest content is 638 described in Section 4.1.3.2.1. The manifest's fileList includes 639 the file names and hash pair for all objects associated with this 640 CA that have been published at the CA's repository publication 641 point. The collection of objects to be included in the manifest 642 includes all subordinate certificates issued by this CA that are 643 published at the CA's repository publication point, the most 644 recent CRL issued by the CA , and all objects verified by 645 "single-use" EE certificates that were issued by this CA that are 646 published at the CA's repository publication point. 648 5. Encapsulate the Manifest content using the CMS SignedData content 649 type (as specified in Section Section 4), sign the manifest using 650 the private key corresponding to the EE certificate, and publish 651 the manifest in repository system publication point that is 652 described by the manifest. 654 6. In the case of a key pair that is to be used only once, in 655 conjunction with a "one-time-use" EE certificate, the private key 656 associated with this key pair SHOULD now be destroyed. 658 5.2. End Entity Manifest Generation 660 EE repository publication points are only used in conjunction with 661 "multi-use" EE Certificates. In this case the EE Certificate has two 662 accessMethods specified in its SIA field. The id-ad- 663 signedObjectRepository accessMethod has an associated accessLocation 664 that points to the repository publication point of the objects signed 665 by this EE certificate, as specified in [I-D.sidr-res-certs]. The 666 id-ad-rpkiManifest accessMethod has an associated access location 667 that points to the manifest object as an object URL, that is 668 associated with this repository publication point. This manifest 669 describes all the signed objects that are to be found in that 670 publication point that have been signed by this EE certificate, and 671 the hash value of each product (excluding the manifest itself). 673 To create a manifest, each "multi-use" EE MUST perform the following 674 steps:. 676 o Construct the Manifest content. Note that the manifest does not 677 include a self reference (i.e., its own file name and hash), since 678 it would be impossible to compute the hash of the manifest itself 679 prior to it being signed. The manifest content is described in 680 Section 4.1.3.2.1. The manifest's fileList includes the file 681 names and hash pair for all objects verified using that EE 682 certificate that have been published at the EE's repository 683 publication point. 685 o Encapsulate the Manifest content using the CMS SignedData content 686 type (as specified in Section Section 4), sign the manifest using 687 the EE certificate, and publish the manifest in repository system 688 publication point that is described by the manifest. 690 "Single Use" EE certificates (EE certificates with an SIA 691 accessMethod OID of id-as-signedObject) do not have repository 692 publication points. The object signed by the "Single Use" EE 693 certificate is published in the repository publication point of the 694 CA certificate that issued the EE certificate, and is listed in the 695 corresponding manifest for this CA certificate. 697 5.3. Common Considerations for Manifest Generation 699 o A new manifest MUST be issued on or before the nextUpdate time. 701 o An authority MUST issue a new manifest in conjunction with the 702 finalization of changes made to objects in the publication point. 703 An authority MAY perform a number of object operations on a 704 publication repository within the scope of a repository change 705 before issuing a single manifest that covers all the operations 706 within the scope of this change. Repository operators SHOULD 707 implement some form of synchronization function on the repository 708 to ensure that relying parties who are performing retrieval 709 operations on the repository are not exposed to intermediate 710 states during changes to the repository and the associated 711 manifest. 713 o Since the manifest object URL is included in the SIA of issued 714 certificates then a new manifest MUST NOT invalidate the manifest 715 object URL of previously issued certificates. This implies that 716 the manifest's publication name in the repository, in the form of 717 an object URL, is one that is unchanged across manifest generation 718 cycles. 720 o In the case of a CA publication point manifest, when the entity is 721 performing a key rollover the entity MAY chose to have multiple 722 CAs publishing at the same publication point. In this case there 723 will be one manifest associated with each active CA that is 724 publishing into the common repository publication point. 726 o In the case of an EE publication point the manifest lists all 727 published objects verified using that EE certificate. Multiple 728 EEs may share a common repository publication point, in which case 729 there will be one manifest associated with each active EE that is 730 publishing into the common repository publication point. 732 6. Processing Certificate Requests 734 When an EE certificate is intended for use in verifying multiple 735 objects, the certificate request for the EE certificate MUST include 736 in the SIA of the request an access method OID of id-ad- 737 signedObjectRepository where the associated access location refers to 738 the publication point for objects signed by this EE certificate, and 739 MUST include in the SIA of the request an access method OID of id-ad- 740 rpkiManifest, where the associated access location refers to the 741 publication point of the manifest that is associated with published 742 objects that are verified using this EE certificate 743 [I-D.sidr-res-certs]. 745 When an EE certificate is used to sign a single object, the 746 certificate request for the EE certificate MUST include in the SIA of 747 the request an access method OID of id-ad-signedObject, where the 748 associated access location refers to the publication point of the 749 single object that is verified using this EE certificate. The 750 certificate request MUST NOT include in the SIA of the request the 751 access method OID of id-ad-rpkiManifest. 753 In accordance with the provisions of [I-D.sidr-res-certs], all 754 certificate issuance requests for a CA certificate SHOULD include in 755 the SIA of the request the id-ad-caRepository access method, and also 756 the id-ad-rpkiManifest access method that references the intended 757 publication point of the manifest in the associated access location 758 in the request. 760 The issuer MUST either honor these values in the issued certificate 761 or reject the request entirely. 763 7. Manifest Validation 765 To determine whether a manifest is valid, the relying party must 766 perform the following checks: 768 1. Verify that the Manifest complies with this specification. In 769 particular, verify the following: 771 a. The contentType of the CMS object is SignedData (OID 772 1.2.840.113549.1.7.2) 774 b. The version of the SignedData object is 3. 776 c. The digestAlgorithm in the SignedData object conforms to the 777 RPKI Algorithms and Key Size Profile specification 778 [I-D.sidr-rpki-algs]. 780 d. The certificates field in the SignedData object is present 781 and contains an EE certificate whose Subject Key Identifier 782 (SKI) matches the sid field of the SignerInfo object. 784 e. The crls field in the SignedData object is omitted. 786 f. The eContentType in the EncapsulatedContentInfo is id-ad- 787 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 789 g. The version of the rpkiManifest is 0. 791 h. In the rpkiManifest, thisUpdate precedes nextUpdate. 793 i. The version of the SignerInfo is 3. 795 j. The digestAlgorithm in the SignerInfo object conforms to the 796 RPKI Algorithms and Key Size Profile specification 797 [I-D.sidr-rpki-algs]. 799 k. The signatureAlgorithm in the SignerInfo object conforms to 800 the RPKI Algorithms and Key Size Profile specification 801 [I-D.sidr-rpki-algs]. 803 l. The signedAttrs field in the SignerInfo object is present and 804 contains both the ContentType attribute (OID 805 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 806 1.2.840.113549.1.9.4). 808 m. The unsignedAttrs field in the SignerInfo object is omitted. 810 2. Use the public key in the EE certificate to verify the signature 811 on the Manifest. 813 3. Verify that the EE certificate is a valid end-entity certificate 814 in the resource PKI by constructing a valid certificate path to a 815 trust anchor. (See [I-D.sidr-res-certs] for more details.) 817 If the above procedure indicates that the manifest is invalid, then 818 the manifest MUST be discarded and treated as though no manifest were 819 present. 821 8. Relying Party Use of Manifests 823 The goal of the relying party is to determine which signed objects to 824 use for routing-related tasks, (e.g., which ROAs to use in the 825 construction of route filters). Ultimately, this is a matter of 826 local policy. However, in the following sections, we describe a 827 sequence of tests that the relying party SHOULD perform to determine 828 the manifest state of the given publication point. We then discuss 829 the risks associated with using signed objects in the publication 830 point, given the manifest state; and provide suitable warning text 831 that should placed in a user-accessible log file. It is the 832 responsibility of the relying party to weigh these risks against the 833 risk of routing failure that could occur if valid data is rejected, 834 and construct a suitable local policy. Note that if a certificate is 835 deemed unfit for use do to local policy, then any descendant object 836 that is validated using this certificate should also be deemed unfit 837 for use (regardless of the status of the manifest at its own 838 publication point). 840 8.1. Tests for Determining Manifest State 842 For a given publication point, the relying party should perform the 843 following tests to determine the manifest state of the publication 844 point: 846 1. For each entity using this publication point, select the entity's 847 manifest having highest manifestNumber among all valid manifests 848 (where manifest validity is defined in Section Section 7). 850 * If the publication point does not contain a valid manifest, 851 see Section Section 8.2. Lacking a valid manifest, the 852 following tests cannot be performed. 854 2. Check that the current time is between thisUpdate and nextUpdate. 856 * If the current time does not lie within this interval then see 857 Section 8.4, but still continue with the following tests. 859 3. Check that every file at the publication point appears in one and 860 only one manifest, and that every file listed in each manifest 861 appears at the publication point. 863 * If there exists files at the publication point that do not 864 appear on any manifest, or files listed in a manifest that do 865 not appear at the publication point then see Section 8.5 but 866 still continue with the following test. 868 4. Check that listed hash value of every file listed in each 869 manifest matches the value obtained by hashing the file at the 870 publication point. 872 * If there exist files at the publication point whose hash does 873 not match the hash value listed in the manifest, then see 874 Section 8.6. 876 For a particular signed object, if all of the following conditions 877 hold: 879 * the manifest for its publication, and the associated 880 publication point, pass all of the above checks; 881 * the signed object is valid; and 882 * the manifests for every certificate on the certificate path 883 used to validate the signed object, and the associated 884 publication points, pass all of the above checks; 885 then the relying party can conclude that no attack against the 886 repository system has compromised the given signed object, and the 887 signed object MUST be treated as valid. 889 8.2. Missing Manifests 891 The absence of a valid manifest at a publication point could occur 892 due to an error by the publisher or due to (malicious or accidental) 893 deletion or corruption of all valid manifests. 895 When no valid manifest is available, there is no protection against 896 attacks that delete signed objects or replay old versions of signed 897 objects. All signed objects at the publication point, and all 898 descendant objects that are validated using a certificate at this 899 publication point should be viewed as somewhat suspect, but may be 900 used by the relying party, as per local policy. 902 The primary risk in using signed objects at this publication point is 903 that a deleted CRL causes the relying party to improperly treat a 904 revoked certificate as valid (and thus rely upon signed objects that 905 are validated using that certificate). This risk is somewhat 906 mitigated if the CRL for this publication point has a short time 907 between thisUpdate and nextUpdate (and the current time is within 908 this interval). The risk in discarding signed objects at this 909 publication point is that the relying party may incorrectly discard a 910 large number of valid objects. This gives significant power to an 911 adversary that is able to delete all manifests at the publication 912 point. 914 Regardless of whether signed objects from this publication are deemed 915 fit for use by the relying party, this situation should result in a 916 warning to the effect that: "No manifest is available for , and thus there may have been undetected deletions or replay 918 substitutions from the publication point." 920 In the case where the relying party has access to a local cache of 921 previously issued manifests that are valid, the relying party MAY use 922 the most recently previously issued valid manifests for this RPKI 923 repository publication collection in this case for each entity that 924 publishes at his publication point. 926 8.3. Invalid Manifests 928 The presence of invalid manifests at a publication point could occur 929 due to an error by the publisher or due to (malicious or accidental) 930 corruption of a valid manifest. An invalid manifest MUST never be 931 used even if the manifestNumber is greater than that on valid 932 manifests. 934 There are no risks associated with using signed objects at a 935 publication point containing an invalid manifest, provided that valid 936 manifests the collectively cover all the signed objects are also 937 present. 939 If an invalid manifest is present at a publication point that also 940 contains one or more valid manifests, this situation should result in 941 a warning to the effect that: "An invalid manifest was found at , this indicates an attack against the publication point 943 or an error by the publisher. Processing for this publication point 944 will continue using the most recent valid manifest." 946 In the case where the relying party has access to a local cache of 947 previously issued manifests that are valid, the relying party MAY use 948 the locally cached most recently previously issued valid manifest 949 issued by the entity that issued the invalid manifest in this case. 951 8.4. Stale Manifests 953 A manifest is considered stale if the current time is after the 954 nextUpdate time for the manifest. This could be due to publisher 955 failure to promptly publish a new manifest, or due to (malicious or 956 accidental) corruption of a more recent manifest. 958 All signed objects at the publication point, and all descendant 959 objects that are validated using a certificate at this publication 960 point should be viewed as somewhat suspect, but may be used by the 961 relying party as per local policy. 963 The primary risk in using signed objects at this publication point is 964 that a newer manifest exists that, if present, would indicate that 965 certain objects are have been removed or replaced. (e.g., the new 966 manifest if present might show the existence of a newer CRL and the 967 removal of several revoked certificates). Thus use of objects on a 968 stale manifest may cause the relying party to incorrectly treat 969 several invalid objects as valid. The risk is that a stale CRL 970 causes the relying party to improperly treat a revoked certificate as 971 valid. This risk is somewhat mitigated if the time between the 972 nextUpdate field of the manifest and the current time is short. The 973 risk in discarding signed objects at this publication point is that 974 the relying party may incorrectly discard a large number of valid 975 objects. This gives significant power to an adversary that is able 976 to prevent the publication of a new manifest at a given publication 977 point. 979 Regardless of whether signed objects from this publication are deemed 980 fit for use by the relying party, this situation should result in a 981 warning to the effect that: "The manifest for is no 982 longer current. It is possible that undetected deletions have 983 occurred at this publication point." 985 Note that there is also a less common case where the current time is 986 before the thisUpdate time for the manifest. This case could be due 987 to publisher error, or a local clock error, and in such a case this 988 situation should result in a warning to the effect that: "The 989 manifest found at has an incorrect thisUpdate field. 990 This could be due to publisher error, or a local clock error, and 991 processing for this publication point will continue using this 992 otherwise valid manifest." 994 8.5. Mismatch between Manifest and Publication Point 996 If there exist otherwise valid signed objects that do not appear in 997 any manifest, then provided the manifest is not stale (see Section 998 Section 8.4) it is likely that their omission is an error by the 999 publisher. It is also possible that this state could be the result 1000 of a (malicious or accidental) replacement of a current manifest with 1001 an older, but still valid manifest. However, regarding the 1002 appropriate interpretation such objects, it remains the case that if 1003 the objects were intended to be invalid, then they should have been 1004 revoked using whatever revocation mechanism is appropriate for the 1005 signed object in question.) Therefore, there is little risk in using 1006 such signed objects. If the manifest in question is stale, then 1007 there is a greater risk that the objects in question were revoked 1008 with a missing CRL, whose absence is undetectable since the manifest 1009 is stale. In any case, the use of signed objects not present on a 1010 manifest, or descendant objects that are validated using such signed 1011 objects, is a matter of local policy. 1013 Regardless of whether objects not appearing on a manifest are deemed 1014 fit for use by the relying party, this situation should result in a 1015 warning to the effect that: "The following files are present in the 1016 repository at , but are not on the manifest ." 1019 If there exist files listed on the manifest that do not appear in the 1020 repository, then these objects are likely to have been improperly 1021 (via malice or accident) deleted from the manifest. A primary 1022 purpose of manifests is to detect such deletions. Therefore, in such 1023 a case this situation should result in a warning to the effect that: 1024 "The following files that should have been present in the repository 1025 at , are missing . This indicates an 1026 attack against this publication point, or the repository, or an error 1027 by the publisher." 1029 8.6. Hash Values Not Matching Manifests 1031 A file appearing on a manifest with an incorrect hash value could 1032 occur because of publisher error, but it is likely to indicate that a 1033 serious error has occurred. 1035 If an object appeared on a previous valid manifest with a correct 1036 hash value and now appears with an invalid hash value, then it is 1037 likely that the object has been superseded by a new (unavailable) 1038 version of the object. If the object is used there is a risk that 1039 the relying party will be treating a stale object as valid. This 1040 risk is more significant if the object in question is a CRL. 1041 Assuming that the object is validated in the RPKI, the use of these 1042 objects is a matter of local policy. 1044 If an object appears on a manifest with an invalid hash and has never 1045 previously appeared on a manifest, then it is unclear whether the 1046 available version of the object is more or less recent than the 1047 version whose hash appears in the manifest. If the manifest is stale 1048 (see Section 8.4) then it becomes more likely that the available 1049 version is more recent that the version indicated on the manifest, 1050 but this is never certain. Whether to use such objects is a matter 1051 of local policy. However, in general, it is better to use a possibly 1052 outdated version of the object than to discard the object completely. 1054 While it is a matter of local policy, in the case of CRLs a relying 1055 party should endeavor to use the most recently issued valid CRL even 1056 where the hash value in the manifest matches an older CRL, or does 1057 not match any CRL hand. The thisUpdate field of the CRL can be used 1058 to establish the most recent CRL in the case where a relying party 1059 has more than one valid CRL at hand. 1061 Regardless of whether objects with incorrect hashes are deemed fit 1062 for use by the relying party, this situation should result in a 1063 warning to the effect that: "The following files at the repository 1064 appear on a manifest with incorrect hash values 1065 . It is possible that these objects have been superseded 1066 by a more recent version. It is very likely that this problem is due 1067 to an attack on the publication point, although it could also be due 1068 to a publisher error." 1070 9. Publication Repositories 1072 The RPKI publication system model requires that every publication 1073 point be associated with one or more CAs or one or more EEs, and be 1074 non-empty. Upon creation of the publication point associated with a 1075 CA, the CA MUST create and publish a manifest as well as a CRL. The 1076 manifest will contain at least one entry, the CRL issued by the CA 1077 upon repository creation. Upon the creation of the publication point 1078 associated with an EE, the EE MUST create and publish a manifest. 1079 The manifest in an otherwise empty repository publication point 1080 associated with an EE will contain no entries in the manifest's 1081 fileList sequence (i.e., the ASN.1 SEQUENCE will have a length of 1082 zero). [I-D.sidr-repos-struct] 1084 For each signed object, the EE certificate used to verify the object 1085 is either a single-use certificate, used to verify a single signed 1086 object, or a multiple-use certificate. In the case of a single-use 1087 EE certificate, the signed object is published in the repository 1088 publication point of the CA that issued the single use EE 1089 certificate, and is listed in the manifest associated with that CA 1090 certificate. In the case where an EE certificate is used to verify 1091 multiple objects, each signed object is published in the EE 1092 certificate's repository publication point and listed in the manifest 1093 associated with the EE certificate. 1095 10. Security Considerations 1097 Manifests provide an additional level of protection for relying 1098 parties of the repository system. Manifests can assist a relying 1099 party to determine if repository objects have been occluded or other 1100 removed from view, and to determine if an older version of an object 1101 has been substituted for the current object . 1103 Manifests cannot repair the effects of such forms of attempted 1104 corruption of repository retrieval operations, but are capable of 1105 allowing a relying party to determine if a locally maintained copy of 1106 a repository is a complete and up to date copy, even when the 1107 repository retrieval operation is conduction over an insecure 1108 channel. In those cases where the manifest and the retrieved 1109 repository contents differ, the manifest can assist in determining 1110 which repository objects form the difference set in terms of missing, 1111 extraneous or older objects . 1113 The signing structure of a manifest and the use of the nextUpdate 1114 value allows the relying party to determine if the manifest itself is 1115 the subject of attempted alteration. The requirement for every 1116 repository publication point to contain at least one manifest allows 1117 a relying party to determine is the manifest itself has been occluded 1118 from view. Such attacks against the manifest are detectable within 1119 the time frame of the regular schedule of manifest updates. Forms of 1120 replay attack within finer-grained time frames are not necessarily 1121 detectable by the manifest structure . 1123 11. IANA Considerations 1125 [Note to IANA, to be removed prior to publication: there are no IANA 1126 considerations stated in this version of the document.] 1128 12. Acknowledgements 1130 The authors would like to acknowledge the contributions from George 1131 Michelson and Randy Bush in the preparation of the manifest 1132 specification. Additionally, the authors would like to thank Mark 1133 Reynolds and Christopher Small for assistance in clarifying manifest 1134 validation and relying party behavior. 1136 13. Notes 1138 [Note to Reviewers: These notes are part of the working group draft 1139 document, and will be removed prior to publication.] 1141 13.1. Changes in the draft from -04 to -05 1143 Removed references to RSA and SHA-256 from the specification of the 1144 DigestAlgorithms field of CMS SignedData, the SignatureAlgorithm and 1145 digestAlgorithm fields of the SignerInfo field and from the 1146 fileHashAlg field of the Manifest, replacing them with a reference to 1147 the RPKI Algorithm and Hash Profile, to allow for RPKI-wide algorithm 1148 agility. 1150 14. Normative References 1152 [I-D.sidr-arch] 1153 Lepinski, M. and S. Kent, "An Infrastructure to Support 1154 Secure Internet Routing", draft-ietf-sidr-arch-08.txt 1155 (work in progress), July 2009. 1157 [I-D.sidr-repos-struct] 1158 Huston, G., Loomans, R., and G. Michaleson, "A Profile for 1159 Resource Certificate Repository Structure", 1160 draft-ietf-sidr-repos-struct-02.txt (work in progress), 1161 August 2009. 1163 [I-D.sidr-res-certs] 1164 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 1165 X.509 PKIX Resource Certificates", 1166 draft-ietf-sidr-res-certs-16.txt (work in progress), 1167 February 2009. 1169 [I-D.sidr-rpki-algs] 1170 Huston, G., "A Profile for Algorithms and Key Sizes for 1171 use in the Resource Public Key Infrastructure", 1172 draft-huston-sidr-rpki-algs-00.txt (work in progress), 1173 July 2009. 1175 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1176 Addresses and AS Identifiers", RFC 3779, June 2004. 1178 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1179 RFC 3852, July 2004. 1181 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 1182 Representing Date and Time in ASN.1", RFC 4049, 1183 April 2005. 1185 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1186 Housley, R., and W. Polk, "Internet X.509 Public Key 1187 Infrastructure Certificate and Certificate Revocation List 1188 (CRL) Profile", RFC 5280, May 2008. 1190 Authors' Addresses 1192 Rob Austein 1193 Internet Systems Consortium 1194 950 Charter St. 1195 Redwood City, CA 94063 1196 USA 1198 Email: sra@isc.org 1200 Geoff Huston 1201 Asia Pacific Network Information Centre 1202 33 Park Rd. 1203 Milton, QLD 4064 1204 Australia 1206 Email: gih@apnic.net 1207 URI: http://www.apnic.net 1209 Stephen Kent 1210 BBN Technologies 1211 10 Moulton St. 1212 Cambridge, MA 02138 1213 USA 1215 Email: kent@bbn.com 1217 Matt Lepinski 1218 BBN Technologies 1219 10 Moulton St. 1220 Cambridge, MA 02138 1221 USA 1223 Email: mlepinski@bbn.com