On 12/7/10 12:41 AM, Rob Austein wrote:
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.
If I remember correctly I think Roque and Steve mentioned that CA
certificates on any level may be used by RPs as a Trust Anchor -- even
if you did not plan to make yourself available as a TA (i.e. publishing
your cert info as per TA draft). The staging period was introduced to
give RPs down the chain from you at least some opportunity to notice the
change and start using the new cert in place of the old one..
But as I said, if I remember correctly.. maybe Roque or Steve can
comment on this?
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.
First of all just for reference: our current implementation of the key
roll does not automatically revoke the old key (yet). We keep the old CA
cert, manifest and CRL around. It no longer publishes anything else, but
we are thus able to revoke previously issued stuff that may still be
alive out-of-band. Revocation is, for us, still a manual step that may
be done eg when we suspect a problem with the key. We planned to change
this when the key roll draft is final.
Having said that..
I don't really object to having a staging period here, but it may not
help. Out of band / cached subordinate validation may still fail because
the subordinate no longer appears on the new manifest for OLD CA; it's
published by new CA.
Case 1: top-down validation and caching
The assumption here is that when the new CA certificate is fetched the
RP will also fetch the CRL, manifest and all issued certificates and
objects for this new CA cert. This would mean that your cached
certificates issued by OLD CA would be replaced.
So I guess the big question is: is this a safe assumption to make? Or
maybe even: should there be a normative statement somewhere that RPs
SHOULD do this?
Or maybe even.. non-normative, just operational: should RP tools that
use caching be smart in this case? And before rejecting a cached
subordinate because its parent is revoked try to re-fetch?
Case 2: bottom-up (use signed objects out of band)
If we need to support the case for out-of-band use of subordinate
certificates and objects for as long as possible. And RPs do not care
about manifest validation in this case.. then it might be good to keep
the OLD CA around until everything issued under it is either expired or
revoked; unless there is an overriding reason to revoke OLD CA like key
loss or compromise.
But is there really a use case for this? My impression was that there
wasn't and everything is top-down oriented. And that's why I didn't
resist having the revoke step. If there *is* a use case for out-of-band
support for as long as possible then the model that we have currently
implemented may be useful.
Regards
Tim
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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
