idnits 2.17.00 (12 Aug 2021) /tmp/idnits13611/draft-ietf-sidr-policy-qualifiers-02.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 an Introduction section. 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 (July 3, 2014) is 2872 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft ARIN 4 Updates: 6487 (if approved) G. Huston 5 Intended status: Standards Track APNIC 6 Expires: January 4, 2015 July 3, 2014 8 Policy Qualifiers in RPKI Certificates 9 draft-ietf-sidr-policy-qualifiers-02 11 Abstract 13 This document updates RFC 6487 by clarifying the inclusion of policy 14 qualifiers in the certificate policies extension of RPKI resource 15 certificates. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 4, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Update to RFC 6487 . . . . . . . . . . . . . . . . . . . . . 2 53 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 56 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 59 1. Terminology 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 2. Update to RFC 6487 67 [RFC6487] profiles certificates, certificate revocation lists, and 68 certificate signing requests specified in [RFC5280] for use in 69 routing public key infrastructure. 71 [RFC5280] defines an extension to certificates for the listing of 72 policy information (See section 4.2.1.4). [RFC6487] states in 73 Section 4.8.9: "This extension MUST be present and MUST be marked 74 critical. It MUST include exactly one policy, as specified in the 75 RPKI CP [RFC6484]". This references the CertPolicyId of the sequence 76 allowed in PolicyInformation as defined by [RFC5280]. 78 [RFC5280] also specifies that PolicyInformation may optionally have a 79 sequence of PolicyQualifierInfo objects. [RFC6487] does not 80 specifically allow or disallow these PolicyQualifierInfo objects 81 although it also states in section 4: "Unless specifically noted as 82 being OPTIONAL, all the fields listed here MUST be present, and any 83 other fields MUST NOT appear in a conforming resource certificate." 85 Because there is a need for some RPKI Certificate Authorities to 86 include policy qualifiers in their certificates, this document 87 updates [RFC6487], Section 4.8.9, as follows: 89 OLD: 91 This extension MUST be present and MUST be marked critical. It 92 MUST include exactly one policy, as specified in the RPKI 93 Certificate Policy (CP) [RFC6484]. 95 NEW: 97 This extension MUST be present and MUST be marked critical. It 98 MUST include exactly one policy, as specified in the RPKI CP 99 [RFC6484]. Exactly one policy qualifier MAY be included. If a 100 policy qualifier is included, the policyQualifierId MUST be the 101 Certification Practice Statement (CPS) pointer qualifier type 102 (id-qt-cps). 104 As noted in [RFC5280], section 4.2.1.4: "Optional qualifiers, which 105 MAY be present, are not expected to change the definition of the 106 policy." In this case any optional policy qualifier that MAY be 107 present in a resource certificate MUST NOT change the definition of 108 the RPKI CP [RFC6484]. 110 3. IANA Considerations 112 None. 114 4. Security Considerations 116 The Security Considerations of [RFC6487] apply to this document. 118 This document updates the RPKI certificate profile to specify that 119 the certificate policies extension can include a policy qualifier, 120 which is a URI. While de-referencing the URI is not required for 121 certificate validation, doing so could provide a denial-of-service 122 (DoS) vector, where the target host may be subjected to bogus work 123 de-referencing the URI. However, this specification, like [RFC5280], 124 places no processing requirements on the URI included in the 125 qualifier. 127 As an update to [RFC6487], this document broadens the class of 128 certificates that conform to the RPKI profile by explicitly including 129 within the profile those certificates that contain a policy qualifier 130 as described here. A relying party that performs a strict validation 131 based on [RFC6487] and fails to support the updates described in this 132 document, would incorrectly invalidate RPKI objects that include the 133 changes in Section 2. 135 5. Acknowledgments 137 Frank Hill and Adam Guyot helped define the scope of this issue and 138 identified and worked with RPKI validator implementers to clarify the 139 use of policy qualifiers in resource certificates. 141 Sean Turner provided significant text to this document regarding the 142 processing of the CPS URI and limiting the scope of the allowable 143 content of the policy qualifier. 145 6. Normative References 147 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 148 Requirement Levels", BCP 14, RFC 2119, March 1997. 150 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 151 Housley, R., and W. Polk, "Internet X.509 Public Key 152 Infrastructure Certificate and Certificate Revocation List 153 (CRL) Profile", RFC 5280, May 2008. 155 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 156 Policy (CP) for the Resource Public Key Infrastructure 157 (RPKI)", BCP 173, RFC 6484, February 2012. 159 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 160 X.509 PKIX Resource Certificates", RFC 6487, February 161 2012. 163 Authors' Addresses 165 Andrew Lee Newton 166 American Registry for Internet Numbers 167 3635 Concorde Parkway 168 Chantilly, VA 20151 169 USA 171 Email: andy@arin.net 172 URI: http://www.arin.net 174 Geoff Huston 175 Asia Pacific Network Information Center 176 6 Cordelia Street 177 South Brisbane QLD 4101 178 Australia 180 Email: gih@apnic.net 181 URI: http://www.apnic.net