idnits 2.17.1 draft-ietf-sidr-rpki-manifests-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (May 13, 2010) is 5095 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 556 -- Looks like a reference, but probably isn't: '1' on line 552 == 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: 3 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: November 14, 2010 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 May 13, 2010 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-07.txt 14 Abstract 16 This document defines a "manifest" for use in the Resource Public Key 17 Infrastructure. A manifest is a signed object that contains a 18 listing of all the signed objects in the repository publication point 19 associated with an authority responsible for publishing in the 20 repository. For each certificate, CRL, or other type of signed 21 objects issued by the authority that are published at this repository 22 publication point, the manifest contains both the name of the file 23 containing the object, and a hash of the file content. Manifests are 24 intended to enable a Relying Party to detect certain forms of attacks 25 against a repository. Specifically, if a Relying Party checks a 26 manifest's contents against the signed objects retrieved from a 27 repository publication point, then the Relying Party can detect 28 "stale" (valid) data and deletion of signed objects. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 14, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Manifest Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 5 69 4.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 5 71 4.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 6 72 4.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 8 73 4.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . 8 75 4.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 13 77 5.1. CA Manifest Generation . . . . . . . . . . . . . . . . . . 13 78 5.2. End Entity Manifest Generation . . . . . . . . . . . . . . 14 79 5.3. Common Considerations for Manifest Generation . . . . . . 15 80 6. Processing Certificate Requests . . . . . . . . . . . . . . . 16 81 7. Manifest Validation . . . . . . . . . . . . . . . . . . . . . 17 82 8. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 18 83 8.1. Tests for Determining Manifest State . . . . . . . . . . . 18 84 8.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 20 85 8.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 21 86 8.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 21 87 8.5. Mismatch between Manifest and Publication Point . . . . . 22 88 8.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 23 89 9. Publication Repositories . . . . . . . . . . . . . . . . . . . 24 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 93 13. Normative References . . . . . . . . . . . . . . . . . . . . . 25 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 96 1. Introduction 98 The Resource Public Key Infrastructure (RPKI) [I-D.sidr-arch] makes 99 use of a distributed repository system [I-D.sidr-repos-struct] to 100 make available a variety of objects needed by Relying Parties (RPs). 101 Because all of the objects stored in the repository system are 102 digitally signed by the entities that created them, attacks that 103 modify these published objects are detectable by RPs. However, 104 digital signatures provide no protection against attacks that 105 substitute "stale" versions of signed objects (i.e., objects that 106 were valid and have not expired, but have since been superseded) or 107 attacks that remove an object that should be present in the 108 repository. To assist in the detection of such attacks, the RPKI 109 repository system can make use of a signed object called a 110 "manifest". 112 A manifest is a signed object that contains a listing of all the 113 signed objects in the repository publication point that are 114 associated with an authority responsible for publishing in the 115 repository. For every signed object issued by an authority that is 116 published at the authority's repostory publication point, the 117 authority's manifest contains both the name of the file containing 118 the object, and a hash of the file content. Manifests allow a RP to 119 obtain sufficient information to detect whether the retrieval of 120 objects from an RPKI repository has been compromised by unauthorized 121 object removal, or by the substitution of "stale" versions of 122 objects. Manifests are designed to be used both for Certification 123 Authority (CA) publication points in repositories, that contain 124 subordinate certificates, CRLs and other signed objects, and End 125 Entity (EE) publication points in repositories that contain signed 126 objects. 128 Manifests are modeled on CRLs, as the issues involved in detecting 129 stale manifests, and detection of potential attacks using manifest 130 replays, etc are similar to those for CRLs. The syntax of the 131 manifest payload differs from CRLs, since RPKI repositories can 132 contain objects not covered by CRLs, such as digitally signed 133 objects, such as ROAs. 135 1.1. Terminology 137 It is assumed that the reader is familiar with the terms and concepts 138 described in "Internet X.509 Public Key Infrastructure Certificate 139 and Certificate Revocation List (CRL) Profile" [RFC5280]> and "X.509 140 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119. 146 2. Manifest Scope 148 In the case of a CA's manifest for it's associated repository 149 publication point, the manifest contains the current published 150 certificates issued by this CA, the most recent CRL issued by this 151 CA, and all objects that are signed using a "single-use" EE 152 certificate (i.e., the SIA extension of the EE certificate has an 153 accessMethod OID of id-ad-signedObject), where the EE certificate was 154 issued by this CA. 156 In the case where multiple CAs share a common publication point, as 157 may be the case when an entity performs a staged key-rollover 158 operation, the repository publication point will contain multiple 159 manifests. In such a scenario, each manifest describes only the 160 collection of published products of its associated CA. 162 In the case of a "multi-use" EE certificate, where an EE has a 163 defined repository publication point (i.e., the SIA extension of the 164 EE certificate has an accessMethod OID of id-ad- 165 signedObjectRepository), the EE's manifest contains all published 166 objects that have been signed by the EE's key, and the accessMethod 167 id-as-rpkiManifest points to the publication point of the EE's 168 manifest. 170 3. Manifest Signing 172 A CA's manifest is verified using an EE certificate that is 173 designated in [I-D.sidr-res-certs] as a "single-use" EE certificate. 174 The SIA field of the "single-use" EE certificate contains the access 175 method OID of id-ad-signedObject. 177 The CA MAY chose to sign only one manifest with the private key of 178 the EE certificate, and generate a new EE certificate for each new 179 version of the manifest. This form of use of a "single-use" EE 180 certificate is termed a "one-time-use" EE certificate. 182 Alternatively the CA MAY chose to use the same EE certificate's 183 private key to sign a sequence of manifests. Because only a single 184 manifest is current at any point in time, the EE certificate is used 185 only to verify a single object at a time. As long as the sequence of 186 objects signed by this EE certificate's private key are published as 187 the same named object, so that the SIA accessMethod id-ad- 188 signedObject value can refer to the current instance of the sequence 189 of such objects, then this sequential multiple use of this "single- 190 use" EE certificate is also valid. This form of use of a "single- 191 use" EE certificate is termed a "sequential-use" EE certificate. 193 A "multi-use" EE's manifest of it's publication repository is signed 194 with the private key of the EE certificate. 196 4. Manifest Syntax 198 A manifest is a Cryptographic Message Syntax (CMS) [RFC5652] signed- 199 data object. The general format of a CMS object is: 201 ContentInfo ::= SEQUENCE { 202 contentType ContentType, 203 content [0] EXPLICIT ANY DEFINED BY contentType } 205 ContentType ::= OBJECT IDENTIFIER 207 The ContentType is the signed-data type of id-data, namely the id- 208 signedData OID, 1.2.840.113549.1.7.2. [RFC5652] 210 4.1. Signed-Data Content Type 212 According to the CMS specification, signed-data content types have 213 the ASN.1 type SignedData: 215 SignedData ::= SEQUENCE { 216 version CMSVersion, 217 digestAlgorithms DigestAlgorithmIdentifiers, 218 encapContentInfo EncapsulatedContentInfo, 219 certificates [0] IMPLICIT CertificateSet OPTIONAL, 220 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 221 signerInfos SignerInfos } 223 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 225 SignerInfos ::= SET OF SignerInfo 227 4.1.1. version 229 The version is the syntax version number. It MUST be 3, 230 corresponding to the signerInfo structure having version number 3. 232 4.1.2. digestAlgorithms 234 The digestAlgorithms set contains a set of OIDs of the algorithms 235 used to sign the data. The algorithms used to sign the data MUST 236 conform to the RPKI Algorithms and Key Size Profile specification 238 [I-D.sidr-rpki-algs]. 240 4.1.3. encapContentInfo 242 encapContentInfo is the signed content, consisting of a content type 243 identifier and the content itself. 245 EncapsulatedContentInfo ::= SEQUENCE { 246 eContentType ContentType, 247 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 249 ContentType ::= OBJECT IDENTIFIER 251 4.1.3.1. eContentType 253 The eContentType for a Manifest is defined as id-ct-rpkiManifest, and 254 has the numerical value of 1.2.840.113549.1.9.16.1.26. 256 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 257 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 259 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 261 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 263 4.1.3.2. eContent 265 The content of a Manifest is defined as follows: 267 Manifest ::= SEQUENCE { 268 version [0] INTEGER DEFAULT 0, 269 manifestNumber INTEGER, 270 thisUpdate GeneralizedTime, 271 nextUpdate GeneralizedTime, 272 fileHashAlg OBJECT IDENTIFIER, 273 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash 274 } 276 FileAndHash ::= SEQUENCE { 277 file IA5String 278 hash BIT STRING 279 } 281 4.1.3.2.1. Manifest 283 The manifestNumber, thisUpdate, and nextUpdate fields are modeled 284 after the corresponding fields in X.509 CRLs (see [RFC5280]). 285 Analogous to CRLS, a manifest is nominally current until the time 286 specified in nextUpdate or until a manifest is issued with a greater 287 manifest number, whichever comes first. The revoked EE certificate 288 for the previous manifest's signature will be removed from the CRL 289 when it expires. 291 If a "one-time-use" EE certificate is employed to verify a manifest, 292 the EE certificate MUST have an validity period that coincides with 293 the interval from thisUpdate to nextUpdate, to prevent needless 294 growth of the CA's CRL. 296 If a "sequential-use EE certificate is employed to verify a manifest, 297 the EE certificate's validity period needs to be no shorter than the 298 nextUpdate time of the current manifest. The extended validity time 299 raises the possibility of a substitution attack using a stale 300 manifest, as described in Section 8.4. 302 4.1.3.2.1.1. version 304 The version number of this version of the manifest specification is 305 0. 307 4.1.3.2.1.2. manifestNumber 309 The manifestNumber field is a sequence number that is incremented 310 each time a new manifest is issued for a given publication point. 311 This field is used to allow a RP to detect gaps in a sequence of 312 published manifest. 314 4.1.3.2.1.3. thisUpdate 316 The thisUpdate field contains the time when the manifest was created. 318 4.1.3.2.1.4. nextUpdate 320 The nextUpdate field contains the time at which the next scheduled 321 manifest will be issued. The value of nextUpdate MUST be later than 322 the value of thisUpdate. If the authority alters any of the items in 323 the repository publication point, then the authority MUST issue a new 324 manifest before the nextUpdate time. If a manifest encompasses a 325 CRL, the nextUpdate field of the manifest MUST match that of the CRL, 326 as the manifest will be reissued when a new CRL is published. If a 327 "one-time-use" EE certificate is used to verify the manifest, then 328 when a new manifest is issued before the time specified in nextUpdate 329 of the current manifest, the CA MUST also issue a new CRL that 330 includes the EE certificate corresponding to the old manifest. 332 4.1.3.2.1.5. fileHashAlg 334 The fileHashAlg field contains the OID of the hash algorithm used to 335 hash the files that the authority has placed into the repository. 336 The hash algorithm used MUST conform to the RPKI Algorithms and Key 337 Size Profile specification [I-D.sidr-rpki-algs]. 339 4.1.3.2.1.6. fileList 341 The fileList field is a sequence of FileAndHash objects. There is 342 one FileAndHash entry for each currently valid signed object that has 343 been issued by the authority. Each FileAndHash is an ordered pair 344 consisting of the name of the file in the repository that contains 345 the object in question, and a hash of the file's contents. 347 4.1.4. certificates 349 The certificates field MUST be included, and MUST contain the RPKI EE 350 certificate needed to validate this manifest in the context of the 351 RPKI. 353 4.1.5. crls 355 This field MUST be omitted. 357 4.1.6. signerInfos 359 Signer Infos is defined as a SignerInfo, which is defined under CMS 360 as: 362 SignerInfo ::= SEQUENCE { 363 version CMSVersion, 364 sid SignerIdentifier, 365 digestAlgorithm DigestAlgorithmIdentifier, 366 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 367 signatureAlgorithm SignatureAlgorithmIdentifier, 368 signature SignatureValue, 369 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 371 4.1.6.1. version 373 The version number MUST be 3, corresponding with the choice of 374 SubjectKeyIdentifier for the sid. 376 4.1.6.2. sid 378 The sid is defined as: 380 SignerIdentifier ::= CHOICE { 381 issuerAndSerialNumber IssuerAndSerialNumber, 382 subjectKeyIdentifier [0] SubjectKeyIdentifier } 384 For a Manifest, the sid MUST be a SubjectKeyIdentifier. 386 4.1.6.3. digestAlgorithm 388 The digestAlgorithm field contains the OIDs of the algorithm used to 389 sign the data. The algorithm used to sign the data MUST conform to 390 the RPKI Algorithms and Key Size Profile specification 391 [I-D.sidr-rpki-algs]. 393 4.1.6.4. signedAttrs 395 The signedAttrs is defined as signedAttributes: 397 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 399 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 401 Attribute ::= SEQUENCE { 402 attrType OBJECT IDENTIFIER, 403 attrValues SET OF AttributeValue } 405 AttributeValue ::= ANY 407 The signedAttr element MUST be present and MUST include the content- 408 type and message-digest attributes. The signer MAY also include the 409 signing-time signed attribute, the binary-signing-time signed 410 attribute, or both signing-time attributes. Other signed attributes 411 that are deemed appropriate MAY also be included. The intent is to 412 allow additional signed attributes to be included if a future need is 413 identified. This does not cause an interoperability concern because 414 unrecognized signed attributes are ignored by the relying party. 416 The signedAttr MUST include only a single instance of any particular 417 attribute. Additionally, even though the syntax allows for a SET OF 418 AttributeValue, in a Manifest the attrValues MUST consist of only a 419 single AttributeValue. 421 4.1.6.4.1. Content-Type Attribute 423 The ContentType attribute MUST be present. The attrType OID for the 424 ContentType attribute is 1.2.840.113549.1.9.3. 426 The attrValues for the ContentType attribute in a Manifest MUST be 427 1.2.840.113549.1.9.16.1.26, matching the eContentType in the 428 EncapsulatedContentInfo. 430 4.1.6.4.2. Message-Digest Attribute 432 The MessageDigest Attribute MUST be present. The attrType OID for 433 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 435 The attrValues for the MessageDigest attribute contains the output of 436 the digest algorithm applied to the content being signed, as 437 specified in Section 11.1 of [RFC5652]. 439 4.1.6.4.3. SigningTime Attribute 441 The SigningTime attribute MAY be present. The presence of absence of 442 the SigningTime attribute in no way affects the validation of the 443 Manifest (as specified in Section Section 7). 445 The attrType OID for the SigningTime attribute is 446 1.2.840.113549.1.9.5. 448 The attrValues for the SigningTime attribute is defined as: 450 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 451 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 453 SigningTime ::= Time 455 Time ::= CHOICE { 456 utcTime UTCTime, 457 generalizedTime GeneralizedTime } 459 The Time element specifies the time, based on the local system clock, 460 at which the digital signature was applied to the content. 462 4.1.6.4.4. BinarySigningTime Attribute 464 The signer MAY include a BinarySigningTime attribute, specifying the 465 time at which the digital signature was applied to the content. If 466 both the BinarySigningTime and SigningTime attributes are present, 467 the time that is represented by the binary-signing-time attribute 468 MUST represent the same time value as the signing-time attribute. 469 The presence or absence of the Binary-SigningTime attribute in no way 470 affects the validation of the Manifest (as specified in Section 471 Section 7). 473 The binary-signing-time attribute is defined in [RFC4049] as: 475 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 476 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 477 smime(16) aa(2) 46 } 479 BinarySigningTime ::= BinaryTime 481 BinaryTime ::= INTEGER (0..MAX) 483 4.1.6.5. signatureAlgorithm 485 The signatureAlgorithm MUST conform to the RPKI Algorithms and Key 486 Size Profile specification [I-D.sidr-rpki-algs]. 488 4.1.6.6. signature 490 The signature value is defined as: 492 SignatureValue ::= OCTET STRING 494 The signature characteristics are defined by the digest and signature 495 algorithms. 497 4.1.6.7. unsignedAttrs 499 unsignedAttrs MUST be omitted. 501 4.2. ASN.1 503 The following is the ASN.1 specification of the CMS-signed Manifest. 505 ContentInfo ::= SEQUENCE { 506 contentType ContentType, 507 content [0] EXPLICIT ANY DEFINED BY contentType } 509 ContentType ::= OBJECT IDENTIFIER 511 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 512 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 514 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 516 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 518 Manifest ::= SEQUENCE { 519 version [0] INTEGER DEFAULT 0, 520 manifestNumber INTEGER, 521 thisUpdate GeneralizedTime, 522 nextUpdate GeneralizedTime, 523 fileHashAlg OBJECT IDENTIFIER, 524 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash} 526 FileAndHash ::= SEQUENCE { 527 file IA5String 528 hash BIT STRING} 530 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 531 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 533 SignedData ::= SEQUENCE { 534 version CMSVersion, 535 digestAlgorithms DigestAlgorithmIdentifiers, 536 encapContentInfo EncapsulatedContentInfo, 537 certificates [0] IMPLICIT CertificateSet OPTIONAL, 538 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 539 signerInfos SignerInfos } 541 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 543 SignerInfos ::= SET OF SignerInfo 545 SignerInfo ::= SEQUENCE { 546 version CMSVersion, 547 sid SignerIdentifier, 548 digestAlgorithm DigestAlgorithmIdentifier, 549 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 550 signatureAlgorithm SignatureAlgorithmIdentifier, 551 signature SignatureValue, 552 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 554 SignerIdentifier ::= CHOICE { 555 issuerAndSerialNumber IssuerAndSerialNumber, 556 subjectKeyIdentifier [0] SubjectKeyIdentifier } 558 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 560 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 562 Attribute ::= SEQUENCE { 563 attrType OBJECT IDENTIFIER, 564 attrValues SET OF AttributeValue } 566 AttributeValue ::= ANY 568 SignatureValue ::= OCTET STRING 570 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 571 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 573 ContentType ::= OBJECT IDENTIFIER 575 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 576 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 578 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, 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. 612 * This EE certificate has an SIA extension access description 613 field with an accessMethod OID value of id-ad-signedobject 614 where the associated accessLocation references the publication 615 point of the manifest as an object URL. 617 * This EE certificate MUST describe its IP number resources 618 using the "inherit" attribute, rather than explicit 619 description of a resource set. 621 * In the case of a "one-time-use" EE certificate, the validity 622 times of the EE certificate SHOULD exactly match the 623 thisUpdate and nextUpdate times of the manifest, and MUST 624 encompass the interval from thisUpdate to nextUpdate. 626 * In the case of a "sequential-use" EE certificate the validity 627 times of the EE certificate MUST encompass the time interval 628 from thisUpdate to nextUpdate. 630 3. The EE certificate SHOULD NOT be published in the authority's 631 repository publication point. 633 4. Construct the manifest content. Note that the manifest does not 634 include a self reference (i.e., its own file name and hash), 635 since it would be impossible to compute the hash of the manifest 636 itself prior to it being signed. The manifest content is 637 described in Section 4.1.3.2.1. The manifest's fileList includes 638 the file names and hash pair for each object issued by this CA 639 that has been published at this CA's repository publication 640 point. The collection of objects to be included in the manifest 641 includes all certificates issued by this CA that are published at 642 the CA's repository publication point, the most recent CRL issued 643 by the CA, and all objects verified by "single-use" EE 644 certificates that were issued by this CA that are published at 645 the CA's repository publication point. 647 5. Encapsulate the Manifest content using the CMS SignedData content 648 type (as specified in Section Section 4), sign the manifest using 649 the private key corresponding to the EE certificate, and publish 650 the manifest in repository system publication point that is 651 described by the manifest. 653 6. In the case of a key pair that is to be used only once, in 654 conjunction with a "one-time-use" EE certificate, the private key 655 associated with this key pair SHOULD now be destroyed. 657 5.2. End Entity Manifest Generation 659 EE repository publication points are used only in conjunction with 660 "multi-use" EE Certificates. In this case the EE Certificate has two 661 accessMethods specified in its SIA field. The id-ad- 662 signedObjectRepository accessMethod has an associated accessLocation 663 that points to the repository publication point of the objects signed 664 by this EE certificate, as specified in [I-D.sidr-res-certs]. The 665 id-ad-rpkiManifest accessMethod has an associated access location 666 that points to the manifest object as an object URL, that is 667 associated with this repository publication point. This manifest 668 describes all the signed objects that are to be found in that 669 publication point that have been signed by this EE certificate, and 670 the hash value of each product (excluding the manifest itself). 672 To create a manifest, each "multi-use" EE MUST perform the following 673 steps:. 675 o Construct the Manifest content. Note that the manifest does not 676 include a self reference (i.e., its own file name and hash), since 677 it would be impossible to compute the hash of the manifest itself 678 prior to it being signed. The manifest content is described in 679 Section 4.1.3.2.1. The manifest's fileList includes the file 680 names and hash pair for each object verified using that EE 681 certificate that has been published at the EE's repository 682 publication point. 684 o Encapsulate the Manifest content using the CMS SignedData content 685 type (as specified in Section Section 4), sign the manifest using 686 the private key corresponding to the public key in the EE 687 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 verified 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 syntactically with this 769 specification. In 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 one EE certificate whose Subject Key Identifier 782 (SKI) field 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 a relying party is to determine which signed objects to 824 use for validating assertions about IP number resources and their use 825 (For example, which ROAs to use in the construction of route 826 filters). Ultimately, this selection is a matter of local policy. 827 However, in the following sections, we describe a sequence of tests 828 that the relying party SHOULD perform to determine the manifest state 829 of the given publication point. We then discuss the risks associated 830 with using signed objects in the publication point, given the 831 manifest state; and provide suitable warning text that should placed 832 in a user-accessible log file. It is the responsibility of the 833 relying party to weigh these risks against the risk of routing 834 failure that could occur if valid data is rejected, and construct a 835 suitable local policy. Note that if a certificate is deemed unfit 836 for use do to local policy, then any descendant object that is 837 validated using this certificate should also be deemed unfit for use 838 (regardless of the status of the manifest at its own publication 839 point). 841 8.1. Tests for Determining Manifest State 843 For a given publication point, the relying party should perform the 844 following tests to determine the manifest state of the publication 845 point: 847 1. For each entity using this publication point, select the entity's 848 current manifest (where the "current" manifest is the manifest 849 issued by this CA having highest manifestNumber among all valid 850 manifests, and where manifest validity is defined in Section 7). 852 * If the publication point does not contain a valid manifest, 853 see Section Section 8.2. Lacking a valid manifest, the 854 following tests cannot be performed. 856 2. Check that the current time (translated to UTC) is between 857 thisUpdate and nextUpdate. 859 * If the current time does not lie within this interval then see 860 Section 8.4, but still continue with the following tests. 862 3. Check that every file at the publication point appears in one and 863 only one current manifest, and that every file listed in each 864 current manifest that is published at this publication point also 865 is published at the publication point. 867 * If there exist files at the publication point that do not 868 appear on any manifest, or files listed in a manifest that do 869 not appear at the publication point then see Section 8.5, but 870 still continue with the following test. 872 4. Check that listed hash value of every file listed in each current 873 manifest matches the value obtained by hashing the file at the 874 publication point. 876 * If there exist files at the publication point whose hash does 877 not match the hash value listed in the manifest, then see 878 Section 8.6. 880 5. Check that the contents of each current manifest conforms to the 881 manifest's scope constraints, as specified in Section 2. 883 * If a current manifest contains entries for objects that are 884 not within the scope of the manifest, then the out-of-scope 885 entries should be disregarded in the context of this manifest. 886 If there is no other current manifest that describes these 887 objects within that other manifest's scope, then see 888 Section 8.2. 890 For a particular signed object, if all of the following conditions 891 hold: 893 * the manifest for its publication, and the associated 894 publication point, pass all of the above checks; 895 * the signed object is valid; and 896 * the manifests for every certificate on the certificate path 897 used to validate the signed object, and the associated 898 publication points, pass all of the above checks; 899 then the relying party can conclude that no attack against the 900 repository system has compromised the given signed object, and the 901 signed object MUST be treated as valid. 903 8.2. Missing Manifests 905 The absence of a current manifest at a publication point could occur 906 due to an error by the publisher or due to (malicious or accidental) 907 deletion or corruption of all valid manifests. 909 When no valid manifest is available, there is no protection against 910 attacks that delete signed objects or replay old versions of signed 911 objects. All signed objects at the publication point, and all 912 descendant objects that are validated using a certificate at this 913 publication point should be viewed as somewhat suspect, but may be 914 used by the relying party, as per local policy. 916 The primary risk in using signed objects at this publication point is 917 that a deleted CRL would cause the relying party to improperly accept 918 a revoked certificate as valid (and thus rely upon signed objects 919 that are validated using that certificate). This risk is somewhat 920 mitigated if the CRL for this publication point has a short time 921 between thisUpdate and nextUpdate (and the current time is within 922 this interval). The risk in discarding signed objects at this 923 publication point is that a relying party may incorrectly discard a 924 large number of valid objects. This gives significant power to an 925 adversary that is able to delete all manifests at the publication 926 point. 928 Regardless of whether signed objects from this publication are deemed 929 fit for use by the relying party, this situation should result in a 930 warning to the effect that: "No manifest is available for , and thus there may have been undetected deletions or replay 932 substitutions from the publication point." 934 In the case where the relying party has access to a local cache of 935 previously issued manifests that are valid, the relying party MAY use 936 the most recently previously issued valid manifests for this RPKI 937 repository publication collection in this case for each entity that 938 publishes at his publication point. 940 8.3. Invalid Manifests 942 The presence of invalid manifests at a publication point could occur 943 due to an error by the publisher or due to (malicious or accidental) 944 corruption of a valid manifest. An invalid manifest MUST never be 945 used even if the manifestNumber is greater than that of valid 946 manifests. 948 There are no risks associated with using signed objects at a 949 publication point containing an invalid manifest, provided that valid 950 manifests that collectively cover all the signed objects are also 951 present. 953 If an invalid manifest is present at a publication point that also 954 contains one or more valid manifests, this situation should result in 955 a warning to the effect that: "An invalid manifest was found at , this indicates an attack against the publication point 957 or an error by the publisher. Processing for this publication point 958 will continue using the most recent valid manifest." 960 In the case where the relying party has access to a local cache of 961 previously issued manifests that are valid, the relying party MAY use 962 the locally cached most recently previously issued valid manifest 963 issued by the entity that issued the invalid manifest in this case. 965 8.4. Stale Manifests 967 A manifest is considered stale if the current time is after the 968 nextUpdate time for the manifest. This could be due to publisher 969 failure to promptly publish a new manifest, or due to (malicious or 970 accidental) corruption of a more recent manifest. 972 All signed objects at the publication point, and all descendant 973 objects that are validated using a certificate at this publication 974 point should be viewed as somewhat suspect, but may be used by the 975 relying party as per local policy. 977 The primary risk in using signed objects at this publication point is 978 that a newer manifest exists that, if present, would indicate that 979 certain objects are have been removed or replaced. (For example, the 980 new manifest might show the existence of a newer CRL and the removal 981 of one or more revoked certificates). This use of objects from a 982 stale manifest may cause the relying party to incorrectly treat 983 invalid objects as valid. The risk is that a stale CRL causes the 984 relying party to improperly treat a revoked certificate as valid. 985 This risk is somewhat mitigated if the time between the nextUpdate 986 field of the manifest and the current time is short. The risk in 987 discarding signed objects at this publication point is that the 988 relying party may incorrectly discard a large number of valid 989 objects. This gives significant power to an adversary that is able 990 to prevent the publication of a new manifest at a given publication 991 point. 993 Regardless of whether signed objects from this publication are deemed 994 fit for use by the relying party, this situation should result in a 995 warning to the effect that: "The manifest for is no 996 longer current. It is possible that undetected deletions have 997 occurred at this publication point." 999 Note that there is also a less common case where the current time is 1000 before the thisUpdate time for the manifest. This case could be due 1001 to publisher error, or a local clock error, and in such a case this 1002 situation should result in a warning to the effect that: "The 1003 manifest found at has an incorrect thisUpdate field. 1004 This could be due to publisher error, or a local clock error, and 1005 processing for this publication point will continue using this 1006 otherwise valid manifest." 1008 8.5. Mismatch between Manifest and Publication Point 1010 If there exist otherwise valid signed objects that do not appear in 1011 any manifest, then provided the manifest is not stale (see 1012 Section 8.4) it is likely that their omission is an error by the 1013 publisher. It is also possible that this state could be the result 1014 of a (malicious or accidental) replacement of a current manifest with 1015 an older, but still valid manifest. However, regarding the 1016 appropriate interpretation such objects, it remains the case that if 1017 the objects were intended to be invalid, then they should have been 1018 revoked using whatever revocation mechanism is appropriate for the 1019 signed object in question.) Therefore, there is little risk in using 1020 such signed objects. If the manifest in question is stale, then 1021 there is a greater risk that the objects in question were revoked 1022 with a missing CRL, whose absence is undetectable since the manifest 1023 is stale. In any case, the use of signed objects not present on a 1024 manifest, or descendant objects that are validated using such signed 1025 objects, is a matter of local policy. 1027 Regardless of whether objects not appearing on a manifest are deemed 1028 fit for use by the relying party, this situation should result in a 1029 warning to the effect that: "The following files are present in the 1030 repository at , but are not on the manifest ." 1033 If there exist files listed on the manifest that do not appear in the 1034 repository, then these objects are likely to have been improperly 1035 (via malice or accident) deleted from the repository. A primary 1036 purpose of manifests is to detect such deletions. Therefore, in such 1037 a case this situation should result in a warning to the effect that: 1038 "The following files that should have been present in the repository 1039 at , are missing . This indicates an 1040 attack against this publication point, or the repository, or an error 1041 by the publisher." 1043 8.6. Hash Values Not Matching Manifests 1045 A file appearing on a manifest with an incorrect hash value could 1046 occur because of publisher error, but it also may indicate that an 1047 attack has occurred. 1049 If an object appeared on a previous valid manifest with a correct 1050 hash value, and now appears with an invalid hash value, then it is 1051 likely that the object has been superseded by a new (unavailable) 1052 version of the object. If the object is used there is a risk that 1053 the relying party will be treating a stale object as valid. This 1054 risk is more significant if the object in question is a CRL. 1055 Assuming that the object is validated in the RPKI, the use of these 1056 objects is a matter of local policy. 1058 If an object appears on a manifest with an invalid hash and has never 1059 previously appeared on a manifest, then it is unclear whether the 1060 available version of the object is more or less recent than the 1061 version whose hash appears in the manifest. If the manifest is stale 1062 (see Section 8.4) then it becomes more likely that the available 1063 version is more recent that the version indicated on the manifest, 1064 but this is never certain. Whether to use such objects is a matter 1065 of local policy. However, in general, it is better to use a possibly 1066 outdated version of the object than to discard the object completely. 1068 While it is a matter of local policy, in the case of CRLs, a relying 1069 party should endeavor to use the most recently issued valid CRL even 1070 where the hash value in the manifest matches an older CRL, or does 1071 not match any CRL hand. The thisUpdate field of the CRL can be used 1072 to establish the most recent CRL in the case where a relying party 1073 has more than one valid CRL at hand. 1075 Regardless of whether objects with incorrect hashes are deemed fit 1076 for use by the relying party, this situation should result in a 1077 warning to the effect that: "The following files at the repository 1078 appear on a manifest with incorrect hash values 1079 . It is possible that these objects have been superseded 1080 by a more recent version. It is very likely that this problem is due 1081 to an attack on the publication point, although it could also be due 1082 to a publisher error." 1084 9. Publication Repositories 1086 The RPKI publication system model requires that every publication 1087 point be associated with one or more CAs or one or more EEs, and be 1088 non-empty. Upon creation of the publication point associated with a 1089 CA, the CA MUST create and publish a manifest as well as a CRL. The 1090 manifest will contain at least one entry, the CRL issued by the CA 1091 upon repository creation. Upon the creation of the publication point 1092 associated with an EE, the EE MUST create and publish a manifest. 1093 The manifest in an otherwise empty repository publication point 1094 associated with an EE will contain no entries in the manifest's 1095 fileList sequence (i.e., the ASN.1 SEQUENCE will have a length of 1096 zero). [I-D.sidr-repos-struct] 1098 For each signed object, the EE certificate used to verify the object 1099 is either a single-use certificate, used to verify a single signed 1100 object, or a multiple-use certificate. In the case of a single-use 1101 EE certificate, the signed object is published in the repository 1102 publication point of the CA that issued the single use EE 1103 certificate, and is listed in the manifest associated with that CA 1104 certificate. In the case where an EE certificate is used to verify 1105 multiple objects, each signed object is published in the EE 1106 certificate's repository publication point and listed in the manifest 1107 associated with the EE certificate. 1109 10. Security Considerations 1111 Manifests provide an additional level of protection for relying 1112 parties of the repository system. Manifests can assist a relying 1113 party to determine if repository objects have been occluded or other 1114 removed from view, and to determine if an older version of an object 1115 has been substituted for the current object. 1117 Manifests cannot repair the effects of such forms of corruption of 1118 repository retrieval operations, but are capable of allowing a 1119 relying party to determine if a locally maintained copy of a 1120 repository is a complete and up to date copy, even when the 1121 repository retrieval operation is conduction over an insecure 1122 channel. In those cases where the manifest and the retrieved 1123 repository contents differ, the manifest can assist in determining 1124 which repository objects form the difference set in terms of missing, 1125 extraneous or older objects . 1127 The signing structure of a manifest and the use of the nextUpdate 1128 value allows the relying party to determine if the manifest itself is 1129 the subject of attempted alteration. The requirement for every 1130 repository publication point to contain at least one manifest allows 1131 a relying party to determine is the manifest itself has been occluded 1132 from view. Such attacks against the manifest are detectable within 1133 the time frame of the regular schedule of manifest updates. Forms of 1134 replay attack within finer-grained time frames are not necessarily 1135 detectable by the manifest structure . 1137 11. IANA Considerations 1139 [Note to IANA, to be removed prior to publication: there are no IANA 1140 considerations stated in this version of the document.] 1142 12. Acknowledgements 1144 The authors would like to acknowledge the contributions from George 1145 Michelson and Randy Bush in the preparation of the manifest 1146 specification. Additionally, the authors would like to thank Mark 1147 Reynolds and Christopher Small for assistance in clarifying manifest 1148 validation and relying party behavior. 1150 13. 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 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 1179 Representing Date and Time in ASN.1", RFC 4049, 1180 April 2005. 1182 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1183 Housley, R., and W. Polk, "Internet X.509 Public Key 1184 Infrastructure Certificate and Certificate Revocation List 1185 (CRL) Profile", RFC 5280, May 2008. 1187 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 1188 RFC 5652, September 2009. 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 1216 Matt Lepinski 1217 BBN Technologies 1218 10 Moulton St. 1219 Cambridge, MA 02138 1220 USA 1222 Email: mlepinski@bbn.com