Consider maximum certificate lifetime well below CABF limits

[konklone]

Certificate automation isn't widespread in the federal IT community. Agency IT departments still tend to manage certificates manually, and favor long-lived certificates so they don't need to replace them often. This makes migrations from old algorithms and technical standards slow and painful.

That's particularly acute right now with the transition from SHA-1 to SHA-2, but I'm more concerned with what happens if a weakness is demonstrated in SHA-2 in the next few years and we suddenly all have to move to SHA-3 (and so on).

One way we might make a down payment on algorithm agility in the federal enterprise is to limit the lifespan of certificates beyond CABF's existing 39-month limit. You can imagine a spectrum of possible approaches:

• No certificate lasts longer than 30 days. (Manual rotation is infeasible. Pressure to automate is overwhelming.)
• No certificate lasts longer than 90 days. (Manual rotation is feasible but annoying. Pressure to automate is present. This is what Let's Encrypt does.)
• No certificate lasts longer than 1 year. (Manual rotation is quite feasible, but agencies are still forced to replace their certificates at a pace that's responsive to broader security trends. Pressure to automate is weak, though.)

You could also imagine that, during a transition period of some future deprecation, the root could update its CP to limit end-entity issuance of certificates using deprecated algorithms to less than the overall limit. For something like this, we'd want to have generic language in the CP now that sets expectations that this is how the root will handle transitions, and empowers future staff to follow through on such a decision, even if it causes inconvenience and frustration for agencies at that time.

However, that wouldn't be a replacement for limiting the lifespan of all certificates in some way, since a 39-month deprecated certificate issued a few months before deprecation would still prevent deprecation from completing for 3 years.

[bifurcation]

(Speaking as a private individual knowledgeable in PKI matters)

Much though I would prefer a 30 day lifetime limit (or even 10 days), I think the state of technology still supports a 90 day lifetime. The existence of automated tools is increasing, but until there's more widespread support for automated certificate management (I would estimate another 9-18 months), there still needs to be some provision for manual intervention.

I see no reason to have certificates longer than 1 year in the current environment. As @konklone notes, that is well within the realm of what can be managed manually. It's quite generous, though. If there's sufficient discomfort with automation that people are unwilling to accept a 90 day lifetime, you might consider a 6 month lifetime as an intermediate step.

Note that in any case, this should be a maximum, and applicants for certificates should be able to request shorter lifetimes. There are facilities for this in ACME if that's the protocol that will be used for automation here.

[jsha]

Speaking as an EFF Senior Staff Technologist. I work on EFF's Encrypt the Web iniative, and the Let's Encrypt certificate authority. I support a 90-day maximum certificate lifetime. Similar to @bifurcation, I think it strikes a decent balance between encouraging automation and minimizing risks. Below are some pros and cons I distilled from a Let's Encrypt forum thread involving many seasoned systems administrators (I've remove the points specific to Let's Encrypt):

Pros:

• When an attacker compromises a certificate's private key, they may bypass revocation checks and use that certificate until it expires. Shorter lifetimes decrease the compromise window in situations like Heartbleed.
• Offering free certificates with a shorter lifetime provides encouragement for operators to automate issuance. Automated issuance decreases accidental expiration, which in turn may reduce warning-blindness in end-users.

Cons:

• Common non-HTTPS servers (IRC, mail, VPN) may require a restart to load new certificates. Ninety-day certs mean six server restarts per year instead of one, interrupting long-lived connections more frequently.
• Automated deployment of renewed certificates to routers, firewalls, and Internet of Things devices is difficult.
• Some operators choose not to run any automated renewal software on their servers. Manually renewing every 60 days is burdensome.
• More frequent renewals increase the chance that a renewal may fail repeatedly for 30 days while an operator is unavailable, leading to an outage.

[lachellel]

These are all spot-on pros / cons.

Let's take the most urgent question on the table, and get some feedback:

• server authentication maximum lifetime: 13 months

What is needed to achieve this US government wide for HTTPS servers? Are there blockers in policy, processes, NIST standards, commonly used platforms, knowledge dissemination, or even procurement practices - that would need to be addressed?

ref #80

[konklone]

I've never come across any policy, standards, platform, or procurement limitations that would prevent the use of 1-year certificates across the board. It might be helpful to do a poll of IT shops to ask how they structure their certificate acquisition, but a USG-run option would also be in the helpful situation of not needing to be "procured".

I think the main issue would be knowledge dissemination -- limiting surprise and consternation when staff discover they can't get a 2 or 3 year certificate like they're used to. It's also quite possible that some offices might choose to continue the status quo of using a 2-3 year commercial certificate over switching to a 1-year USG certificate. That could be mitigated somewhat by what I would expect to be strong internal agency policy pressure to use USG-issued certificates once they are publicly trusted. It's tough to say what might win out in the immediate term, but I would expect that with every year, more agencies would move more of their certs over to a USG option, and that the USG PKI would be happy it made the decision up front to keep themselves to issuing shorter certificates.

I personally think a 90-day limit would backfire for an unacceptably long period of time, but that a 1 year limit would be accepted right away by most of the federal community, with the share increasing every year after that.

[IanLee1521]

For my own edification, is there a anything (today) to automate / streamline the signing and returning of CSR's if a site maintains it's own CA?

I've just recently taken on responsibility for getting a number of vulnerability / compliance issues out of the way in our HPC center, and I think one of the biggest hurdles is simply the raw number of certificates that need to be generated (~ hundreds)... Typically the workflow has been to email them in to our local PKI team for signing and return, but that process has been quite slow.

As I've started following more of the PKI efforts, I've started thinking about what we could do to automate this workflow, and from the above conversation, am trying to figure out if the blockers / delays mentioned (e.g. that automation may be months - years away) are for a federal PKI authority, or if that would apply to locally managed PKI CAs as well?

[jsha]

@IanLee1521: The ACME spec aims to automate the validation and signing of CSRs: https://ietf-wg-acme.github.io/acme/. The first deployment has been the Let's Encrypt public certificate authority, but the protocol could also work well for internal CAs, and I've heard of sites starting to deploy it for that purpose. Feel free to post at https://community.letsencrypt.org/ if you'd like to learn more!

[grandamp]

A few random thoughts...

FIPS validated hardware (gt Level 2 protection) may be challenged with crypto officer or user key generation, which may require a manual process. I.e., safenet and thales HSMs.

Shorter lifetimes help with the revocation burden, as well as CRL or OCSP DB sizes, but are we saying that there would no longer be a need for revocation? IMO, this could create a substantial risk for high assurance systems. I.e., making payments on behalf of the united states, auctioning $80b in debt, etc.

A general challenge I perceive, not to contradict @konklone, is that certificates themselves are not entirely to blame for lack of algorithm agility. I believe we clearly see that some key management systems (CAs), as well as relying party software (browsers, etc), are not quite agile in implementing standards, and in some cases not comprehensively. Yet, the issue is not just algorithm agility, but basic function. Revocation checking (due to availability and scale), or lack thereof, is a good example. So is processing a certificate according to RFC 5280, which is a core baseline requirement.

On Sat, Feb 11, 2017, 15:04 Jacob Hoffman-Andrews notifications@github.com wrote:

@IanLee1521 https://github.com/IanLee1521: The ACME spec aims to automate the validation and signing of CSRs: https://ietf-wg-acme.github.io/acme/. The first deployment has been the Let's Encrypt public certificate authority, but the protocol could also work well for internal CAs, and I've heard of sites starting to deploy it for that purpose. Feel free to post at https://community.letsencrypt.org/ if you'd like to learn more!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uspki/policies/issues/72#issuecomment-279171989, or mute the thread https://github.com/notifications/unsubscribe-auth/AMhKoBd7KUy5AQsGTSUBVawulkacv_xCks5rbhRVgaJpZM4Lq44d .

[jsha]

FIPS validated hardware (gt Level 2 protection) may be challenged with crypto officer or user key generation, which may require a manual process. I.e., safenet and thales HSMs.

While best practice in most cases is to generate a new key for each end-entity certificate, it would seem reasonable to sign a new cert each year while retaining the same private key, if the private key is stored in an HSM. I think this would alleviate some of this concern.

Shorter lifetimes help with the revocation burden, as well as CRL or OCSP DB sizes, but are we saying that there would no longer be a need for revocation?

I'm pretty sure that no one on this thread is proposing to do away with revocation.

[konklone]

Shorter lifetimes help with the revocation burden, as well as CRL or OCSP DB sizes, but are we saying that there would no longer be a need for revocation?

I'm pretty sure that no one on this thread is proposing to do away with revocation.

Yes, definitely not. (And not to speak for Let's Encrypt, but I'll note that they recently implemented support for the OCSP Must-Staple extension.)

A general challenge I perceive, not to contradict @konklone, is that certificates themselves are not entirely to blame for lack of algorithm agility.

I don't feel contradicted. 😉 I agree entirely! There are multiple other benefits to shorter certificates, which @jsha laid out nicely in https://github.com/uspki/policies/issues/72#issuecomment-274677996.

[grandamp]

Thanks for the clarification! It was mentioned last year by @sleevi that Chrome on android does not perform revocation checking. I was not certain if this was a widespread pattern. I certainly understand the challenge, as our validation service consumes 1.5GB+ revocation data on a daily basis.

From an operations perspective, the U.S. Government has been in love with certificate revocation when said certificate is no longer used. This is unfortunate in circumstances where you have proof that a private key is destroyed, such as a post-issuance update on a FIPS-201/SP 800-73 conformant smart card (PIV/PIV-I credential). This leads to the 256 byte to ~40mb CRLs you see within the FPKI.

As for key re-use over a certain "crypto period"... I certainly support. This is quite similar to ephemeral OCSP signing certificates (yet the nocheck extension inhibits revocation checking) within the Federal PKI. The keys may have a period of up to 3 years, but the certificates must be short lived to reduce the risk of assumed CA compromise.

Thanks for the feedback, and entertaining my thoughts!

[jsha]

It was mentioned last year by @sleevi that Chrome on android does not perform revocation checking. I was not certain if this was a widespread pattern.

Yes, that's correct, and Chrome on other platforms does the same. Similarly, Firefox on all platforms has what I would call "weak revocation checking," since a failure or timeout of the OCSP request will not block a connection. There are various points of view on whether these choices are good or bad, but they are the current status quo.

However, CAs do still have an obligation to maintain and make available revocation data, and high assurance systems can set their own, stricter policies about revocation checking.

None of the certificate lifetime choices proposed here would affect either of these things.

There have been some discussions in the browser world of super-short (< 7 days) certificates as an alternative to OCSP-based revocation, but that's not being proposed here.

[grandamp]

However, CAs do still have an obligation to maintain and make available revocation data, and high assurance systems can set their own, stricter policies about revocation checking.

Awesome. I believe the language for revocation requirements, and availability of the data, should be abundantly clear. I also believe that in circumstances where revocation is not needed, revocation is not required. I.e., cessation of operation and destruction of the private key.

I believe some SLA type of language is also needed for any substantial infrastructure change, such as notification (to those whom care) 2 weeks prior (from every issuing CA) for new PKI artifacts. I.e., ocsp URI, CDP URI, cross certificates, etc. However, this may be a different topic, and thus a candidate for another issue.

[brodygov]

Most of the government programs I've seen would struggle with a 90 day maximum. They already have trouble remembering to renew 1-year certificates. And this is certainly a good case for automation, but most programs I've seen just don't have that level of maturity in their deployment processes.

👍 to a 1 year maximum. In my experience, once you have enough certificates deployed, even a 1 year maximum provides some pressure to automate. You could also use a scorecard approach to apply pressure, giving a better score to agencies that select the 90-day-validity checkbox when issuing certificates.

[lachellel]

My 2 cents:

I think the most we could do in the policy is put in a practice note OR a target date

For example:

• All subscriber certificates issued on or after January 1, 2019 shall have a maximum validity period of thirteen (13) months.

[konklone]

As a note, the CA/Browser Forum virtually unanimously (zero No votes, a few abstentions) passed Ballot 193, which lowers the maximum certificate lifetime to 825 days (~26 months):

https://cabforum.org/pipermail/public/2017-March/010101.html

This cuts max certificate lifetimes from ~39 months to ~26 months.

I'll suggest again that I think it would be a great idea for us to place a 13-month limit, and @lachellel's suggestion of giving a future date so as to give people sufficient time to adjust would be a totally acceptable way to do it.

That said, it'll probably be at least January 2019 until anyone's issuing certifcates from this thing anyway. :) So the time it takes this thing to get into operation may already provide the reasonable buffer -- in which case, I would suggest we just decide to do it and communicate those expectations up front.

[lachellel]

The original text of ballot 193:

• https://cabforum.org/pipermail/public/2017-March/009885.html

Update Section 6, 4, etc.

@tlsrus - discussion topic for awareness and planning

[lachellel]

While reviewing for final edits ->

Question: Should we put a note that states we should be prepping for a 13 month certificate maximum lifetime by \? Such as by 2020 (arbitrary date)

[konklone]

Answer: :+1:

:) Setting a too-specific date might create some unexpected consequences, but suggesting that we expect certificate max lifetimes to drop to 13 months by circa 2020 seems like a positive step.

[LarryFrank]

Sorry - apparently I missed this thread... As much as I would like shorter time frames, I would recommend using the current CA/B standard and NOT put a specific date for shortening. While ACME may work wonderfully, it requires web server changes that will cost time and money which system owners may not have in their budgets. Recurring manual processes generate a lot of anxiety (and push back) in DoD.

[sleevi]

Note that the CA/B Forum represents the industry defined minimum standards, and some vendors have indicated they will reduce that even more. That's why I'm very supportive of proactive measures for CAs to be hold a higher security standard than the bare minimum. :)

[grandamp]

I'm very supportive of doing our best to reduce lifetime, and support automation.

Automation helps to reduce costs, un-educated mistakes, and promotes better cryptographic/trust surety.

I couldn't imagine needing to contract for human support for registration & systems configuration of TLS server cerficates, especially with a growing number of devices/systems. That model is not sustainable.

On Thu, Sep 14, 2017, 14:39 sleevi notifications@github.com wrote:

Note that the CA/B Forum represents the industry defined minimum standards, and some vendors have indicated they will reduce that even more. That's why I'm very supportive of proactive measures for CAs to be hold a higher security standard than the bare minimum. :)

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/uspki/policies/issues/72#issuecomment-329572433, or mute the thread https://github.com/notifications/unsubscribe-auth/AMhKoPbPq4BqtQkS36vXg0PHgcuggFCTks5siXLQgaJpZM4Lq44d .

[LarryFrank]

As a long time player in this PKI game, good intentions married to arbitrary deadlines that don't get met causes problems. I am saying that this PKI needs to let the industry standard dictate the certificate life. Will be hard enough meeting that.

[konklone]

I agree about unmet deadlines and don't think we have to put a specific deadline, but we can communicate that:

• subscribers are encouraged to get certs at or under 13 months
• that it's possible the PKI may reduce the maximum lifetime by policy at a later time
• individual issuing CAs are allowed/encouraged to use a lower max lifetime than the ceiling in the root CP

[LarryFrank]

•subscribers are encouraged to get certs at or under 13 months •that it's possible the PKI may reduce the maximum lifetime by policy at a later time •individual issuing CAs are allowed/encouraged to use a lower max lifetime than the ceiling in the root CP

Agree. Although bullet two is probably too weak - I think we will be required to reduce the max time by changes to the CA/B BR and subscribers need to know that earlier than later.

[konklone]

I think we will be required to reduce the max time by changes to the CA/B BR and subscribers need to know that earlier than later.

Agree as well. So yeah, emphasizing that it's very likely that we may either choose to, or be required to, lower the maximum lifetime to 13 months in the future would be helpful.

That said: I still think we would be best served by just setting a 13-month limit for ourselves now. There's no better way to set people's expectations for this than by just doing it!

[LarryFrank]

That said: I still think we would be best served by just setting a 13-month limit for ourselves now. There's no better way to set people's expectations for this than by just doing it!

Be prepared for a non-concur from DoD if you do that...

[lachellel]

This topic is still open.

• Limit all serverAuth to 13-month (or the 395 days general equivalency).

If we would limit the validity time period in the Certificate Policy, should the following also be aligned:

• Limit reuse of validation / identity evidence to 13 months

[LarryFrank]

•Limit reuse of validation / identity evidence to 13 months

Do not see a need to do that although I expect it will be done in practice. But let's not make manual any harder than it has to be...

[techliaison]

I agree with Larry

[konklone]

I want to be flexible where we can, but if we were to limit cert lifetimes to 13 months, I think it would be a requirement to limit reuse of validation information. If reuse of validation information were valid for 26 months, it would defeat the purpose of the lifetime limitation.

[rmhrisk]

re: If reuse of validation information were valid for 26 months, it would defeat the purpose of the lifetime limitation.

Not that I disagree with the overall conclusion on not limiting validity, you have business constraints to consider after all but limiting lifetime to 13 months would ensure new keys for that period which is a value in itself.

[LarryFrank]

lifetime limitation

The "purpose" isn't articulated in the policy. One good purpose for shorter lifetimes is cryptographic securty of the keys - the longer and more often a key is used the more easily it can be cracked (or so I am told...)

Do we actually KNOW what the actual purpose of reducing key life is? We are doing this because of the CT requirement (at least that is what I understand) to post to more logs if longer than 13 months - not because the CA/B forum may (probably will?) reduce lifetimes at some point in the future.

[rmhrisk]

CA/Browser forum doesn’t have any CT requirements. browsers do, the longer lived the cert the more likely there could be a log failure. That is where the more log requirement originates.

[LarryFrank]

CA/Browser forum doesn’t have any CT requirements. browsers do, the longer lived the cert the more likely there could be a log failure. That is where the more log requirement originates.

Agree - I didn't mean to imply that the number of CT logs was a CA/B Forum requirement - just that the number of CT logs is the reason the Fed PKI is intending to require a max of 13 months cert life. That should not force a change in the useful life of information held by the CA for confirming ownership. Given that ownership of a domain name almost NEVER changes in the Fed, it is just busy work to have to obtain new copies of the same documentation every 13 months...

[sleevi]

@LarryFrank I couldn't find any statements that the sole purpose was related to CT - could you clarify?

There were several reasons articulated above, but here's a small sample of the reasons to prefer shorter certificates:

• As the Revocation Infrastructure for publicly-trusted certificates is a disaster (from the CA side), and provides perverse incentives for both privacy and performance reasons, browsers have been forced to disable revocation checking. Shorter lifetime certificates bound the maximum harm possible.
• Publicly-trusted certificates need to be agile to changes in validation methods used to ascertain domain control and subscriber information - weaknesses in both are an active topic of the CA/Browser Forum, and assurance can only be had (both as a CA and ecosystem wide) when all certificates validated under the old regime have expired.
  • Notably, this can be partially mitigated by CAs actively declaring what version of the BRs they used and what method they validated domains with, but at a performance cost for clients
  • Examples of this include the sunset of "Any other method" for validation or "internal server name" certificates
• Publicly-trusted certificates need to be agile to changes in certificate profiles and policies. This is distinct from the validation method, and applies to everything from the hash algorithm used to the extensions present and their content.
  • Examples of this include the deprecation of SHA-1 or the presence of iPAddresses in dNSNames, along with the countless CA misconfigurations
• Cryptographic strength of the key over time
  • Although this primarily relates to Intermediate certificates, it affects some other considerations below
• Achievable cryptographic protection of the key over time (e.g. how long can this key be kept in storage, yet also "Internet Exposed", safely?)
  • Examples of this include a number of provides - Google, Facebook, Cloudflare - engaging in more frequent key rotation, due to the wide distribution of that key in order to serve such endpoints

There's also 'soft' factors to consider

• The familiarity by systems personnel in obtaining and renewing certificates
  • A playbook exercised once every three years is much less valuable than a routine playbook, annually or even quarterly
• The ability to respond to CA ecosystem changes in a timely fashion
  • As trust in CAs may change over time, the habit of periodically replacing the certificate ensures that any change in service or trust is something that can be responded to as part of regular maintenance
• The ability to sunset existing intermediates (and their supporting infrastructure, such as CRLs and OCSP) in a timely fashion, reducing overhead from these systems and their risk management
• Redundancy of CT logs (as you've mentioned)
• Overall trends in the browser industry to require shorter lived certificates

As to what motivates this particular policy, I can't respond to that, but these are just a few of the reasons why they're preferable and offer better security for both users and site operators :)

[lachellel]

To reduce complexity:

• Intent is to validate domain(s) immediately prior to issuance of any certificate that contains that domain in the SAN
• Issue has been raised and noted that when using the Domain Authorization Document validation method, more complexity and overhead is introduced if a requirement is to validate a domain every single time any certificate is issued with that domain
• Other subject information will be very limited, even for the OV cert profile (Subject Information will include org / US Government and State / District of Columbia)
• To move towards the intent to validate each time and to reduce complexity of dates, identity evidence validity (section 4.x) will be decreased to 395 days but will not be further reduced in this version of the CP

@konklone @LarryFrank