[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Normative reference for 'CA rollover'?
max pritikin wrote:
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:
220.127.116.11 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
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
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
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.
You are most welcome, regards,
- Thierry Moreau