[sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)
Ben Campbell <ben@nostrum.com> Tue, 29 August 2017 02:36 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E14CA13213D; Mon, 28 Aug 2017 19:36:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.59.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com>
Date: Mon, 28 Aug 2017 19:36:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/EcrAs4qW-wYo2t-2bFkQBH8koiM>
Subject: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Aug 2017 02:36:25 -0000
Ben Campbell has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is probably just a matter of me being dense, but I'd like to understand what I am missing: Is it legal to mix certificate policies in a given cert path? The last paragraph of section 5 implies that you can, but doesn't say so explicitly. If you _can_ mix policies, what happens if you do? If I read the rules in 4.2.4.4. correctly (and it's likely that I am not), if you run into a cert in the chain that does not follow this profile, it's likely to give a null VRS-IP or VRS-AS value, which would seem to invalidate an certificate further down the chain that _does_ follow this policy? So, I guess it comes down to the following: If mixed policies are allowed, how does that work? If mixed policies are not allowed, there needs to be text that says that. It's quite possible such text exists (here or elsewhere), and I missed it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: - General: There's a lot of amending going on here--does this draft really not update any RFCs (e.g. 6487)? - 4.2.4.4: -- "Any extension not thus identified MUST NOT appear in certificate x." (Repeats multiple times) That seems to prevent future extensibility. Is that the intent? -- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT appear on a CRL issued by the CA represented by certificate x-1" Is this intended as a requirement to check CRLs? If so, please say that explicitly. Editorial: -4.2.2.1: The third paragraph seems redundant to the first paragraph (pattern repeats in several sections.)he - 4.2.4.3: "Either the IP Resources extension, or the AS Resources extension, or both, MUST be present in all RPKI certificates, and if present, MUST be marked critical." "... and if present..." seems redundant, since the previous clause said one MUST be present. - 4.3.4.3: "... values are NOT supported..." a floating, capitalized "NOT" is not defined in RFC 2119. I suspect the all-caps is just for emphasis, but we typically reserve that for RFC 2119 keywords. - 4.2.4.4 : -- "Certificate validation requires verifying that all of the following conditions hold, in addition to the certification path validation criteria specified in Section 6 of [RFC5280]." The "... in addition to..." part doesn't seem quite true. For example, making sure the current date fits in the active range, ensuring a cert is signed by the issuer, etc. are already covered in 5280. - - "...certificate MUST contain all extensions defined in section 4.8 of [RFC6487] that must be present." That seems tautologically true. If this is a statement of fact, then please avoid the MUST. If this is really a new normative requirement, then I'm confused at the intent. -- "all extensions defined in section 4.8 of [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be present. " It would be more reader-friendly to mention what extensions are defined in 4.8.9. -- "7. Compute the VRS-IP and VRS-AS set values as indicated below:" Inconsistent voice. -- list entry 7, 4th bullet: "If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension." That seems identical to the first bullet. Should it has said "AS Address Delegation extension"?
- [sidr] Ben Campbell's Discuss on draft-ietf-sidr-… Ben Campbell
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Tim Bruijnzeels
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Alvaro Retana (aretana)
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Ben Campbell
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Tim Bruijnzeels
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Ben Campbell
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Tim Bruijnzeels
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Ben Campbell
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Tim Bruijnzeels
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Ben Campbell
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Tim Bruijnzeels
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Ben Campbell
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Alvaro Retana
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Tim Bruijnzeels
- Re: [sidr] Ben Campbell's Discuss on draft-ietf-s… Carlos Martinez