idnits 2.17.1 draft-ietf-sidrops-https-tal-05.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.) 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 (October 11, 2018) is 1996 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 (==), 3 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: April 14, 2019 G. Michaelson 7 APNIC 8 S. Kent 9 Unaffiliated 10 T. Bruijnzeels 11 NLnet Labs 12 October 11, 2018 14 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator 15 draft-ietf-sidrops-https-tal-05 17 Abstract 19 This document defines a Trust Anchor Locator (TAL) for the Resource 20 Public Key Infrastructure (RPKI). This document obsoletes RFC 7730 21 by adding support for HTTPS URIs in a TAL. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 14, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Trust Anchor Locator . . . . . . . . . . . . . . . . . . . . 2 60 2.1. Trust Anchor Locator Format . . . . . . . . . . . . . . . 2 61 2.2. TAL and Trust Anchor Certificate Considerations . . . . . 4 62 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 5 64 4. HTTPS Considerations . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 This document defines a Trust Anchor Locator (TAL) for the Resource 75 Public Key Infrastructure (RPKI) [RFC6480]. This format may be used 76 to distribute trust anchor material using a mix of out-of-band and 77 online means. Procedures used by Relying Parties (RPs) to verify 78 RPKI signed objects SHOULD support this format to facilitate 79 interoperability between creators of trust anchor material and RPs. 80 This document obsoletes [RFC7730] by adding support for HTTPS URIs in 81 a TAL. 83 1.1. Terminology 85 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 86 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 87 document, are to be interpreted as described in [RFC2119]. 89 2. Trust Anchor Locator 91 2.1. Trust Anchor Locator Format 93 This document does not propose a new format for trust anchor 94 material. A trust anchor in the RPKI is represented by a self-signed 95 X.509 Certification Authority (CA) certificate, a format commonly 96 used in PKIs and widely supported by RP software. This document 97 specifies a format for data used to retrieve and verify the 98 authenticity of a trust anchor in a very simple fashion. That data 99 is referred to as the TAL. 101 The motivation for defining the TAL is to enable selected data in the 102 trust anchor to change, without needing to effect redistribution of 103 the trust anchor per se. In the RPKI, certificates contain 104 extensions that represent Internet Number Resources (INRs) [RFC3779]. 105 The set of INRs associated with an entity acting as a trust anchor is 106 likely to change over time. Thus, if one were to use the common PKI 107 convention of distributing a trust anchor to RPs in a secure fashion, 108 then this procedure would need to be repeated whenever the INR set 109 for the entity acting as a trust anchor changed. By distributing the 110 TAL (in a secure fashion), instead of distributing the trust anchor, 111 this problem is avoided, i.e., the TAL is constant so long as the 112 trust anchor's public key and its location do not change. 114 The TAL is analogous to the TrustAnchorInfo data structure specified 115 in [RFC5914], which is on the Standards Track. That specification 116 could be used to represent the TAL, if one defined an rsync or HTTPS 117 URI extension for that data structure. However, the TAL format was 118 adopted by RPKI implementors prior to the PKIX trust anchor work, and 119 the RPKI implementer community has elected to utilize the TAL format, 120 rather than define the requisite extension. The community also 121 prefers the simplicity of the ASCII encoding of the TAL, versus the 122 binary (ASN.1) encoding for TrustAnchorInfo. 124 The TAL is an ordered sequence of: 126 1. an optional comment section consisting of one or more lines 127 starting with the '#' character, containing human readable 128 informational ASCII text, followed by an empty line using a 129 "" or "" line break only. 131 2. a URI section, 133 3. a "" or "" line break, 135 4. a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded 136 in Base64 (see Section 4 of [RFC4648]). To avoid long lines, 137 "" or "" line breaks MAY be inserted into the 138 Base64-encoded string. 140 where the URI section is comprised or one of more of the ordered 141 sequence of: 143 2.1. either an rsync URI [RFC5781], or an HTTPS URI [RFC7230] 144 2.2. a "" or "" line break. 146 2.2. TAL and Trust Anchor Certificate Considerations 148 Each URI in the TAL MUST reference a single object. It MUST NOT 149 reference a directory or any other form of collection of objects. 151 The referenced object MUST be a self-signed CA certificate that 152 conforms to the RPKI certificate profile [RFC6487]. This certificate 153 is the trust anchor in certification path discovery [RFC4158] and 154 validation [RFC5280] [RFC3779]. 156 The validity interval of this trust anchor SHOULD reflect the 157 anticipated period of stability of the particular set of INRs that 158 are associated with the putative trust anchor. 160 The INR extension(s) of this trust anchor MUST contain a non-empty 161 set of number resources. It MUST NOT use the "inherit" form of the 162 INR extension(s). The INR set described in this certificate is the 163 set of number resources for which the issuing entity is offering 164 itself as a putative trust anchor in the RPKI [RFC6480]. 166 The public key used to verify the trust anchor MUST be the same as 167 the subjectPublicKeyInfo in the CA certificate and in the TAL. 169 The trust anchor MUST contain a stable key. This key MUST NOT change 170 when the certificate is reissued due to changes in the INR 171 extension(s), when the certificate is renewed prior to expiration, or 172 for any reason other than a key change. 174 Because the public key in the TAL and the trust anchor MUST be 175 stable, this motivates operation of that CA in an offline mode. 176 Thus, the entity that issues the trust anchor SHOULD issue a 177 subordinate CA certificate that contains the same INRs (via the use 178 of the "inherit" option in the INR extensions of the subordinate 179 certificate). This allows the entity that issues the trust anchor to 180 keep the corresponding private key of this certificate offline, while 181 issuing all relevant child certificates under the immediate 182 subordinate CA. This measure also allows the Certificate Revocation 183 List (CRL) issued by that entity to be used to revoke the subordinate 184 CA certificate in the event of suspected key compromise of this 185 online operational key pair that is potentially more vulnerable. 187 The trust anchor MUST be published at a stable URI. When the trust 188 anchor is reissued for any reason, the replacement CA certificate 189 MUST be accessible using the same URI. 191 Because the trust anchor is a self-signed certificate, there is no 192 corresponding CRL that can be used to revoke it, nor is there a 193 manifest [RFC6486] that lists this certificate. 195 If an entity wishes to withdraw a self-signed CA certificate as a 196 putative trust anchor, for any reason, including key rollover, the 197 entity MUST remove the object from the location referenced in the 198 TAL. 200 Where the TAL contains two or more URIs, then the same self- signed 201 CA certificate MUST be found at each referenced location. In order 202 to increase operational resilience, it is RECOMMENDED that the domain 203 name parts of each of these URIs resolve to distinct IP addresses 204 that are used by a diverse set of repository publication points, and 205 these IP addresses be included in distinct Route Origin 206 Authorizations (ROAs) objects signed by different CAs. 208 2.3. Example 210 # This TAL is intended for documentation purposes only. 211 # Do not attempt to use this in a production setting. 213 rsync://rpki.example.org/rpki/hedgehog/root.cer 214 https://rpki.example.org/rpki/hedgehog/root.cer 216 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx 217 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 218 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 219 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa 220 BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG 221 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 222 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB 224 3. Relying Party Use 226 In order to use the TAL to retrieve and validate a (putative) trust 227 anchor, an RP SHOULD: 229 1. Retrieve the object referenced by (one of) the URI(s) contained 230 in the TAL. 232 2. Confirm that the retrieved object is a current, self-signed RPKI 233 CA certificate that conforms to the profile as specified in 234 [RFC6487]. 236 3. Confirm that the public key in the TAL matches the public key in 237 the retrieved object. 239 4. Perform other checks, as deemed appropriate (locally), to ensure 240 that the RP is willing to accept the entity publishing this self- 241 signed CA certificate to be a trust anchor. These tests apply to 242 the validity of attestations made in the context of the RPKI 243 relating to all resources described in the INR extension of this 244 certificate. 246 An RP SHOULD perform these functions for each instance of TAL that it 247 is holding for this purpose every time the RP performs a 248 resynchronization across the local repository cache. In any case, an 249 RP also SHOULD perform these functions prior to the expiration of the 250 locally cached copy of the retrieved trust anchor referenced by the 251 TAL. 253 In the case where a TAL contains multiple URIs, an RP MAY use a 254 locally defined preference rule to select the URI to retrieve the 255 self-signed RPKI CA certificate that is to be used as a trust anchor. 256 Some examples are: 258 o Using the order provided in the TAL 260 o Selecting the URI randomly from the available list 262 o Creating a prioritized list of URIs based on RP-specific 263 parameters, such as connection establishment delay 265 If the connection to the preferred URI fails, or the retrieved CA 266 certificate public key does not match the TAL public key, the RP 267 SHOULD retrieve the CA certificate from the next URI, according to 268 the local preference ranking of URIs. 270 4. HTTPS Considerations 272 Note that a Man in the Middle (MITM) cannot produce a CA certificate 273 that would be considered valid according to the process described in 274 Section 3. However, a MITM attack can be performed to prevent the 275 Relying Party from learning about an updated CA certificate. Because 276 of this, Relying Parties SHOULD do TLS certificate and host name 277 validation when they fetch a CA certificate using an HTTPS URI on a 278 TAL. 280 Relying Party tools SHOULD log any TLS certificate or host name 281 validation issues found, so that an operator can investigate the 282 cause. However, such validation issues are often due to 283 configuration errors or a lack of a common TLS trust anchor. In 284 these cases, it is better if the Relying Party retrieves the CA 285 certificate regardless and performs validation on it. Therefore, the 286 Relying Party MUST continue to retrieve the data in case of errors. 288 It is RECOMMENDED that Relying Parties and Repository Servers follow 289 the Best Current Practices outlined in [RFC7525] on the use of HTTP 290 over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS 291 certificate and host name validation using subjectAltName dNSName 292 identities as described in [RFC6125]. The rules and guidelines 293 defined in [RFC6125] apply here, with the following considerations: 295 o Relying Parties and Repository Servers SHOULD support the DNS-ID 296 identifier type. The DNS-ID identifier type SHOULD be present in 297 Repository Server certificates. 299 o DNS names in Repository Server certificates SHOULD NOT contain the 300 wildcard character "*". 302 o A Common Name (CN) field may be present in a Repository Server 303 certificate's subject name but SHOULD NOT be used for 304 authentication within the rules described in [RFC6125]. 306 o This protocol does not require the use of SRV-IDs. 308 o This protocol does not require the use of URI-IDs. 310 Note, however, that this validation is done on a best-effort basis 311 and serves to highlight potential issues, but CA certificate 312 validation in relation to a TAL as described in Section 3 does not 313 depend on this. Therefore, Relying Parties MAY deviate from the 314 validation steps listed above. 316 5. Security Considerations 318 Compromise of a trust anchor private key permits unauthorized parties 319 to masquerade as a trust anchor, with potentially severe 320 consequences. Reliance on an inappropriate or incorrect trust anchor 321 has similar potentially severe consequences. 323 This TAL does not directly provide a list of resources covered by the 324 referenced self-signed CA certificate. Instead, the RP is referred 325 to the trust anchor itself and the INR extension(s) within this 326 certificate. This provides necessary operational flexibility, but it 327 also allows the certificate issuer to claim to be authoritative for 328 any resource. Relying parties should either have great confidence in 329 the issuers of such certificates that they are configuring as trust 330 anchors, or they should issue their own self-signed certificate as a 331 trust anchor and, in doing so, impose constraints on the subordinate 332 certificates. 334 6. Acknowledgements 336 This approach to trust anchor material was originally described by 337 Robert Kisteleki. 339 The authors acknowledge the contributions of Rob Austein and Randy 340 Bush, who assisted with drafting this document and with helpful 341 review comments. 343 The authors acknowledge with work of Roque Gagliano, Terry Manderson, 344 and Carlos Martinez Cagnazzo in developing the ideas behind the 345 inclusion of multiple URIs in the TAL. 347 7. References 349 7.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, 354 . 356 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 357 Addresses and AS Identifiers", RFC 3779, 358 DOI 10.17487/RFC3779, June 2004, 359 . 361 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 362 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 363 . 365 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 366 Housley, R., and W. Polk, "Internet X.509 Public Key 367 Infrastructure Certificate and Certificate Revocation List 368 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 369 . 371 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 372 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 373 . 375 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 376 Verification of Domain-Based Application Service Identity 377 within Internet Public Key Infrastructure Using X.509 378 (PKIX) Certificates in the Context of Transport Layer 379 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 380 2011, . 382 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 383 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 384 February 2012, . 386 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 387 X.509 PKIX Resource Certificates", RFC 6487, 388 DOI 10.17487/RFC6487, February 2012, 389 . 391 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 392 Protocol (HTTP/1.1): Message Syntax and Routing", 393 RFC 7230, DOI 10.17487/RFC7230, June 2014, 394 . 396 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 397 "Recommendations for Secure Use of Transport Layer 398 Security (TLS) and Datagram Transport Layer Security 399 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 400 2015, . 402 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 403 "Resource Public Key Infrastructure (RPKI) Trust Anchor 404 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 405 . 407 [X.509] TU-T Recommendation X.509, "The Directory: Public-key and 408 attribute certificate frameworks", October 2012. 410 7.2. Informative References 412 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 413 Nicholas, "Internet X.509 Public Key Infrastructure: 414 Certification Path Building", RFC 4158, 415 DOI 10.17487/RFC4158, September 2005, 416 . 418 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 419 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 420 . 422 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 423 "Manifests for the Resource Public Key Infrastructure 424 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 425 . 427 Authors' Addresses 429 Geoff Huston 430 APNIC 432 Email: gih@apnic.net 433 URI: https://www.apnic.net 435 Samuel Weiler 436 W3C/MIT 438 Email: weiler@csail.mit.edu 440 George Michaelson 441 APNIC 443 Email: ggm@apnic.net 444 URI: https://www.apnic.net 446 Stephen Kent 447 Unaffiliated 449 Email: kent@alum.mit.edu 451 Tim Bruijnzeels 452 NLnet Labs 454 Email: tim@nlnetlabs.nl 455 URI: https://www.nlnetlabs.nl