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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
