Hi Tim, > > 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? >
Yes, you MAY have more than one certificate for the same CA entity. Think about key roll-overs for identity CAs. You need to change your key, but not your DN (name, email, address, etc). Check section 4.1.2.6 of RFC 5280: " Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN). The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer field. A CA MAY issue more than one certificate with the same DN to the same subject entity." > 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. > You do not necessarily need two publication points, they can both be in the same one. However, your example simplifies construction of the manifest. > 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. > Again, this is a corner case but you cannot control what the RP will be doing and what tools they will be using. > 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. Correct, but my point was that during that time you need to publish all signed materials under both CAs, the OLD and the CURRENT. Roque. > >>> >>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
