Re: [sidr] Questions about draft-huston-rpki-validation-01

[Stephen Kent <[e-mail]>]

Geoff,
> Hi Steve,
>
> I appreciate the backlog of mail you are working from, as you note in your mail, but
> I always think it useful to have carefully read a document before performing a critique. I'm sure
> you would agree with that sentiment. I was therefore quite surprised to find you had said the
> following:
>
>> 2- A separate concern is that the candidate doc contains two separable cases: one relaxes
>> path validation by not mandating that every subordinate cert contain only a subset
>> of the resources in the parent cert. The other case introduces the notion of a join
>> into the RPKI tree structure. This latter case was extensively criticized during the
>> SIDR WG meeting, by a number of folks. I suggest that case not be part of a new WG
>> doc at this time.

I did read the doc carefully, and we exchanged a few very detailed 
messages in mid-February,
prior to the SIDR meeting in London. But, that was a few months ago, and 
I conflated your
briefing at that meeting (specifically slide 15) with the text of the 
document.
My bad.
> I would be grateful for the precise reference in the "candidate doc" you talk about
> to the concept of a "join". I looked though draft-huston-rpki-validation-01.txt, and
> maybe I missed something incredibly obtuse and well buried in the whitespace, but I
> couldn't find any such reference in this document. Are you perhaps performing a critique
> of some other draft in this rather lengthy message and not in fact referring to
> draft-huston-rpki-validation-01.txt at all?
you're right; As noted above, I was referring to slide 15 in your 
briefing at
the SIDR meeting (a briefing on the doc in question, hence my confusion).
> The description of the first case is also inappropriately informal - the alternative view
> described in the draft is that a relying party can consider a certificate to be valid
> with respect to only those resources that are contained in all certificates that form
> the validation path. Perhaps the subtle difference in your description might be the
> cause of your evident discomfort with what you believe is contained in this document.
The "algorithm" in the I-D, Section 3.2, describes validity in terms of a
"specific resource". The definition of the phrase specific resource is 
vague,
at best. It made sense if one assumed that the specific resource was 
contained in
an EE or CA) since that would avoid declaring a superior CA cert as 
invalid if an
RP did not try to evaluate such a cert. But, for the incremental, top 
down CA
cert eval process, there is no indication of how one should determine a 
specific
resource. Your slides were better ion this point, suggesting that one 
construct
the set of valid resources as part of the cert path evaluation process. 
But, you
noted that my criticism of the "join" aspect of you design was 
inaccurate, because
it is not in the doc in question, so, equivalently, the improved 
description of
the proposed path validation alg in youyr slides ought not be in scope 
either :-).
> I think a careful read of section 2 of this draft adequately addresses why your proposal for
> additional operational procedures in point 1 of your note seems to be well wide of addressing the issues
> described in the draft.
I agree that my suggested CA practices represent a deviation from the 
mechanism you
are tryign to describe. But, if the WG is to consider revising path 
validation
based on the concerns you cite, then it makes sense to ask whether RIR 
CAs, in particular,
are doing what could already be done to avoid the problems in question. 
If not, then it
seems somewhat premature to impose significant changes on all RPs when 
CAs are not
doing what they could to address this potential problem. I'm not saying 
that we
ought not consider your proposal, but let's try to avoid the problem 
with easy,
prudent behavior by CAs, first.
> The assertion in point 3 that this is "not viable" I interpret as one opinion, most likely one held
> by yourself. Obviously there are other opinions and perspectives on this matter, and this draft
> describes such a different perspective and also includes the motivation behind it. I would recommend
> that perhaps this conversation would benefit from such a careful reading of the draft in question.
As I noted, and as you well know, I read the draft carefully and sent a 
couple of long messages to
you, cc'd to the WG chairs, on 2/13 and 14. The perspective of the I-D 
is not the issue; the issue is that it is imprecise on a number of 
important points. It is not a rigorous description of a proposal. Of 
course there are other opinions; there always are in the IETF.

Steve