[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pki-tc] Question: Best Practice for PKI in a DR situation
Most of the HSM vendors provide ways that you can securely back up a CA private key, and I believed this was the norm for disaster recovery. There are 2 methods commonly used for DR, both involve equipment at a 2nd site - one is the lower cost off-line method, which takes longer to recover, i.e. having a copy of your CA key material kept securely at a back up site, and to do regular data backups to that site. The other is to have a method of online data backup (this depends on the database you are using, or you can use a number of other data backup methods). As Steve says, the issue of CA key compromise, is the much harder one to get to comprehend, yet alone work out how to handle it. The use of multiple people being required in order to activate an HSM, greatly reduces the risk i.e. even if the HSM is stolen, the tamper proffing should stop acces to the keys. However you can consider other scenarios where the HSM doesn't have to be stolen. Regards Helen Mullenger UniCERT Product Manager Cybertrust Office: +44 (0)208 831 2901 Mobile: +44 (0)789 994 5411 helen.mullenger@cybertrust.com -----Original Message----- From: swilson@galexia.com.au [mailto:swilson@galexia.com.au] On Behalf Of Stephen Wilson Sent: 12 August 2005 06:49 To: pki-tc@lists.oasis-open.org Subject: Re: [pki-tc] Question: Best Practice for PKI in a DR situation 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.p > >>hp > > > > > > > > -------------------------------------------------------------------- > > - 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.p > > hp > > > > --------------------------------------------------------------------- > 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> --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]