idnits 2.17.1 draft-huston-sidr-validity-00.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 96: '...ns all fields that MUST be present, as...' RFC 2119 keyword, line 102: '... defines as MUST NOT be present i...' RFC 2119 keyword, line 123: '...dation algorithm MAY perform these tes...' RFC 2119 keyword, line 129: '...uting this procedure MAY apply further...' RFC 2119 keyword, line 133: '...certificate validation MAY halt with a...' -- The draft header indicates that this document updates RFC6487, but the abstract doesn't seem to directly say this. It does mention RFC6487 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6487, updated by this document, for RFC5378 checks: 2006-06-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 9, 2015) is 3123 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Huston 3 Internet-Draft G. Michaelson 4 Updates: 6487 (if approved) APNIC 5 Intended status: Standards Track October 9, 2015 6 Expires: April 11, 2016 8 Update to RPKI Validation 9 draft-huston-sidr-validity-00.txt 11 Abstract 13 This document updates the RPKI certificate validation procedure as 14 specified in Section 7.2 of RFC6487. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 11, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. The RPKI Certification Path Validation . . . . . . . . . . . . 3 52 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 55 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1. Introduction 60 This document updates the RPKI certificate validation procedure as 61 specified in Section 7.2 of [RFC6487], by replacing the section 7.2 62 of [RFC6487] with the specification contained here. 64 2. The RPKI Certification Path Validation 66 Validation of signed resource data using a target resource 67 certificate, and a specific set of number resources, consists of 68 verifying that the digital signature of the signed resource data is 69 valid, using the public key of the target resource certificate, and 70 also validating the resource certificate in the context of the RPKI, 71 using the path validation process. This path validation process 72 verifies, among other things, that a prospective certification path 73 (a sequence of n certificates) satisfies the following conditions: 75 1. for all 'x' in {1, ..., n-1}, the Subject of certificate 'x' 76 is the Issuer of certificate ('x' + 1); 78 2. certificate '1' is issued by a trust anchor; 80 3. certificate 'n' is the certificate to be validated; and 82 4. for all 'x' in {1, ..., n}, certificate 'x' is valid for the 83 specific set of resources. 85 RPKI validation for a specific set of resources entails verifying 86 that all of the following conditions hold, in addition to the 87 Certification Path Validation criteria specified in Section 6 of 88 [RFC5280]: 90 1. The certificate can be verified using the Issuer's public key 91 and the signature algorithm 93 2. The current time lies within the certificate's Validity From 94 and To values. 96 3. The certificate contains all fields that MUST be present, as 97 specified by [RFC6487], and contains values for selected 98 fields that are defined as allowable values by this 99 specification. 101 4. No field, or field value, that the [RFC6487] specification 102 defines as MUST NOT be present is used in the certificate. 104 5. The Issuer has not revoked the certificate. A revoked 105 certificate is identified by the certificate's serial number 106 being listed on the Issuer's current CRL, as identified by the 107 CRLDP of the certificate, the CRL is itself valid, and the 108 public key used to verify the signature on the CRL is the same 109 public key used to verify the certificate itself. 111 6. The resource extension data contained in this certificate 112 "encompasses" the entirety of the resources in the specific 113 resource set ("encompass" in this context is defined in 114 Section 7.1 of [RFC6487]). 116 7. The Certification Path originates with a certificate issued by 117 a trust anchor, and there exists a signing chain across the 118 Certification Path where the Subject of Certificate 'x' in the 119 Certification Path matches the Issuer in Certificate 'x + 1' 120 in the Certification Path, and the public key in Certificate 121 'x' can verify the signature value in Certificate 'x+1'. 123 A certificate validation algorithm MAY perform these tests in any 124 chosen order. 126 There exists the possibility of encountering certificate paths that 127 are arbitrarily long, or attempting to generate paths with loops as 128 means of creating a potential denial-of-service (DOS) attack on an 129 Relying Party (RP). An RP executing this procedure MAY apply further 130 heuristics to guide the certification path validation process to a 131 halt in order to avoid some of the issues associated with attempts to 132 validate such malformed certification path structures. 133 Implementations of resource certificate validation MAY halt with a 134 validation failure if the certification path length exceeds a locally 135 defined configuration parameter. 137 3. Security Considerations 139 This update is intended to improve the robustness of the RPKI 140 framework by altering the procedure of the original validation path 141 that included an "encompassing" condition applied pairwise to the 142 certificates used in the validation path. 144 The intent of this update is to ensure that all certificates on a 145 validation path encompass the resources that are included in the 146 validation query, but to remove the "encompassing" constraint on the 147 resources used in pairwise comparison. This change to the validation 148 procedure reduces the criticality of strict orchestration of the 149 sequence of certificate issuance and revocation in those 150 circumstances, and can thereby improve the robustness of the RPKI as 151 a consequence, without altering the underlying semnatics of the 152 association of a public key value across a collection of number 153 resources. 155 4. IANA Considerations 157 No updates to the registries are suggested by this document. 159 5. Acknowledgements 161 Thanks 163 6. Normative References 165 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 166 Housley, R., and W. Polk, "Internet X.509 Public Key 167 Infrastructure Certificate and Certificate Revocation List 168 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 169 . 171 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 172 X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/ 173 RFC6487, February 2012, 174 . 176 Authors' Addresses 178 Geoff Huston 179 Asia Pacific Network Information Centre 180 6 Cordelia St 181 South Brisbane, QLD 4101 182 Australia 184 Phone: +61 7 3858 3100 185 Email: gih@apnic.net 187 George Michaelson 188 Asia Pacific Network Information Centre 189 6 Cordelia St 190 South Brisbane, QLD 4101 191 Australia 193 Phone: +61 7 3858 3100 194 Email: ggm@apnic.net