Re: Managing Long-Lived CA certs

Hi Carl, all,

yes, I agree with you that in a perfect world that would work... but 
lightbulbs and other small IoT will probably never do any OCSP.. so, 
this proposal is to address a problem that we are already seeing today 
and that device manufacturer are not really equipped to address and/or 
even understand it.

It is not a perfect solution, but a possible mitigation.. :D

What I understand from all the responses is that today nothing really 
exists, and there might be space for a simple proposal.. maybe in LAMPS 
or as an individual contribution. I personally think there is value for 
the IoT / Devices environment.

Thanks everybody for your replies!

Cheers,
Max


On 7/17/17 6:46 PM, Carl Wallace wrote:
> 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 <[email protected] <mailto:[email protected]>> on 
> behalf of "Dr. Pala" <[email protected] <mailto:[email protected]>>
> Organization: OpenCA Labs
> Date: Monday, July 17, 2017 at 12:29 PM
> To: <[email protected] <mailto:[email protected]>>
> 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
>     OpenCA Logo
>     _______________________________________________ pkix mailing list
>     [email protected] <mailto:[email protected]>
>     https://www.ietf.org/mailman/listinfo/pkix 
>

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix