At 10:25 PM -0500 11/13/11, Brian Dickson wrote:
On Sun, Nov 13, 2011 at 9:16 PM, Stephen Kent <[email protected]> wrote:
You suggested that we codify how the community should deal with problems
that motivate delaying a phase transition. We're not writing the timeline
document now, but the text at the beginning of this message is an effort to
make sure such considerations are addressed in that document.
When you say "timeline document", do you mean "timeline for specific
implementation of the phases in this document"?
I ask because the algorithm-agility sure looks like a timeline document.
I mean a document that associates dates with the phases described in the
alg agility doc. I've reworded the agility doc to say "timetable"
instead of "timeline" to try to avoid confusion.
...
This statement is entirely predicated on having Phase 2, as it is currently
defined, after Phase 1 (CAs ready for receiving B) and before Phase 3
(when RPs are able to validate using B). I don't see what this step
in this order, buys us, or even that it is necessary at all.
Phase 1 allows early adopter CAs to get certs under the new alg
suite, but does not require them to do a lot of work, because they
don't have to issue new certs except for the children who ask for
them.
Phase 2 requires CAs to do this work, which enables RPs to test their
RP software with the new alg, if they wish, i.e., another early
adopter capability.
Phase 3 says RP have to be able to do this.
I think the order makes sense.
Let's take a look at what happens after Phase 3:
- RPs speak "B".
- CAs can process "B".
This characterization strikes me as backwards. RPs process Suite B
products. CAs generate Suite B products. CAs "process" requests for
certs under Suite B. But, let's not quibble.
The rest of your message argues that Phase 2 is unnecessary. But, you
acknowledge the need for CAs and RPs to experiment with software that
supports Suite B, and processes that support transition from A to B.
Thart is precisely what Phase 2 enables. It gives RPs time to work on
processing Suite B product sets, but it does not require that they do
so. Also, if some CAs didn't get the Suite B product set generation
right there is an opportunity to provide feedback, but Suite A
products sets are still there, so things don't break. Trying to move
from Phase 1 to Phase 3, as you suggest seems very likely to cause
things to break, especially when coupled with the notion that a CA
can decide to make use of only Suite B if it wishes.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
