idnits 2.17.1 draft-ietf-sidr-ta-07.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 (April 13, 2011) is 4754 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) == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-17 ** Downref: Normative reference to an Informational RFC: RFC 5781 == Outdated reference: A later version (-02) exists of draft-reynolds-rpki-ltamgmt-01 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-11 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR G. Huston 3 Internet-Draft APNIC 4 Intended status: Standards Track S. Weiler 5 Expires: October 15, 2011 SPARTA, Inc. 6 G. Michaelson 7 APNIC 8 S. Kent 9 BBN 10 April 13, 2011 12 Resource Certificate PKI (RPKI) Trust Anchor Locator 13 draft-ietf-sidr-ta-07 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 October 15, 2011. 37 Copyright Notice 39 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 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) [ID.sidr-arch]. This 73 format may be used to distribute trust anchor material using a mix of 74 out-of-band and online means. Procedures used by relying parties 75 (RPs) to verify RPKI signed objects SHOULD support this format to 76 facilitate interoperability between creators of Trust Anchor (TA) 77 material 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 RFC 2119. 85 2. Trust Anchor Locator 87 2.1. Trust Anchor Locator Format 89 This document does not propose a new format for TA material. A TA in 90 the RPKI is represented by a self-signed X.509 CA certificate, a 91 format commonly used in PKIs and widely supported by RP software. 92 This document specifies a format for data used to retrieve and verify 93 the authenticity of a TA, in a very simple fashion. That data is 94 referred to as "Trust Anchor Locator" (TAL). 96 The motivation for defining the TAL is to enable selected data in the 97 trust anchor to change, without needing to effect re-distribution of 98 the trust anchor per se. In the RPKI, certificates contain 99 extensions that represent Internet Number Resources (INRs) [RFC3779]. 100 The set of INRs associated with an entity likely will change over 101 time. Thus, if one were to use the common PKI convention of 102 distributing a TA to RPs in a secure fashion, this procedure would 103 need to be repeated whenever the INR set for the TA changed. By 104 distributing the TAL (in a secure fashion), instead of the TA, this 105 problem is avoided, i.e., the TAL is constant so long as the TA's 106 public key and its location does not change. 108 The TAL is analogous to the TrustAnchorInfo data structure adopted as 109 a PKIX standard [RFC5914]. That standard could be used to represent 110 the TAL, if one defined an rsync URI extension for that data 111 structure. However, the TAL format was adopted by RPKI implementors 112 prior to the PKIX TA work, and the RPKI implementer community has 113 elected to utilize the TAL format, rather than define the requisite 114 extension. The community also prefers the simplicity of the ASCII 115 encoding of the TAL, vs. the binary (ASN.1) encoding for 116 TrustAnchorInfo. 118 The TAL is an ordered sequence of a rsync URI [RFC5781], and a base 119 64-encoding with URL and filename safe alphabet [RFC4648], DER- 120 encoded X.509 [X.509] subjectPublicKeyInfo [RFC5280]. The sequence 121 separator is an ASCII line break sequence, namely the CR LF character 122 pair. The CR character is OPTIONAL. 124 2.2. TAL and Trust Anchor Certificate Considerations 126 The rsync URI in the TAL MUST reference a single object. It MUST NOT 127 reference a directory or any other form of collection of objects. 129 The referenced object MUST be a self-signed CA certificate that 130 conforms to the RPKI certificate profile [ID.sidr-res-certs]. This 131 certificate is the trust anchor in certification path discovery 132 [RFC4158] and validation [RFC5280][RFC3779]. 134 The validity interval of this trust anchor SHOULD reflect the 135 anticipated period of stability the particular set of Internet Number 136 Resources (INRs) that are associated with the putative TA. 138 The INR [RFC3779] extension(s) of this trust anchor MUST contain a 139 non-empty set of number resources. It MUST NOT use the "inherit" 140 form of the INR extension(s). The INR set described in this 141 certificate is the set of number resources for which the issuing 142 entity is offering itself as a putative trust anchor in the RPKI 143 [ID.sidr-arch]. 145 The public key used to verify the trust anchor MUST be the same as 146 the subjectPublicKeyInfo in the CA certificate and in the TAL. 148 The trust anchor MUST contain a stable key. This key MUST NOT change 149 when the certificate is reissued due to changes in the INR 150 extension(s), when the certificate is renewed prior to expiration or 151 for any reason other than a key change. 153 Because the public key in the TAL and the trust anchor MUST be 154 stable, this motivates operation of that CA in an off-line mode. 155 Thus the entity that issues the trust anchor SHOULD issue a 156 subordinate CA certificate that contains the same INRs (via the use 157 of the "inherit" option in the INR extensions of the subordinate 158 certificate). This allows the entity that issues the trust anchor to 159 keep the corresponding private key of this certificate off-line, 160 while issuing all relevant child certificates under the immediate 161 subordinate CA. This measure also allows the CRL issued by that 162 entity to be used to revoke the subordinate (CA) certificate in the 163 event of suspected key compromise of this potentially more vulnerable 164 online operational key pair. 166 The trust anchor MUST be published at a stable URI. When the trust 167 anchor is re-issued for any reason, the replacement CA certificate 168 MUST be accessible using the same URI. 170 Becuase the trust anchor is a self-signed certificate, there is no 171 corresponding Certificate Revocation List that can be used to revoke 172 it, nor is there a manifest [ID.sidr-rpki-manifests] that lists this 173 certificate. 175 If an entity wishes to withdraw a self-signed CA certificate as a 176 putative Trust Anchor, for any reason, including key rollover, the 177 entity MUST remove the object from the location referenced in the 178 TAL. 180 2.3. Example 182 rsync://rpki.example.org/rpki/hedgehog/root.cer 183 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx 184 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 185 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 186 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa 187 BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG 188 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 189 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB 191 3. Relying Party Use 193 In order to use the TAL to retrieve and validate a (putative) TA, an 194 RP SHOULD: 196 1. Retrieve the object referenced by the URI contained in the TAL. 198 2. Confirm that the retrieved object is a current, self-signed RPKI 199 CA certificate that conforms to the profile as specified in 200 [ID.sidr-res-certs]. 202 3. Confirm that the public key in the TAL matches the public key in 203 the retrieved object. 205 4. Perform other checks, as deemed appropriate (locally), to ensure 206 that the RP is willing to accept the entity publishing this self- 207 signed CA certificate to be a trust anchor, relating to the 208 validity of attestations made in the context of the RPKI 209 (relating to all resources described in the INR extension of this 210 certificate). 212 An RP SHOULD perform these functions for each instance of TAL that it 213 is holding for this purpose every time the RP performs a re- 214 synchronization across the local repository cache. In any case, an 215 RP also SHOULD perform these functions prior to the expiration of the 216 locally cached copy of the retrieved trust anchor referenced by the 217 TAL. 219 4. Security Considerations 221 Compromise of a trust anchor private key permits unauthorized parties 222 to masquerade as a trust anchor, with potentially severe 223 consequences. Reliance on an inappropriate or incorrect trust anchor 224 has similar potentially severe consequences. 226 This trust anchor locator does not directly provide a list of 227 resources covered by the referenced self-signed CA certificate. 228 Instead, the RP is referred to the TA itself and the INR extension(s) 229 within this certificate. This provides necessary operational 230 flexibility, but it also allows the certificate issuer to claim to be 231 authoritative for any resource. Relying parties should either have 232 great confidence in the issuers of such certificates that they are 233 configuring as trust anchors, or they should issue their own self- 234 signed certificate as a trust anchor and, in doing so, impose 235 constraints on the subordinate certificates. For more information on 236 this approach, see [ID.reynolds-rpki-ltamgmt]. 238 5. IANA Considerations 240 [This document specifies no IANA actions.] 242 6. Acknowledgments 244 This approach to TA material was originally described by Robert 245 Kisteleki. 247 The authors acknowledge the contributions of Rob Austein and Randy 248 Bush, who assisted with earlier versions of this document and with 249 helpful review comments. 251 7. References 252 7.1. Normative References 254 [ID.sidr-res-certs] 255 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 256 X.509 PKIX Resource Certificates", Work in progress: 257 Internet Drafts draft-ietf-sidr-res-certs-17.txt, 258 September 2009. 260 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 261 Addresses and AS Identifiers", RFC 3779, June 2004. 263 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 264 Encodings", RFC 4648, October 2006. 266 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 267 Housley, R., and W. Polk, "Internet X.509 Public Key 268 Infrastructure Certificate and Certificate Revocation List 269 (CRL) Profile", RFC 5280, May 2008. 271 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 272 Scheme", RFC 5781, February 2010. 274 [X.509] ITU-T, "Recommendation X.509: The Directory - 275 Authentication Framework", 2000. 277 7.2. Informative References 279 [ID.reynolds-rpki-ltamgmt] 280 Reynolds, M. and S. Kent, "Local Trust Anchor Management 281 for the Resource Public Key Infrastructure", Work in 282 progress: Internet 283 Drafts draft-reynolds-rpki-ltamgmt-01.txt, September 2010. 285 [ID.sidr-arch] 286 Lepinski, M. and S. Kent, "An Infrastructure to Support 287 Secure Internet Routing", Work in progress: Internet 288 Drafts draft-ietf-sidr-arch-11.txt, September 2010. 290 [ID.sidr-rpki-manifests] 291 Austein, R., Huston, G., Kent, S., and M. Lepinski, 292 "Manifests for the Resource Public Key Infrastructure", 293 draft-ietf-sidr-rpki-manifests (work in progress), 294 May 2010. 296 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 297 Nicholas, "Internet X.509 Public Key Infrastructure: 298 Certification Path Building", RFC 4158, September 2005. 300 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 301 Format", RFC 5914, June 2010. 303 Authors' Addresses 305 Geoff Huston 306 APNIC 308 Email: gih@apnic.net 309 URI: http://www.apnic.net 311 Samuel Weiler 312 SPARTA, Inc. 313 7110 Samuel Morse Drive 314 Colombia, Maryland 21046 315 USA 317 Email: weiler@sparta.com 319 George Michaelson 320 Asia Pacific Network Information Centre 322 Email: ggm@apnic.net 323 URI: http://www.apnic.net 325 Stephen Kent 326 BBN Technologies 327 10 Moulton St. 328 Cambridge, MA 02138 329 USA 331 Email: kent@bbn.com