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