Peter Bowen wrote:
On Wed, Jan 8, 2014 at 11:54 PM, ianG <i...@iang.org> wrote:
On 9/01/14 02:49 AM, Paul F Fraser wrote:
Software and physical safe keeping of Root CA secret key are central to
security of a large set of issued certificates.
Are there any safe techniques for handling this problem taking into
account the need to not have the control in the hands of one person?
Any links or suggestions of how to handle this problem?
The easiest place to understand the formal approach would be to look at
Baseline Requirements, which Joe pointed to. It's the latest in a series of
documents that has emphasised a certain direction.
(fwiw, the techniques described in BR are not safe, IMHO. But they are
industry 'best practice' so you might have to choose between loving
acceptance and safety.)
Is there a better reference for safe or a place that has commentary on
the 'best practice' weaknesses?
The short answer is 'no'.
As a first comment replace "CA certificate Secret Key" by "root CA
private signature key [used to sign certificates]" because 1) you want
to trust (or establish trustworthiness for) a CA *entity*, 2) you might
wish to have some continuity if the CA entity replaces its signature key
pair, and 3) a "secret key" might refer to some other type of key.
If you understand the fundamentals, you may see that the root DNSSEC
signature key (handled by ICANN/IANA, see https://www.iana.org/dnssec )
requires indeed the exact same type of protections.
Documents were circulated prior to the launch of the DNSSEC service for
the DNS root zone that disclosed a lot of design decisions that are now
embedded in the details of "KSK ceremonies." I got the feeling that
ICANN employees are nowadays in the public-relations mood when
questioned (more or less consciously by the person asking a question who
may have been absent when call for comments were made).
I would suggest that the DNSSEC deployment at the root would be a good
case study for IT security management, from an historic perspective. The
primary source documents, and the conclusion of such case study, could
be helpful to you but ...
... if you want to "do it right" (and since the resources -- money,
personnel, organizational trustworthiness, immediate attention from a
community of experts -- available to ICANN aren't available to you), you
may need to revise your understanding of underlying principles (hint:
don't start by reverse engineering the PKCS#12 specifications).
You may want to do it "best practice" and there you go.
Good luck
--
- Thierry Moreau
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
