Subject: Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed?

From: "Salz, Rich" <[email-masked]>
Date: Tue, 28 Jul 2020 12:19:38 +0000

Mail alias issues.  Mea culpa

On 7/28/20, 8:16 AM, "Salz, Rich" <[email-masked]> wrote:

    Moving CFRG to BCC; the LAMPS working group is a better place (it handles 5280 updates) to discuss this.

    On 7/28/20, 6:22 AM, "Wang Guilin" <[email-masked]> wrote:

        Dear all, 

        I am here to enquire one question about revoking PKI certificates. 

        In practice, to guarantee high security, the validity (say 10 years) of a root certificate private key may be essentially shorter that the validity (say 30 years) of the corresponding public key. After the first 10 years, a new root certificate with a new key pair will be generated, and the old root private may be even destroyed. After that, however, how can we use the new root private key to issue CRLs to revoke certificates previously signed by the old root private key? 

        At first, I thought this is the case of using indirect revocation mechanism discussed in RFC 5280, which may involve the link certificate NewWithOld, which is a certificate for the new root public key signed by the old  root private key. However, it seems that indirect revocation only works for different entities. Namely, by using indirect revocation, the certificates issued by A can be revoked by a different entity B. However, in the above case, the old and new root certificates are for the same entity (or owner). So, my real questions is: Can indirect revocation be used in such a scenario? If not, is there any good way to do this, especially if interoperability with TLS, SSL, IPSec etc is required? 

        Thanks a lot in advance, 

        Guilin

        _______________________________________________
        Cfrg mailing list
        [email-masked]
        https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_cfrg&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=b8Put5_oFgOXmo6ZgfgkPLBgfZ8vtTBo-eRV9ADE6RQ&s=WFVsSgLHOQk5Z_uA5UFyPS18SCDbL27-UwYopNi9gD4&e=

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 28 Jul 2020 10:48:19 -0400

This is something the CA would address as part of the RFC 3647 framework
for discussing CA or RA termination:
https://tools.ietf.org/html/rfc3647#section-4.5.8

I don't understand the remark about signing CRLs after the expiration of
the (old) root. After that expiration, there is presumably no temporally
valid certificate chain for those existing certificates, and they are thus
not time valid, as called out in
https://tools.ietf.org/html/rfc5280#section-4.1.2.5 and
https://tools.ietf.org/html/rfc5280#section-6.1.3

I suspect I must be misunderstanding something about the question, because
I'm having trouble understanding the scenario where the revocation data
would be relevant after the expiration of all issuer certificate(s)? Is it
describing a scenario in which the new root issues a cross-certificate for
the old root, after the old root's private key has been destroyed, which
extends the lifetime of the old root beyond the 10 years specified?

On Tue, Jul 28, 2020 at 8:20 AM Salz, Rich <rsalz=
[email-masked]> wrote:

>         In practice, to guarantee high security, the validity (say 10
> years) of a root certificate private key may be essentially shorter that
> the validity (say 30 years) of the corresponding public key. After the
> first 10 years, a new root certificate with a new key pair will be
> generated, and the old root private may be even destroyed. After that,
> however, how can we use the new root private key to issue CRLs to revoke
> certificates previously signed by the old root private key?
>
>         At first, I thought this is the case of using indirect revocation
> mechanism discussed in RFC 5280, which may involve the link certificate
> NewWithOld, which is a certificate for the new root public key signed by
> the old  root private key. However, it seems that indirect revocation only
> works for different entities. Namely, by using indirect revocation, the
> certificates issued by A can be revoked by a different entity B. However,
> in the above case, the old and new root certificates are for the same
> entity (or owner). So, my real questions is: Can indirect revocation be
> used in such a scenario? If not, is there any good way to do this,
> especially if interoperability with TLS, SSL, IPSec etc is required?
>
>         Thanks a lot in advance,
>
>         Guilin
>
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 28 Jul 2020 14:54:08 +0000

I think that is the key point.  A CA cannot sign anything that goes beyond its own notAfter field.

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 28 Jul 2020 14:54:22 +0000

Ryan,

I’m interpreting the scenario to be a 30-year root cert, issuing 30 year end entities. At the 10 year mark they destroyed the root’s priv key. They are now realizing that they have end entities valid for another 20 years but no way to issue fresh CRLs for them. I may be mis-reading though.

---
Mike Ounsworth
Software Security Architect, Entrust Datacard

From: Spasm <[email-masked]> On Behalf Of Ryan Sleevi
Sent: July 28, 2020 9:48 AM
To: Salz, Rich <rsalz=[email-masked]>
Cc: [email-masked]; Wang Guilin <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed?

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
This is something the CA would address as part of the RFC 3647 framework for discussing CA or RA termination: https://tools.ietf.org/html/rfc3647#section-4.5.8

I don't understand the remark about signing CRLs after the expiration of the (old) root. After that expiration, there is presumably no temporally valid certificate chain for those existing certificates, and they are thus not time valid, as called out in https://tools.ietf.org/html/rfc5280#section-4.1.2.5 and https://tools.ietf.org/html/rfc5280#section-6.1.3

I suspect I must be misunderstanding something about the question, because I'm having trouble understanding the scenario where the revocation data would be relevant after the expiration of all issuer certificate(s)? Is it describing a scenario in which the new root issues a cross-certificate for the old root, after the old root's private key has been destroyed, which extends the lifetime of the old root beyond the 10 years specified?

On Tue, Jul 28, 2020 at 8:20 AM Salz, Rich <rsalz=[email-masked]<mailto:[email-masked]>> wrote:
Mail alias issues.  Mea culpa

On 7/28/20, 8:16 AM, "Salz, Rich" <[email-masked]<mailto:[email-masked]>> wrote:

    On 7/28/20, 6:22 AM, "Wang Guilin" <[email-masked]<mailto:[email-masked]>> wrote:

        Dear all,

        Thanks a lot in advance,

        Guilin

        _______________________________________________
        Cfrg mailing list
        [email-masked]<mailto:[email-masked]>
        https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_cfrg&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=b8Put5_oFgOXmo6ZgfgkPLBgfZ8vtTBo-eRV9ADE6RQ&s=WFVsSgLHOQk5Z_uA5UFyPS18SCDbL27-UwYopNi9gD4&e=

_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Jul 2020 07:55:59 -0700

> I think that is the key point.  A CA cannot sign anything that goes beyond its own notAfter field.

You could perhaps decide that you don't want to carry the operational risk
of securing the private key for the whole validity period, though, and
destroy all copies of the private key before the notAfter time.

-Ben

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 28 Jul 2020 11:04:15 -0400

Right, but in that scenario, it's to be treated like a CA termination
event. I don't know if you're necessarily reducing risk, but rather,
shifting risk.

Prior to destroying that key material, operationally you'd be expected to
do something such as "sign final CRLs" - e.g. revoking all certificates
that have been issued. That's the interoperable answer: destroying the key
is a termination event. Or, if you're looking at a business
continuity termination, you have arrangements for some other service
provider to continue to provide revocation services, using a copy of the
key that they have and maintain. But there's not really a good
interoperable way post key-destruction to continue the provision of
revocation information in an interoperable fashion.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 28 Jul 2020 11:59:16 -0400

Existing certs would not have CRL DPs to match the IDPs the CRLs issued by the new issuer would need contain. This would have had to have been planned to even attain poor interop. 

From: Spasm <[email-masked]> on behalf of Ryan Sleevi <[email-masked]>
Date: Tuesday, July 28, 2020 at 11:04 AM
To: Benjamin Kaduk <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>, "[email-masked]" <[email-masked]>, "Salz, Rich" <rsalz=[email-masked]>, Wang Guilin <[email-masked]>
Subject: Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed?

Right, but in that scenario, it's to be treated like a CA termination event. I don't know if you're necessarily reducing risk, but rather, shifting risk.

Prior to destroying that key material, operationally you'd be expected to do something such as "sign final CRLs" - e.g. revoking all certificates that have been issued. That's the interoperable answer: destroying the key is a termination event. Or, if you're looking at a business continuity termination, you have arrangements for some other service provider to continue to provide revocation services, using a copy of the key that they have and maintain. But there's not really a good interoperable way post key-destruction to continue the provision of revocation information in an interoperable fashion.

-Ben

_______________________________________________ Spasm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 Jul 2020 08:05:00 -0400

Using the correct WG mail list address ...

> On Jul 28, 2020, at 8:16 AM, Salz, Rich <rsalz=[email-masked]> wrote:
>