On 7/7/10 1:03 PM, Geoff Huston wrote:
>
> On 06/07/2010, at 11:42 PM, Tim Bruijnzeels 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.
>>
>> 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.
>>
>> 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
>>
>
> As far as I can tell this matches the procedure described in the res-certs
> document.
Right. Thanks for pointing this out (and thank you Roque).
I think we started our implementation before this section was added to
the res-certs document. But it's been a while and the initial
implementation was done by another developer. Our implementation is very
close though. The most notable difference is that revocation (step 7-8)
is only done manually when a key is lost or compromised.
Section 8 - where the key roll over is documented - starts with this:
" The following notes provide some additional commentary on the
considerations that lie behind some of the design choices that were
made in the design of this certificate profile. These notes do not
constitute a formal part of the profile specification, and the
interpretation of key words as defined in RFC2119 are not applicable
in this section of the document. "
So the key roll over section is not a formal specification, it's an
example used to justify design choices. And as far as I know there is no
formal specification to this effect at the moment.
Steve suggested that there should be one at the start of this email
thread. My question to Steve, Roque and Sean, and the wg in general is
why? Is there really only one way to do this right?
Don't get me wrong, I think it's quite useful to discuss this. But
should all implementers be forced to do this the same way?
>
>> 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 share this understanding (thats its okay to have two manifests and two CRLs
> in the same repository publication point within the scope of this key
> rollover procedure).
>
>
>> b) It's okay for a key pair to *not* publish *all* valid objects issued
>> by it... This eliminates the need that the child certificate should have
>> a different publication point for the new key.
>
> Again, I share this understanding. The procedure described in the draft for
> key rollover allows the CA with the new key to issue and publish subordinate
> objects that have precisely the same publication point as the comparable
> subordinate object that was issued by the CA with the old key. This
> deliberate overwriting of the published object implies that the CA with the
> old key has, at this point, extant valid subordinate objects that are not
> published.
>
>
>>
>> So, consider this starting situation:
>>
>> rsync://repo/TA
>> CN=RTA,O=RIPE%20NCC,C=NL.cer <- Trust Anchor
>> CN=RTA,O=RIPE%20NCC,C=NL.crl
>> CN=RTA,O=RIPE%20NCC,C=NL.mnf
>> CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert
>>
>> rsync://repo/PARENT_CA
>> jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl
>> jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf
>> xSDgrpWpxMdHx-9tHN7QKtlILFw.cer <- Child key1 cert
>> AIA -> jfs24...cer
>> CRL -> jfs24...crl
>>
>> rsync://repo/CHILD_CA
>> xSDgrpWpxMdHx-9tHN7QKtlILFw.crl
>> xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf
>> ITg3GhNYIyZQ78D5Zt3sXJkmeLc.roa EE-AIA -> xSD..cer
>> EE-CRL -> xSD..crl
>>
>> Now we perform a key roll-over for the PARENT_CA. When this happens our
>> system triggers a new certificate request one level down for the
>> CHILD_CA. The repositories now look like this:
>>
>> rsync://repo/TA
>> CN=RTA,O=RIPE%20NCC,C=NL.cer <- Trust Anchor
>> CN=RTA,O=RIPE%20NCC,C=NL.crl
>> CN=RTA,O=RIPE%20NCC,C=NL.mnf
>> CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert
>> CN=FrN8YYiB-9CUT_B833qvigzedIc.cer <- Parent key2 cert
>>
>> So, our offline TA now certifies two keys for our production parent CA
>>
>> rsync://repo/PARENT_CA
>> jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl <- Key1 crl
>> jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf <- Key1 manifest
>> FrN8YYiB-9CUT_B833qvigzedIc.crl <- Key2 crl
>> FrN8YYiB-9CUT_B833qvigzedIc.mnf <- Key2 manifest
>> xSDgrpWpxMdHx-9tHN7QKtlILFw.cer <- Child key1 cert
>> AIA -> FrN8..cer
>> CRL -> FrN8..crl
>>
>> These keys (certificates) use the same publication point. We have a CRL
>> and manifest for each key. Furthermore the Child-Key1.cer is re-issued
>> under the new 'active' key. It is now pointing to the new, 'active',
>> key's certificate and CRL.
>>
>> The old key no longer publishes any new objects. It just maintains a CRL
>> and manifest that contains just the CRL file so that it can still revoke
>> previously issued certificates should there ever be any reason.
>>
>> rsync://repo/CHILD_CA
>> xSDgrpWpxMdHx-9tHN7QKtlILFw.crl
>> xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf
>> _jrinG02UFGiBXx1wgiQDJo0uww.roa EE-AIA -> xSD..cer
>> EE-CRL -> xSD..crl
>>
>> 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.
>>
>> The old ROA object is no longer published, but it still validates for
>> people that downloaded it and use the AIA pointers to construct a
>> validation chain -- as our validator does. There was no reason to revoke
>> the old EE, and its parent certificate is updated to use the new chain.
>>
Pasting Roque's comment (other email) here:
>
> We though about the RIPE implementation. One problematic corner case raised:
>
> - Imagine I am a relying party and I am using a PARENT CA cert as TA
> (jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer).
> - If there is a key-roll over of the PARENT CA and If I am doing TOP-DOWN
> validation using that TA cert; during the Key roll-over process, I will lose
> all the signed materials (particularly ROAs) as they are not longer
> published. The new ROA will not validate as I do not have the RIPE TA.
>
> This may be the case of a hosted client wanting to use its own cert as TA.
> Again, a corner case that you may want to think about.
So a TA roll over requires a different approach.
I am not sure how this is done 'normally'. I am no PKI expert, so if
anyone has clear ideas about this I think it would be useful to share.
Would it be legal two have two different certificates for the same key?
That way we could have two repositories -- just for the TA level:
the old TA repository:
rsync://repo/TA
CN=RTA,O=RIPE%20NCC,C=NL.cer <- OLD Trust Anchor, old key
CN=RTA,O=RIPE%20NCC,C=NL.crl
CN=RTA,O=RIPE%20NCC,C=NL.mnf
CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert
and a new one:
rsync://repo/TA-NEW
CN=RTA,O=RIPE%20NCC,C=NL.cer <- NEW Trust Anchor, new key
CN=RTA,O=RIPE%20NCC,C=NL.crl
CN=RTA,O=RIPE%20NCC,C=NL.mnf
CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert
so both repositories have a certificate for 'parent key1', signed by a
different key but having the same subject public key and sia.
This may be completely wrong.. as I said I am not a pki expert, so
someone speak up ;)
In any case we never considered the requirement that any level CA
certificate should be usable as TA. So our current implementation does
not address this issue. Our validator _currently_ even requires a TA to
be self-signed.
I think it complicates implementation a great deal if we must assure
that CA certificates on every level should be usable as TAs and be
roll-over-able without affecting RPs that still use the old key. Can
someone confirm that this is requirement?
A possible work around I can see here is to allow for some time between
steps 3 and 4 of the process described in the res-certs document, and
publish the NEW certificate before activating it. This could give
relying parties time to use the new certificate as another TA next to
the 'current' certificate. But like I said, I think this makes the whole
system more complicated.
>>
>> 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'.
>>
>> 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.
>
> This is the procedure described in the res-cert draft relating to key
> rollover - i.e. the entity can complete a key rollover without having to
> await child entities undertaking a reissuance request against the CA with the
> new CA.
>
>>
>> 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..
>
> One issue here is that in such a case the old key is kept active for an
> indeterminate period. If this old key has been compromised, then is it really
> appropriate to keep this key in an active state? If the CA wants to retire
> the old key, why should it be held up awaiting an action by the child that
> may not occur for weeks, months,...?
True. I guess there is no real reason, unless we would need the
'prepare' state somehow because of Roque's concerns.
>
>
>>
>> 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.
>>
>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
