Network Working Group G. Huston Internet-Draft G. Michaelson Updates: 6487 (if approved) APNIC Intended status: Standards Track October 9, 2015 Expires: April 11, 2016 Update to RPKI Validation draft-huston-sidr-validity-00.txt Abstract This document updates the RPKI certificate validation procedure as specified in Section 7.2 of RFC6487. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 11, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Huston & Michaelson Expires April 11, 2016 [Page 1] Internet-Draft RPKI Validation October 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The RPKI Certification Path Validation . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Huston & Michaelson Expires April 11, 2016 [Page 2] Internet-Draft RPKI Validation October 2015 1. Introduction This document updates the RPKI certificate validation procedure as specified in Section 7.2 of [RFC6487], by replacing the section 7.2 of [RFC6487] with the specification contained here. 2. The RPKI Certification Path Validation Validation of signed resource data using a target resource certificate, and a specific set of number resources, consists of verifying that the digital signature of the signed resource data is valid, using the public key of the target resource certificate, and also validating the resource certificate in the context of the RPKI, using the path validation process. This path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions: 1. for all 'x' in {1, ..., n-1}, the Subject of certificate 'x' is the Issuer of certificate ('x' + 1); 2. certificate '1' is issued by a trust anchor; 3. certificate 'n' is the certificate to be validated; and 4. for all 'x' in {1, ..., n}, certificate 'x' is valid for the specific set of resources. RPKI validation for a specific set of resources entails verifying that all of the following conditions hold, in addition to the Certification Path Validation criteria specified in Section 6 of [RFC5280]: 1. The certificate can be verified using the Issuer's public key and the signature algorithm 2. The current time lies within the certificate's Validity From and To values. Huston & Michaelson Expires April 11, 2016 [Page 3] Internet-Draft RPKI Validation October 2015 3. The certificate contains all fields that MUST be present, as specified by [RFC6487], and contains values for selected fields that are defined as allowable values by this specification. 4. No field, or field value, that the [RFC6487] specification defines as MUST NOT be present is used in the certificate. 5. The Issuer has not revoked the certificate. A revoked certificate is identified by the certificate's serial number being listed on the Issuer's current CRL, as identified by the CRLDP of the certificate, the CRL is itself valid, and the public key used to verify the signature on the CRL is the same public key used to verify the certificate itself. 6. The resource extension data contained in this certificate "encompasses" the entirety of the resources in the specific resource set ("encompass" in this context is defined in Section 7.1 of [RFC6487]). 7. The Certification Path originates with a certificate issued by a trust anchor, and there exists a signing chain across the Certification Path where the Subject of Certificate 'x' in the Certification Path matches the Issuer in Certificate 'x + 1' in the Certification Path, and the public key in Certificate 'x' can verify the signature value in Certificate 'x+1'. A certificate validation algorithm MAY perform these tests in any chosen order. There exists the possibility of encountering certificate paths that are arbitrarily long, or attempting to generate paths with loops as means of creating a potential denial-of-service (DOS) attack on an Relying Party (RP). An RP executing this procedure MAY apply further heuristics to guide the certification path validation process to a halt in order to avoid some of the issues associated with attempts to validate such malformed certification path structures. Implementations of resource certificate validation MAY halt with a validation failure if the certification path length exceeds a locally defined configuration parameter. Huston & Michaelson Expires April 11, 2016 [Page 4] Internet-Draft RPKI Validation October 2015 3. Security Considerations This update is intended to improve the robustness of the RPKI framework by altering the procedure of the original validation path that included an "encompassing" condition applied pairwise to the certificates used in the validation path. The intent of this update is to ensure that all certificates on a validation path encompass the resources that are included in the validation query, but to remove the "encompassing" constraint on the resources used in pairwise comparison. This change to the validation procedure reduces the criticality of strict orchestration of the sequence of certificate issuance and revocation in those circumstances, and can thereby improve the robustness of the RPKI as a consequence, without altering the underlying semnatics of the association of a public key value across a collection of number resources. 4. IANA Considerations No updates to the registries are suggested by this document. 5. Acknowledgements Thanks 6. Normative References [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/ RFC6487, February 2012, . Huston & Michaelson Expires April 11, 2016 [Page 5] Internet-Draft RPKI Validation October 2015 Authors' Addresses Geoff Huston Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia Phone: +61 7 3858 3100 Email: gih@apnic.net George Michaelson Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia Phone: +61 7 3858 3100 Email: ggm@apnic.net Huston & Michaelson Expires April 11, 2016 [Page 6]