idnits 2.17.1 draft-ietf-sidr-rfc6490-bis-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 : ---------------------------------------------------------------------------- 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 (March 29, 2015) is 3309 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 informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR G. Huston 3 Internet-Draft APNIC 4 Obsoletes: 6490 (if approved) S. Weiler 5 Intended status: Standards Track Parsons 6 Expires: September 30, 2015 G. Michaelson 7 APNIC 8 S. Kent 9 BBN 10 March 29, 2015 12 Resource Certificate PKI (RPKI) Trust Anchor Locator 13 draft-ietf-sidr-rfc6490-bis-03 15 Abstract 17 This document defines a Trust Anchor Locator (TAL) for the Resource 18 Certificate Public Key Infrastructure (RPKI). This document 19 obsoletes RFC 6490 by adding support for multiple URIs in a TAL. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 30, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Trust Anchor Locator . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Trust Anchor Locator Format . . . . . . . . . . . . . . . . 3 59 2.2. TAL and Trust Anchor Certificate Considerations . . . . . . 4 60 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document defines a Trust Anchor Locator (TAL) for the Resource 73 Certificate Public Key Infrastructure (RPKI) [RFC6480]. This format 74 may be used to distribute trust anchor material using a mix of out- 75 of-band and online means. Procedures used by Relying Parties (RPs) 76 to verify RPKI signed objects SHOULD support this format to 77 facilitate interoperability between creators of trust anchor material 78 and RPs. This document obsoletes RFC 6490 by adding support for 79 multiple URIs in a TAL. 81 1.1. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Trust Anchor Locator 89 2.1. Trust Anchor Locator Format 91 This document does not propose a new format for trust anchor 92 material. A trust anchor in the RPKI is represented by a self-signed 93 X.509 Certificate Authority (CA), a format commonly used in PKIs and 94 widely supported by RP software. This document specifies a format 95 for data used to retrieve and verify the authenticity of a trust 96 anchor in a very simple fashion. That data is referred to as the 97 TAL. 99 The motivation for defining the TAL is to enable selected data in the 100 trust anchor to change, without needing to effect re-distribution of 101 the trust anchor per se. In the RPKI, certificates contain 102 extensions that represent Internet Number Resources (INRs) [RFC3779]. 103 The set of INRs associated with an entity acting as a trust anchor is 104 likely to change over time. Thus, if one were to use the common PKI 105 convention of distributing a trust anchor to RPs in a secure fashion, 106 this procedure would need to be repeated whenever the INR set for the 107 entity acting as a trust anchor changed. By distributing the TAL (in 108 a secure fashion), instead of the trust anchor, this problem is 109 avoided, i.e., the TAL is constant so long as the TA's public key and 110 its location does not change. 112 The TAL is analogous to the TrustAnchorInfo data structure [RFC5914] 113 adopted as a PKIX standard. That standard could be used to represent 114 the TAL, if one defined an rsync URI extension for that data 115 structure. However, the TAL format was adopted by RPKI implementors 116 prior to the PKIX trust anchor work, and the RPKI implementer 117 community has elected to utilize the TAL format, rather than define 118 the requisite extension. The community also prefers the simplicity 119 of the ASCII encoding of the TAL, vs. the binary (ASN.1) encoding for 120 TrustAnchorInfo. 122 The TAL is an ordered sequence of: 124 1) a URI section, 126 2) a or line break, 128 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], 129 encoded in Base64 (see Section 4 of [RFC4648]. 131 where the URI section is comprised of one of more of the ordered 132 sequence of: 134 1.1) an rsync URI [RFC5781], 136 1.2) a or line break. 138 2.2. TAL and Trust Anchor Certificate Considerations 140 Each rsync URI in the TAL MUST reference a single object. It MUST 141 NOT reference a directory or any other form of collection of objects. 143 The referenced object MUST be a self-signed CA certificate that 144 conforms to the RPKI certificate profile [RFC6487]. This certificate 145 is the trust anchor in certification path discovery [RFC4158] and 146 validation [RFC5280][RFC3779]. 148 The validity interval of this trust anchor SHOULD reflect the 149 anticipated period of stability the particular set of Internet Number 150 Resources (INRs) that are associated with the putative TA. 152 The INR extension(s) of this trust anchor MUST contain a non-empty 153 set of number resources. It MUST NOT use the "inherit" form of the 154 INR extension(s). The INR set described in this certificate is the 155 set of number resources for which the issuing entity is offering 156 itself as a putative trust anchor in the RPKI [RFC6480]. 158 The public key used to verify the trust anchor MUST be the same as 159 the subjectPublicKeyInfo in the CA certificate and in the TAL. 161 The trust anchor MUST contain a stable key. This key MUST NOT change 162 when the certificate is reissued due to changes in the INR 163 extension(s), when the certificate is renewed prior to expiration or 164 for any reason other than a key change. 166 Because the public key in the TAL and the trust anchor MUST be 167 stable, this motivates operation of that CA in an off-line mode. 168 Thus the entity that issues the trust anchor SHOULD issue a 169 subordinate CA certificate that contains the same INRs (via the use 170 of the "inherit" option in the INR extensions of the subordinate 171 certificate). This allows the entity that issues the trust anchor to 172 keep the corresponding private key of this certificate off-line, 173 while issuing all relevant child certificates under the immediate 174 subordinate CA. This measure also allows the CRL issued by that 175 entity to be used to revoke the subordinate (CA) certificate in the 176 event of suspected key compromise of this potentially more vulnerable 177 online operational key pair. 179 The trust anchor MUST be published at a stable URI. When the trust 180 anchor is re-issued for any reason, the replacement CA certificate 181 MUST be accessible using the same URI. 183 Because the trust anchor is a self-signed certificate, there is no 184 corresponding Certificate Revocation List that can be used to revoke 185 it, nor is there a manifest [RFC6486] that lists this certificate. 187 If an entity wishes to withdraw a self-signed CA certificate as a 188 putative Trust Anchor, for any reason, including key rollover, the 189 entity MUST remove the object from the location referenced in the 190 TAL. 192 Where the TAL contains two or more rsync URIs, then the same self- 193 signed CA certificate MUST be found at each referenced location. In 194 order to operational increase resilience, it is RECOMMENDED that the 195 domain name parts of each of these URIs resolve to distinct IP 196 addresses that are used by a diverse set of repository publication 197 points, and these IP addresses be included in distinct Route 198 Origination Authorizations (ROAs) objects signed by different CAs. 200 2.3. Example 202 rsync://rpki.example.org/rpki/hedgehog/root.cer 204 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx 205 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 206 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 207 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa 208 BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG 209 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 210 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB 212 3. Relying Party Use 214 In order to use the TAL to retrieve and validate a (putative) TA, an 215 RP SHOULD: 217 1. Retrieve the object referenced by (one of) the URI(s) contained 218 in the TAL. 220 2. Confirm that the retrieved object is a current, self-signed RPKI 221 CA certificate that conforms to the profile as specified in 222 [RFC6487]. 224 3. Confirm that the public key in the TAL matches the public key in 225 the retrieved object. 227 4. Perform other checks, as deemed appropriate (locally), to ensure 228 that the RP is willing to accept the entity publishing this self- 229 signed CA certificate to be a trust anchor, relating to the 230 validity of attestations made in the context of the RPKI 231 (relating to all resources described in the INR extension of this 232 certificate). 234 An RP SHOULD perform these functions for each instance of TAL that it 235 is holding for this purpose every time the RP performs a re- 236 synchronization across the local repository cache. In any case, an 237 RP also SHOULD perform these functions prior to the expiration of the 238 locally cached copy of the retrieved trust anchor referenced by the 239 TAL. 241 In the case where a TAL contains multiple URIs, an RP MAY use a 242 locally defined preference rule to select the URI to retrieve the 243 self-signed RPKI CA certificate that is to be used as a trust anchor. 244 Some examples are: 245 o Using the order provided in the TAL 246 o Selecting the URI randomly from the available list 247 o Creating a prioritized list of URIs based on RP-specific 248 parameters, such as connection establishment delay 250 If the connection to the preferred URI fails, or the retrieved CA 251 certificate public key does not match the TAL public key, the RP 252 SHOULD retrieve the CA certificate from the next URI, according to 253 the local preference ranking of URIs. 255 4. Security Considerations 257 Compromise of a trust anchor private key permits unauthorized parties 258 to masquerade as a trust anchor, with potentially severe 259 consequences. Reliance on an inappropriate or incorrect trust anchor 260 has similar potentially severe consequences. 262 This trust anchor locator does not directly provide a list of 263 resources covered by the referenced self-signed CA certificate. 264 Instead, the RP is referred to the trust anchor itself and the INR 265 extension(s) within this certificate. This provides necessary 266 operational flexibility, but it also allows the certificate issuer to 267 claim to be authoritative for any resource. Relying parties should 268 either have great confidence in the issuers of such certificates that 269 they are configuring as trust anchors, or they should issue their own 270 self-signed certificate as a trust anchor and, in doing so, impose 271 constraints on the subordinate certificates. 273 5. IANA Considerations 275 [This document specifies no IANA actions.] 277 6. Acknowledgments 279 This approach to TA material was originally described by Robert 280 Kisteleki. 282 The authors acknowledge the contributions of Rob Austein and Randy 283 Bush, who assisted with earlier versions of this document and with 284 helpful review comments. 286 The authors acknowledge with work of Roque Gagliano, Terry Manderson 287 and Carlos Martinez Cagnazzo in developing the ideas behind the 288 inclusion of multiple URIs in the TAL. 290 7. References 292 7.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 298 Addresses and AS Identifiers", RFC 3779, June 2004. 300 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 301 Encodings", RFC 4648, October 2006. 303 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 304 Housley, R., and W. Polk, "Internet X.509 Public Key 305 Infrastructure Certificate and Certificate Revocation List 306 (CRL) Profile", RFC 5280, May 2008. 308 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 309 Scheme", RFC 5781, February 2010. 311 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 312 X.509 PKIX Resource Certificates", RFC 6487, 313 February 2012. 315 [X.509] ITU-T, "Recommendation X.509: The Directory - 316 Authentication Framework", 2000. 318 7.2. Informative References 320 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 321 Nicholas, "Internet X.509 Public Key Infrastructure: 322 Certification Path Building", RFC 4158, September 2005. 324 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 325 Format", RFC 5914, June 2010. 327 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 328 Secure Internet Routing", RFC 6480, February 2012. 330 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 331 "Manifests for the Resource Public Key Infrastructure 332 (RPKI)", RFC 6486, February 2012. 334 Authors' Addresses 336 Geoff Huston 337 APNIC 339 Email: gih@apnic.net 340 URI: http://www.apnic.net 342 Samuel Weiler 343 Parsons 344 7110 Samuel Morse Drive 345 Columbia, Maryland 21046 346 USA 348 Email: weiler@tislabs.com 349 George Michaelson 350 Asia Pacific Network Information Centre 352 Email: ggm@apnic.net 353 URI: http://www.apnic.net 355 Stephen Kent 356 BBN Technologies 357 10 Moulton St. 358 Cambridge, MA 02138 359 USA 361 Email: kent@bbn.com