Hi all,
this discussion seems to have calmed down somewhat, but the conclusion
is not entirely clear to me. When this thread was active I did not have
time to properly read all messages and respond. I would like to give my
delayed input now, coming from the implementation we have been working
on at the RIPE NCC.
- 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.
- 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
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..
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.
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.
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.
Regards,
Tim Bruijnzeels
Senior Software Engineer
RIPE NCC
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
