...

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.

In other words, not only do you hold the resource holders private key, but, they do not. This means that the ability to sign their resources is 100% under your control and 0% under their control except to the extent that you allow it. While I'm not accusing RIPE of nefarious conduct and do not believe that there is any malicious intent in the system, I do believe that it is a security model that any rational provider would likely consider untenable. The fact that you cannot retrieve the key is of little relevance, since you have full use of the key without retrieving it.

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.

Exactly...

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.

But by the very nature, the administrators of the system have the ability to make themselves members of the certification group. While I'm not saying that I think RIPE would do such a thing, the reality is that using this hosted solution is placing a tremendous amount of trust in the system and the administrators of the system. I have no problem with LIRs that choose to do this, so long as they are making an informed decision and understand the risks. I think the risks have been substantially down-played.

...

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.

Really? There's no way for any member of RIPE staff to make corrections to an LIR's admin account such that it would be possible to bypass this? I tend to doubt that any sustainable system could be built in such a manner. Again, I am not accusing RIPE of doing so, but, pointing out that for such a hosted solution to remain functional over time, there must be certain compromises in the trust model. These compromises should at least give one pause and be carefully considered prior to handing over that level of trust.

...

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.

So at least if someone does something horrible, assuming the system integrity is not compromised in the process, we can tell what happened and either who did it, or, at least who they chose to impersonate. That's good, but, by itself it is not enough.

There is currently no additional notification mechanism implemented but that would be fairly trivial to add if there is a demand.

That would be a good additional safety feature.

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.

Exactly my point... Such a choice should be an informed decision and if it is not a matter of choice made by the organization holding the resource (as is currently the case), then, there are issues.

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

Which is a major step forward in this area.

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.

Another alternative in the meantime would be for the resource holder to maintain their private key and have transactions accomplished through a CSR process, but, obviously, this comes with a different set of tradeoffs, not the least of which is a certain amount of manual and mechanical complexity.

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.

I think that's a good plan. However, Randy's criticisms of the hosted solution are not without merit. While I am glad to see that the RIPE hosted solution is not such a scheme, my comments were based on the fact that other schemes I have seen for other certificate systems involved the user holding their private key after it was given to them by the hosted system. Such a system would obviously the worst of all worlds from a security standpoint. Owen