At 12:36 PM +1000 7/14/10, Geoff Huston wrote:
>> - Key roll-over algorithm
Our software currently implements a specific way to do roll-overs. At
the time we implemented this it wasn't 100% clear to us how this
*should* be done, and indeed whether there should be some prescribed way
to do this.
I believe that we need to have a single, prescribed way to do
this; each CA needs to know what is expected of it by its
subordinate CAs and by all RPs. I believe we should have a separate
document that clearly articulates what a CA is required to do.
There are CA-local aspects to this procedure, as Geoff's text
notes. The parameters for those belong in the CPS for the CA. The
current description is not normative and I think that needs to
change.
You are proposing that the procedure as described in section 8 of
draft-ietf-sidr-res-certs-18.txt be placed into a normative form in
its own document?
I am proposing that a revised, updated version of that text become a
stand alone, standards track document.
The addition noted in the WG mail thread was the addition of a delay
between steps 3 and 4, to allow Relying Parties to collect the new
CA and add it to their local repository caches.
Is there a suggested period for local RPs to refresh their local
repository cache at this point?
I think we discussed this on the list, and suggested at least once
per day. However, I also recall that we removed mention of this from
the architecture document and agreed to create a new document that
would contain suggested operational practices. I don't know that
anyone is generating that document, yet.
...
I guess the big assumptions here are:
a) It's okay that two keys share a publication directory. The manifest
for a key (using a strict filename pattern: keyhash.mnf*) tells you what
to expect for the specific key.
*: we plan to change the extenstion .mnf to .mft as specified by the
latest repos draft later.. This was implemented before the draft
contained this recommendation..
I feel strongly that the repository structure document needs to
mandate the file extensions, not make them recommendations.
MUST not MAY?
yes. My reasoning is two-fold:
- we have seen a lot of examples where folks see conventions
described in a non-normative fashion in an RFC, and then code is
created that relies on the conventions. This seems like a perfect
case where a developer might be tempted to do precisely that.
- I see no benefit to allowing other file extensions to be used here.
...
I think option B is the more elegant of the two in that this offers the
least surprises to the child. On the other hand option A has a possible
use case for un-planned roll-overs. It allows for a re-key followed by
revocation of the old production key. In principle this should not
affect the child unless the child is using its old certificate out of band.
I think it's appropriate for the rekeying CA to reissue certs for
its children, i.e., option A above. But, it may not be OK to delete
the old cert immediately. I worry about race conditions for RPs.
"delete" or "revoke"?
delete.
The procedure describes "overwriting" at the repository publication
point (in order to preserve the integrity of the AIA pointer of
subordinate products), but does NOT propose revocation of the
overwritten subordinate products of the CA with the old key.
yes, I understand (although I didn't understand at first :-)). If
one does not delete (overwrite) then the AIA pointer would have to
become a pointer to the directory, vs. the file. But, I agree that
your current description of how to perform key rollover is consistent
with the current definition of the AIA pointer.
...
- we do not assume strict top-down tree walk for RPs when we
analyze possible race conditions re rekeying.
specifically, it may be useful to consider RPs performing AIA
"walks" as described in Tim's note, in which case preservation of
the integrity of the AIA chain during the process is of importance.
that's one good example, but I have another one in mind. If one
begins a top-down tree walk, one may encounter repositories that are
temporarily unreachable, or directories that are locked. I'd like to
allow RP software to skip over these, and come back later. I
envision parallel repository accesses, to help avoid possible DoS
vulnerabilities. Since we assume that an RP will usually (although
not always) have a local copy of repository system data, it has info
that could allow it to try to skip over directories or whole
repositories that are inaccessible. I wan tot make sure that our key
rollover design does not preclude such behavior.
...
Finally, I am concerned that we have made almost no progress on
the top-level questions I posed about alg migration. Geoff
responded to my message, I replied to him, and then the discussion
stopped.
my apologies - other circumstances have arisen that take my attention.
no problem. We ought not be the only two people who care about this :-)!
...
My concerns, as noted in the rpki-algs draft, is to avoid what could
be construed as gratuitous duplication in the RPKI on the basis that
what would be highly undesireable was an outcome where a ROA could
be validated with algorithm A, but an equivalent assertion could not
be validated in the realm of algorithm B.
I agree that we want to avoid "gratuitous duplication in the RPKI"
and that's why I believe that we need to think through the process,
to avoid the stuation you cite.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
