Re: [pkix] Managing Long-Lived CA certs

[Carl Wallace <[e-mail]>]

If the system is compromised, revoke all issued certs since you stopped
using the key (assuming the system compromise isn't such that your efforts
can be undone by the attacker). You could do this fairly easily with OCSP
and a whitelist of issued certs generated when the private key stops being
used for certificates. That begs a different question. What about responder
certs? Would there be a loophole for those?

The upside feels light relative to the challenge of updating path validation
implementations and I tend to doubt enough implementations would pick this
up to obviate the need for one of the above steps anyway – especially when
considering a target is implementations that are already incomplete.

From:  pkix <[e-mail]> on behalf of "Dr. Pala"
<[e-mail]>
Organization:  OpenCA Labs
Date:  Monday, July 17, 2017 at 12:29 PM
To:  <[e-mail]>
Subject:  Re: [pkix] Managing Long-Lived CA certs

>     
>  
> 
> Hi Carl,
>  
> 
> you are totally right :D That case would be covered by the revocation of the
> CA key. However, there are also other types of compromises (e.g., the system
> is compromised, but the key is not - certificates issued by non-authorized
> person).
>  
> 
> Keep in mind that in the ecosystem where this happens (device certs and many
> others) certificate revocation is not really checked... this would limit the
> exposure for non-catastrophic compromise events.
>  
> 
> Does this make sense ? What do you think ?
>  
> 
> Cheers,
>  Max
>  [*] = I know that checking revocation is still, regrettably, not common...
>  
>  
> On 7/17/17 5:42 PM, Carl Wallace wrote:
>  
>  
>> [...] 
>> [CW] Wouldn't the protection need to come in the form of revocation? If the
>> CA key is compromised, the validity period in certificates cannot be trusted.
>> [...]
>>   
>  
>  
> -- 
>  
>  Best Regards, 
>  Massimiliano Pala, Ph.D.
>  OpenCA Labs Director
>  
>  
>  
>  
>  
> _______________________________________________ pkix mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/pkix