Hi, My apologies for the delay - I am just back from a late summer holiday.
Let me address the DISCUSS is in this, and Terry Manderson’s email, first. > On 29 Aug 2017, at 04:36, Ben Campbell <b...@nostrum.com> wrote: > > 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. > First of all it was my understanding that there was an agreement with the AD that actual deployment should be discussed in sidrops. So this document serves as a benchmark to describe the alternative algorithm. In my opinion a mix is supported by this document, but the choice whether this is an acceptable deployment model can be discussed later. The current document leaves the OID as a per certificate choice and 4.2.2.4 provides a validation model that can be used in either case. In either case the VRS-IP/AS are calculated as described in item #7. Under item #8, the VRS-IP/AS is then compared again to the certificate to determine if it was ‘over-claiming’ compared to its acceptable VRS-IP/AS set. The OID choice determines whether this results in a warning about such over claiming resources, or rejecting. The algorithm defined here when only old OIDs are used is semantically equivalent to section 7.2 of RFC6847. Note that item #7 does not have explicit text on the case where ‘inherit’ is used, but I believe that this is technically covered by the text in sections 2.2.3.5 and 3.2.3.3 of RFC3779. Essentially: the value of the signing certificate applies, use recursion if that also uses inherit. > > ---------------------------------------------------------------------- > 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 mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
