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