idnits 2.17.1 draft-ietf-sidr-rpki-manifests-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1233. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2008) is 5654 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 544 -- Looks like a reference, but probably isn't: '1' on line 540 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'ID.sidr-arch') == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-10 ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing R. Austein 3 Internet-Draft ISC 4 Intended status: Standards Track G. Huston 5 Expires: April 28, 2009 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 October 25, 2008 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-04.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 28, 2009. 39 Abstract 41 This document defines a "manifest" for use in the Resource Public Key 42 Infrastructure. A manifest is a signed object that contains a 43 listing of all the signed objects in the repository publication point 44 associated with an authority responsible for publishing in the 45 repository. For each certificate, or other forms of signed objects 46 issued by the authority that are published at this repository 47 publication point, the manifest contains both the name of the file 48 containing the object, and a hash of the file content. Manifests are 49 intended to expose potential attacks against relying parties of the 50 Resource Public Key Infrastructure, such as a man-in-the middle 51 attack of withholding repository data from relying party access, or 52 replaying stale repository data to a relying party's access request. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Manifest Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 5 62 4.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 5 64 4.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 6 65 4.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 8 66 4.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . 8 68 4.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 13 70 5.1. CA Manifest Generation . . . . . . . . . . . . . . . . . . 13 71 5.2. End Entity Manifest Generation . . . . . . . . . . . . . . 14 72 5.3. Common Considerations for Manifest Generation . . . . . . 15 73 6. Processing Certificate Requests . . . . . . . . . . . . . . . 16 74 7. Manifest Validation . . . . . . . . . . . . . . . . . . . . . 16 75 8. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 18 76 8.1. Tests for Determining Manifest State . . . . . . . . . . . 18 77 8.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 19 78 8.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 20 79 8.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 20 80 8.5. Mismatch between Manifest and Publication Point . . . . . 21 81 8.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 22 82 9. Publication Repositories . . . . . . . . . . . . . . . . . . . 23 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 86 13. Normative References . . . . . . . . . . . . . . . . . . . . . 24 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 88 Intellectual Property and Copyright Statements . . . . . . . . . . 27 90 1. Introduction 92 The Resource Public Key Infrastructure (RPKI) [ID.sidr-arch] makes 93 use of a distributed repository system [ID.sidr-repos-struct] to make 94 available a variety of objects needed by relying parties (RPs) such 95 as Internet service providers (ISPs). Because all of the objects 96 stored in the repository system are digitally signed by the entities 97 that created them, attacks that modify these objects are detectable 98 by RPs. However, digital signatures provide no protection against 99 attacks that substitute "stale" versions of signed objects (i.e., 100 objects that were valid and have not expired, but have since been 101 superseded) or attacks that remove an object that should be present 102 in the repository. To assist in the detection of such attacks, the 103 RPKI repository system will make use of a new signed object called a 104 "manifest". 106 A manifest is a signed object that contains a listing of all the 107 signed objects in the repository publication point associated with an 108 authority responsible for publishing in the repository. For each 109 certificate, Certificate Revocation List (CRL), or other signed 110 object, such as a Route Origination Authorization (ROA), issued by an 111 authority, the authority's manifest contains both the name of the 112 file containing the object, and a hash of the file content. 113 Manifests allow a RP to obtain sufficient information to detect 114 whether the retrieval of objects from an RPKI repository has been 115 compromised by unauthorized object removal, or by the substitution of 116 "stale" versions of objects. Manifests are designed to be used both 117 for Certification Authority (CA) publication points in repositories, 118 that contain subordinate certificates, CRLs and other signed objects, 119 and End Entity (EE) publication points in repositories that contain 120 signed objects. 122 Manifests are modeled on CRLs, as the issues involved in detecting 123 stale manifests, and detection of potential attacks using manifest 124 replays, etc are similar to those for CRLs. The syntax of the 125 manifest payload differs from CRLs, since RPKI repositories can 126 contain objects not covered by CRLs, such as digitally signed 127 objects, such as ROAs. 129 1.1. Terminology 131 It is assumed that the reader is familiar with the terms and concepts 132 described in "Internet X.509 Public Key Infrastructure Certificate 133 and Certificate Revocation List (CRL) Profile" [RFC5280]and "X.509 134 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119. 140 2. Manifest Scope 142 In the case of a CA's manifest for its associated publication 143 repository, the manifest contains the current published certificates 144 issued by this CA, the most recent CRL issued by this CA, and all 145 objects that are signed using a "single-use" EE certificate (i.e., 146 the SIA extension of the EE certificate has an accessMethod OID of 147 id-ad-signedObject), where the EE certificate was issued by this CA. 149 In the case where multiple CAs share a common publication point, as 150 may be the case when an entity performs a staged key-rollover 151 operation, the repository publication will contain multiple 152 manifests. In such a scenario, each manifest describes only the 153 collection of published products of its associated CA. 155 In the case of a "multi-use" EE certificate, where an EE has a 156 defined publication repository (i.e., the SIA extension of the EE 157 certificate has an accessMethod OID of id-ad-signedObjectRepository), 158 the EE's manifest contains all published objects that have been 159 signed by the EE's key, and the accessMethod id-as-rpkiManifest 160 points to the publication point of the EE's manifest. 162 3. Manifest Signing 164 A CA's manifest is verified using an EE certificate that is 165 designated in [ID.sidr-res-certs] as a "single-use" EE certificate. 166 The SIA field of the "single-use" EE certificate contains the access 167 method OID of id-ad-signedObject. 169 The CA MAY chose to sign only one manifest with the private key of 170 the EE certificate, and generate a new EE certificate for each new 171 version of the manifest. This form of use of a "single-use" EE 172 certificate is termed a "one-time-use" EE certificate. 174 Alternatively the CA MAY chose to use the same EE certificate's 175 private key to sign a sequence of manifests. Because only a single 176 manifest is current at any point in time, the EE certificate is used 177 only to verify a single object at a time. As long as the sequence of 178 objects signed by this EE certificate's private key are published as 179 the same named object, so that the SIA accessMethod id-ad- 180 signedObject value can refer to the current instance of the sequence 181 of such objects, then this sequential multiple use of this "single- 182 use" EE certificate is also valid. This form of use of a "single- 183 use" EE certificate is termed a "sequential-use" EE certificate. 185 A "multi-use" EE's manifest of it's publication repository is signed 186 with the private key of the EE certificate. 188 4. Manifest Syntax 190 A manifest is a Cryptographic Message Syntax (CMS) [RFC3852] signed- 191 data object. The general format of a CMS object is: 193 ContentInfo ::= SEQUENCE { 194 contentType ContentType, 195 content [0] EXPLICIT ANY DEFINED BY contentType } 197 ContentType ::= OBJECT IDENTIFIER 199 A Manifest is a signed-data object. The ContentType used is the 200 signed-data type of id-data, namely the id-signedData OID, 201 1.2.840.113549.1.7.2. [RFC3852] 203 4.1. Signed-Data Content Type 205 According to the CMS specification, signed-data content types shall 206 have the ASN.1 type SignedData: 208 SignedData ::= SEQUENCE { 209 version CMSVersion, 210 digestAlgorithms DigestAlgorithmIdentifiers, 211 encapContentInfo EncapsulatedContentInfo, 212 certificates [0] IMPLICIT CertificateSet OPTIONAL, 213 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 214 signerInfos SignerInfos } 216 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 218 SignerInfos ::= SET OF SignerInfo 220 4.1.1. version 222 The version is the syntax version number. It MUST be 3, 223 corresponding to the signerInfo structure having version number 3. 225 4.1.2. digestAlgorithms 227 The digestAlgorithms set MUST include only SHA-256, the OID for which 228 is 2.16.840.1.101.3.4.2.1 [RFC4055]. It MUST NOT contain any other 229 algorithms. 231 4.1.3. encapContentInfo 233 encapContentInfo is the signed content, consisting of a content type 234 identifier and the content itself. 236 EncapsulatedContentInfo ::= SEQUENCE { 237 eContentType ContentType, 238 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 240 ContentType ::= OBJECT IDENTIFIER 242 4.1.3.1. eContentType 244 The eContentType for a Manifest is defined as id-ct-rpkiManifest, and 245 has the numerical value of 1.2.840.113549.1.9.16.1.26. 247 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 248 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 250 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 252 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 254 4.1.3.2. eContent 256 The content of a Manifest is defined as follows: 258 Manifest ::= SEQUENCE { 259 version [0] INTEGER DEFAULT 0, 260 manifestNumber INTEGER, 261 thisUpdate GeneralizedTime, 262 nextUpdate GeneralizedTime, 263 fileHashAlg OBJECT IDENTIFIER, 264 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash 265 } 267 FileAndHash ::= SEQUENCE { 268 file IA5String 269 hash BIT STRING 270 } 272 4.1.3.2.1. Manifest 274 The manifestNumber, thisUpdate, and nextUpdate fields are modeled 275 after the corresponding fields in X.509 CRLs (see [RFC5280]). 276 Analogous to CRLS, a manifest is nominally valid until the time 277 specified in nextUpdate or until a manifest is issued with a greater 278 manifest number, whichever comes first. The revoked EE certificate 279 for the previous manifest's signature will be removed from the CRL 280 when it expires. 282 If a "one-time-use" EE certificate is employed to verify a manifest, 283 the EE certificate MUST have an validity period that coincides with 284 the interval from thisUpdate to nextUpdate, to prevent needless 285 growth of the CA's CRL. 287 If a "sequential-use EE certificate is employed to verify a manifest, 288 the EE certificate's validity period needs to be no shorter than the 289 nextUpdate time of the current manifest. The extended validity time 290 raises the possibility of a substitution attack using a stale 291 manifest, as described in Section 8.4. 293 4.1.3.2.1.1. version 295 The version number of the rpkiManifest MUST be 0. 297 4.1.3.2.1.2. manifestNumber 299 The manifestNumber field is a sequence number that is incremented 300 each time a new manifest is issued for a given publication point. 301 This field is used to allow a RP to detect gaps in a sequence of 302 published manifest. 304 4.1.3.2.1.3. thisUpdate 306 The thisUpdate field contains the time when the manifest was created. 308 4.1.3.2.1.4. nextUpdate 310 The nextUpdate field contains the time at which the next scheduled 311 manifest will be issued. The value of nextUpdate MUST be later than 312 the value of thisUpdate. If the authority alters any of the items in 313 the repository publication point, then the authority MUST issue a new 314 manifest before the nextUpdate time. If a manifest encompasses a 315 CRL, the nextUpdate field of the manifest MUST match that of the CRL, 316 as the manifest will be reissued when a new CRL is published. When a 317 "one-time-use" EE certificate is being used to verify the manifest, 318 then when a new manifest is issued before the time specified in 319 nextUpdate of the current manifest, the CA MUST also issue a new CRL 320 that includes the EE certificate corresponding to the old manifest. 322 4.1.3.2.1.5. fileHashAlg 324 The fileHashAlg field contains the OID of the hash algorithm used to 325 hash the files that the authority has placed into the repository. 326 The mandatory to implement hash algorithm is SHA-256 and its OID is 327 2.16.840.1.101.3.4.2.1. [RFC4055]. 329 4.1.3.2.1.6. fileList 331 The fileList field contains a sequence of FileAndHash pairs, one for 332 each currently valid signed object that has been issued by the 333 authority. Each FileAndHash pair contains the name of the file in 334 the repository that contains the object in question, and a hash of 335 the file's contents. 337 4.1.4. certificates 339 The certificates field MUST be included, and MUST contain the RPKI EE 340 certificate needed to validate this manifest in the context of the 341 RPKI. 343 4.1.5. crls 345 This field MUST be omitted. 347 4.1.6. signerInfos 349 Signer Infos is defined as a SignerInfo, which is defined under CMS 350 as: 352 SignerInfo ::= SEQUENCE { 353 version CMSVersion, 354 sid SignerIdentifier, 355 digestAlgorithm DigestAlgorithmIdentifier, 356 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 357 signatureAlgorithm SignatureAlgorithmIdentifier, 358 signature SignatureValue, 359 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 361 4.1.6.1. version 363 The version number MUST be 3, corresponding with the choice of 364 SubjectKeyIdentifier for the sid. 366 4.1.6.2. sid 368 The sid is defined as: 370 SignerIdentifier ::= CHOICE { 371 issuerAndSerialNumber IssuerAndSerialNumber, 372 subjectKeyIdentifier [0] SubjectKeyIdentifier } 374 For a Manifest, the sid MUST be a SubjectKeyIdentifier. 376 4.1.6.3. digestAlgorithm 378 The digestAlgorithm MUST be SHA-256, the OID for which is 379 2.16.840.1.101.3.4.2.1. [RFC4055] 381 4.1.6.4. signedAttrs 383 The signedAttrs is defined as signedAttributes: 385 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 387 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 389 Attribute ::= SEQUENCE { 390 attrType OBJECT IDENTIFIER, 391 attrValues SET OF AttributeValue } 393 AttributeValue ::= ANY 395 The signedAttr element MUST be present and MUST include the content- 396 type and message-digest attributes. The signer MAY also include the 397 signing-time signed attribute, the binary-signing-time signed 398 attribute, or both signing-time attributes. Other signed attributes 399 that are deemed appropriate MAY also be included. The intent is to 400 allow additional signed attributes to be included if a future need is 401 identified. This does not cause an interoperability concern because 402 unrecognized signed attributes are ignored by the relying party. 404 The signedAttr MUST include only a single instance of any particular 405 attribute. Additionally, even though the syntax allows for a SET OF 406 AttributeValue, in a Manifest the attrValues MUST consist of only a 407 single AttributeValue. 409 4.1.6.4.1. Content-Type Attribute 411 The ContentType attribute MUST be present. The attrType OID for the 412 ContentType attribute is 1.2.840.113549.1.9.3. 414 The attrValues for the ContentType attribute in a Manifest MUST be 415 1.2.840.113549.1.9.16.1.26, matching the eContentType in the 416 EncapsulatedContentInfo. 418 4.1.6.4.2. Message-Digest Attribute 420 The MessageDigest Attribute MUST be present. The attrType OID for 421 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 423 The attrValues for the MessageDigest attribute contains the output of 424 the digest algorithm applied to the content being signed, as 425 specified in Section 11.1 of [RFC3852]. 427 4.1.6.4.3. SigningTime Attribute 429 The SigningTime attribute MAY be present. The presence of absence of 430 the SigningTime attribute in no way affects the validation of the 431 Manifest (as specified in Section Section 7). 433 The attrType OID for the SigningTime attribute is 434 1.2.840.113549.1.9.5. 436 The attrValues for the SigningTime attribute is defined as: 438 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 439 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 441 SigningTime ::= Time 443 Time ::= CHOICE { 444 utcTime UTCTime, 445 generalizedTime GeneralizedTime } 447 The Time element specifies the time, based on the local system clock, 448 at which the digital signature was applied to the content. 450 4.1.6.4.4. BinarySigningTime Attribute 452 The signer MAY include a BinarySigningTime attribute, specifying the 453 time at which the digital signature was applied to the content. If 454 both the BinarySigningTime and SigningTime attributes are present, 455 the time that is represented by the binary-signing-time attribute 456 MUST represent the same time value as the signing-time attribute. 457 The presence or absence of the Binary-SigningTime attribute in no way 458 affects the validation of the Manifest (as specified in Section 459 Section 7). 461 The binary-signing-time attribute is defined in [RFC4049] as: 463 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 464 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 465 smime(16) aa(2) 46 } 467 BinarySigningTime ::= BinaryTime 469 BinaryTime ::= INTEGER (0..MAX) 471 4.1.6.5. signatureAlgorithm 473 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which 474 is 1.2.840.113549.1.1.1. 476 4.1.6.6. signature 478 The signature value is defined as: 480 SignatureValue ::= OCTET STRING 482 The signature characteristics are defined by the digest and signature 483 algorithms. 485 4.1.6.7. unsignedAttrs 487 unsignedAttrs MUST be omitted. 489 4.2. ASN.1 491 The following is the ASN.1 specification of the CMS-signed Manifest. 493 ContentInfo ::= SEQUENCE { 494 contentType ContentType, 495 content [0] EXPLICIT ANY DEFINED BY contentType } 497 ContentType ::= OBJECT IDENTIFIER 499 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 500 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 502 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 504 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 506 Manifest ::= SEQUENCE { 507 version [0] INTEGER DEFAULT 0, 508 manifestNumber INTEGER, 509 thisUpdate GeneralizedTime, 510 nextUpdate GeneralizedTime, 511 fileHashAlg OBJECT IDENTIFIER, 512 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash} 514 FileAndHash ::= SEQUENCE { 515 file IA5String 516 hash BIT STRING} 518 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 519 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 521 SignedData ::= SEQUENCE { 522 version CMSVersion, 523 digestAlgorithms DigestAlgorithmIdentifiers, 524 encapContentInfo EncapsulatedContentInfo, 525 certificates [0] IMPLICIT CertificateSet OPTIONAL, 526 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 527 signerInfos SignerInfos } 529 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 531 SignerInfos ::= SET OF SignerInfo 533 SignerInfo ::= SEQUENCE { 534 version CMSVersion, 535 sid SignerIdentifier, 536 digestAlgorithm DigestAlgorithmIdentifier, 537 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 538 signatureAlgorithm SignatureAlgorithmIdentifier, 539 signature SignatureValue, 540 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 542 SignerIdentifier ::= CHOICE { 543 issuerAndSerialNumber IssuerAndSerialNumber, 544 subjectKeyIdentifier [0] SubjectKeyIdentifier } 546 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 548 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 550 Attribute ::= SEQUENCE { 551 attrType OBJECT IDENTIFIER, 552 attrValues SET OF AttributeValue } 554 AttributeValue ::= ANY 556 SignatureValue ::= OCTET STRING 558 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 559 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 561 ContentType ::= OBJECT IDENTIFIER 563 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 564 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 566 MessageDigest ::= OCTET STRING 567 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 568 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 570 SigningTime ::= Time 572 Time ::= CHOICE { 573 utcTime UTCTime, 574 generalizedTime GeneralizedTime } 576 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 577 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 578 smime(16) aa(2) 46 } 580 BinarySigningTime ::= BinaryTime 582 BinaryTime ::= INTEGER (0..MAX) 584 5. Manifest Generation 586 5.1. CA Manifest Generation 588 Each CA in the RPKI publishes the certificates and CRLs it issues at 589 a publication point in the RPKI repository system. To create a 590 manifest, each CA MUST perform the following steps: 592 1. If no key pair exists, or if using a "one-time-use" EE 593 certificate with a new key pair, then generate a key pair. 595 2. If using a "one-time-use" EE certificate, or if a key pair was 596 generated in step 1, issue a "single-use" EE certificate for this 597 key pair to enable relying parties to verify the signature on the 598 manifest. 600 * This EE certificate has an SIA extension access description 601 field with an accessMethod OID value of id-ad-signedobject 602 where the associated accessLocation references the publication 603 point of the manifest as an object URL. 605 * This EE certificate MUST describe its IP number resources 606 using the "inherit" attribute, rather than explicit 607 description of a resource set. 609 * In the case of a "one-time-use" EE certificate, the validity 610 times of the EE certificate SHOULD exactly match the 611 thisUpdate and nextUpdate times of the manifest, and MUST 612 encompass the interval from thisUpdate to nextUpdate. 614 * In the case of a "sequential-use" EE certificate the validity 615 times of the EE certificate MUST encompass the time interval 616 from thisUpdate to nextUpdate. 618 3. The EE certificate SHOULD NOT be published in the authority's 619 repository publication point. 621 4. Construct the manifest content. Note that the manifest does not 622 include a self reference (i.e., its own file name and hash), 623 since it would be impossible to compute the hash of the manifest 624 itself prior to it being signed. The manifest content is 625 described in Section 4.1.3.2.1. The manifest's fileList includes 626 the file names and hash pair for all objects associated with this 627 CA that have been published at the CA's repository publication 628 point. The collection of objects to be included in the manifest 629 includes all subordinate certificates issued by this CA that are 630 published at the CA's repository publication point, the most 631 recent CRL issued by the CA , and all objects verified by 632 "single-use" EE certificates that were issued by this CA that are 633 published at the CA's repository publication point. 635 5. Encapsulate the Manifest content using the CMS SignedData content 636 type (as specified in Section Section 4), sign the manifest using 637 the private key corresponding to the EE certificate, and publish 638 the manifest in repository system publication point that is 639 described by the manifest. 641 6. In the case of a key pair that is to be used only once, in 642 conjunction with a "one-time-use" EE certificate, the private key 643 associated with this key pair SHOULD now be destroyed. 645 5.2. End Entity Manifest Generation 647 EE repository publication points are only used in conjunction with 648 "multi-use" EE Certificates. In this case the EE Certificate has two 649 accessMethods specified in its SIA field. The id-ad- 650 signedObjectRepository accessMethod has an associated accessLocation 651 that points to the repository publication point of the objects signed 652 by this EE certificate, as specified in [ID.sidr-res-certs]. The id- 653 ad-rpkiManifest accessMethod has an associated access location that 654 points to the manifest object as an object URL, that is associated 655 with this repository publication point. This manifest describes all 656 the signed objects that are to be found in that publication point 657 that have been signed by this EE certificate, and the hash value of 658 each product (excluding the manifest itself). 660 To create a manifest, each "multi-use" EE MUST perform the following 661 steps:. 663 o Construct the Manifest content. Note that the manifest does not 664 include a self reference (i.e., its own file name and hash), since 665 it would be impossible to compute the hash of the manifest itself 666 prior to it being signed. The manifest content is described in 667 Section 4.1.3.2.1. The manifest's fileList includes the file 668 names and hash pair for all objects verified using that EE 669 certificate that have been published at the EE's repository 670 publication point. 672 o Encapsulate the Manifest content using the CMS SignedData content 673 type (as specified in Section Section 4), sign the manifest using 674 the EE certificate, and publish the manifest in repository system 675 publication point that is described by the manifest. 677 "Single Use" EE certificates (EE certificates with an SIA 678 accessMethod OID of id-as-signedObject) do not have repository 679 publication points. The object signed by the "Single Use" EE 680 certificate is published in the repository publication point of the 681 CA certificate that issued the EE certificate, and is listed in the 682 corresponding manifest for this CA certificate. 684 5.3. Common Considerations for Manifest Generation 686 o A new manifest MUST be issued on or before the nextUpdate time. 688 o An authority MUST issue a new manifest in conjunction with the 689 finalization of changes made to objects in the publication point. 690 An authority MAY perform a number of object operations on a 691 publication repository within the scope of a repository change 692 before issuing a single manifest that covers all the operations 693 within the scope of this change. Repository operators SHOULD 694 implement some form of synchronization function on the repository 695 to ensure that relying parties who are performing retrieval 696 operations on the repository are not exposed to intermediate 697 states during changes to the repository and the associated 698 manifest. 700 o Since the manifest object URL is included in the SIA of issued 701 certificates then a new manifest MUST NOT invalidate the manifest 702 object URL of previously issued certificates. This implies that 703 the manifest's publication name in the repository, in the form of 704 an object URL, is one that is unchanged across manifest generation 705 cycles. 707 o In the case of a CA publication point manifest, when the entity is 708 performing a key rollover the entity MAY chose to have multiple 709 CAs publishing at the same publication point. In this case there 710 will be one manifest associated with each active CA that is 711 publishing into the common repository publication point. 713 o In the case of an EE publication point the manifest lists all 714 published objects verified using that EE certificate. Multiple 715 EEs may share a common repository publication point, in which case 716 there will be one manifest associated with each active EE that is 717 publishing into the common repository publication point. 719 6. Processing Certificate Requests 721 When an EE certificate is intended for use in verifying multiple 722 objects, the certificate request for the EE certificate MUST include 723 in the SIA of the request an access method OID of id-ad- 724 signedObjectRepository where the associated access location refers to 725 the publication point for objects signed by this EE certificate, and 726 MUST include in the SIA of the request an access method OID of id-ad- 727 rpkiManifest, where the associated access location refers to the 728 publication point of the manifest that is associated with published 729 objects that are verified using this EE certificate 730 [ID.sidr-res-certs]. 732 When an EE certificate is used to sign a single object, the 733 certificate request for the EE certificate MUST include in the SIA of 734 the request an access method OID of id-ad-signedObject, where the 735 associated access location refers to the publication point of the 736 single object that is verified using this EE certificate. The 737 certificate request MUST NOT include in the SIA of the request the 738 access method OID of id-ad-rpkiManifest. 740 In accordance with the provisions of [ID.sidr-res-certs], all 741 certificate issuance requests for a CA certificate SHOULD include in 742 the SIA of the request the id-ad-caRepository access method, and also 743 the id-ad-rpkiManifest access method that references the intended 744 publication point of the manifest in the associated access location 745 in the request. 747 The issuer MUST either honor these values in the issued certificate 748 or reject the request entirely. 750 7. Manifest Validation 752 To determine whether a manifest is valid, the relying party must 753 perform the following checks: 755 1. Verify that the Manifest complies with this specification. In 756 particular, verify the following: 758 a. The contentType of the CMS object is SignedData (OID 759 1.2.840.113549.1.7.2) 761 b. The version of the SignedData object is 3. 763 c. The digestAlgorithm in the SignedData object is SHA-256 (OID 764 2.16.840.1.101.3.4.2.1). 766 d. The certificates field in the SignedData object is present 767 and contains an EE certificate whose Subject Key Identifier 768 (SKI) matches the sid field of the SignerInfo object. 770 e. The crls field in the SignedData object is omitted. 772 f. The eContentType in the EncapsulatedContentInfo is id-ad- 773 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 775 g. The version of the rpkiManifest is 0. 777 h. In the rpkiManifest, thisUpdate precedes nextUpdate. 779 i. The version of the SignerInfo is 3. 781 j. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 782 2.16.840.1.101.3.4.2.1). 784 k. The signatureAlgorithm in the SignerInfo object is RSA (OID 785 1.2.840.113549.1.1.1). 787 l. The signedAttrs field in the SignerInfo object is present and 788 contains both the ContentType attribute (OID 789 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 790 1.2.840.113549.1.9.4). 792 m. The unsignedAttrs field in the SignerInfo object is omitted. 794 2. Use the public key in the EE certificate to verify the signature 795 on the Manifest. 797 3. Verify that the EE certificate is a valid end-entity certificate 798 in the resource PKI by constructing a valid certificate path to a 799 trust anchor. (See [ID.sidr-res-certs] for more details.) 801 If the above procedure indicates that the manifest is invalid, then 802 the manifest MUST be discarded and treated as though no manifest were 803 present. 805 8. Relying Party Use of Manifests 807 The goal of the relying party is to determine which signed objects to 808 use for routing-related tasks, (e.g., which ROAs to use in the 809 construction of route filters). Ultimately, this is a matter of 810 local policy. However, in the following sections, we describe a 811 sequence of tests that the relying party SHOULD perform to determine 812 the manifest state of the given publication point. We then discuss 813 the risks associated with using signed objects in the publication 814 point, given the manifest state; and provide suitable warning text 815 that should placed in a user-accessible log file. It is the 816 responsibility of the relying party to weigh these risks against the 817 risk of routing failure that could occur if valid data is rejected, 818 and construct a suitable local policy. Note that if a certificate is 819 deemed unfit for use do to local policy, then any descendant object 820 that is validated using this certificate should also be deemed unfit 821 for use (regardless of the status of the manifest at its own 822 publication point). 824 8.1. Tests for Determining Manifest State 826 For a given publication point, the relying party should perform the 827 following tests to determine the manifest state of the publication 828 point: 830 1. For each entity using this publication point, select the entity's 831 manifest having highest manifestNumber among all valid manifests 832 (where manifest validity is defined in Section Section 7). 834 * If the publication point does not contain a valid manifest, 835 see Section Section 8.2. Lacking a valid manifest, the 836 following tests cannot be performed. 838 2. Check that the current time is between thisUpdate and nextUpdate. 840 * If the current time does not lie within this interval then see 841 Section 8.4, but still continue with the following tests. 843 3. Check that every file at the publication point appears in one and 844 only one manifest, and that every file listed in each manifest 845 appears at the publication point. 847 * If there exists files at the publication point that do not 848 appear on any manifest, or files listed in a manifest that do 849 not appear at the publication point then see Section 8.5 but 850 still continue with the following test. 852 4. Check that listed hash value of every file listed in each 853 manifest matches the value obtained by hashing the file at the 854 publication point. 856 * If there exist files at the publication point whose hash does 857 not match the hash value listed in the manifest, then see 858 Section 8.6. 860 For a particular signed object, if all of the following conditions 861 hold: 863 * the manifest for its publication, and the associated 864 publication point, pass all of the above checks; 865 * the signed object is valid; and 866 * the manifests for every certificate on the certificate path 867 used to validate the signed object, and the associated 868 publication points, pass all of the above checks; 869 then the relying party can conclude that no attack against the 870 repository system has compromised the given signed object, and the 871 signed object MUST be treated as valid. 873 8.2. Missing Manifests 875 The absence of a valid manifest at a publication point could occur 876 due to an error by the publisher or due to (malicious or accidental) 877 deletion or corruption of all valid manifests. 879 When no valid manifest is available, there is no protection against 880 attacks that delete signed objects or replay old versions of signed 881 objects. All signed objects at the publication point, and all 882 descendant objects that are validated using a certificate at this 883 publication point should be viewed as somewhat suspect, but may be 884 used by the relying party, as per local policy. 886 The primary risk in using signed objects at this publication point is 887 that a deleted CRL causes the relying party to improperly treat a 888 revoked certificate as valid (and thus rely upon signed objects that 889 are validated using that certificate). This risk is somewhat 890 mitigated if the CRL for this publication point has a short time 891 between thisUpdate and nextUpdate (and the current time is within 892 this interval). The risk in discarding signed objects at this 893 publication point is that the relying party may incorrectly discard a 894 large number of valid objects. This gives significant power to an 895 adversary that is able to delete all manifests at the publication 896 point. 898 Regardless of whether signed objects from this publication are deemed 899 fit for use by the relying party, this situation should result in a 900 warning to the effect that: "No manifest is available for , and thus there may have been undetected deletions or replay 902 substitutions from the publication point." 904 In the case where the relying party has access to a local cache of 905 previously issued manifests that are valid, the relying party MAY use 906 the most recently previously issued valid manifests for this RPKI 907 repository publication collection in this case for each entity that 908 publishes at his publication point. 910 8.3. Invalid Manifests 912 The presence of invalid manifests at a publication point could occur 913 due to an error by the publisher or due to (malicious or accidental) 914 corruption of a valid manifest. An invalid manifest MUST never be 915 used even if the manifestNumber is greater than that on valid 916 manifests. 918 There are no risks associated with using signed objects at a 919 publication point containing an invalid manifest, provided that valid 920 manifests the collectively cover all the signed objects are also 921 present. 923 If an invalid manifest is present at a publication point that also 924 contains one or more valid manifests, this situation should result in 925 a warning to the effect that: "An invalid manifest was found at , this indicates an attack against the publication point 927 or an error by the publisher. Processing for this publication point 928 will continue using the most recent valid manifest." 930 In the case where the relying party has access to a local cache of 931 previously issued manifests that are valid, the relying party MAY use 932 the locally cached most recently previously issued valid manifest 933 issued by the entity that issued the invalid manifest in this case. 935 8.4. Stale Manifests 937 A manifest is considered stale if the current time is after the 938 nextUpdate time for the manifest. This could be due to publisher 939 failure to promptly publish a new manifest, or due to (malicious or 940 accidental) corruption of a more recent manifest. 942 All signed objects at the publication point, and all descendant 943 objects that are validated using a certificate at this publication 944 point should be viewed as somewhat suspect, but may be used by the 945 relying party as per local policy. 947 The primary risk in using signed objects at this publication point is 948 that a newer manifest exists that, if present, would indicate that 949 certain objects are have been removed or replaced. (e.g., the new 950 manifest if present might show the existence of a newer CRL and the 951 removal of several revoked certificates). Thus use of objects on a 952 stale manifest may cause the relying party to incorrectly treat 953 several invalid objects as valid. The risk is that a stale CRL 954 causes the relying party to improperly treat a revoked certificate as 955 valid. This risk is somewhat mitigated if the time between the 956 nextUpdate field of the manifest and the current time is short. The 957 risk in discarding signed objects at this publication point is that 958 the relying party may incorrectly discard a large number of valid 959 objects. This gives significant power to an adversary that is able 960 to prevent the publication of a new manifest at a given publication 961 point. 963 Regardless of whether signed objects from this publication are deemed 964 fit for use by the relying party, this situation should result in a 965 warning to the effect that: "The manifest for is no 966 longer current. It is possible that undetected deletions have 967 occurred at this publication point." 969 Note that there is also a less common case where the current time is 970 before the thisUpdate time for the manifest. This case could be due 971 to publisher error, or a local clock error, and in such a case this 972 situation should result in a warning to the effect that: "The 973 manifest found at has an incorrect thisUpdate field. 974 This could be due to publisher error, or a local clock error, and 975 processing for this publication point will continue using this 976 otherwise valid manifest." 978 8.5. Mismatch between Manifest and Publication Point 980 If there exist otherwise valid signed objects that do not appear in 981 any manifest, then provided the manifest is not stale (see Section 982 Section 8.4) it is likely that their omission is an error by the 983 publisher. It is also possible that this state could be the result 984 of a (malicious or accidental) replacement of a current manifest with 985 an older, but still valid manifest. However, regarding the 986 appropriate interpretation such objects, it remains the case that if 987 the objects were intended to be invalid, then they should have been 988 revoked using whatever revocation mechanism is appropriate for the 989 signed object in question.) Therefore, there is little risk in using 990 such signed objects. If the manifest in question is stale, then 991 there is a greater risk that the objects in question were revoked 992 with a missing CRL, whose absence is undetectable since the manifest 993 is stale. In any case, the use of signed objects not present on a 994 manifest, or descendant objects that are validated using such signed 995 objects, is a matter of local policy. 997 Regardless of whether objects not appearing on a manifest are deemed 998 fit for use by the relying party, this situation should result in a 999 warning to the effect that: "The following files are present in the 1000 repository at , but are not on the manifest ." 1003 If there exist files listed on the manifest that do not appear in the 1004 repository, then these objects are likely to have been improperly 1005 (via malice or accident) deleted from the manifest. A primary 1006 purpose of manifests is to detect such deletions. Therefore, in such 1007 a case this situation should result in a warning to the effect that: 1008 "The following files that should have been present in the repository 1009 at , are missing . This indicates an 1010 attack against this publication point, or the repository, or an error 1011 by the publisher." 1013 8.6. Hash Values Not Matching Manifests 1015 A file appearing on a manifest with an incorrect hash value could 1016 occur because of publisher error, but it is likely to indicate that a 1017 serious error has occurred. 1019 If an object appeared on a previous valid manifest with a correct 1020 hash value and now appears with an invalid hash value, then it is 1021 likely that the object has been superseded by a new (unavailable) 1022 version of the object. If the object is used there is a risk that 1023 the relying party will be treating a stale object as valid. This 1024 risk is more significant if the object in question is a CRL. 1025 Assuming that the object is validated in the RPKI, the use of these 1026 objects is a matter of local policy. 1028 If an object appears on a manifest with an invalid hash and has never 1029 previously appeared on a manifest, then it is unclear whether the 1030 available version of the object is more or less recent than the 1031 version whose hash appears in the manifest. If the manifest is stale 1032 (see Section 8.4) then it becomes more likely that the available 1033 version is more recent that the version indicated on the manifest, 1034 but this is never certain. Whether to use such objects is a matter 1035 of local policy. However, in general, it is better to use a possibly 1036 outdated version of the object than to discard the object completely. 1038 While it is a matter of local policy, in the case of CRLs a relying 1039 party should endeavor to use the most recently issued valid CRL even 1040 where the hash value in the manifest matches an older CRL, or does 1041 not match any CRL hand. The thisUpdate field of the CRL can be used 1042 to establish the most recent CRL in the case where a relying party 1043 has more than one valid CRL at hand. 1045 Regardless of whether objects with incorrect hashes are deemed fit 1046 for use by the relying party, this situation should result in a 1047 warning to the effect that: "The following files at the repository 1048 appear on a manifest with incorrect hash values 1049 . It is possible that these objects have been superseded 1050 by a more recent version. It is very likely that this problem is due 1051 to an attack on the publication point, although it could also be due 1052 to a publisher error." 1054 9. Publication Repositories 1056 The RPKI publication system model requires that every publication 1057 point be associated with one or more CAs or one or more EEs, and be 1058 non-empty. Upon creation of the publication point associated with a 1059 CA, the CA MUST create and publish a manifest as well as a CRL. The 1060 manifest will contain at least one entry, the CRL issued by the CA 1061 upon repository creation. Upon the creation of the publication point 1062 associated with an EE, the EE MUST create and publish a manifest. 1063 The manifest in an otherwise empty repository publication point 1064 associated with an EE will contain no entries in the manifest's 1065 fileList sequence (i.e., the ASN.1 SEQUENCE will have a length of 1066 zero). [ID.sidr-repos-struct] 1068 For each signed object, the EE certificate used to verify the object 1069 is either a single-use certificate, used to verify a single signed 1070 object, or a multiple-use certificate. In the case of a single-use 1071 EE certificate, the signed object is published in the repository 1072 publication point of the CA that issued the single use EE 1073 certificate, and is listed in the manifest associated with that CA 1074 certificate. In the case where an EE certificate is used to verify 1075 multiple objects, each signed object is published in the EE 1076 certificate's repository publication point and listed in the manifest 1077 associated with the EE certificate. 1079 10. Security Considerations 1081 Manifests provide an additional level of protection for relying 1082 parties of the repository system. Manifests can assist a relying 1083 party to determine if repository objects have been occluded or other 1084 removed from view, and to determine if an older version of an object 1085 has been substituted for the current object . 1087 Manifests cannot repair the effects of such forms of attempted 1088 corruption of repository retrieval operations, but are capable of 1089 allowing a relying party to determine if a locally maintained copy of 1090 a repository is a complete and up to date copy, even when the 1091 repository retrieval operation is conduction over an insecure 1092 channel. In those cases where the manifest and the retrieved 1093 repository contents differ, the manifest can assist in determining 1094 which repository objects form the difference set in terms of missing, 1095 extraneous or older objects . 1097 The signing structure of a manifest and the use of the nextUpdate 1098 value allows the relying party to determine if the manifest itself is 1099 the subject of attempted alteration. The requirement for every 1100 repository publication point to contain at least one manifest allows 1101 a relying party to determine is the manifest itself has been occluded 1102 from view. Such attacks against the manifest are detectable within 1103 the time frame of the regular schedule of manifest updates. Forms of 1104 replay attack within finer-grained time frames are not necessarily 1105 detectable by the manifest structure . 1107 11. IANA Considerations 1109 [Note to IANA, to be removed prior to publication: there are no IANA 1110 considerations stated in this version of the document.] 1112 12. Acknowledgements 1114 The authors would like to acknowledge the contributions from George 1115 Michelson and Randy Bush in the preparation of the manifest 1116 specification. Additionally, the authors would like to thank Mark 1117 Reynolds and Christopher Small for assistance in clarifying manifest 1118 validation and relying party behavior. 1120 13. Normative References 1122 [ID.sidr-arch] 1123 Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure 1124 to Support Secure Internet Routing", Work in progress: 1125 Internet Drafts draft-ietf-sidr-arch-03.txt, 1126 February 2008. 1128 [ID.sidr-repos-struct] 1129 Huston, G., Loomans, R., and G. Michaleson, "A Profile for 1130 Resource Certificate Repository Structure", Work in 1131 progress: Internet 1132 Drafts draft-huston-sidr-repos-struct-02.txt, June 2008. 1134 [ID.sidr-res-certs] 1135 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 1136 X.509 PKIX Resource Certificates", Work in progress: 1137 Internet Drafts draft-ietf-sidr-res-certs-10.txt, 1138 June 2008. 1140 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1141 Addresses and AS Identifiers", RFC 3779, June 2004. 1143 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1144 RFC 3852, July 2004. 1146 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 1147 Representing Date and Time in ASN.1", RFC 4049, 1148 April 2005. 1150 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1151 Algorithms and Identifiers for RSA Cryptography for use in 1152 the Internet X.509 Public Key Infrastructure Certificate 1153 and Certificate Revocation List (CRL) Profile", RFC 4055, 1154 June 2005. 1156 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1157 Housley, R., and W. Polk, "Internet X.509 Public Key 1158 Infrastructure Certificate and Certificate Revocation List 1159 (CRL) Profile", RFC 5280, May 2008. 1161 Authors' Addresses 1163 Rob Austein 1164 Internet Systems Consortium 1165 950 Charter St. 1166 Redwood City, CA 94063 1167 USA 1169 Email: sra@isc.org 1170 Geoff Huston 1171 Asia Pacific Network Information Centre 1172 33 Park Rd. 1173 Milton, QLD 4064 1174 Australia 1176 Email: gih@apnic.net 1177 URI: http://www.apnic.net 1179 Stephen Kent 1180 BBN Technologies 1181 10 Moulton St. 1182 Cambridge, MA 02138 1183 USA 1185 Email: kent@bbn.com 1187 Matt Lepinski 1188 BBN Technologies 1189 10 Moulton St. 1190 Cambridge, MA 02138 1191 USA 1193 Email: mlepinski@bbn.com 1195 Full Copyright Statement 1197 Copyright (C) The IETF Trust (2008). 1199 This document is subject to the rights, licenses and restrictions 1200 contained in BCP 78, and except as set forth therein, the authors 1201 retain all their rights. 1203 This document and the information contained herein are provided on an 1204 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1205 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1206 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1207 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1208 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1209 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1211 Intellectual Property 1213 The IETF takes no position regarding the validity or scope of any 1214 Intellectual Property Rights or other rights that might be claimed to 1215 pertain to the implementation or use of the technology described in 1216 this document or the extent to which any license under such rights 1217 might or might not be available; nor does it represent that it has 1218 made any independent effort to identify any such rights. Information 1219 on the procedures with respect to rights in RFC documents can be 1220 found in BCP 78 and BCP 79. 1222 Copies of IPR disclosures made to the IETF Secretariat and any 1223 assurances of licenses to be made available, or the result of an 1224 attempt made to obtain a general license or permission for the use of 1225 such proprietary rights by implementers or users of this 1226 specification can be obtained from the IETF on-line IPR repository at 1227 http://www.ietf.org/ipr. 1229 The IETF invites any interested party to bring to its attention any 1230 copyrights, patents or patent applications, or other proprietary 1231 rights that may cover technology that may be required to implement 1232 this standard. Please address the information to the IETF at 1233 ietf-ipr@ietf.org.