idnits 2.17.1 draft-ietf-sidr-ta-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2009) is 5538 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 461 -- Looks like a reference, but probably isn't: '1' on line 448 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-16 ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR G. Michaelson 3 Internet-Draft APNIC 4 Intended status: Standards Track S. Kent 5 Expires: August 31, 2009 BBN 6 G. Huston 7 APNIC 8 February 27, 2009 10 A Profile for Trust Anchor Material for the Resource Certificate PKI 11 draft-ietf-sidr-ta-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 31, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 This document defines a standard profile for the publication of Trust 51 Anchor material for the Resource Certificate Public Key 52 Infrastructure. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Trust Anchors for Resource Certificates . . . . . . . . . . . 4 59 3. Publication of Trust Anchor Material . . . . . . . . . . . . . 6 60 4. Cryptographic Message Syntax Profile for RPKI Trust Anchor 61 Material . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 9 63 4.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 9 64 4.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 10 65 4.2. RPKI Trust Anchor Object Validation . . . . . . . . . . . 13 66 5. Relying Party use of Trust Anchor Material . . . . . . . . . . 14 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 This document defines a standard profile for the publication of Trust 77 Anchor (TA) material for the Resource Certificate Public Key 78 Infrastructure [ID.sidr-arch]. The format may be used to distribute 79 trust anchor material using a mix of out-of-band and online means. 80 Procedures used by relying parties (RPs) to verify RPKI signed 81 objects SHOULD support this format to facilitate interoperability 82 between creators of TA material and RPs. 84 In the context of the public Internet, and the use of public number 85 resources within this context, it is intended that Resource 86 Certificates are used in a manner that is explicitly aligned with the 87 public number resource distribution function. This corresponds to a 88 hierarchical PKI structure, as described in section 1.5.1 of 89 [RFC4158], where there is a unique certification path between a 90 certification authority operating at an apex of a resource 91 distribution hierarchy and any RPKI certificate. 93 Validation of a Resource Certificate in a PKI is effected by 94 establishing a validated certificate chain from a certificate issued 95 by a trust anchor certification authority to the certificate being 96 validated [RFC4158]. Because Resource Certificates contain [RFC3779] 97 IP number resource extensions, certificate validation requires that 98 each subject's resources are fully encompassed by those of the issuer 99 at each step in the certificate chain. Certificate path validation 100 in this context corresponds to validation of an associated set of 101 assignment or allocation actions of IP number resources. 103 The constraints imposed by the RFC 3779 extensions are applied to the 104 entire certificate chain, starting with a TA. Thus it is potentially 105 difficult for a relying party to manage trust anchors locally in a 106 fashion that incorporates certificates by well known entities in the 107 RPKI and accommodates certificates that describe private IPv4 address 108 space, private use AS numbers, and IPv6 ULA prefixes. To address 109 this problem, this document defines a compound TA model, in which the 110 one portion of the TA is not an RPKI certificate, and thus need not 111 meet the requirements imposed by RFC 3779. 113 This document describes a data structure for representing Trust 114 Anchors for use in the RPKI. The structure is designed to enable 115 Relying Parties (RPs) to acquire and locally manage trust anchors in 116 a fashion that preserves the resource subset constraints imposed by 117 the use the RFC 3779 extensions. 119 1.1. Terminology 121 It is assumed that the reader is familiar with the terms and concepts 122 described in "Internet X.509 Public Key Infrastructure Certificate 123 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 124 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 125 "Internet X.509 Public Key Infrastructure: Certification Path 126 Building" [RFC4158]. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119. 132 2. Trust Anchors for Resource Certificates 134 This document does not nominate any organizations as default trust 135 anchors for the RPKI. The data structures and procedures described 136 here are capable of accommodating a variety of trust anchor 137 arrangements, involving entities such as IANA, the RIRs, NIRs, LIRs, 138 etc., and involving various forms of off-line and on-line two-tier 139 models for trust anchor management. The constraints imposed by use 140 of RFC 3779 extensions imply that a unique path exists between any 141 RPKI certificate and a TA and there are no loops. 143 It is common to represent a trust anchor as a long-lived, self-signed 144 certificate, although PKI standards (e.g., [RFC5280]) do not mandate 145 this representation. A TA is long-lived because it is usually 146 delivered out-of-band and thus verifying the integrity and 147 authenticity of a TA is "expensive". The self-signed certificate 148 format is commonly employed because it is readily processed by 149 software that is prepared to process certificates, e.g., OpenSSL 150 [OpenSSL],. The self-signed certificate also provides a basic level 151 of consistency checking, as a self-signed certificate cannot be 152 modified (undetectably) by other than the holder of the private key 153 corresponding to the public key in the certificate. 155 A resource certificate held by an RIR, NIR, or LIR may change over a 156 period of some months, in response to resource allocation activity, 157 or in response to other forms of movement of resources between 158 entities. This means that the RFC 3779 extensions will change in 159 these certificates. This makes such certificates poor candidates as 160 trust anchors, since it violates the notion of the TA certificate as 161 being long-lived and, hence, unchanged. 163 This observation about the potential volatility of resource holdings 164 over time by various entities who may be in a position to offer their 165 service as a trust anchor for use by RPs motivates the consideration 166 of a compound trust anchor structure for the RPKI. This structure 167 permits the distribution of a trust anchor that is invariant over 168 long periods, while still allowing the resource certificate intended 169 as a TA for RPKI certificate verification to vary over shorter time 170 intervals. 172 This consideration does not necessarily apply in the context of trust 173 anchor material published by the IANA with respect to the apex of the 174 IP number resource allocation hierarchy. If such IANA-issued trust 175 anchor material described the entirety of the number resource set, 176 then this would constitute "long-lived" material. This would allow 177 the trust anchor to be represented as a long-lived, self-signed 178 resource certificate that contained the IP resource extension of 0/0 179 in IPv4, 0/0 in IPv6, and an AS resource extension of 0-4294967296. 180 However, a commonly used model of trust anchor management is to use 181 an offline CA for the very long-term, self-signed TA, and use a 182 subordinate certificate for an online (and potentially more 183 vulnerable) CA. This implies that even for the situation of an IANA- 184 issued TA, the compound trust anchor structure described here would 185 also be a useful approach to support the long term integrity of such 186 a TA. 188 A similar consideration relating to the use of a compound trust 189 anchor structure applies in the domain of use of resource 190 certificates in scoped environments using certification of private 191 address space and private AS numbers. For example, in IPv6 Unique 192 Local Address (ULA) prefixes are generated locally with a random 193 prefix generation, but can be used in a (semi-) private confederation 194 context. Such address prefixes are are intended to be contextually 195 unique, but are not testable from any external allocating registry. 196 Such a confederation of two or more entities who wish to share 197 routing information using ULAs may choose to instantiate a scoped 198 RPKI over their respective ULA spaces, and may do so using this 199 mechanism. 201 The compound trust anchor model can also support operational 202 arrangemets of the form of an offline CA for the self-signed TA and 203 an online subordinate CA. 205 The first part of a structured trust anchor in the RPKI is a self- 206 signed CA certificate that contains no resource extensions. It 207 conforms to the certificate profile as defined in 208 [ID.sidr-res-certs], except for the omission of IP Resource and AS 209 Resource extensions. This CA certificate will be referred to as an 210 "external TA" (certificate), or ETA. The ETA will issue a CRL and 211 one EE certificate. The CRL conforms to the [ID.sidr-res-certs] 212 profile. The EE certificate also conforms to the [ID.sidr-res-certs] 213 profile, except for the omission of IP Resource and AS Resource 214 extensions. This certificate will be referred to as a "ETA EE" 215 (certificate). 217 The second part of a structured trust anchor in the RPKI is a self- 218 signed RPKI CA certificate that includes RFC 3779 extensions. This 219 certificate will function as a TA for purposes of processing resource 220 certificates, i.e., the certificate path will terminate at this 221 certificate. This certificate is referred to as an "RPKI TA" 222 (certificate) or an RTA. The format used to represent the ETA is 223 based on ongoing IETF PKIX WG activities to define a format for trust 224 anchor material. 226 There are no required relationships between the (Subject/Issuer) 227 names used in the ETA certificates and RPKI TA certificate, but the 228 (public) keys used in the two certificates SHOULD be different. 230 Because both of these certificates are self-signed, it is not 231 possible to verify the RPKI TA certificate directly from the ETA 232 certificate. Instead, the two TAs are related by the use of a CMS 233 object [RFC3852]. The RPKI TA certificate is encapsulated in a CMS 234 structure that is signed by the private key associated with the ETA 235 EE certificate. Section 4 describes this CMS structure in detail, 236 profiling the CMS signed-object format, and provides the algorithm 237 that MUST be employed to validate this object and extract the RTA for 238 use in validating RPKI certificate chains. 240 3. Publication of Trust Anchor Material 242 The RPKI architecture [ID.sidr-arch] calls for certificates to be 243 issued by the entities that allocate Internet number resources 244 (addresses and AS numbers). This suggests that the structure of 245 certificates in the RPKI that relate to the use of public number 246 resources is a public context should reflect the hierarchy used to 247 allocate these resources. This document does not mandate nor even 248 recommend a specific set of default TAs, but it does observe that, 249 for most RPs, the IANA is in a unique role as the default TA for 250 representing public address space and public AS numbers. 252 In any PKI an important principle is that entities issuing 253 certificates are authoritative for the information in the 254 certificates they issue. In the context of the RPKI, this means that 255 an organization represented by an RTA SHOULD be authoritative for the 256 resources enumerated in its (self-signed) certificate. Any deviation 257 from this principle creates opportunities for accidental (or 258 malicious) misrepresentation. 260 It will be necessary for an RP to establish RTAs in ways that deviate 261 from this principle in order to represent private-use address space, 262 locally-scoped address space, and private-use AS numbers. However, 263 this is a "safe" RTA management practice because it affects only 264 those RPs that choose to configure their local TA store in this 265 fashion. It does not "endanger" other RPs who are not a participant 266 in such locally scoped environments. 268 An ETA certificate that is not managed on an entirely local basis, 269 where the TA issuer and the RP are essentially the same entity, is 270 presumed to be long-lived as it will likely be distributed with 271 relying party validation software, or via a similar out-of-band 272 means. 274 An entity offering itself as a putative trust anchor in the context 275 of the RPKI is required to regularly publish an RPKI TA certificate 276 at a stable URL, and to publish at this URL its CRL and the CMS- 277 signed object that contains its RTA. The recommended operational 278 maintenance procedures for publication of this material are as 279 follows: 281 * The entity issues an RTA certificate. This certificate MUST be 282 reissued periodically, prior to its expiration, and MUST be 283 reissued upon any change in the resource set that has been 284 allocated to the entity operating this RPKI TA. The validity 285 interval of this certificate SHOULD reflect the anticipated 286 period of changes to the entity's resource set. 288 * The entity issues an ETA certificate. Remember that this 289 certificate contains no RFC 3779 extension. The validity 290 period of this certificate should be very long, as is the 291 conventional practice for trust anchor material. The SIA of 292 this certificate references a publication point where the CRL 293 and the CMS object (defined in Section 4) are published. 295 * The ETA issues an ETA EE certificate with a validity period 296 identical to the validity period of the RTA certificate. This 297 ETA EE certificate MUST have the digitalSignature bit set, and 298 this MUST be the only bit set to TRUE in the key usage 299 extension. There is no BasicConstraints extension in this 300 certificate (since it is an EE certificate). 302 * The ETA regularly issues a CRL. The CRL issuance cycle SHOULD 303 be shorter than the validity period for the RTA certificate. 305 * Each time an RTA certificate is re-issued, or prior to the 306 expiration of the ETA EE certificate, the ETA generates a 307 Cryptographic Message Syntax (CMS) [RFC3852] signed-data 308 object, the payload of which is an RTA certificate. The object 309 is CMS-signed with the private key corresponding to the ETA EE 310 certificate. The ETA EE certificate MUST be included as a CMS 311 signed attribute in the CMS object. The ETA certificate and 312 the associated CRL MUST NOT be included in the CMS object. The 313 format of the CMS object is specified in Section 4. The CMS 314 object is published at the location referenced in the SIA of 315 the ETA certificate. 317 * The entity publicly distributes its ETA in an out-of-band 318 fashion, e.g., as part of widely-distributed relying party 319 software, or by passing the ETA to a relying party in person. 321 [Author note: possible placeholder for an explanation of how an RP 322 can deal with generation and installation of ETAs and RTAs that are 323 not part of a distributed putative TA set.] 325 [Author note: a diagram would help here!] 327 If a trust anchor chooses to reissue its RTA certificate before the 328 expiration of that certificate, it MUST perform the follow actions: 330 * revise the nextUpdate time of the ETA's CRL to reflect the 331 issue date for the new ETA EE certificate, 333 * issue a new ETA EE certificate and a new CMS object with the 334 new RTA CA certificate, and 336 * revoke the old ETA EE certificate at the nextUpdate time in the 337 next issued CRL. This revocation will provide an indication to 338 relying parties to perform the retrieve the RTA CA certificate 339 at a time earlier than the normal update cycle time. 341 4. Cryptographic Message Syntax Profile for RPKI Trust Anchor Material 343 Using the Cryptographic Message Syntax (CMS) [RFC3852], a RPKI Trust 344 Anchor Object is a type of signed-data object. The general format of 345 a CMS object is: 347 ContentInfo ::= SEQUENCE { 348 contentType ContentType, 349 content [0] EXPLICIT ANY DEFINED BY contentType } 351 ContentType ::= OBJECT IDENTIFIER 353 As an RTA Trust Anchor Object is a signed-data object, it uses the 354 corresponding OID, 1.2.840.113549.1.7.2. [RFC3852]. 356 4.1. Signed-Data ContentType 358 According to the CMS specification, the signed-data content type 359 shall have ASN.1 type SignedData: 361 SignedData ::= SEQUENCE { 362 version CMSVersion, 363 digestAlgorithms DigestAlgorithmIdentifiers, 364 encapContentInfo EncapsulatedContentInfo, 365 certificates [0] IMPLICIT CertificateSet OPTIONAL, 366 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 367 signerInfos SignerInfos } 369 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 371 SignerInfos ::= SET OF SignerInfo 373 The elements of the signed-data content type are as follows: 375 version 376 The version is the syntax version number. It MUST be 3, 377 corresponding to the signerInfo structure having version 378 number 3. 380 digestAlgorithms 381 The digestAlgorithms set MUST include only SHA-256, the OID 382 for which is 2.16.840.1.101.3.4.2.1. [RFC4055]. It MUST 383 NOT contain any other algorithms. 385 encapContentInfo 386 This element is defined in Section 4.1.1. 388 certificates 389 The certificates element MUST be included and MUST contain 390 only the single PKI EE certificate needed to validate this 391 CMS Object. The CertificateSet type is defined in section 392 10 of [RFC3852] 394 crls 395 The crls element MUST be omitted. 397 signerInfos 398 This element is defined in Section 4.1.2. 400 4.1.1. encapContentInfo 402 encapContentInfo is the signed content, consisting of a content type 403 identifier and the content itself. 405 EncapsulatedContentInfo ::= SEQUENCE { 406 eContentType ContentType, 407 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 409 ContentType ::= OBJECT IDENTIFIER 411 The elements of this signed content type are as follows: 413 eContentType 414 The ContentType for an RTA Trust Anchor Object is defined as 415 id-ct-RPKITrustAnchor and has the numerical value of 416 1.2.840.113549.1.9.16.1.33. 418 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 419 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 421 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 423 id-ct-RPKITrustAnchor OBJECT IDENTIFIER ::= { id-ct 33 } 425 eContent 426 The content of an RTA Trust Anchor Object is an RPKI self- 427 signed CA certificate.It is formally defined as: 428 [Author note: Need to change this in the next rev of this 429 document, because as the ASN.1 constructs are from CMS, then 430 we have to stick with the SETs and SEQUENCEs, even though 431 this profile requires exactly one element in the set.] 433 id-ct-RPKITrustAnchor ::= Certificate 435 The definition of Certificate is taken from [X.509]. 437 4.1.2. signerInfos 439 SignerInfo is defined under CMS as: 441 SignerInfo ::= SEQUENCE { 442 version CMSVersion, 443 sid SignerIdentifier, 444 digestAlgorithm DigestAlgorithmIdentifier, 445 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 446 signatureAlgorithm SignatureAlgorithmIdentifier, 447 signature SignatureValue, 448 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 450 The content of the SignerInfo element are as follows: 452 version 453 The version number MUST be 3, corresponding with the choice 454 of SubjectKeyIdentifier for the sid. 456 sid 457 The sid is defined as: 459 SignerIdentifier ::= CHOICE { 460 issuerAndSerialNumber IssuerAndSerialNumber, 461 subjectKeyIdentifier [0] SubjectKeyIdentifier } 463 For a RTA Trust Anchor Object, the sid MUST be a 464 SubjectKeyIdentifier. 466 digestAlgorithm 467 The digestAlgorithm MUST be SHA-256, the OID for which is 468 2.16.840.1.101.3.4.2.1. [RFC4055] 470 signedAttrs 471 The signedAttrs element is defined as: 473 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 475 Attribute ::= SEQUENCE { 476 attrType OBJECT IDENTIFIER, 477 attrValues SET OF AttributeValue } 479 AttributeValue ::= ANY 481 The signedAttr element MUST be present and MUST include the 482 content-type and message-digest attributes. The signer MAY 483 also include the signing-time signed attribute, the binary- 484 signing-time signed attribute, or both signed attributes. 485 Other signed attributes that are deemed appropriate MAY also 486 be included. The intent is to allow additional signed 487 attributes to be included if a future need is identified. 488 This does not cause an interoperability concern because 489 unrecognized signed attributes are ignored by the relying 490 party. 492 The signedAttr MUST include only a single instance of any 493 particular attribute. Additionally, even though the syntax 494 allows for a SET OF AttributeValue, in a RTA Trust Anchor 495 object the attrValues must consist of only a single 496 AttributeValue. 498 [Author note: Note to recheck this, as it may be required to 499 use a SET with a single member in the CMS specification.] 501 ContentType Attribute 502 The ContentType attribute MUST be present. The 503 attrType OID for the ContentType attribute is 504 1.2.840.113549.1.9.3. 506 The attrValues for the ContentType attribute in 507 a RTA Trust Anchor Object MUST be 508 1.2.840.113549.1.9.16.1.24 (matching the 509 eContentType in the EncapsulatedContentInfo). 511 MessageDigest Attribute 512 The MessageDigest attribute MUST be present. 513 The attrType OID for the MessageDigest Attribute 514 is 1.2.840.113549.1.9.4. 516 The attrValues for the MessageDigest attribute 517 contains the output of the digest algorithm 518 applied to the content being signed, as 519 specified in Section 11.1 of [RFC3852]. 521 SigningTime Attribute 522 The SigningTime attribute MAY be present. If it 523 is present it MUST be ignored by the relying 524 party. The presence of absence of the 525 SigningTime attribute in no way affects the 526 validation of the RTA Trust Anchor Object. The 527 attrType OID for the SigningTime attribute is 528 1.2.840.113549.1.9.5. 530 The attrValues for the SigningTime attribute is 531 defined as: 533 SigningTime ::= Time 535 Time ::= CHOICE { 536 utcTime UTCTime, 537 generalizedTime GeneralizedTime } 539 The Time element specifies the time, based on 540 the local system clock, at which the digital 541 signature was applied to the content. 543 BinarySigningTime Attribute 544 The BinarySigningTime attribute MAY be present. 545 If it is present it MUST be ignored by the 546 relying party. The presence of absence of the 547 BinarySigningTime attribute in no way affects 548 the validation of the RTA Trust Anchor Object. 549 The attrType OID for the SigningTime attribute 550 is 1.2.840.113549.1.9.16.2.46. 552 The attrValues for the SigningTime attribute is 553 defined as: 555 BinarySigningTime ::= BinaryTime 557 BinaryTime ::= INTEGER (0..MAX) 559 The BinaryTime element specifies the time, based 560 on the local system clock, at which the digital 561 signature was applied to the content. 563 signatureAlgorithm 564 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID 565 for which is 1.2.840.113549.1.1.1.q 567 signature 568 The signature value is defined as: 570 SignatureValue ::= OCTET STRING 572 The signature characteristics are defined by the digest and 573 signature algorithms. 575 unsignedAttrs 576 unsignedAttrs MUST be omitted. 578 4.2. RPKI Trust Anchor Object Validation 580 Before a relying party can use an RTA Trust Anchor Object, the 581 relying party must first validate the object by performing the 582 following steps. 584 1. Verify that the RTA Trust Anchor Object syntax complies with 585 this specification. In particular, verify the following: 587 a. The contentType of the CMS object is SignedData (OID 588 1.2.840.113549.1.7.2). 590 b. The version of the SignedData object is 3. 592 c. The digestAlgorithm in the SignedData object is SHA-256 593 (OID 2.16.840.1.101.3.4.2.1). 595 d. The certificates field in the SignedData object is present 596 and contains a single EE certificate whose Subject Key 597 Identifier (SKI) matches the CMS sid field of the 598 SignerInfo object. 600 e. The CMS crls field in the SignedData object is omitted. 602 f. The eContentType in the EncapsulatedContentInfo is id-ct- 603 RPKITrustAnchor (OID 1.2.840.113549.1.9.16.1.33) 605 g. The version of the SignerInfo is 3. 607 h. The digestAlgorithm in the SignerInfo object is SHA-256 608 (OID 2.16.840.1.101.3.4.2.1). 610 i. The signatureAlgorithm in the SignerInfo object is RSA 611 (OID 1.2.840.113549.1.1.1). 613 j. The signedAttrs field in the SignerInfo object is present 614 and contains both the ContentType attribute (OID 615 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 616 1.2.840.113549.1.9.4). 618 k. The unsignedAttrs field in the SignerInfo object is 619 omitted. 621 2. Use the public key in the EE certificate to verify the 622 signature on the RTA Trust Anchor Object. 624 3. Verify that the ETA EE certificate is a valid end-entity 625 certificate issued directly under ETA, and the ETA's CRL has 626 not revoked this certificate, and that the ETA's CRL is valid. 628 5. Relying Party use of Trust Anchor Material 630 Relying Parties can assemble the putative trust anchor collection by 631 using the ETA certificate for each putative trust anchor: 633 * The ETA's CRL and CMS objects are retrieved from the 634 publication point referenced by the SIA in the ETA certificate. 636 * Extract the EE certificate from the CMS object and verify this 637 certificate using the ETA certificate. 639 * Verify the ETA's CRL (using the ETA certificate) and use this 640 CRL to verify the revocation status of the ETA EE certificate 641 from the CMS object. 643 * Verify the signature on the CMS object using the (already 644 verified) ETA EE certificate from the CMS object. 646 * The relying party can then load the enclosed RPKI TA 647 certificate and use it to validate other RPKI certificates. 649 Relying Parties SHOULD perform this retrieval and validation 650 operation at intervals no less frequent than the nextUpdate time of 651 the published ETA CRL, and SHOULD perform the retrieval operation 652 prior to the expiration of the ETA EE certificate, or upon revocation 653 of the ETA EE certificate. 655 6. Security Considerations 657 The security considerations noted in [RFC4158] are applicable here. 659 7. IANA Considerations 661 [Note to IANA, to be removed prior to publication: there are no IANA 662 considerations stated in this document in terms of IANA registry 663 actions. The document discussed a potential role for the IANA in the 664 operational management of a trust anchor for the public resource 665 RPKI, but does not specifically mandate or recommend that IANA 666 undertake such a role.] 668 8. References 670 8.1. Normative References 672 [ID.sidr-res-certs] 673 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 674 X.509 PKIX Resource Certificates", Work in progress: 675 Internet Drafts draft-ietf-sidr-res-certs-16.txt, 676 February 2009. 678 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 679 Addresses and AS Identifiers", RFC 3779, June 2004. 681 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 682 RFC 3852, July 2004. 684 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 685 Algorithms and Identifiers for RSA Cryptography for use in 686 the Internet X.509 Public Key Infrastructure Certificate 687 and Certificate Revocation List (CRL) Profile", RFC 4055, 688 June 2005. 690 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 691 Housley, R., and W. Polk, "Internet X.509 Public Key 692 Infrastructure Certificate and Certificate Revocation List 693 (CRL) Profile", RFC 5280, May 2008. 695 [X.509] ITU-T, "Recommendation X.509: The Directory - 696 Authentication Framework", 2000. 698 8.2. Informative References 700 [ID.sidr-arch] 701 Lepinski, M. and S. Kent, "An Infrastructure to Support 702 Secure Internet Routing", Work in progress: Internet 703 Drafts draft-ietf-sidr-arch-04.txt, November 2008. 705 [OpenSSL] TBA, "OpenSSL", 2009. 707 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 708 Nicholas, "Internet X.509 Public Key Infrastructure: 709 Certification Path Building", RFC 4158, September 2005. 711 Authors' Addresses 713 George Michaelson 714 Asia Pacific Network Information Centre 716 Email: ggm@apnic.net 717 URI: http://www.apnic.net 718 Stephen Kent 719 BBN Technologies 720 10 Moulton St. 721 Cambridge, MA 02138 722 USA 724 Email: kent@bbn.com 726 Geoff Huston 727 Asia Pacific Network Information Centre 729 Email: gih@apnic.net 730 URI: http://www.apnic.net