Bug 1087932

Given the ability to re-key, it may be a good idea to set a new configuration option for the number of renewals before re-keying. This probably needs to be more complex than an integer to reflect different validity periods, so perhaps a formula like n renewals in y years, then re-key.

Other than any variations in how the request is sent to the CA, I'm not sure that any other new policies around this forced re-key is required. We'd still want to revoke the old key.

This should apply only to server certificates, not signing certificates.

(In reply to Rob Crittenden from comment #2)
> Given the ability to re-key, it may be a good idea to set a new
> configuration option for the number of renewals before re-keying. This
> probably needs to be more complex than an integer to reflect different
> validity periods, so perhaps a formula like n renewals in y years, then
> re-key.
> 
> Other than any variations in how the request is sent to the CA, I'm not sure
> that any other new policies around this forced re-key is required. We'd
> still want to revoke the old key.
> 
> This should apply only to server certificates, not signing certificates.

For an IPA-issued service certificate (specifically, a caIPAServerCert), what's the downside of always rekeying?

I'm getting the feeling that any scheme for deciding when to rekey, and when not to, that can't be expressed very simply, is going to make it harder for people to verify that they got the desired outcome.  Obviously we'd need to make it something that can be manually triggered, but beyond that I'm having some trouble coming up with a reasonable way to cover cases with both very long and very short lifetimes.

When you refer to signing certificates, do you mean CA subsystem certificates, or something else?  In the general case, I think certificates that can be used to sign things other than certificates can be replaced with certificates using different keys without trouble.  It's the ones where the private key can be used for encrypting data that complicate things, because I think we want to keep those old keys around, and if certificates are short-lived, rekeying often can start using up disk.

I'm not aware of a best practice for re-keying SSL server certs, though it should probably be some number between always and never. I think functionally re-kaying would have little to no impact on the servers themselves except perhaps key size and type (e.g. RSA vs ECC).

I was thinking object signing certs above. I think the trick would be whether you revoke the old cert when you re-key, something generally done, but that invalidates anything signed by the previous key if checking is done.

As for re-keying periods, I can definitely foresee a disconnect between cert profile validity periods and rekeying policies, e.g. a server cert is good for 2 years but re-keying policy says it must be done annually. Whether that's a problem we want to/can solve I don't know. Perhaps sanity can be enforced when policy is created. 

I'm not sure what Fraser has in mind in terms of exposing the policy/profile. I imagine there will be an API call that certmonger can make to get the period. I suppose expressing re-keying in terms of months of validity would be fine-grained enough, and if you store the date a key is generated then it should be relatively "easy" to know whether a re-key is required. I'd imagine there could be a magic value, -1, 0, or some huge value, to say never re-key.

Going forward, we'll be able to interpret a new helper exit status as indicating that we need to try again with a new key in the signing request, and we'll be tracking the date when we generated a key and the number of times we've saved issued certificates to disk that used the current key pair.

I think if we add configuration file options for maximum preferred age and key use counts, we can automate the process of having the client initiate rekey attempts.  I'm a bit leery of cases where we ask for a rekey, and either due to server or helper configuration or behavior we end up getting a certificate that includes the public key that we wanted to replace, because we won't have much recourse when that happens.

If IPA has a reply code (somewhere in the 4300 range?) that it can supply when the server determines that the client needs to try again with a new key pair, we can also catch that in ipa-submit and exit with status 16 to pass that information back to the daemon, which will trigger a rekey at the client.

Er, 17, that is.