idnits 2.17.1 draft-weiler-sidr-trust-anchor-format-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 : ---------------------------------------------------------------------------- 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 (July 13, 2010) is 5037 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-18 ** Downref: Normative reference to an Informational RFC: RFC 5781 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-09 == Outdated reference: A later version (-02) exists of draft-reynolds-rpki-ltamgmt-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Weiler 3 Internet-Draft SPARTA, Inc. 4 Intended status: Standards Track July 13, 2010 5 Expires: January 14, 2011 7 Simple RPKI Trust Anchor Format 8 draft-weiler-sidr-trust-anchor-format-01 10 Abstract 12 This document describes a simple convention for distributing trust 13 anchors for the Resource Public Key Infrastructure (RPKI). 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 14, 2011. 32 Copyright Notice 34 Copyright (c) 2010 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 1. Introduction 49 This document describes a convention for distributing and using trust 50 anchors for the Resource Public Key Infrastructure (RPKI). It 51 assumes a working knowledge of the RPKI. [I-D.ietf-sidr-arch] 53 The trust anchor has two parts: a URI of a self-signed certificate 54 and a copy of the public key from that certificate. Neither part of 55 the trust anchor directly lists the resources for which the 56 certificate is authoritative. Instead, that list is stored in the 57 certificate itself, which allows the list of resources to change 58 without changing the trust anchor. 60 1.1. Terminology 62 RFC5280 and RFC5914 define the term "trust anchor" slightly 63 differently than it is used here. In particular, those definitions 64 do not include an external pointer such as the URI used in this 65 format. 67 The broader security literature, however, uses the term "trust 68 anchor" to refer to something (relatively) static. In this case, the 69 certificate pointed to by the URI contains a dynamic list of 70 resources in the RFC3779 extensions, which makes the certificate 71 unstable. 73 While acknowledging the slight differences from the RFC5280 and 74 RFC5914 definitions, we choose to use the term "trust anchor" in a 75 way that is more consistent with the broader literature and which we 76 find more intuitive. 78 2. Format Details 80 The URI part of the trust anchor is an rsync URI. See [RFC5781]. 81 The URI is followed by a CRLF. 83 The key part is a base64 encoded, DER-encoded X.509 84 subjectPublicKeyInfo. See [RFC5280]. 86 2.1. Example 87 rsync://rpki.example.org/rpki/hedgehog/root.cer 88 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx 89 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 90 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 91 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa 92 BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG 93 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 94 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB 96 3. Usage 98 To use one of these trust anchors, a relying party (RP): 100 1. Retrieves the object referenced by the URI. 101 2. Checks that the received object is a valid, self-signed X.509 102 certificate with [RFC3779] extensions conforming to the profile 103 described in [I-D.ietf-sidr-res-certs]. 104 3. Extracts the public key from the X.509 certificate. 105 4. Compares the public key from the trust anchor to the key from the 106 certificate. If they don't match, the trust anchor is invalid. 108 4. Operational Considerations 110 When creating a certificate which will be referenced by a trust 111 anchor, several constraints apply: 113 1. It must conform to the profile described in 114 [I-D.ietf-sidr-res-certs]. 115 2. It must be self-signed. 116 3. It must use a stable key. When reissuing the certificate, 117 whether because the list of resources changes, or renewal, or for 118 any other reason, the same key must be reused in the new 119 certificate. 120 4. It must be published at a stable URI. When the certificate is 121 reissued, the replacement must be accessible using the same URI. 123 If the issuer of a trust anchor wants to keep the private key 124 corresponding to the self-signed certificate off-line, that can be 125 easily done by delegating all of the resources in the certificate to 126 a single child certificate and issuing all relevant certificates 127 under the child. 129 OPEN ISSUE: should this document mandate the use of a second tier CA 130 cert? 132 5. IANA Considerations 134 This document specifies no IANA Actions. 136 6. Security Considerations 138 This trust anchor format does not directly provide a list of 139 resources covered by the certificate. Instead, the relying party is 140 referred to the certificate itself. This provides necessary 141 operational flexibility, but it also allows the certificate issuer to 142 claim to be authoritative for any resource. Relying parties should 143 either have great confidence in the issuers of certificates that 144 they're configuring as trust anchors, or they should issue their own 145 self-signed certificate as a trust anchor and, in doing so, impose 146 constraints on the child certificates. For more information on this 147 approach, see [I-D.reynolds-rpki-ltamgmt]. 149 7. References 151 7.1. Normative References 153 [I-D.ietf-sidr-res-certs] 154 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 155 X.509 PKIX Resource Certificates", 156 draft-ietf-sidr-res-certs-18 (work in progress), May 2010. 158 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 159 Addresses and AS Identifiers", RFC 3779, June 2004. 161 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 162 Housley, R., and W. Polk, "Internet X.509 Public Key 163 Infrastructure Certificate and Certificate Revocation List 164 (CRL) Profile", RFC 5280, May 2008. 166 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 167 Scheme", RFC 5781, February 2010. 169 7.2. Informative References 171 [I-D.ietf-sidr-arch] 172 Lepinski, M. and S. Kent, "An Infrastructure to Support 173 Secure Internet Routing", draft-ietf-sidr-arch-09 (work in 174 progress), October 2009. 176 [I-D.reynolds-rpki-ltamgmt] 177 Kent, S. and M. Reynolds, "Local Trust Anchor Management 178 for the Resource Public Key Infrastructure", 179 draft-reynolds-rpki-ltamgmt-00 (work in progress), 180 March 2010. 182 Appendix A. Acknowledgments 184 This idea came from Robert Kisteleki, circa 2007. 186 The editor thanks Rob Austein for his help in understanding the 187 details of his implementation of this convention. 189 Author's Address 191 Samuel Weiler 192 SPARTA, Inc. 193 7110 Samuel Morse Drive 194 Columbia, Maryland 21046 195 US 197 Email: weiler@tislabs.com