Re: [pki-tc] Question: Best Practice for PKI in a DR situation

[Stephen Wilson <swilson@lockstep.com.au>]

Dear All

I certainly agree with Arshad's comments, although I tend to think that 
the issues around rebuilding the administrative parts of a PKI after a 
total loss event like 9-11 are pretty well the same as for IT in general.  
You need to have good backups of all subscriber info, of the X.500, and of 
the actual CA/RA software as installed.  All this is conceptually 
straightforward.  

Regarding the total loss of the CA private key, a policy decision needs to 
be made at design time about whether or not you want to be able to recover 
the key as it was, or alternately, cut a new CA signing key in order to 
resume CA operations.  The latter is better in my view; after all, who 
wants the responsibility and hastle of securely backing up a CA private 
key?!  On the other hand, to cut a new CA key will necessitate a new key 
signing ceremony and this could represent a major delay in the time taken 
to go live again. 

Now ... I think there is an altogether different disaster scenario which 
has not been canvassed in the thread so far.  That is: What is a CA to do 
in the event that its signing key (or any root key further up the chain) 
is compromised / stolen?  

Some conservatives suggest that all certificates issued under that CA -- 
ever -- should be revoked.  I understand that view, but a pragmatic 
approach is important too.  I've never seen this scenario in practce -- 
touch wood! -- but I imagine that a forensic investigation would be 
warranted with the aim of trying to determine precisely when the CA key 
was compromised, and therefore trying to make the case that subscriber 
certificates signed up until that point in time are OK.  Obviously there 
is the fear that the validity time coded into certificates cannot 
necessarily be trusted once the CA key is no longer trusted.  

Finally, I have a vague recollection of a brief paper published (or 
reprinted) by the now defunct PricewaterhouseCoopers Crypto Centre of 
Excellence maybe four years agol, which discussed resiliency in multi-part 
CA signing keys.  The author might have been Geoffrey Grabow.  I'm trying 
to track it down. 

Cheers, 


Stephen Wilson
Lockstep Consulting Pty Ltd
www.lockstep.com.au
ABN 59 593 754 482

11 Minnesota Ave
Five Dock NSW 2046
Australia

P +61 (0)414 488 851

--------------------

About Lockstep 
Lockstep was established in early 2004 by noted authentication expert 
Stephen Wilson, to provide independent advice and analysis on cyber 
security policy, strategy, risk management, and identity management.  
Lockstep is also developing unique new smartcard solutions to address 
privacy and identity theft. 
 


> OK - so it is one component of PKI Operations he's referring to.
> 
> While it is conceivable to come up with a "best practice" for PKI
> Disaster Recovery, it is very heavily dependent on the architecture
> of the PKI and the software that was used to implement that design.
> 
> We've noticed that different vendors have quite different ways of
> dealing with disasters - some that were good, and some that were
> completely unacceptable, requiring unconventional ways to recover.
> 
> Trying to build a single document that covers so much variability
> can be daunting - unless we assume a "best practice" for PKI
> architecture, based on "best practice" policies, and implements
> "best practice" operations and business processes.
> 
> I beleive the ISO is circulating something along these lines right
> now - I just received this reference on another newsgroup:
> 
> "International Organization for Standardization's
>  >>Draft of International Standard 21188 "Public key infrastructure for
>  >>financial services - Practices and policy framework."  It was 
> released for
>  >>comment and approval in March.  Voting ends on August 30th."
> 
> Any possibility that OASIS can get this document and circulate it
> to the PKI-TC for review, and perhaps, comment?
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> 
> June Leung wrote:
> > Hi Arshad,
> > He was referring to CA Recovery in an emergency situation, such as 911.
> > Thanks,
> > June
> > 
> > 
> > June Leung, CISSP
> > PKI Department
> > FundSERV Inc.
> > 1700 - 130 King Street West
> > Toronto ON 
> > M5X 1E5
> > T. 416.350.2516
> > F. 416.362.6668  
> > 
> > -----Original Message-----
> > From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
> > Sent: Thursday, August 04, 2005 5:18 PM
> > To: pki-tc@lists.oasis-open.org
> > Subject: Re: [pki-tc] Question: Best Practice for PKI in a DR situation
> > 
> > 
> > What best practices is your colleague referring to, June?
> > PKI policies, architecture, implementation, operations or business
> > processes?
> > 
> > While we tend to use certian well-honed design principles
> > and techniques, we've had to modify them every single time
> > to account for unique customer policies and constraints.
> > 
> > Arshad Noor
> > StrongAuth, Inc.
> > 
> > 
> > June Leung wrote:
> > 
> >>Hello everyone,
> >>A colleague recently asked me if I know of any best practices for PKI 
> >>exists in OASIS.  I personally don't think one exists in OASIS, but is
> > 
> > 
> >>there one exists somewhere else?  If not, maybe it's something the PKI
> > 
> > 
> >>TC can produce. Your feedback is appreciated.
> >>Thanks,
> >>June
> >>
> >>June Leung, CISSP
> >>PKI Department
> >>FundSERV Inc.
> >>1700 - 130 King Street West
> >>Toronto ON
> >>M5X 1E5
> >>T. 416.350.2516
> >>F. 416.362.6668  
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe from this mail list, you must leave the OASIS TC that 
> >>generates this mail.  You may a link to this group and all your TCs in
> > 
> > 
> >>OASIS
> >>at:
> >>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all your TCs in
> > OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 

--
<Put email footer here>