Re: [sidr] key rollover and algorithm migration

[Stephen Kent <[e-mail]>]

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