idnits 2.17.1 draft-ietf-sidrops-https-tal-03.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 (June 8, 2018) is 2143 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) ** 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 (==), 2 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: December 10, 2018 G. Michaelson 7 APNIC 8 S. Kent 9 Unaffiliated 10 T. Bruijnzeels 11 NLnet Labs 12 June 8, 2018 14 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator 15 draft-ietf-sidrops-https-tal-03 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 December 10, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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. a URI section, 128 2. a "" or "" line break, 130 3. a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded 131 in Base64 (see Section 4 of [RFC4648]). To avoid long lines, 132 "" or "" line breaks MAY be inserted into the 133 Base64-encoded string. 135 where the URI section is comprised of one of more of the ordered 136 sequence of: 138 1.1. an rsync URI [RFC5781], or an HTTPS URI [RFC7230] 140 1.2. a "" or "" line break. 142 2.2. TAL and Trust Anchor Certificate Considerations 144 Each URI in the TAL MUST reference a single object. It MUST NOT 145 reference a directory or any other form of collection of objects. 147 The referenced object MUST be a self-signed CA certificate that 148 conforms to the RPKI certificate profile [RFC6487]. This certificate 149 is the trust anchor in certification path discovery [RFC4158] and 150 validation [RFC5280] [RFC3779]. 152 The validity interval of this trust anchor SHOULD reflect the 153 anticipated period of stability of the particular set of INRs that 154 are associated with the putative trust anchor. 156 The INR extension(s) of this trust anchor MUST contain a non-empty 157 set of number resources. It MUST NOT use the "inherit" form of the 158 INR extension(s). The INR set described in this certificate is the 159 set of number resources for which the issuing entity is offering 160 itself as a putative trust anchor in the RPKI [RFC6480]. 162 The public key used to verify the trust anchor MUST be the same as 163 the subjectPublicKeyInfo in the CA certificate and in the TAL. 165 The trust anchor MUST contain a stable key. This key MUST NOT change 166 when the certificate is reissued due to changes in the INR 167 extension(s), when the certificate is renewed prior to expiration, or 168 for any reason other than a key change. 170 Because the public key in the TAL and the trust anchor MUST be 171 stable, this motivates operation of that CA in an offline mode. 172 Thus, the entity that issues the trust anchor SHOULD issue a 173 subordinate CA certificate that contains the same INRs (via the use 174 of the "inherit" option in the INR extensions of the subordinate 175 certificate). This allows the entity that issues the trust anchor to 176 keep the corresponding private key of this certificate offline, while 177 issuing all relevant child certificates under the immediate 178 subordinate CA. This measure also allows the Certificate Revocation 179 List (CRL) issued by that entity to be used to revoke the subordinate 180 CA certificate in the event of suspected key compromise of this 181 online operational key pair that is potentially more vulnerable. 183 The trust anchor MUST be published at a stable URI. When the trust 184 anchor is reissued for any reason, the replacement CA certificate 185 MUST be accessible using the same URI. 187 Because the trust anchor is a self-signed certificate, there is no 188 corresponding CRL that can be used to revoke it, nor is there a 189 manifest [RFC6486] that lists this certificate. 191 If an entity wishes to withdraw a self-signed CA certificate as a 192 putative trust anchor, for any reason, including key rollover, the 193 entity MUST remove the object from the location referenced in the 194 TAL. 196 Where the TAL contains two or more URIs, then the same self- signed 197 CA certificate MUST be found at each referenced location. In order 198 to increase operational resilience, it is RECOMMENDED that the domain 199 name parts of each of these URIs resolve to distinct IP addresses 200 that are used by a diverse set of repository publication points, and 201 these IP addresses be included in distinct Route Origin 202 Authorizations (ROAs) objects signed by different CAs. 204 2.3. Example 206 rsync://rpki.example.org/rpki/hedgehog/root.cer 207 https://rpki.example.org/rpki/hedgehog/root.cer 209 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx 210 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 211 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 212 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa 213 BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG 214 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 215 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB 217 3. Relying Party Use 219 In order to use the TAL to retrieve and validate a (putative) trust 220 anchor, an RP SHOULD: 222 1. Retrieve the object referenced by (one of) the URI(s) contained 223 in the TAL. 225 2. Confirm that the retrieved object is a current, self-signed RPKI 226 CA certificate that conforms to the profile as specified in 227 [RFC6487]. 229 3. Confirm that the public key in the TAL matches the public key in 230 the retrieved object. 232 4. Perform other checks, as deemed appropriate (locally), to ensure 233 that the RP is willing to accept the entity publishing this self- 234 signed CA certificate to be a trust anchor. These tests apply to 235 the validity of attestations made in the context of the RPKI 236 relating to all resources described in the INR extension of this 237 certificate. 239 An RP SHOULD perform these functions for each instance of TAL that it 240 is holding for this purpose every time the RP performs a 241 resynchronization across the local repository cache. In any case, an 242 RP also SHOULD perform these functions prior to the expiration of the 243 locally cached copy of the retrieved trust anchor referenced by the 244 TAL. 246 In the case where a TAL contains multiple URIs, an RP MAY use a 247 locally defined preference rule to select the URI to retrieve the 248 self-signed RPKI CA certificate that is to be used as a trust anchor. 249 Some examples are: 251 o Using the order provided in the TAL 253 o Selecting the URI randomly from the available list 255 o Creating a prioritized list of URIs based on RP-specific 256 parameters, such as connection establishment delay 258 If the connection to the preferred URI fails, or the retrieved CA 259 certificate public key does not match the TAL public key, the RP 260 SHOULD retrieve the CA certificate from the next URI, according to 261 the local preference ranking of URIs. 263 4. HTTPS Considerations 265 Note that a Man in the Middle (MITM) cannot produce a CA certificate 266 that would be considered valid according to the process described in 267 Section 3. However, a MITM can perform withhold or replay attacks 268 targeting a Relying Party and keep the Relying Party from learning 269 about an update CA certificate. Because of this, Relying Parties 270 SHOULD do TLS certificate and host name validation when they fetch a 271 CA certificate using an HTTPS URI on a TAL. 273 Relying Party tools SHOULD log any TLS certificate or host name 274 validation issues found, so that an operator can investigate the 275 cause. However, such validation issues are often due to 276 configuration errors or a lack of a common TLS trust anchor. In 277 these cases, it is better if the Relying Party retrieves the CA 278 certificate regardless and performs validation on it. Therefore, the 279 Relying Party MUST continue to retrieve the data in case of errors. 281 It is RECOMMENDED that Relying Parties and Repository Servers follow 282 the Best Current Practices outlined in [RFC7525] on the use of HTTP 283 over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS 284 certificate and host name validation using subjectAltName dNSName 285 identities as described in [RFC6125]. The rules and guidelines 286 defined in [RFC6125] apply here, with the following considerations: 288 o Relying Parties and Repository Servers SHOULD support the DNS-ID 289 identifier type. The DNS-ID identifier type SHOULD be present in 290 Repository Server certificates. 292 o DNS names in Repository Server certificates SHOULD NOT contain the 293 wildcard character "*". 295 o A Common Name (CN) field may be present in a Repository Server 296 certificate's subject name but SHOULD NOT be used for 297 authentication within the rules described in [RFC6125]. 299 o This protocol does not require the use of SRV-IDs. 301 o This protocol does not require the use of URI-IDs. 303 Note, however, that this validation is done on a best-effort basis 304 and serves to highlight potential issues, but CA certificate 305 validation in relation to a TAL as described in Section 3 does not 306 depend on this. Therefore, Relying Parties MAY deviate from the 307 validation steps listed above. 309 5. Security Considerations 311 Compromise of a trust anchor private key permits unauthorized parties 312 to masquerade as a trust anchor, with potentially severe 313 consequences. Reliance on an inappropriate or incorrect trust anchor 314 has similar potentially severe consequences. 316 This TAL does not directly provide a list of resources covered by the 317 referenced self-signed CA certificate. Instead, the RP is referred 318 to the trust anchor itself and the INR extension(s) within this 319 certificate. This provides necessary operational flexibility, but it 320 also allows the certificate issuer to claim to be authoritative for 321 any resource. Relying parties should either have great confidence in 322 the issuers of such certificates that they are configuring as trust 323 anchors, or they should issue their own self-signed certificate as a 324 trust anchor and, in doing so, impose constraints on the subordinate 325 certificates. 327 6. Acknowledgements 329 This approach to trust anchor material was originally described by 330 Robert Kisteleki. 332 The authors acknowledge the contributions of Rob Austein and Randy 333 Bush, who assisted with drafting this document and with helpful 334 review comments. 336 The authors acknowledge with work of Roque Gagliano, Terry Manderson, 337 and Carlos Martinez Cagnazzo in developing the ideas behind the 338 inclusion of multiple URIs in the TAL. 340 7. References 342 7.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, 346 DOI 10.17487/RFC2119, March 1997, 347 . 349 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 350 Addresses and AS Identifiers", RFC 3779, 351 DOI 10.17487/RFC3779, June 2004, 352 . 354 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 355 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 356 . 358 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 359 Housley, R., and W. Polk, "Internet X.509 Public Key 360 Infrastructure Certificate and Certificate Revocation List 361 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 362 . 364 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 365 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 366 . 368 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 369 Verification of Domain-Based Application Service Identity 370 within Internet Public Key Infrastructure Using X.509 371 (PKIX) Certificates in the Context of Transport Layer 372 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 373 2011, . 375 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 376 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 377 February 2012, . 379 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 380 X.509 PKIX Resource Certificates", RFC 6487, 381 DOI 10.17487/RFC6487, February 2012, 382 . 384 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 385 Protocol (HTTP/1.1): Message Syntax and Routing", 386 RFC 7230, DOI 10.17487/RFC7230, June 2014, 387 . 389 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 390 "Recommendations for Secure Use of Transport Layer 391 Security (TLS) and Datagram Transport Layer Security 392 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 393 2015, . 395 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 396 "Resource Public Key Infrastructure (RPKI) Trust Anchor 397 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 398 . 400 [X.509] TU-T Recommendation X.509, "The Directory: Public-key and 401 attribute certificate frameworks", October 2012. 403 7.2. Informative References 405 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 406 Nicholas, "Internet X.509 Public Key Infrastructure: 407 Certification Path Building", RFC 4158, 408 DOI 10.17487/RFC4158, September 2005, 409 . 411 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 412 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 413 . 415 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 416 "Manifests for the Resource Public Key Infrastructure 417 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 418 . 420 Authors' Addresses 422 Geoff Huston 423 APNIC 425 Email: gih@apnic.net 426 URI: https://www.apnic.net 427 Samuel Weiler 428 W3C/MIT 430 Email: weiler@csail.mit.edu 432 George Michaelson 433 APNIC 435 Email: ggm@apnic.net 436 URI: https://www.apnic.net 438 Stephen Kent 439 Unaffiliated 441 Email: kent@alum.mit.edu 443 Tim Bruijnzeels 444 NLnet Labs 446 Email: tim@nlnetlabs.nl 447 URI: https://www.nlnetlabs.nl