Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)

[Tim Bruijnzeels <[e-mail]>]

Alvaro, Ben,

Given that I will meet with my co-authors in person at IETF100 I would like to take the opportunity to discuss things there with them in person and then get back to the list. Will both of you be there as well by chance? I think we could benefit from a chat in person in order to make updates more efficiently.

Tim

> On 30 Oct 2017, at 20:45, Alvaro Retana <[e-mail]> wrote:
> 
> Tim:
> 
> Hi!
> 
> FWIW, I agree with Ben that the text doesn’t resolve his concerns, and it doesn’t reflect what you said on the thread.  I think you two are actually saying the same thing (or pretty close), but using different words.  
> 
> I think that at least (+ the specific points made by Ben below) the text needs to explicitly expand the new Abstract text throughout the rest of the document, potentially include an example of mixed OIDs, and talk about the use of the new OIDs in with the old procedure.  Some of these things are sort of implicit already; for example, using the new OIDs with the old procedure is not specified in rfc6487…but explicitly mentioning it in this document won’t hurt.
> 
> Thanks!
> 
> Alvaro.
> 
> On October 27, 2017 at 5:57:08 PM, Ben Campbell ([e-mail]) wrote:
> 
>> Hi Tim, 
>> 
>> (Apologies for the delayed response) 
>> 
>> Sorry, but these changes do not resolve my concern. Specifically, I think implementors reading this draft will create inconsistent of mixed-OID chains. Commenting specifically: 
>> 
>> Section 4.2.1 was changed from saying that the new OID indicates that the procedures in 4.2.4.4 are to be used to saying that the new OID “drives the decision” in step 8 4.2.4.4. “Drives the decision” is vague without details about how the how the rule in step 8 of 4.2.4.4 actually uses that information. There has been no change in 4.2.4.4 to address this. Sections 4.2.2.5 and 4.2.2.6 still say that the new OIDs indicate the procedures in 4.2.4.4 are to be used. The “rather than” clause has been removed, but I don’t think that changes anything, and it’s still a reasonable (and likely) interpretation to assume that certificates with the old OID will follow the old validation policy. 
>> 
>> I don’t see how the new text in the abstract changes anything. (And if it did, I would argue the abstract is the wrong place to say it.) 
>> 
>> I think fixing this would require one of the following changes: 
>> 
>> 1) Disallow mixed-OID chains, or… 
>> 
>> 2) The following changes to allow mixed-OID chains: 
>> - Explicit text that implementations MAY/SHOULD use the new validation policy even for certs in the chain that do not include the OID. (Perhaps only if the root cert included it?) 
>> - Change the description of the OID to say the OID is an input into the new validation rules, not a discriminator about which rules to use. (Which, if I understand correctly might remove the point of a new OID in the first place. Maybe it only matters in the root cert?) 
>> - Add text to 4.2.4.4 to explain exactly how the rules use the OID as an input. 
>> 
>> Thanks, 
>> 
>> Ben. 
>> 
>> > On Oct 6, 2017, at 8:36 AM, Tim Bruijnzeels <[e-mail]> wrote: 
>> >  
>> > Dear Ben, Alvaro, others, 
>> >  
>> > Please find a new version -09 attached. Not uploaded yet, because I thought it better to discuss here first and get clarity. 
>> >  
>> > With regards to the changes. I understand that the non-normative text in the abstract and the sections where the new OIDs are introduced in -08 were inconsistent with the intent (and normative) text in section 4.2.2.4 to have one validation algorithm that can be used to validate both current RFC6487 Resource Certificates as well as Resource Certificates that use the new OIDs introduced here.I hope that this new version eliminated this ambiguity. Ben, can you please let us know if this version addresses your concerns? 
>> >  
>> > Alvaro, it’s of course your prerogative to take this back to IETF or WG last call if you feel this confusion was widespread and let to misinterpretations. For our part I do want to re-state though that the normative text in 4.2.2.4 was quite explicit, as well as the deployment considerations section where it’s explicitly mentioned that this is a per CA choice and a mix of OIDs in a tree is possible. I also referred to this in my email to the WG when -07 was published on 3 October 2016. So, it was certainly not our intent to have any unclarity or inconsistency about this in earlier sections in the document. 
>> >  
>> > Please let me know what you think. If we can proceed, then I can update this document with the other review comments and upload, and hopefully get this rolling again. But first I want to make sure that the issues above are resolved. 
>> >  
>> > Kind regards, 
>> >  
>> > Tim Bruijnzeels 
>> >  
>> > ===== 
>> >  
>> > For the impatient, we made changes to the following sections: 
>> >  
>> > Abstract 
>> >  
>> > This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the RPKI, while retaining essential security features. 
>> >  
>> > Where the procedure specified in RFC 6487 requires that Resource Certificates are rejecting entirely if they are found to over-claim any resources not contained on the issuing certificate, the validation process defined here allows an issuing Certificate Authority to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate. 
>> >  
>> > This choice is signalled by form of a set of alternative Object Identifiers (OIDs) of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, and certificate policy for the Resource Public Key Infrastructure (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a Trust Anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487 
>> >  
>> > Furthermore this document provides an alternative to ROA (RFC 6482), and BGPSec Router Certificate (BGPSec PKI Profiles - publication requested) validation. 
>> >  
>> > 4.2.1. Certificate Policy (CP) for use with validation reconsidered in the Resource PKI (RPKI) 
>> >  
>> > ... 
>> > This alternative Certificate Policy is the same as the Certificate Policy described in [RFC6484], except that it is used to drive the decision in step 8 of the validation procedure described in Section 4.2.4.4. 
>> >  
>> > 4.2.2.1. OID for id-pe-ipAddrBlocks-v2 
>> >  
>> > This document request an OID for the extension id-pe-ipAddrBlocks-v2 (id-pe TBD2). This OID MUST only be used in conjunction with the alternative Certificate Policy OID defined in Section 4.2.1. 
>> > …. 
>> >  
>> > 4.2.2.3. OID for id-pe-autonomousSysIds-v2 
>> >  
>> > This document request an OID for the extension id-pe-autonomousSysIds-v2 ( id-pe TBD3). This OID MUST only be used in conjunction with the alternative Certificate Policy OID defined in Section 4.2.1. 
>> > …. 
>> >  
>> >  
>> > 4.2.2.5. Amended IP Address Delegation Extension Certification Path Validation 
>> >  
>> > Certificate path validation is performed as specified in Section 4.2.4.4. 
>> >  
>> > 4.2.2.6. Amended Autonomous System Identifier Delegation Extension Certification Path Validation 
>> >  
>> > Certificate path validation is performed as specified in Section 4.2.4.4. 
>> >  
>> > <draft-ietf-sidr-rpki-validation-reconsidered-09.txt> 
>> >  
>> >  
>> >  
>> >> On 22 Sep 2017, at 22:56, Ben Campbell <[e-mail]> wrote: 
>> >>  
>> >>>  
>> >>> On Sep 19, 2017, at 6:54 AM, Tim Bruijnzeels <[e-mail]> wrote: 
>> >>>  
>> >>>  
>> >>>> On 18 Sep 2017, at 23:36, Ben Campbell <[e-mail]> wrote: 
>> >>>>  
>> >>>>>  
>> >>>>> On Sep 18, 2017, at 8:15 AM, Tim Bruijnzeels <[e-mail]> wrote: 
>> >>>>>  
>> >>>>> Hi Ben, all, 
>> >>>>>  
>> >>>>>> On 15 Sep 2017, at 23:20, Ben Campbell <[e-mail]> wrote: 
>> >>>>>>  
>> >>>>>> Hi, 
>> >>>>>>  
>> >>>>>> See comments inline. I apologize in advance if I am just being dense, and I cannot claim to be an expert on how one applies a path validation policy OID in general. 
>> >>>>>>  
>> >>>>>>  
>> >>>>>> Thanks! 
>> >>>>>>  
>> >>>>>> Ben. 
>> >>>>>>  
>> >>>>>>> On Sep 14, 2017, at 7:00 AM, Tim Bruijnzeels <[e-mail]> wrote: 
>> >>>>>>>  
>> >>>>>>> Hi, 
>> >>>>>>>  
>> >>>>>>> Sure. I also proceeded to discuss your and Terry’s points, but apparently not to the desired level of clarity. Let me try again here, and tackle both your and Terry’s discuss items since they are closely related. 
>> >>>>>>>  
>> >>>>>>>> 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. 
>> >>>>>>>  
>> >>>>>>> According to this document it is. Section 4.2.2.4 starts with the following: 
>> >>>>>>>  
>> >>>>>>> The following is an amended specification for path validation to be 
>> >>>>>>> used in place of section 7.2 of [RFC6487] allowing for the validation 
>> >>>>>>> of both certificates following the profile defined in [RFC6487], as 
>> >>>>>>> well as certificates following the profile described above. 
>> >>>>>>>  
>> >>>>>>> So the intent here is to describe a single validation algorithm that can be used to validate a chain of old OIDs only (in which case it’s semantically equivalent to the current spec in RFC6487), new OIDs only (as described in the example in 4.3), or indeed a mix - but no example is given on how that works out. 
>> >>>>>>>  
>> >>>>>>>  
>> >>>>>>>> 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? 
>> >>>>>>>  
>> >>>>>>>  
>> >>>>>>> The “Validated Resource Sets” (VRS-*) are always calculated, regardless of whether the old or new OIDs are used. 
>> >>>>>>  
>> >>>>>> This is where I am confused. The calculation of VRS is described in this draft in the amendment to the path validation in section 7.2 of 6487. I assumed that the amended path validation procedure only applies with the “new” OID. Is that incorrect? If so, can you point to the text that states that? (It’s entirely possible I missed something, or completely misunderstand how the OIDs are applied. ) 
>> >>>>>  
>> >>>>> First paragraph of 4.2.2.4: 
>> >>>>>  
>> >>>>> "The following is an amended specification for path validation to be used in place of section 7.2 of [RFC6487] 
>> >>>>> allowing for the validation of both certificates following the profile defined in [RFC6487], as well as certificates 
>> >>>>> following the profile described above." 
>> >>>>>  
>> >>>>> So, yes, as far as I am concerned the intent was to have this cover both the old and new OIDs. Where the algorithm if applied to old OID only is semantically equivalent to section 7.2 of RFC6487 - or at least: it has the same outcome. 
>> >>>>>  
>> >>>>  
>> >>>> That intent surprises me, I was under the impression the entire document was specific to the new OIDs. This seems to be supported by this text in the abstract: 
>> >>>>  
>> >>>> "The use of this updated procedure is signalled by form of a set of alternative Object Identifiers (OIDs) indicating that the alternative version of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, and certificate policy for the Resource Public Key Infrastructure ( RFC 6484) defined in this document should be used.” 
>> >>>>  
>> >>>> … and in the specific case of the certificate validation policy OID, there is this text in 4.2.1: 
>> >>>>  
>> >>>> "This alternative Certificate Policy is the same as the Certificate Policy described in [ 
>> >>>> RFC6484], except that it indicates that the validation rules described in 
>> >>>> Section 4.2.4.4 are to be used.” 
>> >>>>  
>> >>>> If the rules in 4.2.4.4 are used even when that OID is not present, then I’m confused about what the OID signals in the first place. 
>> >>>  
>> >>> The OIDs are used to drive a decision in the rules described in 4.2.4.4. 
>> >>> = Old OIDs -> reject over-claim, this has the same result as section 7.2 in RFC6487 
>> >>> = New OIDs -> warn on over-claim 
>> >>  
>> >> Are you suggesting the text “should” say that, or “does” say that? As written, the OID seems to drive the selection about whether you use the rules in 4.2.4.4 or not. But I think you are saying that, if you implement these OIDs, you SHOULD/MAY use the rules in 4.2.4.4 all the time, but use the OID as an input to those rules. Is that correct? 
>> >>  
>> >>  
>> >>>  
>> >>> So as far as clarity goes, it might be better to either leave out the set regarding the need for the different OIDs in their respective sections, or say “This OID is used to in the decision process of the validation rules described in 4.2.4.4. 
>> >>  
>> >> I’m not sure what you mean by the former. If you go with the latter, then the rules in 4.2.4.4 will need to be explicit in how the OID is used in that process. 
>> >>  
>> >>>  
>> >>>>> If this needs to be more explicit I am happy to accept a suggestion - as an author knowing my own intentions, it’s not always trivial to see how others would interpret text differently. 
>> >>>>  
>> >>>> I’m not sure this is just a matter of clarification. The text I mention above explicitly says the OID signals the use of the amended CP. I have to assume that was the working group intent, and what was understood by people during IETF LC. If that is _not_ the intent, we would need some degree of consensus to change that text. ( I suspect that would mean going back to the WG or IETF LC, but I will leave that to Alvaro to decide.) 
>> >>>>  
>> >>>  
>> >>> It was my assumption that my intent was clear. 
>> >>>  
>> >>> But I will accept whatever Alvaro decides on this. 
>> >>>  
>> >>>  
>> >>>> My strictly personal opinion is that it would be _really_ confusing to have some aspects of the new CP apply even when the new OID is not used. 
>> >>>  
>> >>> The assumption on my part here was that RPs can decide to support this RFC-to-be and then use section 4.2.4.4 to validate old and new CP alike. 
>> >>>  
>> >>> The process described in 4.2.4.4 when used for old OIDs only has the same outcome as section 7.2 of RFC 6487. It’s true that “Validated Resource Sets” are not named in RFC6487, but in a tree where only old OIDs are used one will find that the Validated Resource Set for a given *valid* certificate always matches the certificate itself. 
>> >>  
>> >> As I mentioned above, if the idea is to always use the rules in 4.2.4.4, and use the OID to drive decisions _within_ those rules, the rules need to be updated with the explicit details. 
>> >>  
>> >>>  
>> >>> Thanks 
>> >>> Tim 
>> >>>  
>> >>>  
>> >>>>  
>> >>>> Thanks, 
>> >>>>  
>> >>>> Ben. 
>> >