Eric,
i think we are making progress. thanks for the feedback.
...
I really think we should address these issues in a single document.
It seems like splitting this off into a separate/as yet unwritten
document is likely to cause some problems. In particular, since
that document does not yet exist, and it may not be written and
adopted for some time, this draft will not be complete on its own.
I'm worried that it is hard to judge this document's readiness w/o
these timeline issues worked out or even broached (as they may
demand changes to this process). Besides, isn't the corpus of
drafts rather extensive already (w/o adding another)? :)
My motivation for a separate timetable (vs. timeline) doc is that
there seems to be some agreement that this doc should be a product of
the operator community. The alg transition doc is an IETF
architectural statement, the product of this WG. I can't see
combining the two. Did I misunderstand your concern here?
...
OK, I see. But, aren't there second-order effects of this that we
have to worry about? For example, if I am an ISP whose CA performs
the rollover properly, but my upstream's CA does not, then their
CA's failure to keep up will cause my ISP to no longer be able to
participate in BGPsec, right (because I'm no longer part of a
contiguous BGPsec island)? I realize this is a bit different than
my original example, but upon thinking about the motivation for my
comment, my point was more general. It was that transitioning a CA
to this state can have very undesirable effects.
What you say that you performed the rollover but the CA above you
didn't can you be more specific, re the phase number?
s/I envision/we envision/
fixed
kewl, thnx. One minor nit: can we rephrase one part for clarity.
Instead of "If a problem arises that makes this infeasible for a
substantial number of CAs," can we just specify a little bit about
how this is determined. Maybe something like, "If <whoever the
operational governing body we elect for timeline statements> deems a
problem to have arisen that is significant enough to make this
infeasible for a significant enough number of CAs..."
Good suggestion. I had already changed the text to the following form.
If it is determined that a substantial number of CAs are unable
Since we don't have a good placeholder for the bracketed entity I
think it's easier to make the statement without say who makes the
determination.
...
First, same minor nit as above.
Second, do we want to consider the case were we want to rollback
(perhaps an alg B has become unsuitable for some reason and we need
to choose a new alg B altogether)? I'm not saying the above text
should be yanked, maybe just augmented?
AI had not considered the case of an alg concern at this phase, Good
catch. I'll add suitable text to Phases 1-4.
...
I think this is a very strange comment (and I note that you said it
earlier in this email too). "Use of the RPKI... is optional." Is
the goal of this system to protect the global routing infrastructure
or not?
The goal of this work does not imply that we can force all ISPs to
adopt it. We hope that the RPKI will be very widely deployed and
used, but we acknowledge that it may not me universal. So, both
initially and perhaps forever, the world will consist of resources
that are protected by certs and ROAs, and ones that are not.
Unless we are talking about making this an experimental
expedition, and are prepared to create a globally applicable system
later?
that's not a sentence :-).
If the goal is to secure the global routing system (note I am not
saying universal deployment in the foreseeable future, just global
applicability), then this is an operational non-starter.
I'm glad that we agree that universal deployment is not a likely near
term event. We also agree that the RPKI is globally applicable .
Neitehr of these observations conflict with the fact that its use by
an network operator is optional.
I do not believe it is appropriate for us to try and re-legislate
operational axioms in these drafts. What we could be doing is
grossly misaligning this standards work with operational invariants.
I no longer know what you are referring to. I have said that we
cannot mandate adherence to this process. We can offer it as a
preferred approach and hope that it is followed. We have incorporated
a number of phases so that there is an opportunity to verify the
status of the transition, and to allow the timeline to be pushed back
if necessary. if what you are saying is that we ought not specify any
process that calls for CAs and RPs to try to execute a transition in
a coordinated fashion, over a long time interval, then we have an
impasse. The disagreement is based on perceptions, on both of our
parts, not facts.
> First, not that a CA cannot unilaterally decide to transition to
a new algorithm. There is a requirement that the issuer of its
certificate is prepared to accept a certificate request under the
new algorithm suite (because of the PoP requirement).
I'm sorry, I don't understand.
PoP requires the issue of a cert to verify that the cert requester
posses the private key corresponding to the public key in the cert
request. So, if CA N requests a cert that contains a key under Alg X,
CA N-1 (its parent ) cannot issue that cert until CA N-1 has
implemented Alg X. Does this help?
...
To avoid more flame wars, I will duck your question about my views
on DNSSEC and accommodation of different algorithm suites :-).
Shall I take that as a retraction of your comment? ;)
no.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
