[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Normative reference for 'CA rollover'?




max pritikin wrote:




Hi folks,
I'm looking for a normative reference describing how a CA would 'rollover' to a new keypair or 'modified' certificate.
RFC5280 includes the following statements about 'rollover', here quoted with minimal context: 

   4.2.1.10 Name Contraints:
   "Name constraints are not applied to self-issued certificates  (unless
   the certificate is the final certificate in the path).  (This could
   prevent CAs that use name constraints from employing self-issued
   certificates to implement key rollover.)"

   6.1. Basic Path Validation:
   "A certificate is self-issued if the same DN appears in the subject
   and issuer fields (the two DNs are the same if they match according
   to the rules specified in Section 7.1).  In general, the issuer and
   subject of the certificates that make up a path are different for
   each certificate.  However, a CA may issue a certificate to itself  to
   support key rollover or changes in certificate policies.  These
   self-issued certificates are not counted when evaluating path length
   or name constraints."

   8.  Security Considerations:
   "Loss of a CA's private signing key may also be problematic.  The CA
   would not be able to produce CRLs or perform normal key rollover."
But it does not include a recommended description of this rollover process itself.
RFC3647 does not mention rollover at all, although it does define 'renewal' and 'rekey'.
I can find informative discussions of rollover for various CA's (thanks Google).
Can somebody point me in the right direction? Is there a normative reference or should I be able to infer the "correct" behavior from end entity rekey discussions as per the above notes?
This is a BIG issue from early days of e-commerce. VISA International had a patent (now extint due to non-payment of renewal fees) for essentially the RFC5011 solution that was selected by IETF for DNSSEC.
You may have a look at http://www.watersprings.org/pub/id/draft-moreau-pkix-takrem-01.txt 
as the most sensible solution known to mankind (half jocking).
Actually, there is no solution to this problem: either a) you admit that any key management scheme for top-level public key rollover has a "catastrophic failure mode" and you may agree with the preceding paragraph after some investigation, or b) you play the head-in-the-sand game, or security by management exhaustion (see last paragraph below) and then you may field an indefinite scheme. 

Obviously, b) has been emperically verified repeatedly.
Security by management exhaustion: you recursively (or iteratively since we are speaking management) discuss the recourse to yet another security layer (crypto-based) as a means to lower the operating costs of having key custodians actually travelling with key material ... until the manager's attention time is elapsed. Then you field whatever technology is available, irrespective of the discussion. 


Thank you,


You are most welcome, regards,


--

- Thierry Moreau