I attempted to raise this issue at IETF 78 (sic), but it's still in the draft. Sorry for not having been more annoying about this. :)
The case for why we need the "staging period" is pretty much non-existent. There's an assertion that we need it, and a vague comment in section 2 suggesting that somebody somewhere has a worked example of a validator that will break without this, but I see no strong case made anywhere in the document. If somebody has such a validator, and wants to 'fess up to it and explain why this is not just a case of the validator being broken, go for it, but as following the proposed process would require some not completely trivial changes to running code in the case of at least one implementation (mine), I think we need more justification than what I see in the doc now. Consider what would happen if, instead of following the process mandated by this document, a CA simply started issuing new certificates and reissuing old ones as fast as it reasonably could under the "NEW CA", until it had managed to overwrite everything issued by the "OLD CA". What terrible thing happens as a result of this? I have running code that has operated this way for several years in test environments, and if there have been any failures as a result of this, they've been subtle enough to escape notice. So I don't see the need for the staging period here at all, but if there is a need, the doc needs to be a lot clearer about it, so that even I can understand it. The other thing that I find interesting here is that there is *no* delay mandated in the case where I think there might really need to be one: how long to wait after reissuing and publishing all of the CA's products under NEW CA before asking CA's parent to revoke OLD CA. This interval seems much more likely to matter, because the place where we're most likely to be screwed by caching somewhere out there is old subordinate certificates issued by OLD CA, not OLD CA itself. Given these (linked) issues, I don't think this doc is ready yet. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
