You are here: Home > Participate > Join a Discussion > Mailman Archives

Re: [certtest] [REMINDER] Certification Software Questionnaire

  • To: Erik Rozendaal erozendaal@localhost
  • From: Basil Dolmatov dol@localhost
  • Date: Fri, 12 Dec 2008 17:24:40 +0300

Sorry, Eric, but this reminds me the classic question: "Did you drop to drink cognac in the morning?" ;)

The answers to a number of questions posed here can differ drasctically depending upon the technological and organisational procedures implemented. (Another quote: "Insufficient data for meaningful answer@ (c) I.Asimov)

These places I will mark below.


Erik Rozendaal пишет:
[This is a reminder email, please ignore if you've already replied]

All,

To help us prioritise and develop the certification software we would
like to have your feedback. Simply reply to me with your answers in
lined. If anything is unclear, feel free to ask for clarification.

Please answer each question with a number using the following scale:
1. I like it that way.
2. I expect it to be that way.
3. I am neutral.
4. I can live with it that way.
5. I dislike it that way.

Every question is asked twice, in both functional and dysfunctional
form. This helps us understand your priorities better. Feel free to
give additional comments.


Question 1a: If you can use a tool or library to download, validate,
and list ROAs available in the public certificate repositories, how do
you feel?

Answer 1a:

Question 1b: If you cannot use a tool or library to download,
validate, and list ROAs available in the public certificate
repositories, how do you feel?

Answer 1b:

Explanation: A tool like this could be used to check your router
filter tables against the ROAs published in the public certificate
repositories. RIPE NCC or a third party could provide such a tool or
library. The output of this tool would be some form of CSV or maybe
RPSL.
The answer is depending greatly upon the procedures implemented when creating such repositories, upon the internal logic of exception handling in this proposed tool etc. It can be a good thing, but it can be "A very BAD thing" (tm) to create such tool and recommend it for the usage.




Question 2a: If you can schedule periodic key rollovers, how do you feel?

Answer 2a:

Question 2b: If you cannot schedule periodic key rollovers, how do you feel?

Answer 2b:

Explanation: Its generally advised to rollover your keys at least once
per year, to limit the possibility of key compromise. Currently this
has to be done manually.

If the key handling procedures are designed properly, then there is no need in periodic key rollover, because the only reason for key change is key compromise due to stealing of secure key storage. If the key handling procedure does not insist on using secure key storages then periodic key rollovers whether automatic or manual add very little to overall security


Question 3a: If you can audit all actions performed with your
certificate authority (CA), how do you feel?

Answer 3a:

Question 3b: If you cannot audit all actions performed with your
certificate authority (CA), how do you feel?

Answer 3b:

Explanation: The certification system could provide a log of all
actions performed with your CA, allowing you to audit your CA. Example
actions could include configuring a ROA and creating a new key pair.

This implicits that CA is outsorced by certification system and creation of new key pair (what does it mean?) is performed inside of certification system. These keys should be considered compromised from the very moment of their creation and using or non-using logs add nothing to overall security



Question 4a: If you can login using a RIPE NCC provided X.509
certificate, how do you feel?

Answer 4a:

Question 4b: If you cannot login using a RIPE NCC provided X.509
certificate, how do you feel?

Answer 4b:

Explanation: Currently the system only requires a username and
password to login. To improve security RIPE NCC can provide you with a
X.509 certificate that only you can use to login.
Current level of security utilized on RIPE NCC portal is quite low.
Using certificates for login can raise level of security if certificates are properly created and maintained, otherwise it will add nothing to security and just imitate it. The crucial points are: key handling procedures and setting relation between issued crtificate and its holder.





Question 5a: If you can run your own certification engine, how do you feel?

Answer 5a:

Question 5b: If you cannot run your own certification engine, how do you feel?

Answer 5b:

Explanation: By running your own certification engine you keep full
control over your certification keys and engine implementation. Your
certification engine would communicate with the RIPE NCC hosted
certification engine using standardised protocols.
Again two different aspects are freely mixed in this question.

Possibility of own engine implementation - that is one queston.
Possibility of generation and handling keys on the own - is quite another one.

There should be NO other options except generating keys on the user side.

Usage of own engine implementations is highly dependent on the country and status of the user.




Question 6a: If you can give your customers access to the RIPE NCC
hosted certification system to manage their resource certificates, how
do you feel?

Answer 6a:

Question 6b: If you cannot give your customers access to the RIPE NCC
hosted certification system to manage their resource certificates, how
do you feel?

Answer 6b:

Explanation: By giving your customers access to the hosted
certification system they can manage their own certificates and ROAs.
Giving your customers access would require you to configure your
customer's resources in the hosted certification system and to provide
login credentials for your customers. Without this capability you
would have to run your own certification engine or issue ROAs on
behalf of your customers.



Question 7a: If you can programmatically access and configure the RIPE
NCC hosted certification system to manage your certificates and ROAs,
how do you feel?

Answer 7a:

Question 7b: If you cannot programmatically access and configure the
RIPE NCC hosted certification system to manage your certificates and
ROAs, how do you feel?

Answer 7b:

Explanation: Using programmatic access (through a web services or
other API) you can integrate the hosted certification system into your
own resource administration systems. This would eliminate the need to
manually configure ROAs or customer resources in the hosted
certification system.



Question 8a: If you can get a copy of the RIPE NCC certification
implementation, how do you feel?

Answer 8a:

Question 8b: If you cannot get a copy of the RIPE NCC certification
implementation, how do you feel?

Answer 8b:

Explanation: The RIPE NCC certification implementation could be
released (source code or some packaged version). This would allow you
and others to use this software to run your own certification engine.

That seems necessary, this code should be open for inspection.
Moreover there should be means to testify that the code currently running on NCC servers is corresponding with published sources.



Question 9a: If you can upload your issued certificates and ROAs to
the RIPE NCC public certificate repository when running your own
certification engine, how do you feel?

Answer 9a:

Question 9b: If you cannot upload your issued certificates and ROAs to
the RIPE NCC public certificate repository when running your own
certification engine, how do you feel?

Answer 9b:

Explanation: When running your own certification engine, you also need
a mechanism to publish your generated certificates and ROAs. You can
run your own publicly accessible certificate repository or upload to
the RIPE NCC certificate repository. The latter option limits the
number of repositories relying parties need to access.
There can be no meaningful answer without knowlegde of procedures which this repository will run. Will this repository check validity of uploaded certificates or no? Will the repository sign uploaded certificates itself to ensure its validity and diminish need of chain checking, etc.




Final question: Is there anything we missed that you think we should know about?

Answer:
KEY HANDLING PROCEDURES.
EXCEPTION HANDLING PROCEDURES.
CONFLICT RESOLUTION PROCEDURES.

and so on.

The technical and techonological background is no more than 30% of whole PKI working system, most of stability and security threats are lying in the other fields, mainly in procedural one.

вщд"





Thanks for your feedback!

Regards,
Erik