|Subject:||Re: [ekmi] Groups - EKMI Policy Guidelines (DRAFT PDF) v1.0(EKMI-Policy-Guidelines-1.0.pdf) uploaded|
|From:||Arshad Noor (arsh...@strongauth.com)|
|Date:||Jun 27, 2007 9:27:32 am|
Thank you Tomas. I will review this and incorporate it into the PG document. Feel free to send such information to the TC list; I am sure others will be welcome the opportunity to review and add their feedback and input.
----- Original Message ----- From: Tomas Gustavsson <tom...@primekey.se> Date: Wednesday, June 27, 2007 6:40 am Subject: Re: [ekmi] Groups - EKMI Policy Guidelines (DRAFT PDF) v1.0 (EKMI-Policy-Guidelines-1.0.pdf) uploaded
The policy guidelines contains some general issues, which are the same for PKI and SKMS. There is one general guideline for SKMS, SKMSG- 9, that also should apply to PKI.
In the PKI guidelines I will now only refrence to the policy guidelines document. Below is some text that I had written there before the policy guidelines were produced. Perhaps there is something interesting in there.
----- A best practice policy should balance the cost of a certain action against the benefit, and the cost of a breach of security due to a lower level of protection. An example of such balance is requirement for separation of duties for the staff operating the PKI. Strict separation of duties will require lots of staff, only to operate your PKI. If the persons operating the PKI are the same persons operating some of the systems using the PKI for protection, separation of duties for the PKI is unlikely to enhance the security on the organization. In that case it is probably better to allow single, trusted, persons to maintain several roles and spend money on other issues more likely to enhance security.
The cost of a potential security breach should always be calculated when determining the policy. The cost of the security system should never be higher than the objects actually protected. This is something only the organization itself can calculate.
A best practice policy for a middle- to large size organization for a PKI used primarily for EKMI could have he following features: - Requires a hardware security module. The same level of HSM used both for PKI and EKMI. - Logging of all security related events in the PKI should occur to a separate log server with limited access. - Trusted staff members are allowed to administer the PKI and register new entities. Other staff members should perform audit. - There must be some process of approving trusted personnel, and only trusted personnel are allowed to handle the PKI systems. Contractors can not handle the PKI systems without surveillance by trusted personnel. - Dual person control is required for backup and restore of CA signature keys. The PKI servers must be located in a separate, locked, part of the server room. Only trusted PKI personnel can access this room. - Availability is 24/7, 99.9%. Disaster recovery should be on the same level as other critical systems using the EKMI. - An approval process by management is required before issuing certificates to new systems. Enrollment for certificates can be done by trusted personnel, or require at least a shared secret transferred out-of-band to a technician performing the installation and enrollemnt.- Revocation information must be made available to the EKMI not more than 24 hours after revocation occurred. - No particular compliance is needed. - No warranties.
Arshad Noor skrev:
Thanks for the comments and suggestion, Mike. I will make the global change; I agree with you. For the other changes, I'll wait until all the comments are in before I put out another DRAFT.
Question for the rest of the TC: would June 30 be acceptable as a deadline to get feedback on the policy guidelines? Or do we need a little more time? Thanks.
Arshad Noor StrongAuth, inc.
Mike Nelson wrote:
My comments can be found in the attached.
I didn^1t make this edit, but I^1d suggest a global change from ^3company^2 or ^3companies^2 to ^3organization^2 or ^3organizations^2 (or perhaps ^3organisations^2). That will make it read better to those who don^1t work for a ^3company^2 (i.e., a federal agency).
Ken Adler provided a source document with some key-management policy
guidelines distilled from PCI-DSS and some real-world experience.
Ken). They are meant to be the driver for the EKMI Implementation
Operations Guidelines, the prime deliverable of this SC.
I have organized the document along PKI and SKMS and listed the guidelines
with a brief explanation under each. Please review, critique and
your feedback on errors, ommissions, etc.
Arshad Noor StrongAuth, Inc.
P.S. The next message will include an editable ODT document.
The document named EKMI Policy Guidelines (DRAFT PDF)
(EKMI-Policy-Guidelines-1.0.pdf) has been submitted by Arshad Noor* to
EKMI SKMS Implementation and Operations Guidelines SC document
Document Description: A DRAFT (PDF) document that provides some
policy guidelines for an EKMI
(consisting of PKI + SKMS). These guidelines,
once refined and accepted,
will be used to create the Implementation &
Operations Guidelines by this
PLEASE NOTE: If the above links do
not work for you, your email application
may be breaking the link into two
pieces. You may be able to copy and paste
the entire link address into the
address field of your web browser.
-OASIS Open Administration