[certtest] certtest.ripe.net upgraded
-
From: Tim Bruijnzeels tim@localhost
-
Date: Mon, 05 Jul 2010 15:30:39 +0200
Dear colleagues,
we have upgraded certtest.ripe.net to the latest version of our resource
certification code. New features include:
= Increased automation of hosted member CA
- automated certificate renewal
- automated key management
= Trust Anchor support and security hardening
- updated server side
- updated validator
= Performance issues resolved
-- Automation
The automation of the system means that normal users will have no
'worries' about certificate renewal and key management. This should make
the system easier to use. Also, given the hosted nature, the extra
control did not really offer a lot of additional value in our view (see
technical explanation in appendix).
Note that we do plan to offer a non-hosted set up in the future; most
likely Q4/2011. This will allow members that want more control over low
level operations to run their own system.
-- Trust Anchor support
Our new trust anchors can be found here:
ETA: rsync://certrepo.ripe.net/eta/CN=ETA,O=RIPE%20NCC,C=NL.cer
RTA: rsync://certrepo.ripe.net/rta/CN=RTA,O=RIPE%20NCC,C=NL.cer
We would also like to ask you to have another look at the updated
validator. The validator can be downloaded from the welcome page after
you log in. The validator also supports the new TA format using the '-e'
option. The README text has more details on how to validate the trust
anchors mentioned above.
-- Activating your CA
Because of the changes in the Trust Anchor setup we had to wipe the
existing Certificate Authorities (CAs) in the system. Therefore we would
like to ask you all again to log in again and re-activate your member CA.
As a reminder, this is how you can activate your CA:
- Log in to LIR Portal as admin
- Ensure your 'normal' user is a member of the certification group
- Log in as yourself
- Make sure you have a client certificate (click X.509 link)
- Click the certification in the left menu
Then, you will have to:
1- click yes to activate your CA
2- click 'certify my resources' in the 'My Certified Resources' page
3- click 'OK' to accept the proposed key name
We plan to change this for the next release so that new members will
only need to do step 1. We did not have time to this for this release,
but these next steps do not make sense any more now that all other key
handling operations are automated.
Please have a look at the updated system and let us, or better, the list
know what you think.
Kind regards,
Tim Bruijnzeels
Senior Software Engineer
RIPE NCC
--- Appendix (technical)
For those interested I thought it might be good to give a slightly more
in-depth explanation of the changes to the system, and the reasoning
behind it. You can safely skip this if you don't care too much about the
low level details of all of this..
= Increased automation of hosted member CA
-- Certificate renewal
We have now fully automated certificate renewal for member CAs. The
reasoning being that if we leave this up to the user, it may easily be
forgotten. Currently certificates get a validity time to the end of the
current calendar year, plus six months; i.e. until 1 July of the next year.
The same validity time will be used by any ROA objects that the system
generates based on the ROA _specifications_ given by the user of the
hosted member CA. The system will automatically generate a new ROA
object when the validity changes. I.e. after 1 Jan next year a new ROA
object will be generated that lasts until the end of the renewed
certificate.
Note that the actual values for these validity times will change in the
future based on feedback from the certification task force and the testers.
-- Key management
We have changed the system so that key management is now hidden from
users of the hosted member CAs. There are two reasons for this:
- ease of use for member CA managers
- low level operations (such as key handling) can only be
done properly by parties that
As you know the hosted member CAs are in fact running inside a server
hosted by the RIPE NCC, and the keys used by these CAs are contained in
a dedicated Hardware Signing Module (HSM). By design it's impossible for
keys to be stolen. There are remaining risks though:
-- keys are subject to brute force attacks
-- keys can be irretrievably lost
The first risk, brute force cracking of the RSA key, is always there.
The size of the key (2048 bits, as per IETF draft) is a compromise
between longevity (bigger is better) and performance (smaller is
better). Given this key size a life time of about 5 years is usually
recommended. (Note that this also implies a maximum recommended
certificate validity of 5 years)
Planned key 'roll-overs' should be performed in time so that a new key
can be deployed, and the old key can be phased out. In the old version
it was left to users of the member CA to initiate this roll-over. Since
it is quite likely that this will be forgotten, and that introduces the
risk of keys being used for longer than would be considered safe, we
have have now automated this roll-over initiation; it is triggered
whenever a key is older than 2 years (this value can be changed).
The second risk (keys lost) is unlikely. We have mechanisms in place to
ensure that we have back-ups of the keys (the actual keys remain
encrypted). But theoretically this is possible. If this should happen
though, then the RIPE NCC doing the actual operation of the server will
know. Therefore the RIPE NCC is in a position to take immediate action.
We plan to test and document such an *un-planned* key roll-over over the
next weeks.
= Trust Anchor support - server side
The Trust Anchor support is now upgraded to the latest version of this
draft:
http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ta/
This setup allows for the following set up:
- A stable 'External' Trust Anchor certificate (ETA)
- A changing 'Resource' Trust Anchor certificate (RTA)
- A RIPE NCC production resource certificate signed by the RTA
The intention of this TA draft is to provide a mechanism for relying
parties to use an out-of-band, stable, certificate that is unchanging
with regards to resources. In our case delegations being assigned to an
RIR by the IANA. The mechanism used to achieve this is by having this
ETA sign a specific type of object that *contains* the more volatile
Resource Trust Anchor (RTA).
Both these Trust Anchor Certificate Authorities are operated on a
dedicated offline system. The 'RTA' is used to sign the RIPE NCC
production CA certificate that is used in the online system. This
certificate is used in turn to sign RIPE NCC member CAs.
Using an offline system for the Trust Anchor in this way is also
intended to mitigate the inherent risks associated with a 24/7 online
production system. It will enable us to re-key our production system in
case of problems. We plan to test such an unplanned key roll-over over
the next months.
= Trust Anchor support - validator
The old version of the validator already supported 'ETA' trust anchors
using the '-e' option, but was using an implementation that was not
according to spec. This is now updated to support the new TA structure.
= Trust Anchor support - other
Those of you who are following the sidr-wg in the IETF will have noticed
there is some discussion about the TA structure. Currently there is no
consensus yet, but it seems likely that another structure will be proposed.
This structure will eliminate the need for the ETA. Instead it will
present relying parties with a well-defined way to determine the RTA
public key and a stable publication point for its certificate. Combining
this relying parties should be able to fetch the latest RTA and verify
that it has the right key.
We expect no major problems on the implementation side, but we will wait
with any changes until the discussion on this stabilises. Until that
time, we plan to use the TA structure as defined in version 4 of the TA
draft: http://tools.ietf.org/html/draft-ietf-sidr-ta-04
= Performance issues resolved
You may have noticed there were performance issues recently. These
issues were related to a faulty set up in our infrastructure that has
now been resolved.
