idnits 2.17.1 draft-ietf-sidr-ta-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (May 12, 2010) is 5098 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 496 -- Looks like a reference, but probably isn't: '1' on line 483 -- Looks like a reference, but probably isn't: '2' on line 462 == 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: 1 error (**), 0 flaws (~~), 4 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: November 13, 2010 BBN 6 G. Huston 7 APNIC 8 May 12, 2010 10 A Profile for Trust Anchor Material for the Resource Certificate PKI 11 draft-ietf-sidr-ta-04 13 Abstract 15 This document defines a standard profile for the publication of Trust 16 Anchor material for the Resource Certificate Public Key 17 Infrastructure. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 13, 2010. 36 Copyright Notice 38 Copyright (c) 2010 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. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Trust Anchors for Resource Certificates . . . . . . . . . . . 4 56 2.1. A Compound Trust Anchor Structure . . . . . . . . . . . . 5 57 3. Publication of Trust Anchor Material . . . . . . . . . . . . . 7 58 4. Cryptographic Message Syntax Profile for RPKI Trust Anchor 59 Material . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 4.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 9 61 4.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 10 62 4.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 11 63 4.2. RPKI Trust Anchor Object Validation . . . . . . . . . . . 14 64 5. Relying Party use of Trust Anchor Material . . . . . . . . . . 15 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 72 1. Introduction 74 This document defines a standard profile for the publication of Trust 75 Anchor (TA) material for the Resource Certificate Public Key 76 Infrastructure [ID.sidr-arch]. The format may be used to distribute 77 trust anchor material using a mix of out-of-band and online means. 78 Procedures used by relying parties (RPs) to verify RPKI signed 79 objects SHOULD support this format to facilitate interoperability 80 between creators of TA material and RPs. 82 In the context of the public Internet, and the use of public number 83 resources within this context, it is intended that Resource 84 Certificates are used in a manner that is explicitly aligned with the 85 public number resource distribution function. This corresponds to a 86 hierarchical PKI structure, as described in section 1.5.1 of 87 [RFC4158], where there is a unique certification path between a 88 certification authority operating at an apex of a resource 89 distribution hierarchy and any RPKI certificate. 91 Validation of a Resource Certificate in a PKI is effected by 92 establishing a validated certificate chain from a certificate issued 93 by a trust anchor certification authority to the certificate being 94 validated [RFC4158]. Because Resource Certificates contain [RFC3779] 95 IP number resource extensions, certificate validation requires that 96 each subject's resources are fully encompassed by those of the issuer 97 at each step in the certificate chain. Certificate path validation 98 in this context corresponds to validation of an associated set of 99 assignment or allocation actions of IP number resources. 101 The constraints imposed by the RFC 3779 extensions are applied to the 102 entire certificate chain, starting with a TA. Thus it is potentially 103 difficult for a relying party to manage trust anchors locally in a 104 fashion that incorporates certificates by well known entities in the 105 RPKI and accommodates certificates that describe private IPv4 address 106 space, private use AS numbers, and IPv6 ULA prefixes. To address 107 this problem, this document defines a compound TA model, in which the 108 one portion of the TA is not an RPKI certificate, and thus need not 109 meet the requirements imposed by RFC 3779. 111 This document describes a data structure for representing Trust 112 Anchors for use in the RPKI. The structure is designed to enable 113 Relying Parties (RPs) to acquire RPKI trust anchors in a fashion that 114 preserves the resource subset constraints imposed by the use of RFC 115 3779 extensions. 117 1.1. Terminology 119 It is assumed that the reader is familiar with the terms and concepts 120 described in "An Infrastructure to Support Secure Internet Routing" 121 [ID.sidr-arch], "Internet X.509 Public Key Infrastructure Certificate 122 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 123 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 124 "Internet X.509 Public Key Infrastructure: Certification Path 125 Building" [RFC4158], and . 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119. 131 2. Trust Anchors for Resource Certificates 133 This document does not nominate to RPs any organization or 134 organizations as recommended trust anchors for the RPKI. The data 135 structures and procedures described here are capable of accommodating 136 a variety of trust anchor arrangements, and potentially involving 137 various forms of off-line and on-line two-tier models for trust 138 anchor management. The common constraint imposed by the RPKI is that 139 a RP can verify that that a verifiable path exists between any RPKI 140 certificate and a chosen TA [ID.sidr-res-certs]. 142 It is common to represent a trust anchor as a long-lived, self-signed 143 certificate, although PKI standards (e.g., [RFC5280]) do not mandate 144 this representation. A TA is long-lived because it is usually 145 delivered out-of-band and thus verifying the integrity and 146 authenticity of a TA is "expensive". The self-signed certificate 147 format is commonly employed because it is readily processed by 148 software that is prepared to process certificates, e.g., OpenSSL 149 [OpenSSL],. The self-signed certificate also provides a basic level 150 of consistency checking, as a self-signed certificate cannot be 151 modified in an undetectabe manner by anyone other than the holder of 152 the private key corresponding to the public key in the certificate. 154 A resource certificate held by an RIR or a LIR that describes all the 155 resources that are administered by that entity 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, making such certificates poor candidates as trust 160 anchors, since such changes violate the notion of the TA certificate 161 as 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 compound trust anchor model can support operational arrangements 173 of the form of an offline CA for the self-signed TA and an online 174 subordinate CA. 176 2.1. A Compound Trust Anchor Structure 178 The first part of a structured trust anchor in the RPKI is a self- 179 signed CA certificate that contains no resource extensions. It 180 conforms to the certificate profile as defined in 181 [ID.sidr-res-certs], except for the omission of IP Resource and AS 182 Resource extensions. This CA certificate is referred to here as an 183 "external TA" (certificate), or ETA. The ETA issues a CRL and one EE 184 certificate. The CRL conforms to the [ID.sidr-res-certs] profile. 185 The EE certificate also conforms to the [ID.sidr-res-certs] profile, 186 except for the omission of IP Resource and AS Resource extensions. 187 This certificate will be referred to as a "ETA EE" (certificate). 189 The second part of a structured trust anchor in the RPKI is a self- 190 signed RPKI CA certificate that includes RFC 3779 extensions. This 191 certificate will function as a TA for purposes of processing resource 192 certificates, i.e., the certificate path will terminate at this 193 certificate. This certificate is referred to here as an "RPKI TA" 194 (certificate) or an RTA. 196 There are no required relationships between the (Subject/Issuer) 197 names used in the ETA certificates and RPKI TA certificate, but the 198 (public) keys used in the two certificates SHOULD be different. 200 Because both of these certificates are self-signed, it is not 201 possible to verify the RPKI TA certificate directly from the ETA 202 certificate. Instead, the two TAs are related by the use of a CMS 203 object [RFC3852]. The RPKI TA certificate is encapsulated in a CMS 204 structure that is signed by the private key associated with the ETA 205 EE certificate. Section 4 describes this CMS structure in detail, 206 profiling the CMS signed-object format, and provides the algorithm 207 that MUST be employed to validate this object and extract the RTA for 208 use in validating RPKI certificate chains. 210 The structure of the trust anchor material is shown in the following 211 diagram. 213 +------------------------------+ 214 | ETA CA Certificate | 215 | | 216 | Issuer: | 217 | Subject: | 218 | SIA: -------------------|-+ 219 +------------------------------+ | 220 | Signed: ETA (self-signed) | | 221 +------------------------------+ | 222 V 223 +---------------------------------------------------------+ 224 | ETA Repository Publication Point | 225 |+--------------------------------+ +--------------+| 226 || CMS Signed Object |<-+ +->|ETA CRL || 227 ||--------------------------------| | | | || 228 || CMS Attributes and Signer Info | | | | Issuer: || 229 || | | | | || 230 ||+------------------------------+| | | +--------------+| 231 ||| ETA EE Certificate || | | | Signed: ETA || 232 ||| || | | +--------------+| 233 ||| Issuer: || | | | 234 ||| Subject: || | | | 235 ||| SIA: -------------------||--+ | | 236 ||| CRL: -------------------||----+ | 237 ||+------------------------------+| | 238 ||| Signed: ETA || | 239 ||+------------------------------+| | 240 ||--------------------------------| | 241 || CMS Signed Data | | 242 || | | 243 ||+------------------------------+| | 244 ||| RTA CA Certificate || | 245 ||| || | 246 ||| Issuer: || | 247 ||| Subject: || | 248 ||| CRL: -------------------||-------------------------> 249 ||| SIA: -------------------||-------------------------> 250 ||| IP: || | 251 ||| AS: || | 252 ||+------------------------------+| | 253 ||| Signed: RPKI TA (self-signed)|| | 254 ||+------------------------------+| | 255 |+--------------------------------+ | 256 +---------------------------------------------------------+ 258 3. Publication of Trust Anchor Material 260 The RPKI architecture [ID.sidr-arch] calls for certificates to be 261 issued by the entities that allocate Internet number resources 262 (addresses and AS numbers). This suggests that the structure of 263 certificates in the RPKI that relate to the use of public number 264 resources in a public context should reflect the hierarchy used to 265 allocate these resources. This document does not mandate nor 266 recommend a specific set of default TAs. 268 In any PKI an important principle is that entities issuing 269 certificates are authoritative for the information in the 270 certificates they issue. In the context of the RPKI, this means that 271 an organization represented by an RTA SHOULD be authoritative for the 272 resources enumerated in its (self-signed) certificate. Any deviation 273 from this principle creates opportunities for accidental (or 274 malicious) misrepresentation. 276 It will be necessary for an RP to establish RTAs in ways that deviate 277 from this principle in order to represent private-use address space, 278 locally-scoped address space, and private-use AS numbers. However, 279 this is a "safe" RTA management practice because it affects only 280 those RPs that choose to configure their local TA store in this 281 fashion. It does not "endanger" other RPs who are not a participant 282 in such locally scoped environments. 284 An ETA certificate that is not managed on an entirely local basis, 285 where the TA issuer and the RP are essentially the same entity, is 286 presumed to be long-lived as it will likely be distributed with 287 relying party validation software, or via a similar out-of-band 288 means. 290 An entity offering itself as a putative trust anchor in the context 291 of the RPKI is required to regularly publish an RPKI TA certificate 292 at a stable URL, and to publish at this URL its CRL and the CMS- 293 signed object that contains its RTA. The recommended operational 294 maintenance procedures for publication of this material are as 295 follows: 297 * The entity issues an RTA CA certificate. This certificate MUST 298 be reissued periodically, prior to its expiration, and MUST be 299 reissued upon any change in the resource set that has been 300 allocated to the entity operating this RPKI TA. The validity 301 interval of this certificate SHOULD reflect the anticipated 302 period of changes to the entity's resource set. 304 * The entity issues an ETA certificate. This certificate 305 contains no RFC 3779 extension. The validity period of this 306 certificate should be very long, as is the conventional 307 practice for trust anchor material. The SIA of this 308 certificate references a publication point where the CRL and 309 the CMS object (defined in Section 4) are published. To avoid 310 ambiguity, the published ETA CA certificate, the current ETA 311 CRL, and CMS objects SHOULD be the only objects published at 312 this location, and the file extension ".crl" SHOULD be used for 313 the CRL object, and the file extension ".rta" be used for the 314 CMS object that contains the RTA CA certificate as its payload. 316 * The ETA issues an ETA EE certificate with a validity period 317 identical to the validity period of the RTA certificate. This 318 ETA EE certificate MUST have the digitalSignature bit set, and 319 this MUST be the only bit set to TRUE in the key usage 320 extension. There is no BasicConstraints extension in this 321 certificate (since it is an EE certificate). 323 * The ETA regularly issues a CRL. The CRL issuance cycle SHOULD 324 be shorter than the validity period for the RTA CA certificate. 326 * Each time an RTA CA certificate is re-issued, or prior to the 327 expiration of the ETA EE certificate, the ETA generates a 328 Cryptographic Message Syntax (CMS) [RFC3852] signed-data 329 object, the payload of which is an RTA CA certificate. The 330 object is CMS-signed with the private key corresponding to the 331 ETA EE certificate. The ETA EE certificate MUST be included as 332 a CMS signed attribute in the CMS object. The ETA certificate 333 and the associated CRL MUST NOT be included in the CMS object. 334 The format of the CMS object is specified in Section 4. The 335 CMS object is published at the location referenced in the SIA 336 of the ETA certificate. 338 * The entity publicly distributes its ETA in an out-of-band 339 fashion, e.g., as part of widely-distributed relying party 340 software, or by passing the ETA to a relying party in person. 342 If a trust anchor publisher chooses to reissue its RTA CA certificate 343 before the expiration of that certificate, potentially becuase of a 344 change in the number resource set described in the RTA CA 345 certificate, or due to a key rollover operation concerning the the 346 key pair used to self-sign the RTA certficate, or other reasons, the 347 trust anchor publisher MUST perform the follow actions: 349 * generate the new RTA CA certificate, 350 * revise the nextUpdate time of the ETA's CRL to reflect the 351 issue date for the new ETA EE certificate, 353 * issue a new ETA EE certificate and a new CMS object with the 354 new RTA CA certificate as the CMS payload, and 356 * revoke the old ETA EE certificate at the nextUpdate time in the 357 next issued CRL. This revocation will provide an indication to 358 relying parties to perform the retrieve the RTA CA certificate 359 at a time earlier than the normal update cycle time. 361 The procedures relating to management of the keys used by the RTA CA 362 SHOULD be described in the RTA CA's Certification Practice Statement. 363 The RTA CA MAY perform a staged key rollover and publish multiple RTA 364 CMS objects to reflect a staging of current and new keys at the ETA 365 CA's repository publication point. 367 4. Cryptographic Message Syntax Profile for RPKI Trust Anchor Material 369 Using the Cryptographic Message Syntax (CMS) [RFC3852], a RPKI Trust 370 Anchor Object is a type of signed-data object. The general format of 371 a CMS object is: 373 ContentInfo ::= SEQUENCE { 374 contentType ContentType, 375 content [0] EXPLICIT ANY DEFINED BY contentType } 377 ContentType ::= OBJECT IDENTIFIER 379 As an RTA Trust Anchor Object is a signed-data object, it uses the 380 corresponding OID, 1.2.840.113549.1.7.2. [RFC3852]. 382 4.1. Signed-Data ContentType 384 According to the CMS specification, the signed-data content type 385 shall have ASN.1 type SignedData: 387 SignedData ::= SEQUENCE { 388 version CMSVersion, 389 digestAlgorithms DigestAlgorithmIdentifiers, 390 encapContentInfo EncapsulatedContentInfo, 391 certificates [0] IMPLICIT CertificateSet OPTIONAL, 392 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 393 signerInfos SignerInfos } 395 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 396 SignerInfos ::= SET OF SignerInfo 398 The elements of the signed-data content type are as follows: 400 version 401 The version is the syntax version number. It MUST be 3, 402 corresponding to the signerInfo structure having version 403 number 3. 405 digestAlgorithms 406 The digestAlgorithms set is specified in 407 [ID.sidr-rpki-algs]. 409 encapContentInfo 410 This element is defined in Section 4.1.1. 412 certificates 413 The certificates element MUST be included and MUST contain 414 only the single PKI EE certificate needed to validate this 415 CMS Object. The CertificateSet type is defined in section 416 10 of [RFC3852] 418 crls 419 The crls element MUST be omitted. 421 signerInfos 422 This element is defined in Section 4.1.2. 424 4.1.1. encapContentInfo 426 encapContentInfo is the signed content, consisting of a content type 427 identifier and the content itself. 429 EncapsulatedContentInfo ::= SEQUENCE { 430 eContentType ContentType, 431 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 433 ContentType ::= OBJECT IDENTIFIER 435 The elements of this signed content type are as follows: 437 eContentType 438 The ContentType for an RTA Trust Anchor Object is defined as 439 id-ct-RPKITrustAnchor and has the numerical value of 440 1.2.840.113549.1.9.16.1.33. 442 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 443 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 445 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 447 id-ct-RPKITrustAnchor OBJECT IDENTIFIER ::= { id-ct 33 } 449 eContent 450 The content of an RTA Trust Anchor Object is an RPKI self- 451 signed CA certificate. It is formally defined using the 452 Trust Anchor list format described in [ID.pkix-ta-format] 453 as: 455 id-ct-RPKITrustAnchor ::= TrustAnchorList 457 TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice 459 TrustAnchorChoice ::= CHOICE { 460 certificate Certificate, 461 tbsCert [1] EXPLICIT TBSCertificate, 462 taInfo [2] EXPLICIT TrustAnchorInfo } 464 trust-anchor-list PKCS7-CONTENT-TYPE ::= 465 { TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList } 467 In the case of the RPKITrustAnchor, the TrustAnchorList is 468 defined as a sequence containing a single element that uses 469 the Certificate option. The definition of Certificate is 470 taken from [X.509]. 472 4.1.2. signerInfos 474 SignerInfo is defined under CMS as: 476 SignerInfo ::= SEQUENCE { 477 version CMSVersion, 478 sid SignerIdentifier, 479 digestAlgorithm DigestAlgorithmIdentifier, 480 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 481 signatureAlgorithm SignatureAlgorithmIdentifier, 482 signature SignatureValue, 483 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 485 The content of the SignerInfo element are as follows: 487 version 488 The version number MUST be 3, corresponding with the choice 489 of SubjectKeyIdentifier for the sid. 491 sid 492 The sid is defined as: 494 SignerIdentifier ::= CHOICE { 495 issuerAndSerialNumber IssuerAndSerialNumber, 496 subjectKeyIdentifier [0] SubjectKeyIdentifier } 498 For a RTA Trust Anchor Object, the sid MUST be a 499 SubjectKeyIdentifier. 501 digestAlgorithm 502 The digestAlgorithm is specified in [ID.sidr-rpki-algs]. 504 signedAttrs 505 The signedAttrs element is defined as: 507 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 509 Attribute ::= SEQUENCE { 510 attrType OBJECT IDENTIFIER, 511 attrValues SET OF AttributeValue } 513 AttributeValue ::= ANY 515 The signedAttr element MUST be present and MUST include the 516 content-type and message-digest attributes. The signer MAY 517 also include the signing-time signed attribute, the binary- 518 signing-time signed attribute, or both signed attributes. 519 Other signed attributes that are deemed appropriate MAY also 520 be included. The intent is to allow additional signed 521 attributes to be included if a future need is identified. 522 This does not cause an interoperability concern because 523 unrecognized signed attributes are ignored by the relying 524 party. 526 The signedAttr MUST include only a single instance of any 527 particular attribute, and for each Attribute there MUST only 528 be one AttributeValue. 529 The defined signedAttr attributes are: 531 ContentType Attribute 532 The ContentType attribute MUST be present. The 533 attrType OID for the ContentType attribute is 534 1.2.840.113549.1.9.3. 536 The attrValues for the ContentType attribute in 537 a RTA Trust Anchor Object MUST be 538 1.2.840.113549.1.9.16.1.33 (matching the 539 eContentType in the EncapsulatedContentInfo). 541 MessageDigest Attribute 542 The MessageDigest attribute MUST be present. 543 The attrType OID for the MessageDigest Attribute 544 is 1.2.840.113549.1.9.4. 546 The attrValues for the MessageDigest attribute 547 contains the output of the digest algorithm 548 applied to the content being signed, as 549 specified in Section 11.1 of [RFC3852]. 551 SigningTime Attribute 552 The SigningTime attribute MAY be present. If it 553 is present it MUST be ignored by the relying 554 party. The presence of absence of the 555 SigningTime attribute in no way affects the 556 validation of the RTA Trust Anchor Object. The 557 attrType OID for the SigningTime attribute is 558 1.2.840.113549.1.9.5. 560 The attrValues for the SigningTime attribute is 561 defined as: 563 SigningTime ::= Time 565 Time ::= CHOICE { 566 utcTime UTCTime, 567 generalizedTime GeneralizedTime } 569 The Time element specifies the time, based on 570 the local system clock, at which the digital 571 signature was applied to the content. 573 BinarySigningTime Attribute 574 The BinarySigningTime attribute MAY be present. 575 If it is present it MUST be ignored by the 576 relying party. The presence of absence of the 577 BinarySigningTime attribute in no way affects 578 the validation of the RTA Trust Anchor Object. 579 The attrType OID for the SigningTime attribute 580 is 1.2.840.113549.1.9.16.2.46. 582 The attrValues for the SigningTime attribute is 583 defined as: 585 BinarySigningTime ::= BinaryTime 587 BinaryTime ::= INTEGER (0..MAX) 589 The BinaryTime element specifies the time, based 590 on the local system clock, at which the digital 591 signature was applied to the content. 593 signatureAlgorithm 594 The signatureAlgorithm is specified in [ID.sidr-rpki-algs]. 596 signature 597 The signature value is defined as: 599 SignatureValue ::= OCTET STRING 601 The signature characteristics are defined by the digest and 602 signature algorithms. 604 unsignedAttrs 605 unsignedAttrs MUST be omitted. 607 4.2. RPKI Trust Anchor Object Validation 609 Before a relying party can use an RTA Trust Anchor Object, the 610 relying party must first validate the object by performing the 611 following steps. 613 1. Verify that the RTA Trust Anchor Object syntax complies with 614 this specification. In particular, verify the following: 616 a. The contentType of the CMS object is SignedData (OID 617 1.2.840.113549.1.7.2). 619 b. The version of the SignedData object is 3. 621 c. The digestAlgorithm in the SignedData object matches an 622 algorithm specified in [ID.sidr-rpki-algs]. 624 d. The certificates field in the SignedData object is present 625 and contains a single EE certificate whose Subject Key 626 Identifier (SKI) matches the CMS sid field of the 627 SignerInfo object. 629 e. The CMS crls field in the SignedData object is omitted. 631 f. The eContentType in the EncapsulatedContentInfo is id-ct- 632 RPKITrustAnchor (OID 1.2.840.113549.1.9.16.1.33) 634 g. The version of the SignerInfo is 3. 636 h. The digestAlgorithm in the SignerInfo object matches the 637 algorithm specified in [ID.sidr-rpki-algs]. 639 i. The signatureAlgorithm in the SignerInfo object matches 640 the algorithm specified in [ID.sidr-rpki-algs]. 642 j. The signedAttrs field in the SignerInfo object is present 643 and contains both the ContentType attribute (OID 644 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 645 1.2.840.113549.1.9.4). 647 k. The unsignedAttrs field in the SignerInfo object is 648 omitted. 650 2. Use the public key in the EE certificate to verify the 651 signature on the RTA Trust Anchor Object. 653 3. Verify that the ETA EE certificate is a valid end-entity 654 certificate issued directly under ETA, and the ETA's CRL has 655 not revoked this certificate, and that the ETA's CRL is valid. 657 5. Relying Party use of Trust Anchor Material 659 Relying Parties can assemble the putative trust anchor collection by 660 using the ETA certificate for each putative trust anchor: 662 * The ETA's CRL and CMS objects are retrieved from the 663 publication point referenced by the SIA in the ETA certificate. 665 * Extract the EE certificate from the CMS object and verify this 666 certificate using the ETA certificate. 668 * Verify the ETA's CRL (using the ETA certificate) and use this 669 CRL to verify the revocation status of the ETA EE certificate 670 from the CMS object. 672 * Verify the signature on the CMS object using the (already 673 verified) ETA EE certificate from the CMS object. 675 * The relying party can then load the enclosed RPKI TA 676 certificate, and verify the format of the RPKI TA certificate 677 and that the current time lies within the validity time 678 interval specified by the RPKI TA certificate. 680 * The RPKI TA certificate may be configured by the RP as a local 681 trust anchor for use in validation of other RPKI certificates. 683 Relying Parties SHOULD perform this retrieval and validation 684 operation at intervals no less frequent than the nextUpdate time of 685 the published ETA CRL, and SHOULD perform the retrieval operation 686 prior to the expiration of the ETA EE certificate, or upon revocation 687 of the ETA EE certificate. 689 If these verification tests performed on the ETA CA cert or the ETA 690 EE cert fail (such as, for example, in the case where the ETA CA cert 691 has expired, or where the only available ETA EE cert has been 692 revoked) then the Relying Party cannot assume that the RPKI TA that 693 has been "packaged" using this ETA framework is valid. 695 6. Security Considerations 697 The security considerations noted in [RFC4158] are applicable here. 699 7. IANA Considerations 701 [Note to IANA, to be removed prior to publication: There are no IANA 702 considerations stated in this document in terms of IANA registry 703 actions.] 705 8. References 707 8.1. Normative References 709 [ID.pkix-ta-format] 710 Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 711 Format", Work in progress: Internet 712 Drafts draft-ietf-pkix-ta-format-04.txt, October 2009. 714 [ID.sidr-res-certs] 715 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 716 X.509 PKIX Resource Certificates", Work in progress: 717 Internet Drafts draft-ietf-sidr-res-certs-17.txt, 718 September 2009. 720 [ID.sidr-rpki-algs] 721 Huston, G., "A Profile for Algorithms and Key Sizes for 722 use in the Resource Public Key Infrastructure", Work in 723 progress: Internet 724 Drafts draft-ietf-sidr-rpki-algs-00.txt, August 2009. 726 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 727 Addresses and AS Identifiers", RFC 3779, June 2004. 729 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 730 RFC 3852, July 2004. 732 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 733 Housley, R., and W. Polk, "Internet X.509 Public Key 734 Infrastructure Certificate and Certificate Revocation List 735 (CRL) Profile", RFC 5280, May 2008. 737 [X.509] ITU-T, "Recommendation X.509: The Directory - 738 Authentication Framework", 2000. 740 8.2. Informative References 742 [ID.sidr-arch] 743 Lepinski, M. and S. Kent, "An Infrastructure to Support 744 Secure Internet Routing", Work in progress: Internet 745 Drafts draft-ietf-sidr-arch-08.txt, July 2009. 747 [OpenSSL] The OpenSSL Project, "OpenSSL", 2009, 748 . 750 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 751 Nicholas, "Internet X.509 Public Key Infrastructure: 752 Certification Path Building", RFC 4158, September 2005. 754 Authors' Addresses 756 George Michaelson 757 Asia Pacific Network Information Centre 759 Email: ggm@apnic.net 760 URI: http://www.apnic.net 762 Stephen Kent 763 BBN Technologies 764 10 Moulton St. 765 Cambridge, MA 02138 766 USA 768 Email: kent@bbn.com 770 Geoff Huston 771 Asia Pacific Network Information Centre 773 Email: gih@apnic.net 774 URI: http://www.apnic.net