idnits 2.17.1 draft-ietf-sidr-rfc6490-bis-01.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 draft header indicates that this document obsoletes RFC6490, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2014) is 3500 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 ** Downref: Normative reference to an Informational RFC: RFC 6480 -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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 SPARTA, Inc. 6 Expires: March 23, 2015 G. Michaelson 7 APNIC 8 S. Kent 9 BBN 10 September 19, 2014 12 Resource Certificate PKI (RPKI) Trust Anchor Locator 13 draft-ietf-sidr-rfc6490-bis-01 15 Abstract 17 This document defines a Trust Anchor Locator (TAL) for the Resource 18 Certificate Public Key Infrastructure (RPKI). 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 23, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Trust Anchor Locator . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Trust Anchor Locator Format . . . . . . . . . . . . . . . . 3 58 2.2. TAL and Trust Anchor Certificate Considerations . . . . . . 4 59 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 This document defines a Trust Anchor Locator (TAL) for the Resource 72 Certificate Public Key Infrastructure (RPKI) [RFC6480]. This format 73 may be used to distribute trust anchor material using a mix of out- 74 of-band and online means. Procedures used by Relying Parties (RPs) 75 to verify RPKI signed objects SHOULD support this format to 76 facilitate interoperability between creators of trust anchor material 77 and RPs. 79 1.1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Trust Anchor Locator 87 2.1. Trust Anchor Locator Format 89 This document does not propose a new format for trust anchor 90 material. A trust anchor in the RPKI is represented by a self-signed 91 X.509 Certificate Authority (CA), a format commonly used in PKIs and 92 widely supported by RP software. This document specifies a format 93 for data used to retrieve and verify the authenticity of a trust 94 anchor in a very simple fashion. That data is referred to as the 95 TAL. 97 The motivation for defining the TAL is to enable selected data in the 98 trust anchor to change, without needing to effect re-distribution of 99 the trust anchor per se. In the RPKI, certificates contain 100 extensions that represent Internet Number Resources (INRs) [RFC3779]. 101 The set of INRs associated with an entity acting as a trust anchor is 102 likely to change over time. Thus, if one were to use the common PKI 103 convention of distributing a trust anchor to RPs in a secure fashion, 104 this procedure would need to be repeated whenever the INR set for the 105 entity acting as a trust anchor changed. By distributing the TAL (in 106 a secure fashion), instead of the trust anchor, this problem is 107 avoided, i.e., the TAL is constant so long as the TA's public key and 108 its location does not change. 110 The TAL is analogous to the TrustAnchorInfo data structure [RFC5914] 111 adopted as a PKIX standard. That standard could be used to represent 112 the TAL, if one defined an rsync URI extension for that data 113 structure. However, the TAL format was adopted by RPKI implementors 114 prior to the PKIX trust anchor work, and the RPKI implementer 115 community has elected to utilize the TAL format, rather than define 116 the requisite extension. The community also prefers the simplicity 117 of the ASCII encoding of the TAL, vs. the binary (ASN.1) encoding for 118 TrustAnchorInfo. 120 The TAL is an ordered sequence of: 122 1) a URI section, 124 2) a or line break, 126 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], 127 encoded in Base64 (see Section 4 of [RFC4648]. 129 where the URI section is comprised of one of more of the ordered 130 sequence of: 132 1.1) an rsync URI [RFC5781], 134 1.2) a or line break. 136 2.2. TAL and Trust Anchor Certificate Considerations 138 Each rsync URI in the TAL MUST reference a single object. It MUST 139 NOT 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 the particular set of Internet Number 148 Resources (INRs) that are associated with the putative TA. 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 off-line 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 off-line, 171 while issuing all relevant child certificates under the immediate 172 subordinate CA. This measure also allows the CRL issued by that 173 entity to be used to revoke the subordinate (CA) certificate in the 174 event of suspected key compromise of this potentially more vulnerable 175 online operational key pair. 177 The trust anchor MUST be published at a stable URI. When the trust 178 anchor is re-issued 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 Certificate Revocation List that can be used to revoke 183 it, nor is there a 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 rsync URIs, then the same self- 191 signed CA certificate MUST be found at each referenced location. In 192 order to operational increase resilience, it is RECOMMENDED that the 193 domain name parts of each of these URIs resolve to distinct IP 194 addresses that are used by a diverse set of repository publication 195 points, and these IP addresses be included in distinct Route 196 Origination Authorizations (ROAs) objects signed by different CAs. 198 2.3. Example 200 rsync://rpki.example.org/rpki/hedgehog/root.cer 202 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx 203 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 204 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 205 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa 206 BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG 207 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 208 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB 210 3. Relying Party Use 212 In order to use the TAL to retrieve and validate a (putative) TA, an 213 RP SHOULD: 215 1. Retrieve the object referenced by (one of) the URI(s) contained 216 in the TAL. 218 2. Confirm that the retrieved object is a current, self-signed RPKI 219 CA certificate that conforms to the profile as specified in 220 [RFC6487]. 222 3. Confirm that the public key in the TAL matches the public key in 223 the retrieved object. 225 4. Perform other checks, as deemed appropriate (locally), to ensure 226 that the RP is willing to accept the entity publishing this self- 227 signed CA certificate to be a trust anchor, relating to the 228 validity of attestations made in the context of the RPKI 229 (relating to all resources described in the INR extension of this 230 certificate). 232 An RP SHOULD perform these functions for each instance of TAL that it 233 is holding for this purpose every time the RP performs a re- 234 synchronization across the local repository cache. In any case, an 235 RP also SHOULD perform these functions prior to the expiration of the 236 locally cached copy of the retrieved trust anchor referenced by the 237 TAL. 239 In the case where a TAL contains multiple URIs, an RP MAY use a 240 locally defined preference rule to select the URI to retrieve the 241 self-signed RPKI CA certificate that is to be used as a trust anchor. 242 Some examples are: 243 o Using the order provided in the TAL 244 o Selecting the URI randomly from the available list 245 o Creating a prioritized list of URIs based on RP-specific 246 parameters, such as connection establishment delay 248 If the connection to the preferred URI fails, or the retrieved CA 249 certificate public key does not match the TAL public key, the RP 250 SHOULD retrieve the CA certificate from the next URI, according to 251 the local preference ranking of URIs. 253 4. Security Considerations 255 Compromise of a trust anchor private key permits unauthorized parties 256 to masquerade as a trust anchor, with potentially severe 257 consequences. Reliance on an inappropriate or incorrect trust anchor 258 has similar potentially severe consequences. 260 This trust anchor locator does not directly provide a list of 261 resources covered by the referenced self-signed CA certificate. 262 Instead, the RP is referred to the trust anchor itself and the INR 263 extension(s) within this certificate. This provides necessary 264 operational flexibility, but it also allows the certificate issuer to 265 claim to be authoritative for any resource. Relying parties should 266 either have great confidence in the issuers of such certificates that 267 they are configuring as trust anchors, or they should issue their own 268 self-signed certificate as a trust anchor and, in doing so, impose 269 constraints on the subordinate certificates. 271 5. IANA Considerations 273 [This document specifies no IANA actions.] 275 6. Acknowledgments 277 This approach to TA material was originally described by Robert 278 Kisteleki. 280 The authors acknowledge the contributions of Rob Austein and Randy 281 Bush, who assisted with earlier versions of this document and with 282 helpful review comments. 284 The authors acknowledge with work of Roque Gagliano, Terry Manderson 285 and Carloa Martinez Cagnazzo in developing the ideas behind the 286 inclusion of multiple URIs in the TAL. 288 7. References 290 7.1. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 296 Addresses and AS Identifiers", RFC 3779, June 2004. 298 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 299 Encodings", RFC 4648, October 2006. 301 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 302 Housley, R., and W. Polk, "Internet X.509 Public Key 303 Infrastructure Certificate and Certificate Revocation List 304 (CRL) Profile", RFC 5280, May 2008. 306 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 307 Scheme", RFC 5781, February 2010. 309 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 310 Secure Internet Routing", RFC 6480, February 2012. 312 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 313 X.509 PKIX Resource Certificates", RFC 6487, 314 February 2012. 316 [X.509] ITU-T, "Recommendation X.509: The Directory - 317 Authentication Framework", 2000. 319 7.2. Informative References 321 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 322 Nicholas, "Internet X.509 Public Key Infrastructure: 323 Certification Path Building", RFC 4158, September 2005. 325 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 326 Format", RFC 5914, June 2010. 328 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 329 "Manifests for the Resource Public Key Infrastructure 330 (RPKI)", RFC 6486, February 2012. 332 Authors' Addresses 334 Geoff Huston 335 APNIC 337 Email: gih@apnic.net 338 URI: http://www.apnic.net 340 Samuel Weiler 341 SPARTA, Inc. 342 7110 Samuel Morse Drive 343 Colombia, Maryland 21046 344 USA 346 Email: weiler@sparta.com 347 George Michaelson 348 Asia Pacific Network Information Centre 350 Email: ggm@apnic.net 351 URI: http://www.apnic.net 353 Stephen Kent 354 BBN Technologies 355 10 Moulton St. 356 Cambridge, MA 02138 357 USA 359 Email: kent@bbn.com