At 3:42 PM +0200 7/6/10, Tim Bruijnzeels wrote:
Hi all,
this discussion seems to have calmed down somewhat, but the conclusion
is not entirely clear to me. When this thread was active I did not have
time to properly read all messages and respond. I would like to give my
delayed input now, coming from the implementation we have been working
on at the RIPE NCC.
- AIA
First of all the question was raised whether AIA fields would need to be
supported at all. Several people mentioned that it's useful for
discovery if not for validation; and they would like to keep it.
I just want to confirm that our validator supports bottom-up validation
of _downloaded_ objects using the AIA pointers. It starts by building up
the chain up to a known TA (you have to point the validator to a TA file
as well). If the chain can not be built validation fails. Then actual
validation is done top-down for this chain only.
We figured this would be useful for validating a specific object that
may be published somewhere outside of (next to) a 'normal' repository.
Maybe the use case is not that strong for ROAs, but there may be a
stronger case for other object types in future.
I agree completely with this argument for retaining AIA.
- 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.
So, when we build this we thought that our implementation did not
conflict with any drafts (as known at that time). Having said that our
software can be changed if it turns out that it's wrong in general, or
just not in line with a prescribed way to approach this problem.
However, we are not likely to change anything as long as the prescribed
way to do this remains a moving target.
certainly fair.
I would like to submit to the wg how we currently implement these
roll-overs. This is not the only possible approach and maybe not the
best, but hopefully it's useful input when considering a draft.
Currently our software implements key roll-overs using the following
approach:
- it uses stable publication directory for a 'logical CA'
- a 'logical' CA publishes CRLs and manifests for *each* of its keys
- but it only publishes child objects for the 'active' key
- old keys only publish a CRL and a manifest containing just this CRL
- child certificates have a stable URI based on their public key
I don't understand this description based on the language above.
After a lot of careful reading I believe that I understand what Geoff
described in Section 8 of the res-certs I-D. Since Geoff later said
that your description matches his text, I won't worry about my lack
of understanding above :-).
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. But, that
aside, I agree that it's OK to have two manifests and two CRLs at the
same pub point, associated with the old and new CA instances. The
naming convention for manifests and CRLs (which also needs to be a
standard to make this work), accommodates this nicely.
...
I deleted your example in part because it seems to specific to the
remotely managed CA model, as you note later.
Upon receiving a new certificate a new ROA object is generated. Strictly
speaking this is not necessary, but currently our software is not doing
smart enough checks to determine this. It assumes that a new certificate
means more resources or a different validity time, so a new ROA object
is generated automatically.
I think one should not mandate generating new ROAs when they are not
strictly required. Again, in an up/down protocol model the CA that
is rekeying can't
generate ROAs for its children anyway, so ...
One thing to note is that our implementation is using a fully hosted
model for the moment. So child CAs are _hosted_ and live in the same
environment as our production CA. That means that we can actually
trigger the child CA to request a new certificate, and perform triggered
effects for itself like re-issuing a ROA object, when the parent has its
new key 'activated'.
The fact that your model is based on experience building the hosted
CA approach is worrisome to me. We need to publish standards that
are not biased by this specific model. I'm not saying that what you
have done is wrong, but I don't want SIDR to pursue an approach that
is influence by that model, since it is not the general case (even if
it becomes the most common case).
We do plan to implement support for remote child CAs using the up-down
protocol in the near future. And when we do we will no longer be able to
trigger a re-issuance request for the child CA. I see two possible
approaches:
A) The parent CA re-issues anyway based on the last known request
without informing the child CA -- there is no way to tell the child
using up-down.
B) The old key remains active for *this* child CA, until it requests on
its own initiative. When it does the new key becomes active for this
child as well. And the system keeps track of this internally..
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.
So, to summarize, I suggest:
- the design notes in section 8 of res-cert (that deal with
key rollover) need to be removed and made into a separate, standards
track document document. As Geoff has already noted, that text needs
to be updated to insert delays in the process to minimize the
likelihood that an RP will acquire an inconsistent set of repository
objects. I am still concerned that such delays may not suffice, but
I'll need to make a case for that when we have a revised description.
- we do not assume strict top-down tree walk for RPs when we
analyze possible race conditions re rekeying.
- the respos-struct document needs to mandate file extensions
and naming conventions, rather than merely proposing them as
recommendations. If we say that we can have two manifests and two
CRLs in a directory, one per CA key instance, then it seems important
that we all agree on how the names for these files are generated.
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 concern is that we could adopt a simple key rollover scheme and
associated repository structure that is very different from what we
may determine that we need for alg migration. If so, then when we add
support for alg migration, we probably will impose an overlay on the
repository system that makes the overall system much more complex.
Moreover, I anticipate that we will gain a lot of experience with key
rollover in 2-3 years. But, alg migration may not begin for 5 years
or longer. if we use the same procedure for both, we will have
experience from the key rollover process that translates directly
into alg migration. If not, then we will have little basis for
confidence when it comes to alg migration. That may not satisfy the
goal that Tim set for us, and it may cause us terrible problems down
the road.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
