idnits 2.17.1 draft-ietf-sidrops-https-tal-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC7730, but the abstract doesn't seem to directly say this. It does mention RFC7730 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 23, 2019) is 1918 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5781 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Informational RFC: RFC 6480 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7730 (Obsoleted by RFC 8630) -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Huston 3 Internet-Draft APNIC 4 Obsoletes: 7730 (if approved) S. Weiler 5 Intended status: Standards Track W3C/MIT 6 Expires: July 27, 2019 G. Michaelson 7 APNIC 8 S. Kent 9 Unaffiliated 10 T. Bruijnzeels 11 NLnet Labs 12 January 23, 2019 14 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator 15 draft-ietf-sidrops-https-tal-06 17 Abstract 19 This document defines a Trust Anchor Locator (TAL) for the Resource 20 Public Key Infrastructure (RPKI). TALs allow Relying Parties in the 21 RPKI to download the current Trust Anchor (TA) CA certificate from 22 one or more locations, and verify that the key of this self-signed 23 certificate matches the key on the TAL. Thus, Relying Parties can be 24 configured with TA keys, but allow these TAs to change the content of 25 their CA certificate. In particular it allows TAs to change the set 26 of Internet Number Resources included in the RFC3779 extension of 27 their certificate. 29 This document obsoletes the previous definition of Trust Anchor 30 Locators in RFC 7730 by adding support for HTTPS URIs. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 27, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Trust Anchor Locator . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Trust Anchor Locator Motivation . . . . . . . . . . . . . 3 70 2.2. Trust Anchor Locator File Format . . . . . . . . . . . . 3 71 2.3. TAL and Trust Anchor Certificate Considerations . . . . . 4 72 2.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 6 74 4. HTTPS Considerations . . . . . . . . . . . . . . . . . . . . 7 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 7.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 This document defines a Trust Anchor Locator (TAL) for the Resource 85 Public Key Infrastructure (RPKI) [RFC6480]. This format may be used 86 to distribute trust anchor material using a mix of out-of-band and 87 online means. Procedures used by Relying Parties (RPs) to verify 88 RPKI signed objects SHOULD support this format to facilitate 89 interoperability between creators of trust anchor material and RPs. 90 This document obsoletes [RFC7730] by adding support for HTTPS URIs in 91 a TAL. 93 1.1. Terminology 95 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 96 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 97 document, are to be interpreted as described in [RFC2119]. 99 2. Trust Anchor Locator 101 2.1. Trust Anchor Locator Motivation 103 This document does not propose a new format for trust anchor 104 material. A trust anchor in the RPKI is represented by a self-signed 105 X.509 Certification Authority (CA) certificate, a format commonly 106 used in PKIs and widely supported by RP software. This document 107 specifies a format for data used to retrieve and verify the 108 authenticity of a trust anchor in a very simple fashion. That data 109 is referred to as the TAL. 111 The motivation for defining the TAL is to enable selected data in the 112 trust anchor to change, without needing to effect redistribution of 113 the trust anchor per se. In the RPKI, certificates contain 114 extensions that represent Internet Number Resources (INRs) [RFC3779]. 115 The set of INRs associated with an entity acting as a trust anchor is 116 likely to change over time. Thus, if one were to use the common PKI 117 convention of distributing a trust anchor to RPs in a secure fashion, 118 then this procedure would need to be repeated whenever the INR set 119 for the entity acting as a trust anchor changed. By distributing the 120 TAL (in a secure fashion), instead of distributing the trust anchor, 121 this problem is avoided, i.e., the TAL is constant so long as the 122 trust anchor's public key and its location do not change. 124 The TAL is analogous to the TrustAnchorInfo data structure specified 125 in [RFC5914], which is on the Standards Track. That specification 126 could be used to represent the TAL, if one defined an rsync or HTTPS 127 URI extension for that data structure. However, the TAL format was 128 adopted by RPKI implementors prior to the PKIX trust anchor work, and 129 the RPKI implementer community has elected to utilize the TAL format, 130 rather than define the requisite extension. The community also 131 prefers the simplicity of the ASCII encoding of the TAL, versus the 132 binary (ASN.1) encoding for TrustAnchorInfo. 134 2.2. Trust Anchor Locator File Format 136 In this document we define a Trust Anchor URI as a URI that can be 137 used to retrieved a current Trust Anchor certificate. This URI MUST 138 be either an rsync URI [RFC5781], or an HTTPS URI [RFC7230]. 140 The TAL is an ordered sequence of: 142 1. an optional comment section consisting of one or more lines each 143 starting with the '#' character, followed by human readable 144 informational UTF-8 text, and ending with a line break, 146 2. a URI section, that is comprised of one or more ordered lines, 147 each containing a Trust Anchor URI, and ending with a line break, 149 3. a line break, 151 4. a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded 152 in Base64 (see Section 4 of [RFC4648]). To avoid long lines, 153 line breaks MAY be inserted into the Base64-encoded string. 155 Note that line breaks in this file can use either "" or "". 157 2.3. TAL and Trust Anchor Certificate Considerations 159 Each Trust Anchor URI in the TAL MUST reference a single object. It 160 MUST NOT reference a directory or any other form of collection of 161 objects. 163 The referenced object MUST be a self-signed CA certificate that 164 conforms to the RPKI certificate profile [RFC6487]. This certificate 165 is the trust anchor in certification path discovery [RFC4158] and 166 validation [RFC5280] [RFC3779]. 168 The validity interval of this trust anchor SHOULD reflect the 169 anticipated period of stability of the particular set of INRs that 170 are associated with the putative trust anchor. 172 The INR extension(s) of this trust anchor MUST contain a non-empty 173 set of number resources. It MUST NOT use the "inherit" form of the 174 INR extension(s). The INR set described in this certificate is the 175 set of number resources for which the issuing entity is offering 176 itself as a putative trust anchor in the RPKI [RFC6480]. 178 The public key used to verify the trust anchor MUST be the same as 179 the subjectPublicKeyInfo in the CA certificate and in the TAL. 181 The trust anchor MUST contain a stable key. This key MUST NOT change 182 when the certificate is reissued due to changes in the INR 183 extension(s), when the certificate is renewed prior to expiration, or 184 for any reason other than a key change. 186 Because the public key in the TAL and the trust anchor MUST be 187 stable, this motivates operation of that CA in an offline mode. 188 Thus, the entity that issues the trust anchor SHOULD issue a 189 subordinate CA certificate that contains the same INRs (via the use 190 of the "inherit" option in the INR extensions of the subordinate 191 certificate). This allows the entity that issues the trust anchor to 192 keep the corresponding private key of this certificate offline, while 193 issuing all relevant child certificates under the immediate 194 subordinate CA. This measure also allows the Certificate Revocation 195 List (CRL) issued by that entity to be used to revoke the subordinate 196 CA certificate in the event of suspected key compromise of this 197 online operational key pair that is potentially more vulnerable. 199 The trust anchor MUST be published at a stable URI. When the trust 200 anchor is reissued for any reason, the replacement CA certificate 201 MUST be accessible using the same URI. 203 Because the trust anchor is a self-signed certificate, there is no 204 corresponding CRL that can be used to revoke it, nor is there a 205 manifest [RFC6486] that lists this certificate. 207 If an entity wishes to withdraw a self-signed CA certificate as a 208 putative trust anchor, for any reason, including key rollover, the 209 entity MUST remove the object from the location referenced in the 210 TAL. 212 Where the TAL contains two or more Trust Anchor URIs, then the same 213 self-signed CA certificate MUST be found at each referenced location. 214 In order to increase operational resilience, it is RECOMMENDED that 215 the domain name parts of each of these URIs resolve to distinct IP 216 addresses that are used by a diverse set of repository publication 217 points, and these IP addresses be included in distinct Route Origin 218 Authorizations (ROAs) objects signed by different CAs. 220 2.4. Example 222 # This TAL is intended for documentation purposes only. 223 # Do not attempt to use this in a production setting. 224 rsync://rpki.example.org/rpki/hedgehog/root.cer 225 https://rpki.example.org/rpki/hedgehog/root.cer 227 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx 228 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 229 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 230 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa 231 BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG 232 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 233 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB 235 3. Relying Party Use 237 In order to use the TAL to retrieve and validate a (putative) trust 238 anchor, an RP SHOULD: 240 1. Retrieve the object referenced by (one of) the Trust Anchor 241 URI(s) contained in the TAL. 243 2. Confirm that the retrieved object is a current, self-signed RPKI 244 CA certificate that conforms to the profile as specified in 245 [RFC6487]. 247 3. Confirm that the public key in the TAL matches the public key in 248 the retrieved object. 250 4. Perform other checks, as deemed appropriate (locally), to ensure 251 that the RP is willing to accept the entity publishing this self- 252 signed CA certificate to be a trust anchor. These tests apply to 253 the validity of attestations made in the context of the RPKI 254 relating to all resources described in the INR extension of this 255 certificate. 257 An RP SHOULD perform these functions for each instance of TAL that it 258 is holding for this purpose every time the RP performs a 259 resynchronization across the local repository cache. In any case, an 260 RP also SHOULD perform these functions prior to the expiration of the 261 locally cached copy of the retrieved trust anchor referenced by the 262 TAL. 264 In the case where a TAL contains multiple Trust Anchor URIs, an RP 265 MAY use a locally defined preference rule to select the URI to 266 retrieve the self-signed RPKI CA certificate that is to be used as a 267 trust anchor. Some examples are: 269 o Using the order provided in the TAL 271 o Selecting the Trust Anchor URI randomly from the available list 273 o Creating a prioritized list of URIs based on RP-specific 274 parameters, such as connection establishment delay 276 If the connection to the preferred URI fails, or the retrieved CA 277 certificate public key does not match the TAL public key, the RP 278 SHOULD retrieve the CA certificate from the next URI, according to 279 the local preference ranking of URIs. 281 4. HTTPS Considerations 283 Note that a Man in the Middle (MITM) cannot produce a CA certificate 284 that would be considered valid according to the process described in 285 Section 3. However, a MITM attack can be performed to prevent the 286 Relying Party from learning about an updated CA certificate. Because 287 of this, Relying Parties MUST do TLS certificate and host name 288 validation when they fetch a CA certificate using an HTTPS URI on a 289 TAL. 291 Relying Party tools SHOULD log any TLS certificate or host name 292 validation issues found, so that an operator can investigate the 293 cause. 295 It is RECOMMENDED that Relying Parties and Repository Servers follow 296 the Best Current Practices outlined in [RFC7525] on the use of HTTP 297 over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS 298 certificate and host name validation using subjectAltName dNSName 299 identities as described in [RFC6125]. The rules and guidelines 300 defined in [RFC6125] apply here, with the following considerations: 302 o Relying Parties and Repository Servers SHOULD support the DNS-ID 303 identifier type. The DNS-ID identifier type SHOULD be present in 304 Repository Server certificates. 306 o DNS names in Repository Server certificates SHOULD NOT contain the 307 wildcard character "*". 309 o A Common Name (CN) field may be present in a Repository Server 310 certificate's subject name but SHOULD NOT be used for 311 authentication within the rules described in [RFC6125]. 313 o This protocol does not require the use of SRV-IDs. 315 o This protocol does not require the use of URI-IDs. 317 5. Security Considerations 319 Compromise of a trust anchor private key permits unauthorized parties 320 to masquerade as a trust anchor, with potentially severe 321 consequences. Reliance on an inappropriate or incorrect trust anchor 322 has similar potentially severe consequences. 324 This TAL does not directly provide a list of resources covered by the 325 referenced self-signed CA certificate. Instead, the RP is referred 326 to the trust anchor itself and the INR extension(s) within this 327 certificate. This provides necessary operational flexibility, but it 328 also allows the certificate issuer to claim to be authoritative for 329 any resource. Relying parties should either have great confidence in 330 the issuers of such certificates that they are configuring as trust 331 anchors, or they should issue their own self-signed certificate as a 332 trust anchor and, in doing so, impose constraints on the subordinate 333 certificates. 335 6. Acknowledgements 337 This approach to trust anchor material was originally described by 338 Robert Kisteleki. 340 The authors acknowledge the contributions of Rob Austein and Randy 341 Bush, who assisted with drafting this document and with helpful 342 review comments. 344 The authors acknowledge work of Roque Gagliano, Terry Manderson, and 345 Carlos Martinez Cagnazzo in developing the ideas behind the inclusion 346 of multiple URIs in the TAL. 348 The authors acknowledge Job Snijders for suggesting the inclusion of 349 comments at the start of the TAL. 351 7. References 353 7.1. Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 361 Addresses and AS Identifiers", RFC 3779, 362 DOI 10.17487/RFC3779, June 2004, 363 . 365 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 366 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 367 . 369 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 370 Housley, R., and W. Polk, "Internet X.509 Public Key 371 Infrastructure Certificate and Certificate Revocation List 372 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 373 . 375 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 376 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 377 . 379 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 380 Verification of Domain-Based Application Service Identity 381 within Internet Public Key Infrastructure Using X.509 382 (PKIX) Certificates in the Context of Transport Layer 383 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 384 2011, . 386 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 387 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 388 February 2012, . 390 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 391 X.509 PKIX Resource Certificates", RFC 6487, 392 DOI 10.17487/RFC6487, February 2012, 393 . 395 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 396 Protocol (HTTP/1.1): Message Syntax and Routing", 397 RFC 7230, DOI 10.17487/RFC7230, June 2014, 398 . 400 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 401 "Recommendations for Secure Use of Transport Layer 402 Security (TLS) and Datagram Transport Layer Security 403 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 404 2015, . 406 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 407 "Resource Public Key Infrastructure (RPKI) Trust Anchor 408 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 409 . 411 [X.509] TU-T Recommendation X.509, "The Directory: Public-key and 412 attribute certificate frameworks", October 2012. 414 7.2. Informative References 416 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 417 Nicholas, "Internet X.509 Public Key Infrastructure: 418 Certification Path Building", RFC 4158, 419 DOI 10.17487/RFC4158, September 2005, 420 . 422 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 423 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 424 . 426 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 427 "Manifests for the Resource Public Key Infrastructure 428 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 429 . 431 Authors' Addresses 433 Geoff Huston 434 APNIC 436 Email: gih@apnic.net 437 URI: https://www.apnic.net 439 Samuel Weiler 440 W3C/MIT 442 Email: weiler@csail.mit.edu 444 George Michaelson 445 APNIC 447 Email: ggm@apnic.net 448 URI: https://www.apnic.net 450 Stephen Kent 451 Unaffiliated 453 Email: kent@alum.mit.edu 455 Tim Bruijnzeels 456 NLnet Labs 458 Email: tim@nlnetlabs.nl 459 URI: https://www.nlnetlabs.nl