Subject: Re: [Acme] draft-sheffer-acme-star-lurk: key lifetime ?

From: Yaron Sheffer <[email-masked]>
Date: Sun, 2 Apr 2017 19:09:03 +0300

> Date: Fri, 31 Mar 2017 09:07:14 +0300
> From: Ilari Liusvaara <[email-masked]>
> To: "Dr. Pala" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset=utf-8
>
> On Thu, Mar 30, 2017 at 03:36:30PM -0500, Dr. Pala wrote:
>> Hi Ilari, all,
>>
>> I strongly disagree with your statement. From a crypto standpoint, key
>> rotation IS an important point and should be addressed. I think something
>> could/should be added to the I-D to limit the number of renewal or the
>> period where the same CSR can be used for certificate re-issuing.
>>
>> The solution might be as simple as set a validity in the CSR that is
>> generated (if you want that to be in control of the requesting client). I am
>> not suggesting the specifics of how to solve it, but I think that this is a
>> point that should be addressed (possibly something that was in the mind of
>> the original authors, but did not make it in the document... ?).
>
> I just read the draft. A facility to limit the private key period,
> assuming you want to do that, already exists.
>
> And there are a number of sane-looking metrics[1], where any timed key
> rotation strictly[2] decreases security.
>
>
> [1] Basically, anything that considers security issue duration.
>
> [2] Meaning you get '<' operator in comparision, not '<='.
>
>
> -Ilari

The draft is not very clear on this, but the intent is to limit the 
duration of each delegated certificate, as well as the duration of 
delegation as a whole. Once delegation is over, a new CSR needs to be 
generated.

However if the client wants to use the same private key forever, the CA 
will not stop it from doing that. And as far as I know, neither does a 
CA today.

Thanks,
	Yaron