idnits 2.17.1 draft-ietf-sidr-ta-01.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 14, 2009) is 5338 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 504 -- Looks like a reference, but probably isn't: '1' on line 491 == 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 18, 2010 BBN 6 G. Huston 7 APNIC 8 September 14, 2009 10 A Profile for Trust Anchor Material for the Resource Certificate PKI 11 draft-ietf-sidr-ta-01 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 18, 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 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 | CRL: -------------------|-------------------+ 254 | SIA: -------------------|-+ | 255 +------------------------------+ | | 256 | Signed: ETA (self-signed) | | | 257 +------------------------------+ | | 258 V | 259 +--------------------------------------------------|------+ 260 | ETA Repository Publication Point V | 261 |+--------------------------------+ +--------------+| 262 || CMS Signed Object |<-+ +->|ETA CRL || 263 ||--------------------------------| | | | || 264 || CMS Attributes and Signer Info | | | | Issuer: || 265 || | | | | || 266 ||+------------------------------+| | | +--------------+| 267 ||| ETA EE Certificate || | | | Signed: ETA || 268 ||| || | | +--------------+| 269 ||| Issuer: || | | | 270 ||| Subject: || | | | 271 ||| SIA: -------------------||--+ | | 272 ||| CRL: -------------------||----+ | 273 ||+------------------------------+| | 274 ||| Signed: ETA || | 275 ||+------------------------------+| | 276 ||--------------------------------| | 277 || CMS Signed Data | | 278 || | | 279 ||+------------------------------+| | 280 ||| RTA CA Certificate || | 281 ||| || | 282 ||| Issuer: || | 283 ||| Subject: || | 284 ||| CRL: -------------------||-------------------------> 285 ||| SIA: -------------------||-------------------------> 286 ||| IP: || | 287 ||| AS: || | 288 ||+------------------------------+| | 289 ||| Signed: RPKI TA (self-signed)|| | 290 ||+------------------------------+| | 291 |+--------------------------------+ | 292 +---------------------------------------------------------+ 294 3. Publication of Trust Anchor Material 296 The RPKI architecture [ID.sidr-arch] calls for certificates to be 297 issued by the entities that allocate Internet number resources 298 (addresses and AS numbers). This suggests that the structure of 299 certificates in the RPKI that relate to the use of public number 300 resources is a public context should reflect the hierarchy used to 301 allocate these resources. This document does not mandate nor even 302 recommend a specific set of default TAs, but it does observe that, 303 for most RPs, the IANA is in a unique role as the default TA for 304 representing public address space and public AS numbers. 306 In any PKI an important principle is that entities issuing 307 certificates are authoritative for the information in the 308 certificates they issue. In the context of the RPKI, this means that 309 an organization represented by an RTA SHOULD be authoritative for the 310 resources enumerated in its (self-signed) certificate. Any deviation 311 from this principle creates opportunities for accidental (or 312 malicious) misrepresentation. 314 It will be necessary for an RP to establish RTAs in ways that deviate 315 from this principle in order to represent private-use address space, 316 locally-scoped address space, and private-use AS numbers. However, 317 this is a "safe" RTA management practice because it affects only 318 those RPs that choose to configure their local TA store in this 319 fashion. It does not "endanger" other RPs who are not a participant 320 in such locally scoped environments. 322 An ETA certificate that is not managed on an entirely local basis, 323 where the TA issuer and the RP are essentially the same entity, is 324 presumed to be long-lived as it will likely be distributed with 325 relying party validation software, or via a similar out-of-band 326 means. 328 An entity offering itself as a putative trust anchor in the context 329 of the RPKI is required to regularly publish an RPKI TA certificate 330 at a stable URL, and to publish at this URL its CRL and the CMS- 331 signed object that contains its RTA. The recommended operational 332 maintenance procedures for publication of this material are as 333 follows: 335 * The entity issues an RTA certificate. This certificate MUST be 336 reissued periodically, prior to its expiration, and MUST be 337 reissued upon any change in the resource set that has been 338 allocated to the entity operating this RPKI TA. The validity 339 interval of this certificate SHOULD reflect the anticipated 340 period of changes to the entity's resource set. 342 * The entity issues an ETA certificate. This certificate 343 contains no RFC 3779 extension. The validity period of this 344 certificate should be very long, as is the conventional 345 practice for trust anchor material. The SIA of this 346 certificate references a publication point where the CRL and 347 the CMS object (defined in Section 4) are published. 349 * The ETA issues an ETA EE certificate with a validity period 350 identical to the validity period of the RTA certificate. This 351 ETA EE certificate MUST have the digitalSignature bit set, and 352 this MUST be the only bit set to TRUE in the key usage 353 extension. There is no BasicConstraints extension in this 354 certificate (since it is an EE certificate). 356 * The ETA regularly issues a CRL. The CRL issuance cycle SHOULD 357 be shorter than the validity period for the RTA certificate. 359 * Each time an RTA certificate is re-issued, or prior to the 360 expiration of the ETA EE certificate, the ETA generates a 361 Cryptographic Message Syntax (CMS) [RFC3852] signed-data 362 object, the payload of which is an RTA certificate. The object 363 is CMS-signed with the private key corresponding to the ETA EE 364 certificate. The ETA EE certificate MUST be included as a CMS 365 signed attribute in the CMS object. The ETA certificate and 366 the associated CRL MUST NOT be included in the CMS object. The 367 format of the CMS object is specified in Section 4. The CMS 368 object is published at the location referenced in the SIA of 369 the ETA certificate. 371 * The entity publicly distributes its ETA in an out-of-band 372 fashion, e.g., as part of widely-distributed relying party 373 software, or by passing the ETA to a relying party in person. 375 If a trust anchor chooses to reissue its RTA certificate before the 376 expiration of that certificate, it MUST perform the follow actions: 378 * revise the nextUpdate time of the ETA's CRL to reflect the 379 issue date for the new ETA EE certificate, 381 * issue a new ETA EE certificate and a new CMS object with the 382 new RTA CA certificate, and 384 * revoke the old ETA EE certificate at the nextUpdate time in the 385 next issued CRL. This revocation will provide an indication to 386 relying parties to perform the retrieve the RTA CA certificate 387 at a time earlier than the normal update cycle time. 389 4. Cryptographic Message Syntax Profile for RPKI Trust Anchor Material 391 Using the Cryptographic Message Syntax (CMS) [RFC3852], a RPKI Trust 392 Anchor Object is a type of signed-data object. The general format of 393 a CMS object is: 395 ContentInfo ::= SEQUENCE { 396 contentType ContentType, 397 content [0] EXPLICIT ANY DEFINED BY contentType } 399 ContentType ::= OBJECT IDENTIFIER 401 As an RTA Trust Anchor Object is a signed-data object, it uses the 402 corresponding OID, 1.2.840.113549.1.7.2. [RFC3852]. 404 4.1. Signed-Data ContentType 406 According to the CMS specification, the signed-data content type 407 shall have ASN.1 type SignedData: 409 SignedData ::= SEQUENCE { 410 version CMSVersion, 411 digestAlgorithms DigestAlgorithmIdentifiers, 412 encapContentInfo EncapsulatedContentInfo, 413 certificates [0] IMPLICIT CertificateSet OPTIONAL, 414 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 415 signerInfos SignerInfos } 417 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 419 SignerInfos ::= SET OF SignerInfo 421 The elements of the signed-data content type are as follows: 423 version 424 The version is the syntax version number. It MUST be 3, 425 corresponding to the signerInfo structure having version 426 number 3. 428 digestAlgorithms 429 The digestAlgorithms set is specified in 430 [ID.sidr-rpki-algs]. 432 encapContentInfo 433 This element is defined in Section 4.1.1. 435 certificates 436 The certificates element MUST be included and MUST contain 437 only the single PKI EE certificate needed to validate this 438 CMS Object. The CertificateSet type is defined in section 439 10 of [RFC3852] 441 crls 442 The crls element MUST be omitted. 444 signerInfos 445 This element is defined in Section 4.1.2. 447 4.1.1. encapContentInfo 449 encapContentInfo is the signed content, consisting of a content type 450 identifier and the content itself. 452 EncapsulatedContentInfo ::= SEQUENCE { 453 eContentType ContentType, 454 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 456 ContentType ::= OBJECT IDENTIFIER 458 The elements of this signed content type are as follows: 460 eContentType 461 The ContentType for an RTA Trust Anchor Object is defined as 462 id-ct-RPKITrustAnchor and has the numerical value of 463 1.2.840.113549.1.9.16.1.33. 465 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 466 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 468 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 470 id-ct-RPKITrustAnchor OBJECT IDENTIFIER ::= { id-ct 33 } 472 eContent 473 The content of an RTA Trust Anchor Object is an RPKI self- 474 signed CA certificate.It is formally defined as: 476 id-ct-RPKITrustAnchor ::= Certificate 478 The definition of Certificate is taken from [X.509]. 480 4.1.2. signerInfos 482 SignerInfo is defined under CMS as: 484 SignerInfo ::= SEQUENCE { 485 version CMSVersion, 486 sid SignerIdentifier, 487 digestAlgorithm DigestAlgorithmIdentifier, 488 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 489 signatureAlgorithm SignatureAlgorithmIdentifier, 490 signature SignatureValue, 491 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 493 The content of the SignerInfo element are as follows: 495 version 496 The version number MUST be 3, corresponding with the choice 497 of SubjectKeyIdentifier for the sid. 499 sid 500 The sid is defined as: 502 SignerIdentifier ::= CHOICE { 503 issuerAndSerialNumber IssuerAndSerialNumber, 504 subjectKeyIdentifier [0] SubjectKeyIdentifier } 506 For a RTA Trust Anchor Object, the sid MUST be a 507 SubjectKeyIdentifier. 509 digestAlgorithm 510 The digestAlgorithm is specified in [ID.sidr-rpki-algs]. 512 signedAttrs 513 The signedAttrs element is defined as: 515 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 517 Attribute ::= SEQUENCE { 518 attrType OBJECT IDENTIFIER, 519 attrValues SET OF AttributeValue } 521 AttributeValue ::= ANY 523 The signedAttr element MUST be present and MUST include the 524 content-type and message-digest attributes. The signer MAY 525 also include the signing-time signed attribute, the binary- 526 signing-time signed attribute, or both signed attributes. 527 Other signed attributes that are deemed appropriate MAY also 528 be included. The intent is to allow additional signed 529 attributes to be included if a future need is identified. 530 This does not cause an interoperability concern because 531 unrecognized signed attributes are ignored by the relying 532 party. 534 The signedAttr MUST include only a single instance of any 535 particular attribute, and for each Attribute there MUST only 536 be one AttributeValue. 537 The defined signedAttr attributes are: 539 ContentType Attribute 540 The ContentType attribute MUST be present. The 541 attrType OID for the ContentType attribute is 542 1.2.840.113549.1.9.3. 544 The attrValues for the ContentType attribute in 545 a RTA Trust Anchor Object MUST be 546 1.2.840.113549.1.9.16.1.24 (matching the 547 eContentType in the EncapsulatedContentInfo). 549 MessageDigest Attribute 550 The MessageDigest attribute MUST be present. 551 The attrType OID for the MessageDigest Attribute 552 is 1.2.840.113549.1.9.4. 554 The attrValues for the MessageDigest attribute 555 contains the output of the digest algorithm 556 applied to the content being signed, as 557 specified in Section 11.1 of [RFC3852]. 559 SigningTime Attribute 560 The SigningTime attribute MAY be present. If it 561 is present it MUST be ignored by the relying 562 party. The presence of absence of the 563 SigningTime attribute in no way affects the 564 validation of the RTA Trust Anchor Object. The 565 attrType OID for the SigningTime attribute is 566 1.2.840.113549.1.9.5. 568 The attrValues for the SigningTime attribute is 569 defined as: 571 SigningTime ::= Time 573 Time ::= CHOICE { 574 utcTime UTCTime, 575 generalizedTime GeneralizedTime } 577 The Time element specifies the time, based on 578 the local system clock, at which the digital 579 signature was applied to the content. 581 BinarySigningTime Attribute 582 The BinarySigningTime attribute MAY be present. 583 If it is present it MUST be ignored by the 584 relying party. The presence of absence of the 585 BinarySigningTime attribute in no way affects 586 the validation of the RTA Trust Anchor Object. 587 The attrType OID for the SigningTime attribute 588 is 1.2.840.113549.1.9.16.2.46. 590 The attrValues for the SigningTime attribute is 591 defined as: 593 BinarySigningTime ::= BinaryTime 595 BinaryTime ::= INTEGER (0..MAX) 597 The BinaryTime element specifies the time, based 598 on the local system clock, at which the digital 599 signature was applied to the content. 601 signatureAlgorithm 602 The signatureAlgorithm is specified in [ID.sidr-rpki-algs]. 604 signature 605 The signature value is defined as: 607 SignatureValue ::= OCTET STRING 609 The signature characteristics are defined by the digest and 610 signature algorithms. 612 unsignedAttrs 613 unsignedAttrs MUST be omitted. 615 4.2. RPKI Trust Anchor Object Validation 617 Before a relying party can use an RTA Trust Anchor Object, the 618 relying party must first validate the object by performing the 619 following steps. 621 1. Verify that the RTA Trust Anchor Object syntax complies with 622 this specification. In particular, verify the following: 624 a. The contentType of the CMS object is SignedData (OID 625 1.2.840.113549.1.7.2). 627 b. The version of the SignedData object is 3. 629 c. The digestAlgorithm in the SignedData object matches an 630 algorithm specified in [ID.sidr-rpki-algs]. 632 d. The certificates field in the SignedData object is present 633 and contains a single EE certificate whose Subject Key 634 Identifier (SKI) matches the CMS sid field of the 635 SignerInfo object. 637 e. The CMS crls field in the SignedData object is omitted. 639 f. The eContentType in the EncapsulatedContentInfo is id-ct- 640 RPKITrustAnchor (OID 1.2.840.113549.1.9.16.1.33) 642 g. The version of the SignerInfo is 3. 644 h. The digestAlgorithm in the SignerInfo object matches the 645 algorithm specified in [ID.sidr-rpki-algs]. 647 i. The signatureAlgorithm in the SignerInfo object matches 648 the algorithm specified in [ID.sidr-rpki-algs]. 650 j. The signedAttrs field in the SignerInfo object is present 651 and contains both the ContentType attribute (OID 652 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 653 1.2.840.113549.1.9.4). 655 k. The unsignedAttrs field in the SignerInfo object is 656 omitted. 658 2. Use the public key in the EE certificate to verify the 659 signature on the RTA Trust Anchor Object. 661 3. Verify that the ETA EE certificate is a valid end-entity 662 certificate issued directly under ETA, and the ETA's CRL has 663 not revoked this certificate, and that the ETA's CRL is valid. 665 5. Relying Party use of Trust Anchor Material 667 Relying Parties can assemble the putative trust anchor collection by 668 using the ETA certificate for each putative trust anchor: 670 * The ETA's CRL and CMS objects are retrieved from the 671 publication point referenced by the SIA in the ETA certificate. 673 * Extract the EE certificate from the CMS object and verify this 674 certificate using the ETA certificate. 676 * Verify the ETA's CRL (using the ETA certificate) and use this 677 CRL to verify the revocation status of the ETA EE certificate 678 from the CMS object. 680 * Verify the signature on the CMS object using the (already 681 verified) ETA EE certificate from the CMS object. 683 * The relying party can then load the enclosed RPKI TA 684 certificate and use it to validate other RPKI certificates. 686 Relying Parties SHOULD perform this retrieval and validation 687 operation at intervals no less frequent than the nextUpdate time of 688 the published ETA CRL, and SHOULD perform the retrieval operation 689 prior to the expiration of the ETA EE certificate, or upon revocation 690 of the ETA EE certificate. 692 6. Security Considerations 694 The security considerations noted in [RFC4158] are applicable here. 696 7. IANA Considerations 698 [Note to IANA, to be removed prior to publication: There are no IANA 699 considerations stated in this document in terms of IANA registry 700 actions. The document discussed a potential role for the IANA in the 701 operational management of a trust anchor for the public resource 702 RPKI, but does not specifically mandate or recommend that IANA 703 undertake such a role.] 705 8. References 706 8.1. Normative References 708 [ID.sidr-res-certs] 709 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 710 X.509 PKIX Resource Certificates", Work in progress: 711 Internet Drafts draft-ietf-sidr-res-certs-17.txt, 712 September 2009. 714 [ID.sidr-rpki-algs] 715 Huston, G., "A Profile for Algorithms and Key Sizes for 716 use in the Resource Public Key Infrastructure", Work in 717 progress: Internet 718 Drafts draft-ietf-sidr-rpki-algs-00.txt, August 2009. 720 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 721 Addresses and AS Identifiers", RFC 3779, June 2004. 723 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 724 RFC 3852, July 2004. 726 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 727 Housley, R., and W. Polk, "Internet X.509 Public Key 728 Infrastructure Certificate and Certificate Revocation List 729 (CRL) Profile", RFC 5280, May 2008. 731 [X.509] ITU-T, "Recommendation X.509: The Directory - 732 Authentication Framework", 2000. 734 8.2. Informative References 736 [ID.sidr-arch] 737 Lepinski, M. and S. Kent, "An Infrastructure to Support 738 Secure Internet Routing", Work in progress: Internet 739 Drafts draft-ietf-sidr-arch-08.txt, July 2009. 741 [OpenSSL] The OpenSSL Project, "OpenSSL", 2009, 742 . 744 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 745 Nicholas, "Internet X.509 Public Key Infrastructure: 746 Certification Path Building", RFC 4158, September 2005. 748 Authors' Addresses 750 George Michaelson 751 Asia Pacific Network Information Centre 753 Email: ggm@apnic.net 754 URI: http://www.apnic.net 756 Stephen Kent 757 BBN Technologies 758 10 Moulton St. 759 Cambridge, MA 02138 760 USA 762 Email: kent@bbn.com 764 Geoff Huston 765 Asia Pacific Network Information Centre 767 Email: gih@apnic.net 768 URI: http://www.apnic.net