| <<< Chronological >>> | Author Index Subject Index | <<< Threads >>> |
Dear certification testers, Thank you for taking part in the test program. We realise we have been a bit silent since meeting you at RIPE 56 in Berlin, so we decided to send you this update on the project and what you can expect in the near future. Goal of the test program We want to build and extend a web based certification portal that is useful for real world users. The model that is explained in more detail below involves incremental releases of new functionality that you can test. Your feedback and comments will be used to fix problems and will help decide the direction of features to be added to the system. This way we hope to arrive at a stable and valuable release candidate when this test round ends. It is our ambition to reach this phase at the next RIPE meeting in Dubai in October this year. But, of course, we have to be flexible and take your feedback, policy changes and other developments into account. Note that as a first step we will set up a 'hosted' certificate authority. That means that we will provide a portal that you can use to operate your CA. It is likely that at some stage in the future you will be able to host your own CA locally and integrate with our back-end. However, there is a lot of work still to be done before we reach that stage so our focus will be on the 'hosted' scenario for now. Please note also that we will use a TEST certificate as the root 'Trust Anchor' for this test phase and that all certificates and signed objects will remain 'test' objects. Current status Currently we are focussing on delivering a test-ready system. We are working on implementing the core of the certification engine. This involves integration with the resource database and other services so we can do a timely delivery of the test service. In a few weeks we hope to deliver the first working version of the application, and this email is meant as a introduction to the application and the process of improving the application. Process While developing the application we strive to have an open process. This means that while we have a plan (see below), we greatly value the input provided by the test community and we will try our best to incorporate any feedback we get in our planning. The easiest way to give that feedback is by replying to the mailing list, so that everyone is automatically notified of ideas, suggestions, etc. The process of software delivery is an incremental software release. While internally we have 2 week iterations, we strive to deliver new software every 4 weeks, so we can incorporate the feedback we get and deliver new features every release. The section ëfirst releaseí describes our software so far, while the part ëfuture releasesí describes that plan of implementing the items we identified so far. For each release we will provide you with further details and/or documentation about the functionality and what you can do to test. We propose to use this mailing list for discussions of your findings so that we can all have an open discussion about concerns and ideas. Timeline Based on the current developed functionality and the work in progress, the plan is to deliver a first public version at the start of July. First release The features delivered in the first version will consist of: - Testers will be given access to the system with a username and password, allowing them to log in to their Certificate Authority (CA). - Testers will be able to request resource certificates. Resources certificates will contain IPv4 and IPv6 PA allocations and will be signed by the RIPE NCC test certificate authority. - Testers will be able to view the details of their resource certificates. - Testers will be able to download their resource certificates. OpenSSL with the RFC 3779 resource extension can be used to view these resource certificates. Future releases We propose to work on the following features in the order that is listed below. We have ordered them in way that we think gives the optimal value in terms of regularly providing visible functionality for the testers whilst taking dependencies on work in the 'core' system into account. Having said that we are open to suggestions to change the order provided enough testers want a change and it's technically feasible. Certificate publication Publish the resource certificate to a public repository to allow others to access the certificate. This is required for validation of the chain of resource certificates. Certificates can be downloaded by using rsync as part of the specification. Deliverable: A public repository for certificates. Automated provisioning (for resource certificates) Currently there is no client software to automatically validate resource certificates. We plan to provide this functionality as a service. Deliverable: A web interface that can be used to validate a resource certificate using the TEST root certificate as Trust Anchor (TA) Route Origin Authorisation Objects (ROAs) ROAs are a type of signed objects. A ROA is an authorisation for a network identified by an AS number to originate a specific IPv4 and/or IPv6 address space. The ROA can only be signed by the holder of a resource certifacte for that space. Deliverable: 1) A web interface that can be used by testers to generate ROAs. 2) Access to 'my' ROAs and details. 3) A public repository containing all ROAs Automated provisioning (for ROAs) Currently there is no client software to automatically validate ROAs. We plan to provide this functionality as a service. Deliverable: A web interface that can be used to validate a ROA. Certificate and ROA revocation A parent CA can revoke a certificate to invalidate it. Revocation lists (CRL) are published in the appriopriate repository so that third parties can use this information when validating a resource certificate. Deliverable: 1) Provide 'revoke' function for parent CAs 2) Publish CRLs 3) Extend validation to respect CRLs 4) Provide 'ROA' revoke function. Certificate renewal Request a resource certificate with extended resources and/or validity period. For now we are using a hardcoded validity period of one year. Deliverable: Introduce concept of 'active' keypair and 'active' certificate. Support phasing out expired certificates and keypairs that are no longer being used. Planned key rollover Security policy requires that key pairs are replaced, or rolled over, after a certain period. Planned key rollovers must be implemented in a such a way that a key roll over for a parent CA is transparent for a child CA. This implies that certificates have to remain valid and no additional actions should be required. Deliverable: We can showcase a key roll over for your parent CA, the RIPE NCC test CA, and how it affects your CA and resource certificates. Forced key rollover A certifcate authority must be abe to deal with a private key compromise. The way to do this is to force a key roll over. The parent CA should be notified so that they can revoke the old resource certificate and issue a new one based on the new key set. Because the old resource certificate has been revoked, the CA must then re-issue all resource certificates for its child CAs. Deliverable: We can showcase a forced key roll over for your parent CA, the RIPE NCC test CA, and how it affects your CA and resource certificates. Future development There are more than enough ideas about development after these features have been worked out. To name a few: - Support automated filterset generation based on ROAs - Support strong authentication (using certificates in your browser) - Integration with other RIRs We hope this email gives you a clear idea about the development and test process for the next few months. Comments and questions are of course most welcome. Regards, Tim Bruijnzeels Software Engineer RIPE NCC |
| <<< Chronological >>> | Author Subject | <<< Threads >>> |