Hi, as one of the main developers of the RIPE NCC implementation I would like to give some answers to the questions raised by Owen. On 10/4/10 11:59 AM, Owen DeLong wrote:
I'll go a step further and say that the resource holder should be the ONLY holder of the private key for their resources.
Owen
If you're saying that ISPs can only participate in an RPKI scheme if they run their own Certificate Authority, then I think that would practically ruin the chances of Certification actually ever taking off on a large scale.
-Alex
No... I'm saying that if ISPs aren't the only entities that hold their private keys, then they aren't the only entities that can sign their resources.
The hosted system that we created uses Hardware Signing Modules (HSM) for generating keys and signing operations. By design it is impossible to retrieve the private keys. Any process or feature that would involve the transferral of keys cannot be implemented. Access to the *use* of the keys is a different thing though. This is controlled by the software. Although we cannot extract the keys, we can instruct the HSM to create a new key, or use an existing key to sign something. Our hosted software controls all (activated) hosted member certificate authorities. The process has potential access to the *use* of *all* keys in the system. However, other security layers are implemented to ensure that for a given LIR only those users that have the 'certification' group enabled are *authorised* to use the hosted system -- and thereby the applicable keys.
If you choose to delegate the CA role for signing your resources to someone else, then, obviously, you have to give them a valid private key with which to sign those resources.
Given this setup a member can authorise any person to use the system by creating an LIR Portal account for them and enabling the certification group. Only the LIR's admin user can do this.
However, in doing that, you've created a situation where your signature is now much easier to forge. Kind of like automatic signing machines for checks. Benefit: The accounting department can sign thousands of checks and the CFO doesn't have to. Draw-back... The accounting department can sign thousands of checks without the CFO knowing they did so.
The current system has an audit history page that shows all the commands executed by users. It includes details like the name of the user, the time of the change and further details: e.g. in case of the modification of a ROA specification the complete new specification is visible in the history. There is currently no additional notification mechanism implemented but that would be fairly trivial to add if there is a demand. Non-hosted: ===== Of course we put a lot of effort into maintaining security and quality of the implementation we built. But we can well imagine that for some people it is a matter of principle that they want full local access to their own private keys and important configuration objects such as ROAs -- and don't want to be hosted on a shared system outside of their control. Other members may not mind so much about this and choose to trust and use the hosted services. There is standard that is close to completion in the SIDR WG in the IETF that defines a protocol by which a parent and child Certificate Authority can communicate. http://tools.ietf.org/html/draft-ietf-sidr-rescerts-provisioning-06 In our case the RIPE NCC system could function as the parent CA for a non-hosted LIR child CA. The LIR can then deploy anything they see fit themselves. They would have full access to their own private keys and everything else in their system and can delegate as they see fit. And add new features of course. But.. 1) We have not implemented support for this yet. We plan to go live with the fully hosted version first and extend it with support for non-hosted systems around Q2/Q3 2011. 2) It can take considerable effort for LIRs to set up their own non-hosted solution from scratch. We know that ISC is developing an open source solution (rpkid) that may be useful for LIRs that want to run their own instance. From our side we will make sure that we test interoperation with this system when we implement this protocol in our system. Randy Bush who is cc-ed may be able to provide some more insight in the features offered by the ISC rpkid. I don't know whether the features mentioned by Alex in his first message will be supported by this system. Regards Tim Bruijnzeels RIPE NCC
Owen