Terry + Leo,
Sorry I didn't around to reviewing your doc sooner.
here are some comments:
4.1: The suggestion that the RPKI needs to support different
algorithms in different jurisdictions conflicts with RFC 6485.
It is not consistent with the algorithm agility design in RFC 6916
(BCP 182), which assumes a single, system-wide alg suite.
If one were to allow different algs on a per-jurisdiction basis,
it would impose a burden on ALL clients, since all of them would
have to support any alg adopted by any jurisdiction. I also note
that Roque's observations about the GOST experience and DNSSEC
argues against this approach.
4.2: I agree with Roque here too. The wording here seems a bit
confusing, since 6916 already describes an alg transition mechanism,
within which the GTA would be included.
5: again, I agree with Roque. Stay consistent with 6485, and
plan on a key roll prior to 2030.
6.1: The wording here might confuse some readers. We have a spec for
RPKI key rollover (RFC 6489). I suggest you mention it and explain
that rollover of the GTA is not covered by that RFC, because of the special
nature of a "root" CA. Then discuss the TAL (RFC 6490) and note that you
see a need to update that spec to better support GTA key rollover.
7: I find the wording in this section a bit confusing. I agree with your
observation that errors at the higher tiers of the hierarchy can have
significant impact. But, as Roque noted, there is no notion of a
system-wide
cert/ROA validation checker. Validation is a distributed function, performed
by each RP. I would expect any RP that detects a problem with its RPKI
signed
objects to notify its CA to have the problem remedied quickly. The
Suspenders
proposal (draft-kent-sidr-suspenders) calls for that behavior, and I would
expect every RP to do that anyway. But, I agree that we should publish a
doc that recommends such behavior by all RPs, including the RIRs as
subordinate CAs under the GTA. I don't know if an automated procedure is
needed
to deal wtih this sort of problem, or if OOB means of contact, which may
vary
based on the CA, suffice.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
