idnits 2.17.1 draft-ietf-sidr-ta-06.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 (November 8, 2010) is 4911 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: May 12, 2011 SPARTA, Inc. 6 G. Michaelson 7 APNIC 8 S. Kent 9 BBN 10 November 8, 2010 12 Resource Certificate PKI (RPKI) Trust Anchor Locator 13 draft-ietf-sidr-ta-06 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 May 11, 2011. 37 Copyright Notice 39 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 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 TA 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-encoded, DER-encoded X.509 [X.509] subjectPublicKeyInfo [RFC5280]. 120 The sequence separator is an ASCII line break sequence, namely the CR 121 LF character pair. The CR character is OPTIONAL. 123 2.2. TAL and Trust Anchor Certificate Considerations 125 The rsync URI in the TAL MUST reference a single object. It MUST NOT 126 reference a directory or any other form of collection of objects. 128 The referenced object MUST be a self-signed CA certificate that 129 conforms to the RPKI certificate profile [ID.sidr-res-certs]. This 130 certificate is the trust anchor in certification path discovery 131 [RFC4158] and validation [RFC5280][RFC3779]. 133 The validity interval of this trust anchor SHOULD reflect the 134 anticipated period of stability the particular set of Internet Number 135 Resources (INRs) that are associated with the putative TA. 137 The INR [RFC3779] extension(s) of this trust anchor MUST contain a 138 non-empty set of number resources. It MUST NOT use the "inherit" 139 form of the INR extension(s). The INR set described in this 140 certificate is the set of number resources for which the issuing 141 entity is offering itself as a putative trust anchor in the RPKI 142 [ID.sidr-arch]. 144 The public key used to verify the trust anchor MUST be the same as 145 the subjectPublicKeyInfo in the CA certificate and in the TAL. 147 The trust anchor MUST contain a stable key. This key MUST NOT change 148 when the certificate is reissued due to changes in the INR 149 extension(s), when the certificate is renewed prior to expiration or 150 for any reason other than a key change. 152 Because the public key in the TAL and the trust anchor MUST be 153 stable, this motivates operation of that CA in an off-line mode. 154 Thusthe entity that issues the trust anchor SHOULD issue a 155 subordinate CA certificate that contains the same INRs (via the use 156 of the "inherit" option in the INR extensions of the subordinate 157 certificate). This allows the entity that issues the trust anchor to 158 keep the corresponding private key of this certificate off-line, 159 while issuing all relevant child certificates under the immediate 160 subordinate CA. This measure also allows the CRL issued by that 161 entity to be used revoke the subordinate (CA) certificate in the 162 event of suspected key compromise of this potentially more vulnerable 163 online operational key pair. 165 The trust anchor MUST be published at a stable URI. When the trust 166 anchor is re-issued for any reason, the replacement CA certificate 167 MUST be accessible using the same URI. 169 Becuase the trust anchor is a self-signed certificate, there is no 170 corresponding Certificate Revocation List that can be used to revoke 171 it, nor is there a manifest [ID.sidr-rpki-manifests] that lists this 172 certificate. 174 If an entity wishes to withdraw a self-signed CA certificate as a 175 putative Trust Anchor, for any reason, including key rollover, the 176 entity MUST remove the object from the location referenced in the 177 TAL. 179 2.3. Example 181 rsync://rpki.example.org/rpki/hedgehog/root.cer 182 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx 183 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 184 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 185 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa 186 BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG 187 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 188 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB 190 3. Relying Party Use 192 In order to use the TAL to retrieve and validate a (putative) TA, an 193 RP SHOULD: 195 1. Retrieve the object referenced by the URI contained in the TAL. 197 2. Confirm that the retrieved object is a current, self-signed RPKI 198 CA certificate that conforms to the profile as specified in 199 [ID.sidr-res-certs]. 201 3. Confirm that the public key in the TAL matches the public key in 202 the retrieved object. 204 4. Perform other checks, as deem appropriate (locally), to ensure 205 that the RP is willing to accept the entity publishing this self- 206 signed CA certificate to be a trust anchor, relating to the 207 validity oof attestations made in the context of the RPKI 208 (relating to all resources described in the INR extension of this 209 certificate). 211 An RP SHOULD perform these functions for each instance of TAL that it 212 is holding for this purpose every time the RP performs a re- 213 synchronization across the local repository cache. In any case, an 214 RP also SHOULD perform these functions prior to the expiration of the 215 locally cached copy of the retrieved trust anchor referenced by the 216 TAL. 218 4. Security Considerations 220 Compromise of a trust anchor private key permits unauthorized parties 221 to masquerade as a trust anchor, with potentially severe 222 consequences. Reliance on an inappropriate or incorrect trust anchor 223 has similar potentially severe consequences. 225 This trust anchor locator does not directly provide a list of 226 resources covered by the referenced self-signed CA certificate. 227 Instead, the RP is referred to the TA itself and the INR extension(s) 228 within this certificate. This provides necessary operational 229 flexibility, but it also allows the certificate issuer to claim to be 230 authoritative for any resource. Relying parties should either have 231 great confidence in the issuers of such certificates that they are 232 configuring as trust anchors, or they should issue their own self- 233 signed certificate as a trust anchor and, in doing so, impose 234 constraints on the subordinate certificates. For more information on 235 this approach, see [ID.reynolds-rpki-ltamgmt]. 237 5. IANA Considerations 239 [This document specifies no IANA actions.] 241 6. Acknowledgments 243 This approach to TA material was originally described by Robert 244 Kisteleki. 246 The authors acknowledge the contributions of Rob Austein and Randy 247 Bush, who assisted with earlier versions of this document and with 248 helpful review comments. 250 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 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 264 Housley, R., and W. Polk, "Internet X.509 Public Key 265 Infrastructure Certificate and Certificate Revocation List 266 (CRL) Profile", RFC 5280, May 2008. 268 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 269 Scheme", RFC 5781, February 2010. 271 [X.509] ITU-T, "Recommendation X.509: The Directory - 272 Authentication Framework", 2000. 274 7.2. Informative References 276 [ID.reynolds-rpki-ltamgmt] 277 Reynolds, M. and S. Kent, "Local Trust Anchor Management 278 for the Resource Public Key Infrastructure", Work in 279 progress: Internet 280 Drafts draft-reynolds-rpki-ltamgmt-01.txt, September 2010. 282 [ID.sidr-arch] 283 Lepinski, M. and S. Kent, "An Infrastructure to Support 284 Secure Internet Routing", Work in progress: Internet 285 Drafts draft-ietf-sidr-arch-11.txt, September 2010. 287 [ID.sidr-rpki-manifests] 288 Austein, R., Huston, G., Kent, S., and M. Lepinski, 289 "Manifests for the Resource Public Key Infrastructure", 290 draft-ietf-sidr-rpki-manifests (work in progress), 291 May 2010. 293 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 294 Nicholas, "Internet X.509 Public Key Infrastructure: 295 Certification Path Building", RFC 4158, September 2005. 297 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 298 Format", RFC 5914, June 2010. 300 Authors' Addresses 302 Geoff Huston 303 APNIC 305 Email: gih@apnic.net 306 URI: http://www.apnic.net 308 Samuel Weiler 309 SPARTA, Inc. 310 7110 Samuel Morse Drive 311 Colombia, Maryland 21046 312 USA 314 Email: weiler@sparta.com 316 George Michaelson 317 Asia Pacific Network Information Centre 319 Email: ggm@apnic.net 320 URI: http://www.apnic.net 322 Stephen Kent 323 BBN Technologies 324 10 Moulton St. 325 Cambridge, MA 02138 326 USA 328 Email: kent@bbn.com