Bill Manning wrote:
% Please note that at present our certificates are used for identifying % member staff to access internal aplication (MyAPNIC), so the subject of % third-party trust issues may not yet apply. By the time 3rd parties % become involved (eg allocation/route certification), we would certainly % have more standard CA/PKI structures in place. % % This is a new area for most of us, and we are very open to advice and % input from the community. % % Cheers, % Sanjaya % APNIC CA Project Manager
of interest to me is the presumption that all interaction between parties is assumed to be via http applications, e.g. the need to install a cert into your browser.
last time I checked, many/most RIRs supported a variety of methods for interaction w/ their customers. I'd like to see how the use of x509 certs would be applicable/palatable to other applications.
Existing access methods will be unaffected by the RIPE NCC's adoption of X.509 technology to interact with our members (LIRs). We do expect that people will make heavy use of HTTP/SSL because of the ease of use it offers. For a review of the planned changes to the various ways that the LIRs and the RIPE NCC interact, please have a look at section 3 of this document: http://www.ripe.net/ripe/draft-documents/pki-20030429.html
It would be useful to also have more clarification on how bootstraping is to be done.
Briefly, LIRs can obtain a certificate from the LIR Portal: https://lirportal.ripe.net/ They must first have obtained an account, through the existing procedures, documented here: https://lirportal.ripe.net/lirportal/activation/activation_request.html This is explained in the PKI document, at the URL given above.
I tend to chnage hardware/software every 6 months or so and have a tough time keeping up w/ all the existing pswds/keys that the various systems use/expect. I will forget/lose any pswd/key at least once.
One of the reasons X.509 was chosen is because it will allow LIRs to use one authentication mechanism for accessing all RIPE NCC services. This would help reduce the number of passwords or keys you need to keep track of. However, the timeline for adopting such methods is strictly up to the users - you can use current techniques until you find it beneficial for you to change the procedures on your side. The RIPE Database supports many authentication mechanisms today, NONE, passwords hashed with DES or MD5, as well as PGP. It used to support using sender e-mail as authentication, but this was removed by community request. Likewise the community has proposed removing NONE authentication, and this project will move forward. These efforts are separate from this project, however. -- Shane Kerr RIPE NCC