Subject: Normative reference for 'CA rollover'?

From: max pritikin <[email-masked]>
Date: Thu, 2 Apr 2009 09:47:14 -0500

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?

Thank you,

- max

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 02 Apr 2009 10:44:56 -0500

max pritikin wrote:

> RFC5280 includes the following statements about 'rollover', here  quoted 
> with minimal context:
> 
>    "Name constraints are not applied to self-issued certificates  (unless
>    each certificate.  However, a CA may issue a certificate to itself  to
> I can find informative discussions of rollover for various CA's  (thanks 
> Google).
> 

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 02 Apr 2009 12:22:21 -0400

Believe it or not, the new-in-old and old-in-new procedure is 
documented in CMP.  Many people fail to find it there.  Perhaps it 
should be extracted from there and published as a BCP.

Russ

---

From: max pritikin <[email-masked]>
Date: Thu, 2 Apr 2009 12:24:33 -0500

Thank you Russ. This is what I was looking for. I'll review and ask  
questions as necessary.

I would support the idea of publishing this information independently  
from a specific enrollment protocol.

- max

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 02 Apr 2009 13:56:19 -0500

Russ Housley wrote:

> 
> Believe it or not, the new-in-old and old-in-new procedure is documented 
> in CMP.  Many people fail to find it there.  Perhaps it should be 
> extracted from there and published as a BCP.
> 

Well, that's already a specifications-based "solution," i.e. better than 
nothing. I should have notice it before.

If you follow the "catastrophic failure mode" analysis, you soon realize 
  the equivalence between the failure mode that would trigger an 
emergency rollover and the very catastrophic failure mode (of the 
new-in-old and old-in-new procedure). Hence, not very secure. But you 
know because you are specifications-based.

My suspicion is that if you attempt to make it a standalone document, 
you start another round of discussions on better alternate solutions 
(because you make security limitations more conspicuous than they are 
now), falling again in the "security by management exhaustion" vicious 
circle.

But you (the community of which Max is representative by his question) 
do have a solution. Is there a need for a better slution? I guess not. 
(I actually think an equivalent procedure should be implemented in 
DNSSEC validating resolvers instead of comprehensive RFC5011 support, 
fulfilling the expectations of the vast majority of Internet users with 
respect to DNSSEC root key trustworthiness.)

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Apr 2009 19:49:02 +0100

Originally that text was something I wrote when all of PKIX was
going to be done in a single RFC:-) When we split out the CMP stuff
it probably ended up there just because I was a co-author.

As for doing a BCP, that'd be a fine idea, though I'm not sure
how many CAs actually do use this, so I'd wonder if the CMP text
is correct or sufficient compared to what CAs actually do?

Stephen.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 2 Apr 2009 15:16:42 -0400

In the real world, given nuances of MSFT CAPI (CRL to be signed using
the same key as the certificate in question), what many deployments do
for both Root and Sub CA is: have a new DN associated with the new key.
Thus, technically there is no roll over.  The certificate issuance is
manual.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Thursday, April 02, 2009 2:49 PM
> To: max pritikin
> Cc: Russ Housley; [email-masked]
> Subject: Re: Normative reference for 'CA rollover'?
> 
> 
> 
> Originally that text was something I wrote when all of PKIX 
> was going to be done in a single RFC:-) When we split out the 
> CMP stuff it probably ended up there just because I was a co-author.
> 
> As for doing a BCP, that'd be a fine idea, though I'm not 
> sure how many CAs actually do use this, so I'd wonder if the 
> CMP text is correct or sufficient compared to what CAs actually do?
> 
> Stephen.
> 
> max pritikin wrote:
> > 
> > 
> >>> reference or should I be able to infer the "correct" 
> behavior from 
> >>> end entity rekey discussions as per the above notes?
> >>>
> >>> Thank you,
> >>>
> >>> - max
> >>>
> >>
> > 
> > 
> 
>

---

From: max pritikin <[email-masked]>
Date: Thu, 2 Apr 2009 12:24:33 -0500

- max