Tim,
The second point I tried to make is that if it is already clear that consensus
will never be reached on this, then spending more effort on it is a waste of
everyone's time. I understand that there are no guarantees that consensus will
be reached, but if there is a guarantee that consensus will *not* be reached,
then the exercise is pointless.
I understand your reluctance to invest time into a document that may or may
not become an RFC. But, that is what all of us do when we write drafts.
There
are no guarantees; many I-Ds become RFCs, but not all.
I cannot guarantee that the WG will reach consensus on this draft.
First, the consensus
call if made by the WG chairs, not by me. Second, I assume you and your
colleagues
plan to re-write the document, and so it's premature to comment on the
likely
success of a revised document.
So far this discussion actually looks promising and more constructive than it
has been. Can I interpret your statement about 'maybe the result will be worth
pursuing' to mean that you agree that we can continue discuss this
constructively, and it is not certain a priori that it will be rejected?
I am willing to discuss this constructively. I provided extensive comments,
including numerous edits to try to improve the text several months ago. If
you and Carlos and Andy are serious about going forward, I suggest two
actions:
1. review the edits I suggested month ago and either adopt them
or explain why they are rejected
2. reword the proposed solution so that it is technically
unambiguous and
aligned with RFC 6487. In rewording the solution description,
please address
the issues I noted, reproduced below.
The text in step 6 seems a bit vague. It refers to a “resource set”
but that phrase is not defined in this document. Looking at 6487,
the phrase appears twice, in Sections 4.8.10 and 4.8.11. In those
sections it is referring to the set of resources acquired from a
parent when the inherit bit is set. If the intent is to use this
phrase to refer to the set of resources extracted from an RPKI
certificate, irrespective of whether the inherit bit is set, this
text should say so.
The security considerations section says “… the validation path
encompass the resources that are included in the validation query.”
One might read this and infer that a set of INRs is an input to the
validation algorithm. But 6487 does not say INRs are a separate
input to validation. A certificate to be validated is an input to
this algorithm, and I assume that was what is implied in step 6 and
in the text quoted above. If my assumption is correct, this should
be stated clearly in both places.
Thinking about this in more detail, I fear that the results from the
modified algorithm will not yield what you seem to want, at least
not in all cases. If one validates only router certificates and EE
certificates for (non-PKI) signed objects, e.g., for ROAs or
Manifests, then the outcome will yield what I think you want.
However, when validating a CA certificate that “over claims” the
certificate will be considered invalid by the revised step 6, just
as with the current validation algorithm. (The over claiming could
result from some types of CA errors or attacks, or during an “free
style” resource transfer.)
RP software may validate each CA certificate that it initially
acquires, before fetching subordinate signed products. This is a
reasonable strategy to avoid DoS attacks based on returning bogus
certificates to an RP. Also, when a cached CA certificate is
discovered to have changed, an RP probably will validate it before
adding the certificate to the cache. In these cases, the revised
step 6 will treat this certificate as invalid, because it contains
resources not present in all parent certificates. Thus all
certificates and signed products below it will become invalid. So, I
don’t believe the change to step 6, as described in your I-D, and as
interpreted above, will accommodate the motivations described in the
I-D that you plan to replace with this one.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
