idnits 2.17.1 draft-ietf-sidr-ta-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 15, 2009) is 5329 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 503 -- Looks like a reference, but probably isn't: '1' on line 490 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-17 == Outdated reference: A later version (-05) exists of draft-ietf-sidr-rpki-algs-00 ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: March 19, 2010 BBN 6 G. Huston 7 APNIC 8 September 15, 2009 10 A Profile for Trust Anchor Material for the Resource Certificate PKI 11 draft-ietf-sidr-ta-02 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 March 19, 2010. 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 in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document defines a standard profile for the publication of Trust 50 Anchor material for the Resource Certificate Public Key 51 Infrastructure. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Trust Anchors for Resource Certificates . . . . . . . . . . . 4 58 2.1. A Compound Trust Anchor Structure . . . . . . . . . . . . 5 59 3. Publication of Trust Anchor Material . . . . . . . . . . . . . 8 60 4. Cryptographic Message Syntax Profile for RPKI Trust Anchor 61 Material . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 10 63 4.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 11 64 4.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 12 65 4.2. RPKI Trust Anchor Object Validation . . . . . . . . . . . 14 66 5. Relying Party use of Trust Anchor Material . . . . . . . . . . 16 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 "An Infrastructure to Support Secure Internet Routing" 123 [ID.sidr-arch], "Internet X.509 Public Key Infrastructure Certificate 124 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 125 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 126 "Internet X.509 Public Key Infrastructure: Certification Path 127 Building" [RFC4158], and . 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119. 133 2. Trust Anchors for Resource Certificates 135 This document does not nominate any organizations as default trust 136 anchors for the RPKI. The data structures and procedures described 137 here are capable of accommodating a variety of trust anchor 138 arrangements, involving entities such as the Internet Assigned 139 Numbers Authority (IANA), the Regional Internet Registries (RIRs), 140 Local Internet Registries (LIRs), etc., and involving various forms 141 of off-line and on-line two-tier models for trust anchor management. 142 The constraints imposed by use of RFC 3779 extensions imply that a RP 143 can verify that that a unique path exists between any RPKI 144 certificate and a chosen TA. 146 It is common to represent a trust anchor as a long-lived, self-signed 147 certificate, although PKI standards (e.g., [RFC5280]) do not mandate 148 this representation. A TA is long-lived because it is usually 149 delivered out-of-band and thus verifying the integrity and 150 authenticity of a TA is "expensive". The self-signed certificate 151 format is commonly employed because it is readily processed by 152 software that is prepared to process certificates, e.g., OpenSSL 153 [OpenSSL],. The self-signed certificate also provides a basic level 154 of consistency checking, as a self-signed certificate cannot be 155 modified (undetectably) by other than the holder of the private key 156 corresponding to the public key in the certificate. 158 A resource certificate held by an RIR or a LIR that describes all the 159 resources that are administered by that entity may change over a 160 period of some months, in response to resource allocation activity, 161 or in response to other forms of movement of resources between 162 entities. This means that the RFC 3779 extensions will change in 163 these certificates, making such certificates poor candidates as trust 164 anchors, since such changes violate the notion of the TA certificate 165 as being long-lived and, hence, unchanged. 167 This observation about the potential volatility of resource holdings 168 over time by various entities who may be in a position to offer their 169 service as a trust anchor for use by RPs motivates the consideration 170 of a compound trust anchor structure for the RPKI. This structure 171 permits the distribution of a trust anchor that is invariant over 172 long periods, while still allowing the resource certificate intended 173 as a TA for RPKI certificate verification to vary over shorter time 174 intervals. 176 This consideration does not necessarily apply in the context of trust 177 anchor material published by the IANA with respect to the apex of the 178 IP number resource allocation hierarchy. If such IANA-issued trust 179 anchor material described the entirety of the number resource set, 180 then this would constitute "long-lived" material. This would allow 181 the trust anchor to be represented as a long-lived, self-signed 182 resource certificate that contained the IP resource extension of 0/0 183 in IPv4, 0/0 in IPv6, and an AS resource extension of 0-4294967296. 184 However, a commonly used model of trust anchor management is to use 185 an offline CA for the very long-term, self-signed TA, and use a 186 subordinate certificate for an online (and potentially more 187 vulnerable) CA. This implies that even for the situation of an IANA- 188 issued TA, the compound trust anchor structure described here would 189 also be a useful approach to support the long term integrity of such 190 a TA. 192 A similar consideration relating to the use of a compound trust 193 anchor structure applies in the domain of use of resource 194 certificates in scoped environments using certification of private 195 address space and private AS numbers. For example, in IPv6 Unique 196 Local Address (ULA) prefixes are generated locally with a random 197 prefix generation, but can be used in a (semi-) private confederation 198 context. Such address prefixes are intended to be contextually 199 unique, but are not testable from any external allocating registry. 200 Such a confederation of two or more entities who wish to share 201 routing information using ULAs may choose to instantiate a scoped 202 RPKI over their respective ULA spaces, and may do so using this 203 mechanism. 205 The compound trust anchor model can also support operational 206 arrangements of the form of an offline CA for the self-signed TA and 207 an online subordinate CA. 209 2.1. A Compound Trust Anchor Structure 211 The first part of a structured trust anchor in the RPKI is a self- 212 signed CA certificate that contains no resource extensions. It 213 conforms to the certificate profile as defined in 214 [ID.sidr-res-certs], except for the omission of IP Resource and AS 215 Resource extensions. This CA certificate is referred to here as an 216 "external TA" (certificate), or ETA. The ETA issues a CRL and one EE 217 certificate. The CRL conforms to the [ID.sidr-res-certs] profile. 218 The EE certificate also conforms to the [ID.sidr-res-certs] profile, 219 except for the omission of IP Resource and AS Resource extensions. 220 This certificate will be referred to as a "ETA EE" (certificate). 222 The second part of a structured trust anchor in the RPKI is a self- 223 signed RPKI CA certificate that includes RFC 3779 extensions. This 224 certificate will function as a TA for purposes of processing resource 225 certificates, i.e., the certificate path will terminate at this 226 certificate. This certificate is referred to here as an "RPKI TA" 227 (certificate) or an RTA. The format used to represent the ETA is 228 based on ongoing IETF PKIX WG activities to define a format for trust 229 anchor material. 231 There are no required relationships between the (Subject/Issuer) 232 names used in the ETA certificates and RPKI TA certificate, but the 233 (public) keys used in the two certificates SHOULD be different. 235 Because both of these certificates are self-signed, it is not 236 possible to verify the RPKI TA certificate directly from the ETA 237 certificate. Instead, the two TAs are related by the use of a CMS 238 object [RFC3852]. The RPKI TA certificate is encapsulated in a CMS 239 structure that is signed by the private key associated with the ETA 240 EE certificate. Section 4 describes this CMS structure in detail, 241 profiling the CMS signed-object format, and provides the algorithm 242 that MUST be employed to validate this object and extract the RTA for 243 use in validating RPKI certificate chains. 245 The structure of the trust anchor material is shown in the following 246 diagram. 248 +------------------------------+ 249 | ETA CA Certificate | 250 | | 251 | Issuer: | 252 | Subject: | 253 | SIA: -------------------|-+ 254 +------------------------------+ | 255 | Signed: ETA (self-signed) | | 256 +------------------------------+ | 257 V 258 +---------------------------------------------------------+ 259 | ETA Repository Publication Point | 260 |+--------------------------------+ +--------------+| 261 || CMS Signed Object |<-+ +->|ETA CRL || 262 ||--------------------------------| | | | || 263 || CMS Attributes and Signer Info | | | | Issuer: || 264 || | | | | || 265 ||+------------------------------+| | | +--------------+| 266 ||| ETA EE Certificate || | | | Signed: ETA || 267 ||| || | | +--------------+| 268 ||| Issuer: || | | | 269 ||| Subject: || | | | 270 ||| SIA: -------------------||--+ | | 271 ||| CRL: -------------------||----+ | 272 ||+------------------------------+| | 273 ||| Signed: ETA || | 274 ||+------------------------------+| | 275 ||--------------------------------| | 276 || CMS Signed Data | | 277 || | | 278 ||+------------------------------+| | 279 ||| RTA CA Certificate || | 280 ||| || | 281 ||| Issuer: || | 282 ||| Subject: || | 283 ||| CRL: -------------------||-------------------------> 284 ||| SIA: -------------------||-------------------------> 285 ||| IP: || | 286 ||| AS: || | 287 ||+------------------------------+| | 288 ||| Signed: RPKI TA (self-signed)|| | 289 ||+------------------------------+| | 290 |+--------------------------------+ | 291 +---------------------------------------------------------+ 293 3. Publication of Trust Anchor Material 295 The RPKI architecture [ID.sidr-arch] calls for certificates to be 296 issued by the entities that allocate Internet number resources 297 (addresses and AS numbers). This suggests that the structure of 298 certificates in the RPKI that relate to the use of public number 299 resources is a public context should reflect the hierarchy used to 300 allocate these resources. This document does not mandate nor even 301 recommend a specific set of default TAs, but it does observe that, 302 for most RPs, the IANA is in a unique role as the default TA for 303 representing public address space and public AS numbers. 305 In any PKI an important principle is that entities issuing 306 certificates are authoritative for the information in the 307 certificates they issue. In the context of the RPKI, this means that 308 an organization represented by an RTA SHOULD be authoritative for the 309 resources enumerated in its (self-signed) certificate. Any deviation 310 from this principle creates opportunities for accidental (or 311 malicious) misrepresentation. 313 It will be necessary for an RP to establish RTAs in ways that deviate 314 from this principle in order to represent private-use address space, 315 locally-scoped address space, and private-use AS numbers. However, 316 this is a "safe" RTA management practice because it affects only 317 those RPs that choose to configure their local TA store in this 318 fashion. It does not "endanger" other RPs who are not a participant 319 in such locally scoped environments. 321 An ETA certificate that is not managed on an entirely local basis, 322 where the TA issuer and the RP are essentially the same entity, is 323 presumed to be long-lived as it will likely be distributed with 324 relying party validation software, or via a similar out-of-band 325 means. 327 An entity offering itself as a putative trust anchor in the context 328 of the RPKI is required to regularly publish an RPKI TA certificate 329 at a stable URL, and to publish at this URL its CRL and the CMS- 330 signed object that contains its RTA. The recommended operational 331 maintenance procedures for publication of this material are as 332 follows: 334 * The entity issues an RTA certificate. This certificate MUST be 335 reissued periodically, prior to its expiration, and MUST be 336 reissued upon any change in the resource set that has been 337 allocated to the entity operating this RPKI TA. The validity 338 interval of this certificate SHOULD reflect the anticipated 339 period of changes to the entity's resource set. 341 * The entity issues an ETA certificate. This certificate 342 contains no RFC 3779 extension. The validity period of this 343 certificate should be very long, as is the conventional 344 practice for trust anchor material. The SIA of this 345 certificate references a publication point where the CRL and 346 the CMS object (defined in Section 4) are published. 348 * The ETA issues an ETA EE certificate with a validity period 349 identical to the validity period of the RTA certificate. This 350 ETA EE certificate MUST have the digitalSignature bit set, and 351 this MUST be the only bit set to TRUE in the key usage 352 extension. There is no BasicConstraints extension in this 353 certificate (since it is an EE certificate). 355 * The ETA regularly issues a CRL. The CRL issuance cycle SHOULD 356 be shorter than the validity period for the RTA certificate. 358 * Each time an RTA certificate is re-issued, or prior to the 359 expiration of the ETA EE certificate, the ETA generates a 360 Cryptographic Message Syntax (CMS) [RFC3852] signed-data 361 object, the payload of which is an RTA certificate. The object 362 is CMS-signed with the private key corresponding to the ETA EE 363 certificate. The ETA EE certificate MUST be included as a CMS 364 signed attribute in the CMS object. The ETA certificate and 365 the associated CRL MUST NOT be included in the CMS object. The 366 format of the CMS object is specified in Section 4. The CMS 367 object is published at the location referenced in the SIA of 368 the ETA certificate. 370 * The entity publicly distributes its ETA in an out-of-band 371 fashion, e.g., as part of widely-distributed relying party 372 software, or by passing the ETA to a relying party in person. 374 If a trust anchor chooses to reissue its RTA certificate before the 375 expiration of that certificate, it MUST perform the follow actions: 377 * revise the nextUpdate time of the ETA's CRL to reflect the 378 issue date for the new ETA EE certificate, 380 * issue a new ETA EE certificate and a new CMS object with the 381 new RTA CA certificate, and 383 * revoke the old ETA EE certificate at the nextUpdate time in the 384 next issued CRL. This revocation will provide an indication to 385 relying parties to perform the retrieve the RTA CA certificate 386 at a time earlier than the normal update cycle time. 388 4. Cryptographic Message Syntax Profile for RPKI Trust Anchor Material 390 Using the Cryptographic Message Syntax (CMS) [RFC3852], a RPKI Trust 391 Anchor Object is a type of signed-data object. The general format of 392 a CMS object is: 394 ContentInfo ::= SEQUENCE { 395 contentType ContentType, 396 content [0] EXPLICIT ANY DEFINED BY contentType } 398 ContentType ::= OBJECT IDENTIFIER 400 As an RTA Trust Anchor Object is a signed-data object, it uses the 401 corresponding OID, 1.2.840.113549.1.7.2. [RFC3852]. 403 4.1. Signed-Data ContentType 405 According to the CMS specification, the signed-data content type 406 shall have ASN.1 type SignedData: 408 SignedData ::= SEQUENCE { 409 version CMSVersion, 410 digestAlgorithms DigestAlgorithmIdentifiers, 411 encapContentInfo EncapsulatedContentInfo, 412 certificates [0] IMPLICIT CertificateSet OPTIONAL, 413 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 414 signerInfos SignerInfos } 416 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 418 SignerInfos ::= SET OF SignerInfo 420 The elements of the signed-data content type are as follows: 422 version 423 The version is the syntax version number. It MUST be 3, 424 corresponding to the signerInfo structure having version 425 number 3. 427 digestAlgorithms 428 The digestAlgorithms set is specified in 429 [ID.sidr-rpki-algs]. 431 encapContentInfo 432 This element is defined in Section 4.1.1. 434 certificates 435 The certificates element MUST be included and MUST contain 436 only the single PKI EE certificate needed to validate this 437 CMS Object. The CertificateSet type is defined in section 438 10 of [RFC3852] 440 crls 441 The crls element MUST be omitted. 443 signerInfos 444 This element is defined in Section 4.1.2. 446 4.1.1. encapContentInfo 448 encapContentInfo is the signed content, consisting of a content type 449 identifier and the content itself. 451 EncapsulatedContentInfo ::= SEQUENCE { 452 eContentType ContentType, 453 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 455 ContentType ::= OBJECT IDENTIFIER 457 The elements of this signed content type are as follows: 459 eContentType 460 The ContentType for an RTA Trust Anchor Object is defined as 461 id-ct-RPKITrustAnchor and has the numerical value of 462 1.2.840.113549.1.9.16.1.33. 464 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 465 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 467 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 469 id-ct-RPKITrustAnchor OBJECT IDENTIFIER ::= { id-ct 33 } 471 eContent 472 The content of an RTA Trust Anchor Object is an RPKI self- 473 signed CA certificate. It is formally defined as: 475 id-ct-RPKITrustAnchor ::= Certificate 477 The definition of Certificate is taken from [X.509]. 479 4.1.2. signerInfos 481 SignerInfo is defined under CMS as: 483 SignerInfo ::= SEQUENCE { 484 version CMSVersion, 485 sid SignerIdentifier, 486 digestAlgorithm DigestAlgorithmIdentifier, 487 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 488 signatureAlgorithm SignatureAlgorithmIdentifier, 489 signature SignatureValue, 490 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 492 The content of the SignerInfo element are as follows: 494 version 495 The version number MUST be 3, corresponding with the choice 496 of SubjectKeyIdentifier for the sid. 498 sid 499 The sid is defined as: 501 SignerIdentifier ::= CHOICE { 502 issuerAndSerialNumber IssuerAndSerialNumber, 503 subjectKeyIdentifier [0] SubjectKeyIdentifier } 505 For a RTA Trust Anchor Object, the sid MUST be a 506 SubjectKeyIdentifier. 508 digestAlgorithm 509 The digestAlgorithm is specified in [ID.sidr-rpki-algs]. 511 signedAttrs 512 The signedAttrs element is defined as: 514 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 516 Attribute ::= SEQUENCE { 517 attrType OBJECT IDENTIFIER, 518 attrValues SET OF AttributeValue } 520 AttributeValue ::= ANY 522 The signedAttr element MUST be present and MUST include the 523 content-type and message-digest attributes. The signer MAY 524 also include the signing-time signed attribute, the binary- 525 signing-time signed attribute, or both signed attributes. 526 Other signed attributes that are deemed appropriate MAY also 527 be included. The intent is to allow additional signed 528 attributes to be included if a future need is identified. 529 This does not cause an interoperability concern because 530 unrecognized signed attributes are ignored by the relying 531 party. 533 The signedAttr MUST include only a single instance of any 534 particular attribute, and for each Attribute there MUST only 535 be one AttributeValue. 536 The defined signedAttr attributes are: 538 ContentType Attribute 539 The ContentType attribute MUST be present. The 540 attrType OID for the ContentType attribute is 541 1.2.840.113549.1.9.3. 543 The attrValues for the ContentType attribute in 544 a RTA Trust Anchor Object MUST be 545 1.2.840.113549.1.9.16.1.24 (matching the 546 eContentType in the EncapsulatedContentInfo). 548 MessageDigest Attribute 549 The MessageDigest attribute MUST be present. 550 The attrType OID for the MessageDigest Attribute 551 is 1.2.840.113549.1.9.4. 553 The attrValues for the MessageDigest attribute 554 contains the output of the digest algorithm 555 applied to the content being signed, as 556 specified in Section 11.1 of [RFC3852]. 558 SigningTime Attribute 559 The SigningTime attribute MAY be present. If it 560 is present it MUST be ignored by the relying 561 party. The presence of absence of the 562 SigningTime attribute in no way affects the 563 validation of the RTA Trust Anchor Object. The 564 attrType OID for the SigningTime attribute is 565 1.2.840.113549.1.9.5. 567 The attrValues for the SigningTime attribute is 568 defined as: 570 SigningTime ::= Time 572 Time ::= CHOICE { 573 utcTime UTCTime, 574 generalizedTime GeneralizedTime } 576 The Time element specifies the time, based on 577 the local system clock, at which the digital 578 signature was applied to the content. 580 BinarySigningTime Attribute 581 The BinarySigningTime attribute MAY be present. 582 If it is present it MUST be ignored by the 583 relying party. The presence of absence of the 584 BinarySigningTime attribute in no way affects 585 the validation of the RTA Trust Anchor Object. 586 The attrType OID for the SigningTime attribute 587 is 1.2.840.113549.1.9.16.2.46. 589 The attrValues for the SigningTime attribute is 590 defined as: 592 BinarySigningTime ::= BinaryTime 594 BinaryTime ::= INTEGER (0..MAX) 596 The BinaryTime element specifies the time, based 597 on the local system clock, at which the digital 598 signature was applied to the content. 600 signatureAlgorithm 601 The signatureAlgorithm is specified in [ID.sidr-rpki-algs]. 603 signature 604 The signature value is defined as: 606 SignatureValue ::= OCTET STRING 608 The signature characteristics are defined by the digest and 609 signature algorithms. 611 unsignedAttrs 612 unsignedAttrs MUST be omitted. 614 4.2. RPKI Trust Anchor Object Validation 616 Before a relying party can use an RTA Trust Anchor Object, the 617 relying party must first validate the object by performing the 618 following steps. 620 1. Verify that the RTA Trust Anchor Object syntax complies with 621 this specification. In particular, verify the following: 623 a. The contentType of the CMS object is SignedData (OID 624 1.2.840.113549.1.7.2). 626 b. The version of the SignedData object is 3. 628 c. The digestAlgorithm in the SignedData object matches an 629 algorithm specified in [ID.sidr-rpki-algs]. 631 d. The certificates field in the SignedData object is present 632 and contains a single EE certificate whose Subject Key 633 Identifier (SKI) matches the CMS sid field of the 634 SignerInfo object. 636 e. The CMS crls field in the SignedData object is omitted. 638 f. The eContentType in the EncapsulatedContentInfo is id-ct- 639 RPKITrustAnchor (OID 1.2.840.113549.1.9.16.1.33) 641 g. The version of the SignerInfo is 3. 643 h. The digestAlgorithm in the SignerInfo object matches the 644 algorithm specified in [ID.sidr-rpki-algs]. 646 i. The signatureAlgorithm in the SignerInfo object matches 647 the algorithm specified in [ID.sidr-rpki-algs]. 649 j. The signedAttrs field in the SignerInfo object is present 650 and contains both the ContentType attribute (OID 651 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 652 1.2.840.113549.1.9.4). 654 k. The unsignedAttrs field in the SignerInfo object is 655 omitted. 657 2. Use the public key in the EE certificate to verify the 658 signature on the RTA Trust Anchor Object. 660 3. Verify that the ETA EE certificate is a valid end-entity 661 certificate issued directly under ETA, and the ETA's CRL has 662 not revoked this certificate, and that the ETA's CRL is valid. 664 5. Relying Party use of Trust Anchor Material 666 Relying Parties can assemble the putative trust anchor collection by 667 using the ETA certificate for each putative trust anchor: 669 * The ETA's CRL and CMS objects are retrieved from the 670 publication point referenced by the SIA in the ETA certificate. 672 * Extract the EE certificate from the CMS object and verify this 673 certificate using the ETA certificate. 675 * Verify the ETA's CRL (using the ETA certificate) and use this 676 CRL to verify the revocation status of the ETA EE certificate 677 from the CMS object. 679 * Verify the signature on the CMS object using the (already 680 verified) ETA EE certificate from the CMS object. 682 * The relying party can then load the enclosed RPKI TA 683 certificate and use it to validate other RPKI certificates. 685 Relying Parties SHOULD perform this retrieval and validation 686 operation at intervals no less frequent than the nextUpdate time of 687 the published ETA CRL, and SHOULD perform the retrieval operation 688 prior to the expiration of the ETA EE certificate, or upon revocation 689 of the ETA EE certificate. 691 6. Security Considerations 693 The security considerations noted in [RFC4158] are applicable here. 695 7. IANA Considerations 697 [Note to IANA, to be removed prior to publication: There are no IANA 698 considerations stated in this document in terms of IANA registry 699 actions. The document discussed a potential role for the IANA in the 700 operational management of a trust anchor for the public resource 701 RPKI, but does not specifically mandate or recommend that IANA 702 undertake such a role.] 704 8. References 705 8.1. Normative References 707 [ID.sidr-res-certs] 708 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 709 X.509 PKIX Resource Certificates", Work in progress: 710 Internet Drafts draft-ietf-sidr-res-certs-17.txt, 711 September 2009. 713 [ID.sidr-rpki-algs] 714 Huston, G., "A Profile for Algorithms and Key Sizes for 715 use in the Resource Public Key Infrastructure", Work in 716 progress: Internet 717 Drafts draft-ietf-sidr-rpki-algs-00.txt, August 2009. 719 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 720 Addresses and AS Identifiers", RFC 3779, June 2004. 722 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 723 RFC 3852, July 2004. 725 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 726 Housley, R., and W. Polk, "Internet X.509 Public Key 727 Infrastructure Certificate and Certificate Revocation List 728 (CRL) Profile", RFC 5280, May 2008. 730 [X.509] ITU-T, "Recommendation X.509: The Directory - 731 Authentication Framework", 2000. 733 8.2. Informative References 735 [ID.sidr-arch] 736 Lepinski, M. and S. Kent, "An Infrastructure to Support 737 Secure Internet Routing", Work in progress: Internet 738 Drafts draft-ietf-sidr-arch-08.txt, July 2009. 740 [OpenSSL] The OpenSSL Project, "OpenSSL", 2009, 741 . 743 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 744 Nicholas, "Internet X.509 Public Key Infrastructure: 745 Certification Path Building", RFC 4158, September 2005. 747 Authors' Addresses 749 George Michaelson 750 Asia Pacific Network Information Centre 752 Email: ggm@apnic.net 753 URI: http://www.apnic.net 755 Stephen Kent 756 BBN Technologies 757 10 Moulton St. 758 Cambridge, MA 02138 759 USA 761 Email: kent@bbn.com 763 Geoff Huston 764 Asia Pacific Network Information Centre 766 Email: gih@apnic.net 767 URI: http://www.apnic.net