idnits 2.17.1 draft-ietf-sidr-rpki-manifests-03.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 1170. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1188. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1194. 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 (September 24, 2008) is 5694 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 537 -- Looks like a reference, but probably isn't: '1' on line 533 == Missing Reference: 'ID.RESCERT' is mentioned on line 779, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'ID.SIDR-ARCH') == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-10 ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing R. Austein 3 Internet-Draft ISC 4 Intended status: Standards Track G. Huston 5 Expires: March 28, 2009 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 September 24, 2008 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-03.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 March 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . 15 74 7. Manifest Validation . . . . . . . . . . . . . . . . . . . . . 16 75 8. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 17 76 8.1. Tests for Determining Manifest State . . . . . . . . . . . 18 77 8.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 19 78 8.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 19 79 8.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 20 80 8.5. Mismatch between Manifest and Publication Point . . . . . 21 81 8.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 21 82 9. Publication Repositories . . . . . . . . . . . . . . . . . . . 22 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 86 13. Normative References . . . . . . . . . . . . . . . . . . . . . 24 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 88 Intellectual Property and Copyright Statements . . . . . . . . . . 26 90 1. Introduction 92 The Resource Public Key Infrastructure (RPKI) [ID.SIDR-ARCH] makes 93 use of a distributed repository system [ID.SIDR-REPOSITORY] 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 but have since been superceded) or attacks 101 that remove an object that should be present in the repository. To 102 assist in the detection of such attacks, the RPKI repository system 103 will make use of a new signed object called a "manifest." 105 A manifest is an object that lists of all of the other signed objects 106 issued by the authority responsible for a publication point in the 107 repository system. For each certificate, Certificate Revocation List 108 (CRL), or other signed object, such as a Route Origination Authority 109 (ROA), issued by the authority, the manifest contains both the name 110 of the file containing the object, and a hash of the file content. 111 Manifests allow a RP to obtain sufficient information to detect 112 whether the retrieval of objects from an RPKI repository has been 113 compromised by unauthorized object removal, or by the substitution of 114 "stale" versions of objects. Manifests are designed to be used both 115 for Certification Authority (CA) publication points in repositories, 116 that contain subordinate certificates, CRLs and other signed objects, 117 and End Entity (EE) publication points in repositories that contain 118 signed objects. 120 Manifests are modelled on CRLs, as the issues involved in detecting 121 stale manifests, and detection of potential attacks using manifest 122 replays, etc are similar to those for CRLs. The syntax of the 123 manifest payload differs from CRLs, since RPKI repositories can 124 contain objects not covered by CRLs, such as digitally signed 125 objects, such as ROAs. 127 1.1. Terminology 129 It is assumed that the reader is familiar with the terms and concepts 130 described in "Internet X.509 Public Key Infrastructure Certificate 131 and Certificate Revocation List (CRL) Profile" [RFC5280]and "X.509 132 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119. 138 2. Manifest Scope 140 In the case of a CA's manifest of its associated publication 141 repository, the manifest contains the current published certificates 142 issued by this CA, the most recent CRL issued by this CA, and all 143 objects that are signed using a "single-use" EE certificate ((i.e., 144 the SIA extension of the EE certificate has an accessMethod OID of 145 id-ad-signedObject), where the EE certificate was issued by this CA. 147 In the case where multiple CAs share a common publication point, as 148 may be the case when an entity performs a staged key-rollover 149 operation, the respository publication will contain multiple 150 manifests. Each manifest describes only the collection of products 151 of its associated CA. 153 In the case of a "multi-use" EE certificate, where an EE has a 154 defined publication repository (i.e., the SIA extension of the EE 155 certificate has an accessMethod OID of id-ad-signedObjectRepository), 156 the EE's manifest contains all published objects that have been 157 signed by the EE's key pair, and the accessMethod id-as-rpkiManifest 158 points to the publication point of the EE's manifest. 160 3. Manifest Signing 162 A CA's manifest is signed using an EE certificate that is designated 163 in [ID.SIDR-CERTPROFILE] as a "single-use" EE certificate. The SIA 164 field of the "single-use" EE certificate contains the access method 165 OID of id-ad-signedObject. 167 The CA MAY chose to sign only one manifest with the EE certificate, 168 and generate a new EE certificate for each new version of the 169 manifest. This form of use of a "single-use" EE certificate is 170 termed a "one-time-use" EE certificate. 172 Alternatively the CA MAY chose to use the same EE certificate to sign 173 a sequence of manifests. Because only a single manifest is current 174 at any point in time, the EE certificate is only ever used to sign a 175 single object at a time. As long as the sequence of objects signed 176 by this EE certificate are published as the same named object, so 177 that the SIA accessMethod id-ad-signedObject value can refer to the 178 current instance of the sequence of such objects, then this 179 sequential multiple use of this "single-use" EE certificate is also 180 valid. This form of use of a "single-use" EE certificate is termed a 181 "sequential-use" EE certificate. 183 A "multi-use" EE's manifest of it's publication repository MUST be 184 signed by the EE certificate itself. 186 4. Manifest Syntax 188 A manifest is a Cryptographic Message Syntax (CMS) [RFC3852] signed- 189 data object. The general format of a CMS object is: 191 ContentInfo ::= SEQUENCE { 192 contentType ContentType, 193 content [0] EXPLICIT ANY DEFINED BY contentType } 195 ContentType ::= OBJECT IDENTIFIER 197 A Manifest is a signed-data object. The ContentType used is the 198 signed-data type of id-data, namely the id-signedData OID, 199 1.2.840.113549.1.7.2. [RFC3852] 201 4.1. Signed-Data Content Type 203 According to the CMS specification, signed-data content types shall 204 have the ASN.1 type SignedData: 206 SignedData ::= SEQUENCE { 207 version CMSVersion, 208 digestAlgorithms DigestAlgorithmIdentifiers, 209 encapContentInfo EncapsulatedContentInfo, 210 certificates [0] IMPLICIT CertificateSet OPTIONAL, 211 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 212 signerInfos SignerInfos } 214 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 216 SignerInfos ::= SET OF SignerInfo 218 4.1.1. version 220 The version is the syntax version number. It MUST be 3, 221 corresponding to the signerInfo structure having version number 3. 223 4.1.2. digestAlgorithms 225 The digestAlgorithms set MUST include only SHA-256, the OID for which 226 is 2.16.840.1.101.3.4.2.1 [RFC4055]. It MUST NOT contain any other 227 algorithms. 229 4.1.3. encapContentInfo 231 encapContentInfo is the signed content, consisting of a content type 232 identifier and the content itself. 234 EncapsulatedContentInfo ::= SEQUENCE { 235 eContentType ContentType, 236 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 238 ContentType ::= OBJECT IDENTIFIER 240 4.1.3.1. eContentType 242 The eContentType for a Manifest is defined as id-ct-rpkiManifest, and 243 has the numerical value of 1.2.840.113549.1.9.16.1.26. 245 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 246 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 248 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 250 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 252 4.1.3.2. eContent 254 The content of a Manifest is defined as follows: 256 Manifest ::= SEQUENCE { 257 version [0] INTEGER DEFAULT 0, 258 manifestNumber INTEGER, 259 thisUpdate GeneralizedTime, 260 nextUpdate GeneralizedTime, 261 fileHashAlg OBJECT IDENTIFIER, 262 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash 263 } 265 FileAndHash ::= SEQUENCE { 266 file IA5String 267 hash BIT STRING 268 } 270 4.1.3.2.1. Manifest 272 The manifestNumber, thisUpdate, and nextUpdate fields are modelled 273 after the corresponding fields in X.509 CRLs (see [RFC5280]). 274 Analogous to CRLS, a manifest is nominally valid until the time 275 specified in nextUpdate or until a manifest is issued with a greater 276 manifest number, whichever comes first. The revoked EE certificate 277 for the previous manifest's signature will be removed from the CRL 278 when it expires. 280 In the case of "one-time-use" EE certificates being used to sign a 281 manifest, it is RECOMMENDED that the EE certificate have an validity 282 period that coincides with the interval from thisUpdate to 283 nextUpdate, to prevent needless growth of the CA's CRL. 285 In the case of "sequential-use EE certificates to sign a manifest the 286 EE certificate's validity period should reflect the CA's key 287 management policies. 289 4.1.3.2.1.1. version 291 The version number of the rpkiManifest MUST be 0. 293 4.1.3.2.1.2. manifestNumber 295 The manifestNumber field is a sequence number that is incremented 296 each time a new manifest is issued for a given publication point. 297 This field is used to allow a RP to detect gaps in a sequence of 298 published manifest. 300 4.1.3.2.1.3. thisUpdate 302 The thisUpdate field contains the time when the manifest was created. 304 4.1.3.2.1.4. nextUpdate 306 The nextUpdate field contains the time at which the next scheduled 307 manifest will be issued. The value of nextUpdate MUST be later than 308 the value of thisUpdate. If the authority alters any of the items in 309 the repository publication point, then the authority MUST issue a new 310 manifest before the nextUpdate time. In such a case, when the 311 authority issues the new manifest, and when "one-time-use" EE 312 certificates are being used to sign the manifest, the CA MUST also 313 issue a new CRL that includes the EE certificate corresponding to the 314 old manifest. 316 4.1.3.2.1.5. fileHashAlg 318 The fileHashAlg field contains the OID of the hash algorithm used to 319 hash the files that the authority has placed into the repository. 320 The mandatory to implement hash algorithm is SHA-256 and its OID is 321 2.16.840.1.101.3.4.2.1. [RFC4055]. 323 4.1.3.2.1.6. fileList 325 The fileList field contains a sequence of FileAndHash pairs, one for 326 each currently valid signed object that has been issued by the 327 authority. Each FileAndHash pair contains the name of the file in 328 the repository that contains the object in question, and a hash of 329 the file's contents. 331 4.1.4. certificates 333 The certificates field MUST be included, and MUST contain the RPKI EE 334 certificate needed to validate this manifest in the context of the 335 RPKI. 337 4.1.5. crls 339 This field MUST be omitted. 341 4.1.6. signerInfos 343 Signer Infos is defined as a SignerInfo, which is defined under CMS 344 as: 346 SignerInfo ::= SEQUENCE { 347 version CMSVersion, 348 sid SignerIdentifier, 349 digestAlgorithm DigestAlgorithmIdentifier, 350 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 351 signatureAlgorithm SignatureAlgorithmIdentifier, 352 signature SignatureValue, 353 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 355 4.1.6.1. version 357 The version number MUST be 3, corresponding with the choice of 358 SubjectKeyIdentifier for the sid. 360 4.1.6.2. sid 362 The sid is defined as: 364 SignerIdentifier ::= CHOICE { 365 issuerAndSerialNumber IssuerAndSerialNumber, 366 subjectKeyIdentifier [0] SubjectKeyIdentifier } 368 For a Manifest, the sid MUST be a SubjectKeyIdentifier. 370 4.1.6.3. digestAlgorithm 372 The digestAlgorithm MUST be SHA-256, the OID for which is 373 2.16.840.1.101.3.4.2.1. [RFC4055] 375 4.1.6.4. signedAttrs 377 The signedAttrs is defined as signedAttributes: 379 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 381 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 383 Attribute ::= SEQUENCE { 384 attrType OBJECT IDENTIFIER, 385 attrValues SET OF AttributeValue } 387 AttributeValue ::= ANY 389 The signedAttr element MUST be present and MUST include the content- 390 type and message-digest attributes. The signer MAY also include the 391 signing-time signed attribute, the binary-signing-time signed 392 attribute, or both signing-time attributes. Other signed attributes 393 that are deemed appropriate MAY also be included. The intent is to 394 allow additional signed attributes to be included if a future need is 395 identified. This does not cause an interoperability concern because 396 unrecognized signed attributes are ignored by the relying party. 398 The signedAttr MUST include only a single instance of any particular 399 attribute. Additionally, even though the syntax allows for a SET OF 400 AttributeValue, in a Manifest the attrValues MUST consist of only a 401 single AttributeValue. 403 4.1.6.4.1. Content-Type Attribute 405 The ContentType attribute MUST be present. The attrType OID for the 406 ContentType attribute is 1.2.840.113549.1.9.3. 408 The attrValues for the ContentType attribute in a Manifest MUST be 409 1.2.840.113549.1.9.16.1.26, matching the eContentType in the 410 EncapsulatedContentInfo. 412 4.1.6.4.2. Message-Digest Attribute 414 The MessageDigest Attribute MUST be present. The attrType OID for 415 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 417 The attrValues for the MessageDigest attribute contains the output of 418 the digest algorithm applied to the content being signed, as 419 specified in Section 11.1 of [RFC3852]. 421 4.1.6.4.3. SigningTime Attribute 423 The SigningTime attribute MAY be present. The presence of absence of 424 the SigningTime attribute in no way affects the validation of the 425 Manifest (as specified in Section Section 7). 427 The attrType OID for the SigningTime attribute is 428 1.2.840.113549.1.9.5. 430 The attrValues for the SigningTime attribute is defined as: 432 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 433 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 435 SigningTime ::= Time 437 Time ::= CHOICE { 438 utcTime UTCTime, 439 generalizedTime GeneralizedTime } 441 The Time element specifies the time, based on the local system clock, 442 at which the digital signature was applied to the content. 444 4.1.6.4.4. BinarySigningTime Attribute 446 The signer MAY include a BinarySigningTime attribute, specifying the 447 time at which the digital signature was applied to the content. If 448 both the BinarySigningTime and SigningTime attributes are present, 449 the time that is represented by the binary-signing-time attribute 450 MUST represent the same time value as the signing-time attribute. 451 The presence or absence of the Binary-SigningTime attribute in no way 452 affects the validation of the Manifest (as specified in Section 453 Section 7). 455 The binary-signing-time attribute is defined in [RFC4049] as: 457 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 458 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 459 smime(16) aa(2) 46 } 461 BinarySigningTime ::= BinaryTime 463 BinaryTime ::= INTEGER (0..MAX) 465 4.1.6.5. signatureAlgorithm 467 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which 468 is 1.2.840.113549.1.1.1. 470 4.1.6.6. signature 472 The signature value is defined as: 474 SignatureValue ::= OCTET STRING 476 The signature characteristics are defined by the digest and signature 477 algorithms. 479 4.1.6.7. unsignedAttrs 481 unsignedAttrs MUST be omitted. 483 4.2. ASN.1 485 The following is the ASN.1 specification of the CMS-signed Manifest. 487 ContentInfo ::= SEQUENCE { 488 contentType ContentType, 489 content [0] EXPLICIT ANY DEFINED BY contentType } 491 ContentType ::= OBJECT IDENTIFIER 493 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 494 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 496 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 498 id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 500 Manifest ::= SEQUENCE { 501 version [0] INTEGER DEFAULT 0, 502 manifestNumber INTEGER, 503 thisUpdate GeneralizedTime, 504 nextUpdate GeneralizedTime, 505 fileHashAlg OBJECT IDENTIFIER, 506 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash} 508 FileAndHash ::= SEQUENCE { 509 file IA5String 510 hash BIT STRING} 512 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 513 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 515 SignedData ::= SEQUENCE { 516 version CMSVersion, 517 digestAlgorithms DigestAlgorithmIdentifiers, 518 encapContentInfo EncapsulatedContentInfo, 519 certificates [0] IMPLICIT CertificateSet OPTIONAL, 520 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 521 signerInfos SignerInfos } 523 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 524 SignerInfos ::= SET OF SignerInfo 526 SignerInfo ::= SEQUENCE { 527 version CMSVersion, 528 sid SignerIdentifier, 529 digestAlgorithm DigestAlgorithmIdentifier, 530 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 531 signatureAlgorithm SignatureAlgorithmIdentifier, 532 signature SignatureValue, 533 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 535 SignerIdentifier ::= CHOICE { 536 issuerAndSerialNumber IssuerAndSerialNumber, 537 subjectKeyIdentifier [0] SubjectKeyIdentifier } 539 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 541 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 543 Attribute ::= SEQUENCE { 544 attrType OBJECT IDENTIFIER, 545 attrValues SET OF AttributeValue } 547 AttributeValue ::= ANY 549 SignatureValue ::= OCTET STRING 551 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 552 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 554 ContentType ::= OBJECT IDENTIFIER 556 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 557 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 559 MessageDigest ::= OCTET STRING 561 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 562 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 564 SigningTime ::= Time 566 Time ::= CHOICE { 567 utcTime UTCTime, 568 generalizedTime GeneralizedTime } 570 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 571 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 572 smime(16) aa(2) 46 } 574 BinarySigningTime ::= BinaryTime 576 BinaryTime ::= INTEGER (0..MAX) 578 5. Manifest Generation 580 5.1. CA Manifest Generation 582 Each CA in the RPKI publishes the certificates and CRLs it issues at 583 a publication point in the RPKI repository system. To create a 584 manifest, each CA MUST perform the following steps: 586 1. If no key pair exists, or if using a "one-time-use" EE 587 certificate with a new key pair, then generate a key pair. 589 2. If using a "one-time-use" EE certificate, or if a key pair was 590 generated in step 1, issue a "single-use" EE certificate for this 591 key pair to enable relying parties to verify the signature on the 592 manifest. 594 * This EE certificate has an SIA extension access description 595 field with an accessMethod OID value of id-ad-signedobject 596 where the associated accessLocation references the publication 597 point of the manifest as an object URL. 599 * This EE certificate MUST describe its IP number resources 600 using the "inherit" attribute, rather than explicit 601 description of a resource set. 603 * In the case of a "one-time-use" EE certificate, the validity 604 times of the EE certificate SHOULD exactly match the 605 thisUpdate and nextUpdate times of the manifest, and MUST 606 encompass the interval from thisUpdate to nextUpdate. 608 * In the case of a "sequential-use" EE certificate the validity 609 times of the EE certificate MUST encompass the time interval 610 from thisUpdate to nextUpdate. 612 3. The EE certificate SHOULD NOT be published in the authority's 613 repository publication point. 615 4. Construct the manifest content. Note that the manifest does not 616 include a self reference (i.e., its own file name and hash), 617 since it would be impossible to compute the hash of the manifest 618 itself prior to it being signed. 620 5. Encapsulate the Manifest content using the CMS SignedData content 621 type (as specified in Section Section 4), sign the manifest using 622 the EE certificate, and publish the manifest in repository system 623 publication point that is described by the manifest. 625 6. In the case of a key pair that is to be used only once, in 626 conjunction with a "one-time-use" EE certificate, the private key 627 associated with this key pair SHOULD now be destroyed. 629 5.2. End Entity Manifest Generation 631 EE repository publication points are only used in conjunction with 632 "multi-use" EE Certificates. In this case the EE Certificate has two 633 accessMethods specified in its SIA field. The id-ad- 634 signedObjectRepository accessMethod has an associated accessLocation 635 that points to the repository publication point of the objects signed 636 by this EE certificate, as specified in [ID.SIDR-CERTPROFILE]. The 637 id-ad-rpkiManifest accessMethod has an associated access location 638 that points to the manifest object as an object URL, that is 639 associated with this repository publication point. This manifest 640 describes all the signed objects that are to be found in that 641 publication point that have been signed by this EE certificate, and 642 the hash value of each product (excluding the manifest itself). 644 To create a manifest, each "multi-use" EE MUST perform the following 645 steps:. 647 o Construct the Manifest content. Note that the manifest does not 648 include a self reference (i.e., its own file name and hash), since 649 it would be impossible to compute the hash of the manifest itself 650 prior to it being signed. 652 o Encapsulate the Manifest content using the CMS SignedData content 653 type (as specified in Section Section 4), sign the manifest using 654 the EE certificate, and publish the manifest in repository system 655 publication point that is described by the manifest. 657 "Single Use" EE certificates (EE certificates with an SIA 658 accessMethod OID of id-as-signedObject) do not have repository 659 publication points. The object signed by the "Single Use" EE 660 certificate is published in the repository publication point of the 661 CA certificate that issued the EE certificate, and is listed in the 662 corresponding manifest for this CA certificate. 664 5.3. Common Considerations for Manifest Generation 666 o A new manifest MUST be issued on or before the nextUpdate time. 668 o An authority MUST issue a new manifest in conjunction with the 669 finalization of changes made to objects in the publication point. 670 An authority MAY perform a number of object operations on a 671 publication repository within the scope of a repository change 672 before issuing a single manifest that covers all the operations 673 within the scope of this change. Repository operators SHOULD 674 implement some form of synchronization function on the repository 675 to ensure that relying parties who are performing retrieval 676 operations on the repository are not exposed to intermediate 677 states during changes to the repository and the associated 678 manifest. 680 o Since the manifest object URL is included in the SIA of issued 681 certificates then a new manifest MUST NOT invalidate the manifest 682 object URL of previously issued certificates. This implies that 683 the manifest's publication name in the repository, in the form of 684 an object URL, is one that is unchanged across manifest generation 685 cycles. 687 o In the case of a CA publication point manifest, when the entity is 688 performing a key rollover the entity MAY chose to have multiple 689 CAs publishing at the same publication point. In this case there 690 will be one manifest associated with each active CA that is 691 publishing into the common repository publication point. 693 o In the case of an EE publication point the manifest is associated 694 all published objects signed by that EE certificate. Multiple EEs 695 may share a common repository publication point, in which case 696 there will be one manifest associated with each active EE that is 697 publishing into the common repository publication point. 699 6. Processing Certificate Requests 701 When an EE certificate is intended for use in verifying multiple 702 objects, the certificate request for the EE certificate MUST include 703 in the SIA of the request an access method OID of id-ad- 704 signedObjectRepository where the associated access location refers to 705 the publication point for objects signed by this EE certificate, and 706 MUST include in the SIA of the request an access method OID of id-ad- 707 rpkiManifest, where the associated access location refers to the 708 publication point of the manifest that is associated with published 709 objects that are verified using this EE certificate 710 [ID.SIDR-CERTPROFILE]. 712 When an EE certificate is used to sign a single object, the 713 certificate request for the EE certificate MUST include in the SIA of 714 the request an access method OID of id-ad-signedObject, where the 715 associated access location refers to the publication point of the 716 single object that is verified using this EE certificate. The 717 certificate request MUST NOT include in the SIA of the request the 718 access method OID of id-ad-rpkiManifest. 720 In accordance with the provisions of [ID.SIDR-CERTPROFILE], all 721 certificate issuance requests for a CA certificate SHOULD include in 722 the SIA of the request the id-ad-caRepository access method, and also 723 the id-ad-rpkiManifest access method that references the intended 724 publication point of the manifest in the associated access location 725 in the request. 727 The issuer MUST either honor these values in the issued certificate 728 or reject the request entirely. 730 7. Manifest Validation 732 To determine whether a manifest is valid, the relying party must 733 perform the following checks: 735 1. Verify that the Manifest complies with this specification. In 736 particular, verify the following: 738 a. The contentType of the CMS object is SignedData (OID 739 1.2.840.113549.1.7.2) 741 b. The version of the SignedData object is 3. 743 c. The digestAlgorithm in the SignedData object is SHA-256 (OID 744 2.16.840.1.101.3.4.2.1). 746 d. The certificates field in the SignedData object is present 747 and contains an EE certificate whose Subject Key Identifier 748 (SKI) matches the sid field of the SignerInfo object. 750 e. The crls field in the SignedData object is omitted. 752 f. The eContentType in the EncapsulatedContentInfo is id-ad- 753 rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). 755 g. The version of the rpkiManifest is 0. 757 h. In the rpkiManifest, thisUpdate precedes nextUpdate. 759 i. The version of the SignerInfo is 3. 761 j. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 762 2.16.840.1.101.3.4.2.1). 764 k. The signatureAlgorithm in the SignerInfo object is RSA (OID 765 1.2.840.113549.1.1.1). 767 l. The signedAttrs field in the SignerInfo object is present and 768 contains both the ContentType attribute (OID 769 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 770 1.2.840.113549.1.9.4). 772 m. The unsignedAttrs field in the SignerInfo object is omitted. 774 2. Use the public key in the EE certificate to verify the signature 775 on the Manifest. 777 3. Verify that the EE certificate is a valid end-entity certificate 778 in the resource PKI by constructing a valid certificate path to a 779 trust anchor. (See [ID.RESCERT] for more details.) 781 If the above procedure indicates that the manifest is invalid, then 782 the manifest MUST be discarded and treated as though no manifest were 783 present. 785 8. Relying Party Use of Manifests 787 The goal of the relying party is to determine which signed objects to 788 use for routing-related tasks, (e.g. which ROAs to use in the 789 construction of route filters). Ultimately, this is a matter of 790 local policy. However, in the following sections, we describe a 791 sequence of tests that the relying party should perform to determine 792 the manifest state of the given publication point. We then discuss 793 the risks associated with using signed objects in the publication 794 point, given the manifest state; and provide suitable warning text 795 that should placed in a user-accessible log file. It is the 796 responsibility of the relying party to weigh these risks against the 797 risk of routing failure that could occur if valid data is rejected, 798 and construct a suitable local policy. Note that if a certificate is 799 deemed unfit for use do to local policy, then any descendent object 800 that is validated using this certificate should also be deemed unfit 801 for use (regardless of the status of the manifest at its own 802 publication point). 804 8.1. Tests for Determining Manifest State 806 For a given publication point, the relying party should perform the 807 following tests to determine the manifest state of the publication 808 point: 810 1. Select the manifest having highest manifestNumber among all valid 811 manifests (where manifest validity is defined in Section 812 Section 7). 814 * If the publication point does not contain a valid manifest, 815 see Section Section 8.2. Lacking a valid manifest, the 816 following tests cannot be performed. 818 2. Check that the current time is between thisUpdate and nextUpdate. 820 * If the current time does not lie in this interval then see 821 Section Section 8.4, but still continue with the following 822 tests. 824 3. Check that every file at the publication point appears on the 825 manifest, and that every file on the manifest appears at the 826 publication point. 828 * If there exists files at the publication point that do not 829 appear on the manifest, or files on the manifest that do not 830 appear at the publication point then see Section Section 8.5 831 but still continue with the following test. 833 4. Check that the hash of every file listed on the manifest matches 834 the value obtained by hashing the file in at the publication 835 point. 837 * If there exist files at the publication point whose hash does 838 not match the hash value listed in the manifest, then see 839 Section Section 8.6. 841 For a particular signed object, if all of the following conditions 842 hold: 844 o the manifest for its publication passes all of the above checks; 845 o the signed object is valid; and 846 o the manifests for every certificate on the certificate path used 847 to validate the signed object pass all of the above checks; 848 then the relying party can conclude that no attack against the 849 repository system has compromised the given signed object, and the 850 signed object MUST be treated as valid. 852 8.2. Missing Manifests 854 The absence of a valid manifest at a publication could occur due to 855 an error by the publisher or due to (malicious or accidental) 856 deletion or corruption of all valid manifests. 858 When no valid manifest is available, there is no protection against 859 attacks that delete signed objects or replay old versions of signed 860 objects. All signed objects at the publication point, and all 861 descendent objects that are validated using a certificate at this 862 publication point should be viewed as somewhat suspect, but may be 863 used by the relying party as per local policy. 865 The primary risk in using signed objects at this publication point is 866 that a deleted CRL causes the relying party to improperly treat a 867 revoked certificate as valid. This risk is somewhat mitigated if the 868 CRL for this publication point has a short time between thisUpdate 869 and nextUpdate (and the current time is within this interval). The 870 risk in discarding signed objects at this publication point is that 871 the relying party may incorrectly discard a large number of valid 872 objects. This gives significant power to an adversary that is able 873 to corrupt all manifests at the publication point. 875 Regardless of whether signed objects from this publication are deemed 876 fit for use by the relying party, this situation should result in a 877 warning to the effect that: "No manifest is available for , and thus there may have been undetected deletions or replay 879 substitutions from the publication point." 881 8.3. Invalid Manifests 883 The presence of invalid manifests at a publication point could occur 884 due to an error by the publisher or due to (malicious or accidental) 885 corruption of a valid manifest. An invalid manifest MUST never be 886 used even if the manifestNumber is greater than that on valid 887 manifests. 889 There are no risks associated with using signed objects at a 890 publication point containing an invalid manifest, provided that a 891 valid manifest covering the signed objects is also present. 893 If an invalid manifest is present at a publication point that also 894 contains one or more valid manifests, this situation should result in 895 a warning to the effect that: "An invalid manifest was found at , this indicates an attack against the publication point 897 or an error by the publisher. Processing for this publication point 898 will continue using the most recent valid manifest." 900 8.4. Stale Manifests 902 A manifest is considered stale if the current time is after the 903 nextUpdate time for the manifest. This could be due to publisher 904 failure to promptly publish a new manifest, or due to (malicious or 905 accidental) corruption of a more recent manifest. 907 All signed objects at the publication point, and all descendent 908 objects that are validated using a certificate at this publication 909 point should be viewed as somewhat suspect, but may be used by the 910 relying party as per local policy. 912 The primary risk in using signed objects at this publication point is 913 that a newer manifest exists that, if present, would indicate that 914 certain objects are have been removed or replaced. (E.g. the new 915 manifest if present might show the existence of a newer CRL and the 916 removal of several revoked certificates). Thus use of objects on a 917 stale manifest may cause the relying party to incorrectly treat 918 several invalid objects as valid. The risk is that a stale CRL 919 causes the relying party to improperly treat a revoked certificate as 920 valid. This risk is somewhat mitigated if the time between the 921 nextUpdate field of the manifest and the current time is short. The 922 risk in discarding signed objects at this publication point is that 923 the relying party may incorrectly discard a large number of valid 924 objects. This gives significant power to an adversary that is able 925 to prevent the publication of a new manifest at a given 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: "The manifest for is no 931 longer current. It is possible that undetected deletions have 932 occurred at this publication point." 934 Note that there is also a less common case where the current time is 935 before the thisUpdate time for the manifest. This case could be due 936 to publisher error, or a local clock error, and in such a case this 937 situation should result in a warning to the effect that: "The 938 manifest found at has an incorrect thisUpdate field. 939 This could be due to publisher error, or a local clock error, and 940 processing for this publication point will continue using this 941 otherwise valid manifest." 943 8.5. Mismatch between Manifest and Publication Point 945 If there exist otherwise valid signed objects that do not appear on 946 any manifest, then provided the manifest is not stale (see Section 947 Section 8.4) it is likely that their omission is an error by the 948 publisher. (If the objects were intended to be invalid, then they 949 should have been revoked using whatever revocation mechanism is 950 appropriate for the signed object in question.) Therefore, there is 951 little risk in using such signed objects. If the manifest in 952 question is stale, then there is a greater risk that the objects in 953 question were revoked with a missing CRL (whose absence is 954 undetectable since the manifest is stale). In any case, the use of 955 signed objects not present on a manifest (or descendent objects that 956 are validated using such signed objects) is a matter of local policy. 958 Regardless of whether objects not appearing on a manifest are deemed 959 fit for use by the relying party, this situation should result in a 960 warning to the effect that: "The following files are present in the 961 repository at , but are not on the manifest ." 964 If there exist files listed on the manifest that do not appear in the 965 repository, then these objects are likely to have been improperly 966 (via malice or accident) deleted from the manifest. A primary 967 purpose of manifests is to detect such deletions. Therefore, in such 968 a case this situation should result in a warning to the effect that: 969 "The following files that should have been present in the repository 970 at , are missing . This indicates an 971 attack against this publication point, or the repository, or an error 972 by the publisher." 974 8.6. Hash Values Not Matching Manifests 976 A file appearing on a manifest with an incorrect hash value could 977 occur because of publisher error, but it is likely to indicate that a 978 serious error has occurred. 980 If an object appeared on a previous valid manifest with a correct 981 hash value and now appears with an invalid hash value, then it is 982 likely that the object has been superceded by a new (unavailable) 983 version of the object. If the object is used there is a risk that 984 the relying party will be treating a stale object as valid. This 985 risk is more significant if the object in question is a CRL. 986 Assuming that the object is validated in the RPKI, the use of these 987 objects is a matter of local policy. 989 If an object appears on a manifest with an invalid hash and has never 990 previously appeared on a manifest, then it is unclear whether the 991 available version of the object is more or less recent than the 992 version whose hash appears in the manifest. If the manifest is stale 993 (see Section Section 8.4) then it becomes more likely that the 994 available version is more recent that the version indicated on the 995 manifest, but this is never certain. Whether to use such objects is 996 a matter of local policy. However, in general, it is better to use a 997 possibly outdated version of the object than to discard the object 998 completely. 1000 While it is a matter of local policy, in the case of CRLs a relying 1001 party should endeavour to use the most recently issued valid CRL even 1002 where the hash value in the manifest matches an older CRL, or does 1003 not match any CRL hand. The ThisUpdate field of the CRL can be used 1004 to establish the most recent CRL in the case where a relying party 1005 has more than one valid CRL at hand. 1007 Regardless of whether objects with incorrect hashes are deemed fit 1008 for use by the relying party, this situation should result in a 1009 warning to the effect that: "The following files at the repository 1010 appear on a manifest with incorrect hash values 1011 . It is possible that these objects have been superseded 1012 by a more recent version. It is very likely that this problem is due 1013 to an attack on the publication point, although it could also be due 1014 to a publisher error." 1016 9. Publication Repositories 1018 The RPKI publication system model requires that every publication 1019 point be associated with a CA or an EE, and be non-empty. Upon 1020 creation of the publication point associated with a CA, the CA MUST 1021 create and publish a manifest as well as a CRL. The manifest will 1022 contain at least one entry, the CRL issued by the CA upon repository 1023 creation. Upon the creation of the publication point associated with 1024 an EE, the EE MUST create and publish a manifest. The manifest in an 1025 otherwise empty repository publication point associated with an EE 1026 will contain no entries in the manifest's fileList sequence (i.e. a 1027 sequence of length zero). [ID.SIDR-REPOSITORY] 1029 For signed objects EE certificate used in the verification of such 1030 objects is either a single-use certificate, used to verify a single 1031 signed object, or a multiple-use certificate. In the case of a 1032 single-use EE certificate, the signed object is published in the 1033 repository publication point of the CA that issued the single use EE 1034 certificate, and is listed in the manifest associated with that CA 1035 certificate. In the case where the EE certificate is used to verify 1036 multiple objects, signed object is published in the EE certificate's 1037 repository publication point and listed in the manifest associated 1038 with the EE certificate. 1040 10. Security Considerations 1042 Manifests provide an additional level of protection for users of the 1043 repository system. Manifests can assist the user to determine if 1044 repository objects have been occluded or other removed from view, and 1045 to determine if an older version of an object has been substituted 1046 for the current object. 1048 Manifests cannot repair the effects of such forms of attempted 1049 corruption of repository retrieval operations, but are capable of 1050 allowing the user to determine if a locally maintained copy of a 1051 repository is a complete and up to date copy, even when the 1052 repository retrieval operation is conduction over an insecure 1053 channel. In those cases where the manifest and the retrieved 1054 repository contents differ, the manifest can assist in determining 1055 which repository objects form the difference set in terms of missing, 1056 extraneous or older objects. 1058 The signing structure of a manifest and the use of next update times 1059 allows the user to determine if the manifest itself is the subject of 1060 attempted alteration. The requirement for all repositories to 1061 contain manifests allows the user to determine is the manifest itself 1062 has been occluded from view. Such attacks against the manifest are 1063 detectable within the timeframe of the regular schedule of manifest 1064 updates. Forms of replay attack within finer-grained timeframes are 1065 not necessarily detectable by the manifest structure. 1067 11. IANA Considerations 1069 [Note to IANA, to be removed prior to publication: there are no IANA 1070 considerations stated in this version of the document.] 1072 12. Acknowledgements 1074 The authors would like to acknowledge the contributions from George 1075 Michaelson and Randy Bush in the preparation of the manifest 1076 specification. Additionally, the authors would like to thank Mark 1077 Reynolds and Christopher Small for assistance in clarifying manifest 1078 validation and relying party behavior. 1080 13. Normative References 1082 [ID.SIDR-ARCH] 1083 Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure 1084 to Support Secure Internet Routing", Work in progress: 1085 Internet Drafts draft-ietf-sidr-arch-03.txt, 1086 February 2008. 1088 [ID.SIDR-CERTPROFILE] 1089 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 1090 X.509 PKIX Resource Certificates", Work in progress: 1091 Internet Drafts draft-ietf-sidr-res-certs-10.txt, 1092 June 2008. 1094 [ID.SIDR-REPOSITORY] 1095 Huston, G., Loomans, R., and G. Michaleson, "A Profile for 1096 Resource Certificate Repository Structure", Work in 1097 progress: Internet 1098 Drafts draft-huston-sidr-repos-struct-02.txt, June 2008. 1100 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1101 Addresses and AS Identifiers", RFC 3779, June 2004. 1103 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1104 RFC 3852, July 2004. 1106 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 1107 Representing Date and Time in ASN.1", RFC 4049, 1108 April 2005. 1110 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1111 Algorithms and Identifiers for RSA Cryptography for use in 1112 the Internet X.509 Public Key Infrastructure Certificate 1113 and Certificate Revocation List (CRL) Profile", RFC 4055, 1114 June 2005. 1116 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1117 Housley, R., and W. Polk, "Internet X.509 Public Key 1118 Infrastructure Certificate and Certificate Revocation List 1119 (CRL) Profile", RFC 5280, May 2008. 1121 Authors' Addresses 1123 Rob Austein 1124 Internet Systems Consortium 1125 950 Charter St. 1126 Redwood City, CA 94063 1127 USA 1129 Email: sra@isc.org 1131 Geoff Huston 1132 Asia Pacific Network Information Centre 1133 33 park Rd. 1134 Milton, QLD 4064 1135 Australia 1137 Email: gih@apnic.net 1138 URI: http://www.apnic.net 1140 Stephen Kent 1141 BBN Technologies 1142 10 Moulton St. 1143 Cambridge, MA 02138 1144 USA 1146 Email: kent@bbn.com 1148 Matt Lepinski 1149 BBN Technologies 1150 10 Moulton St. 1151 Cambridge, MA 02138 1152 USA 1154 Email: mlepinski@bbn.com 1156 Full Copyright Statement 1158 Copyright (C) The IETF Trust (2008). 1160 This document is subject to the rights, licenses and restrictions 1161 contained in BCP 78, and except as set forth therein, the authors 1162 retain all their rights. 1164 This document and the information contained herein are provided on an 1165 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1166 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1167 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1168 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1169 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1170 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1172 Intellectual Property 1174 The IETF takes no position regarding the validity or scope of any 1175 Intellectual Property Rights or other rights that might be claimed to 1176 pertain to the implementation or use of the technology described in 1177 this document or the extent to which any license under such rights 1178 might or might not be available; nor does it represent that it has 1179 made any independent effort to identify any such rights. Information 1180 on the procedures with respect to rights in RFC documents can be 1181 found in BCP 78 and BCP 79. 1183 Copies of IPR disclosures made to the IETF Secretariat and any 1184 assurances of licenses to be made available, or the result of an 1185 attempt made to obtain a general license or permission for the use of 1186 such proprietary rights by implementers or users of this 1187 specification can be obtained from the IETF on-line IPR repository at 1188 http://www.ietf.org/ipr. 1190 The IETF invites any interested party to bring to its attention any 1191 copyrights, patents or patent applications, or other proprietary 1192 rights that may cover technology that may be required to implement 1193 this standard. Please address the information to the IETF at 1194 ietf-ipr@ietf.org.