Hi Tim, Thanks for this email and keep the discussion going. Let me add some comments inline.
Regards,
Roque.
On Jul 6, 2010, at 3:42 PM, Tim Bruijnzeels wrote:
>
> - 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 that we need to maintain the AIA support for bottom-up fetching
mechanism.
The initial question that Steve raised was whether or not the AIA should points
to a publication point instead of a certificate file. IMHO, RFC 5280 section
4.2.2.1 is ambiguous in the sense that it requires to be a directory for LDAP
but a file for FTP and HTTP as fetching mechanism.
By pointing to a publication point rather than a certificate, you can fetch
from that point a group of certificates, and thus handle key-roll over smoothly
(particularly when you are maintaining the same subject during the roll-over)
as you can list the OLD and CURRENT certs when doing the bottom-up fetch.
In the current SIDR specifications, we are changing the subject name in every
roll-over, so there is probably not that much of a benefit AFAIK.
>
>
> - Key roll-over algorithm
>
(skip)
> 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.
>
> 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.
>
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.
>
> 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.
>
> 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.
Tim, I am not falling you on which CA is doing the key roll-over.
- If it is the "Down CA", you should check Section 8 of the
draft-ietf-sidr-res-certs-18 document.
- If it is the "UP CA", what you can do is to keep all the CSR that you
receive for your subordinates. When you do a key-roll over of the UP CA, you
can re-sign and re-publish all the certificates for the subordinates. As you
are using the same subject key, this should work smoothly. After a given period
(depending if it is an emergency roll-over), you should revoke the old certs.
Regards,
Roque
>
>
> Regards,
>
> Tim Bruijnzeels
>
>
>
> Senior Software Engineer
> RIPE NCC
>
> _______________________________________________
> 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
