At 12:27 PM +0200 7/14/10, Tim Bruijnzeels wrote:
Hi Steve,
Geoff already replied to you and the list. I agree with his points.
I do have one remaining comment though. It seems to me that the
algorithm described in section 8 of res-cert is targeting key roll overs
for normal operational CAs. Not CAs that want to be used as TAs...
are you referring to a CA that uses the WG-selected method to publish
info to make it accessible as a TA, or are you referring to the local
TA management mechanisms that are described in
draft-reynolds-rpki-ltamgmt-00?
...
>> 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).
I understand and agree. The reason that I stressed that we are using a
hosted setup is precisely because:
a) I can not be as certain whether stuff will be the same for remote
b) I want to invite people that do have that experience to jump in..
As it turns out in this specific case there is no problem for child CAs,
the parent does not have to wait for a remote child CA when it re-keys
to request a new certificate, it can 'push' and just re-issue as
described in section 8 of the res-certs draft.
OK.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
