About upcoming limits on trusted certificates

[Clint Wilson]

Hello all,

I wanted to inform this community of an upcoming change to the Apple Root Program.
SSL/TLS certificates issued on or after September 1, 2020 will need to have a total lifetime of no more than 398 days. This change will be put in place in a future release of iOS, macOS, iPadOS, watchOS, and tvOS for default-trusted TLS certificates (i.e. the Roots that come preinstalled on the above OSes).

For additional information, please see https://support.apple.com/en-us/HT211025.

Thank you!
-Clint

[Wayne Thayer]

Thank you for sharing this Clint.

I'd like to ask for input from the community: is this a requirement that we
should add to the Mozilla policy at this time (effective September 1, 2020)?

You may recall that a 398-day maximum validity for TLS certificates was
proposed to the CA/Browser Forum by Google last year. Mozilla voted in
favor, but ballot SC22 failed due to a lack of support from CAs. [1] Many
of the arguments for and against this change can be found in the emails
sent by CA/Browser Forum members during the discussion [2] and when casting
their votes.[3]

- Wayne

[1] https://cabforum.org/pipermail/servercert-wg/2019-September/001080.html
[2] https://cabforum.org/pipermail/servercert-wg/2019-August/
[3] https://cabforum.org/pipermail/servercert-wg/2019-September/

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Matt Palmer]

On Tue, Mar 03, 2020 at 11:55:24AM -0800, Clint Wilson via dev-security-policy wrote:
> For additional information, please see https://support.apple.com/en-us/HT211025.

I have a question regarding this part:

> TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC
> must not have a validity period greater than 398 days.

How is Apple determining when a certificate was issued? That's
traditionally been pretty tricky to determine, exactly, so I'm curious to
know how Apple has solved it.

- Matt

[Matt Palmer]

On Tue, Mar 03, 2020 at 01:27:59PM -0700, Wayne Thayer via dev-security-policy wrote:
> I'd like to ask for input from the community: is this a requirement that we
> should add to the Mozilla policy at this time (effective September 1, 2020)?

I don't see any reason not to.

- Matt

[Clint Wilson]

Hi Matt,

This is determined using the notBefore value in the certificate; if the notBefore value is greater than or equal to September 1, 2020 00:00 GMT/UTC, then the updated policy will apply.

Cheers,
-Clint

[Matt Palmer]

On Tue, Mar 03, 2020 at 01:53:49PM -0800, Clint Wilson wrote:
> On Mar 3, 2020, at 1:41 PM, Matt Palmer via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> > On Tue, Mar 03, 2020 at 11:55:24AM -0800, Clint Wilson via dev-security-policy wrote:
> >> For additional information, please see https://support.apple.com/en-us/HT211025.
> >
> > I have a question regarding this part:
> >
> >> TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC
> >> must not have a validity period greater than 398 days.
> >
> > How is Apple determining when a certificate was issued? That's
> > traditionally been pretty tricky to determine, exactly, so I'm curious to
> > know how Apple has solved it.
>

> This is determined using the notBefore value in the certificate; if the
> notBefore value is greater than or equal to September 1, 2020 00:00
> GMT/UTC, then the updated policy will apply.

It may be worth clarifying that in the support article. Are Apple intending
on taking any active steps to dissuade CAs from backdating certificates?
Relatedly, does Apple have a similar stance against backdating to that of
Mozilla, which lists it as a "potentially problematic practice"?

- Matt

[Nick Lamb]

On Tue, 3 Mar 2020 13:27:59 -0700
Wayne Thayer via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> I'd like to ask for input from the community: is this a requirement
> that we should add to the Mozilla policy at this time (effective
> September 1, 2020)?

If Mozilla adds this as a policy requirement it should also land
enforcement in Firefox that rejects certificates which violate this
policy. I tried to investigate whether this currently happens for the
825 day rule in the BRs but failed to satisfy myself either way.


I read the SC22 discussion when it happened but I will re-read it all in
the light of Apple's recent decision and your question and post again
if that results in something I miss here.


One thing Mozilla definitely shouldn't replicate is Apple's decision to
present this to CA/B in person - resulting in tech news coverage based
on hearsay and conjecture - then only follow up days later to the wider
population with material that doesn't cover every obvious question a
reasonable person would have. A few hours before Clint's post I actually
had to explain to someone that their understanding of the issue was
probably wrong† - but with nothing official from Apple it was
impossible to say so definitively, which means they're left pointlessly
confused, presumably not Apple's purpose here.

If Mozilla does follow Apple's policy here (which I am minded to think
is the wiser course) they should make sure to have materials on hand
immediately to clarify exactly what that will mean to both specialists
and lay people when that policy is announced.


†They had imagined existing two year certificates would suddenly cease
to work on iPhones after their first year, which of course would be a
nightmare to manage and does not match Clint's confirmation here that
notBefore will be used to decide which certificates the policy applies
to.

[Doug Beattie]

Hi Clint,

The content of your email, the blog post and the Apple root policy all say
something a little different and may leave some room for interpretation by
the CAs. As it stands, things are a bit confused. Here's why:

Your mail is a little light on the details. While you say this is an
"upcoming change" to the Root Program you say certificates "will need to
have a lifetime of no more than 398 days". The "will need to have" is
really weak. If this is a hard requirement then I would say something
stronger like: "The Apple Root Program requires (as of Sept 1) CAs to issue
certificates with validity period not to exceed a total life time of 398
days under roots in the Apple root program. Any certificates issued under a
Root in the Apple root program will be considered a violation of the Apple
Root policy" (or something like that). Done, everyone knows exactly what
you mean.

The article you posted does not mention Apple Root program or policy and it
more or less a general statement without any context. "TLS server

certificates issued on or after September 1, 2020 00:00 GMT/UTC must not

have a validity period greater than 398 days." If Connections (presumably
from Safari browser or Apple apps) are attempted, then "This might cause
network and app failures and prevent websites from loading". There is
nothing indicating this is an Apple Root policy requirement or that CAs need
to take note, only that if an Apple endpoint encounters one of these
non-compliant certificates, the connection may/will fail.

Your root policy: Obviously there is nothing here about this new change, and
if this is "the" Apple root policy, I'd recommend getting that updated with
a clear statement of this requirement and what happens if a certificate is
issued with a lifetime outside of this duration. Chrome has a policy that
it will not trust certificates that are not compliant with their CT policy,
but it's not a Root policy. Is this how Apple views their policy, or is it
a Root policy and any non-compliance is considered a mis-issuance by Apple?
The various statements lead me back and fourth between those 2
interpretations.

I think it's important that this be clearly stated, and I dislike formal
root policies being documented only in email threads. How would a new CA
know this is a requirement without going through years of archived email on
multiple lists?

By the way, there is no reporting process outlined in the event that
something in your policy is violated. How should violations be reported and
tracked?

Thanks!

Doug

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On
Behalf Of Clint Wilson via dev-security-policy
Sent: Tuesday, March 3, 2020 2:55 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: About upcoming limits on trusted certificates

Hello all,

I wanted to inform this community of an upcoming change to the Apple Root
Program.
SSL/TLS certificates issued on or after September 1, 2020 will need to have
a total lifetime of no more than 398 days. This change will be put in place
in a future release of iOS, macOS, iPadOS, watchOS, and tvOS for
default-trusted TLS certificates (i.e. the Roots that come preinstalled on
the above OSes).

For additional information, please see
https://support.apple.com/en-us/HT211025.

Thank you!
-Clint

[Wayne Thayer]

On Wed, Mar 4, 2020 at 11:48 AM Nick Lamb <n...@tlrmx.org> wrote:

> On Tue, 3 Mar 2020 13:27:59 -0700
> Wayne Thayer via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > I'd like to ask for input from the community: is this a requirement
> > that we should add to the Mozilla policy at this time (effective
> > September 1, 2020)?
>
> If Mozilla adds this as a policy requirement it should also land
> enforcement in Firefox that rejects certificates which violate this
> policy. I tried to investigate whether this currently happens for the
> 825 day rule in the BRs but failed to satisfy myself either way.
>
>

I'm fairly certain that there is no validity period enforcement in Firefox.
The request is https://bugzilla.mozilla.org/show_bug.cgi?id=908125 I'm also
not in a position to commit Mozilla to technical enforcement if we adopt a
policy of 398 days. However, I believe there is still value in the policy
alone - violations are easily detected via CT logs, and making them a
misissuance under our policy then obligates the CA to file a public
incident report.

> I read the SC22 discussion when it happened but I will re-read it all in
> the light of Apple's recent decision and your question and post again
> if that results in something I miss here.
>
>
> One thing Mozilla definitely shouldn't replicate is Apple's decision to
> present this to CA/B in person - resulting in tech news coverage based
> on hearsay and conjecture - then only follow up days later to the wider
> population with material that doesn't cover every obvious question a
> reasonable person would have. A few hours before Clint's post I actually
> had to explain to someone that their understanding of the issue was
> probably wrong† - but with nothing official from Apple it was
> impossible to say so definitively, which means they're left pointlessly
> confused, presumably not Apple's purpose here.
>
> If Mozilla does follow Apple's policy here (which I am minded to think
> is the wiser course) they should make sure to have materials on hand
> immediately to clarify exactly what that will mean to both specialists
> and lay people when that policy is announced.
>
>

As usual, I'll propose the policy language and we'll discuss it on the list.

[Nick Lamb]

On Wed, 4 Mar 2020 16:41:09 -0700

Wayne Thayer via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> I'm fairly certain that there is no validity period enforcement in
> Firefox. The request is
> https://bugzilla.mozilla.org/show_bug.cgi?id=908125 I'm also not in a
> position to commit Mozilla to technical enforcement if we adopt a
> policy of 398 days. However, I believe there is still value in the
> policy alone - violations are easily detected via CT logs, and making
> them a misissuance under our policy then obligates the CA to file a
> public incident report.

I see, well that explains why I struggled to find it :) Always harder
to prove a negative.

There is some value in policy alone but there's also substantial
independent value in writing the policy into the code. Would Mozilla
accept third party work to implement something like #908125 ? I
appreciate you don't work for them any more Wayne, perhaps Kathleen or
somebody else who does can answer?

Bad guys don't obey policy. Certificates constructed to attack
Microsoft's bad implementation of elliptic curve signatures recently
for example obviously needn't respect policy documents. But they *did*
need to pass Chrome's technical enforcement of that policy. A
certificate constructed to claim notBefore 2019-07-01 was required by
Chrome to have SCTs, which of course an adversary could not obtain
because their certificate only fooled MS Windows. As it happens the SCT
requirement wasn't old enough to sidestep the issue - an adversary
could just choose a fake notBefore prior to Chrome's cut off. But it
was close to just shutting down the attack altogether.


Technical enforcement also quietly benefits Subscribers. If you buy a
certificate, quite legitimately, from an honest but inevitably
imperfect Certificate Authority, and it turns out that certificate is a
policy violation - it's better if when you install and test the
certificate it doesn't work. "Hey, this product you sold me doesn't
work". The CA can investigate, issue you a good certificate, apologise
and if appropriate report the incident to m.d.s.policy.

Whereas if we find it a month later and they have to revoke the
certificate, contact the subscriber, apologise etc. that's potentially
a much bigger inconvenience to that subscriber.

> As usual, I'll propose the policy language and we'll discuss it on
> the list.

Thanks Wayne,

Nick.

[Nicholas Knight]

On Tuesday, March 3, 2020 at 12:28:20 PM UTC-8, Wayne Thayer wrote:
> Thank you for sharing this Clint.
>
> I'd like to ask for input from the community: is this a requirement that we
> should add to the Mozilla policy at this time (effective September 1, 2020)?

Of course. And 180 days next year, and 90 the year after. LE's 90 day lifetime has already significantly improved available cert tooling and practices, time to start tightening the screws to get everybody on board.

[Kathleen Wilson]

All,

First, I would like to say that my preference would have been for this
type of change (limit SSL cert validity period to 398 days) to be agreed
to in the CA/Browser Forum and added to the BRs. However, the ball is
already rolling, and discussion here in m.d.s.p is supportive of
updating Mozilla's Root Store Policy to incorporate the shorter validity
period. So...

What do you all think about also limiting the re-use of domain validation?

BR section 3.2.2.4 currently says: "Completed validations of Applicant
authority may be valid for the issuance of multiple Certificates over time."
And BR section 4.2.1 currently says: "The CA MAY use the documents and
data provided in Section 3.2 to verify certificate information, or may
reuse previous validations themselves, provided that the CA obtained the
data or document from a source specified under Section 3.2 or completed
the validation itself no more than 825 days prior to issuing the
Certificate."

In line with that, section 2.1 of Mozilla's Root Store Policy currently
says:
"CAs whose certificates are included in Mozilla's root program MUST: ...
"5. verify that all of the information that is included in SSL
certificates remains current and correct at time intervals of 825 days
or less;"

When we update Mozilla's Root Store Policy, should we shorten the domain
validation frequency to be in line with the shortened certificate
validity period? i.e. change item 5 in section 2.1 of Mozilla's Root
Store Policy to:
"5. limit the validity period and re-use of domain validation for SSL
certificates to 398 days or less if the certificate is issued on or
after September 1, 2020;"

I realize that in order to enforce shorter frequency in domain
validation we will need to get this change into the BRs and into the
audit criteria. But CAs are expected to follow Mozilla's Root Store
Policy regardless of enforcement mechanisms, and having this in our
policy would make Mozilla's intentions clear.

As always, I will greatly appreciate your thoughtful and constructive
input on this.

Thanks,
Kathleen

[Paul Walsh]

Hi Kathleen,

Can you provide some insight to why you think a shorter frequency in domain validation would be beneficial? At the very least it deserves a new thread as the potential impact could be significant.

And out of curiosity, why not raise your question inside the CA/Browser forum if you believe the original change being discussed should have been brought up there? I believe the potential outcome would have a separate impact on CAs and website owners. In particular, it would cost website owners in more time, resource and money. For this reason, I’m assuming you’re not asking the question to simply line up with another change.

Thanks,
Paul

[Kathleen Wilson]

On 3/11/20 3:51 PM, Paul Walsh wrote:
> Can you provide some insight to why you think a shorter frequency in domain validation would be beneficial?

To start with, it is common for a domain name to be purchased for one
year. A certificate owner that was able to prove ownership/control of
the domain name last year might not have renewed the domain name. So why
should they be able to get a renewal cert without having that re-checked?

> At the very least it deserves a new thread as the potential impact could be significant.

What exactly do you think is the significant impact in regards to
re-verifying that the certificate requestor still has control of the
domain name to be included in the new certificate?

> And out of curiosity, why not raise your question inside the CA/Browser forum if you believe the original change being discussed should have been brought up there? I believe the potential outcome would have a separate impact on CAs and website owners. In particular, it would cost website owners in more time, resource and money. For this reason, I’m assuming you’re not asking the question to simply line up with another change.
>

It was part of the CAB Forum Ballot SC22 that was proposed last year by
Google. That ballot was to change both the cert validity period and the
validation information to 398 days.
"| 2020-03-01 | 4.2.1 and 6.3.2 | Certificates issued SHOULD NOT have a
Validity Period greater than 397 days and MUST NOT have a Validity
Period greater than 398 days. Re-use of validation information limited
to 398 days. |"


Reference:
https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html
https://github.com/cabforum/documents/compare/master...sleevi:0a72b35f7c877e6aa1e7559f712ad9eb84b2da12?diff=split#diff-7f6d14a20e7f3beb696b45e1bf8196f2


Thanks,
Kathleen

[Paul Walsh]

> On Mar 11, 2020, at 4:11 PM, Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On 3/11/20 3:51 PM, Paul Walsh wrote:

>> Can you provide some insight to why you think a shorter frequency in domain validation would be beneficial?
>

> To start with, it is common for a domain name to be purchased for one year. A certificate owner that was able to prove ownership/control of the domain name last year might not have renewed the domain name. So why should they be able to get a renewal cert without having that re-checked?

[PW] I look at it differently. If the owner’s identity has already been validated and that information is still valid, why ask them to validate again? I would like to see the time, effort and cost to website owners reduced where possible - without increasing risk from a security perspective.

That’s my response to your specific question, but what about domains that are purchased for longer durations?

Given that you raised this topic, I believe the onus should be on you to demonstrate why it’s a good idea, not for me or others to demonstrate why it’s not a good idea :) I’m simply asking questions to learn more about your perspective. I’m on the fence until I hear of good reasons to change something that might not be broken.

>
>
>> At the very least it deserves a new thread as the potential impact could be significant.
>

> What exactly do you think is the significant impact in regards to re-verifying that the certificate requestor still has control of the domain name to be included in the new certificate?

[PW] I believe it’s a good idea to ensure they’re still in control of the domain. My comment is in relation to the cost of validating their identity. Any change that you propose and which is accepted, will have an impact on website owners - however small we might think, it might not be small to them.

I specifically use the term “website owners” to humanize the conversation. It’s not about “domains”, it’s about people who have to pay for extra things that we as stakeholders and guests of the web, ask of them. Or in this case, tell them. I’d love to hear what CAs think as they’re the ones who know what website owners want more than any other stakeholder.

>
>
>> And out of curiosity, why not raise your question inside the CA/Browser forum if you believe the original change being discussed should have been brought up there? I believe the potential outcome would have a separate impact on CAs and website owners. In particular, it would cost website owners in more time, resource and money. For this reason, I’m assuming you’re not asking the question to simply line up with another change.
>

> It was part of the CAB Forum Ballot SC22 that was proposed last year by Google. That ballot was to change both the cert validity period and the validation information to 398 days.
> "| 2020-03-01 | 4.2.1 and 6.3.2 | Certificates issued SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. Re-use of validation information limited to 398 days. |"
>
>
> Reference:
> https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html
> https://github.com/cabforum/documents/compare/master...sleevi:0a72b35f7c877e6aa1e7559f712ad9eb84b2da12?diff=split#diff-7f6d14a20e7f3beb696b45e1bf8196f2

[PW] Thanks for this info. If this is already part of the CA/B Forum, is it your intention to potentially do something different/specific for Firefox, irrespective of what happens in that forum?

I’m trying to learn more about your intent and the benefits as you perceive them, it’s not to debate, as I don’t have an opinion on whether it’s a good or bad thing.

Thanks,
Paul

[Kathleen Wilson]

On 3/11/20 4:37 PM, Paul Walsh wrote:
>
>> On Mar 11, 2020, at 4:11 PM, Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>>
>> On 3/11/20 3:51 PM, Paul Walsh wrote:
>>> Can you provide some insight to why you think a shorter frequency in domain validation would be beneficial?

> [PW] If the owner’s identity has already been validated and that information is still valid, why ask them to validate again?


By "domain validation" I specifically mean verifying that the
certificate requestor owns/controls the domain name(s) to be included in
the TLS certificate.

> [PW] I believe it’s a good idea to ensure they’re still in control of the domain.

So I guess we are in agreement on this.

> My comment is in relation to the cost of validating their identity.

My proposal has nothing to do with identity validation.

> [PW] Thanks for this info. If this is already part of the CA/B Forum, is it your intention to potentially do something different/specific for Firefox, irrespective of what happens in that forum?
>

My proposal is that if we are going to update Mozilla's policy to
require TLS certs to have validity period of 398 days or less, we should
also update Mozilla's policy to say that re-use of domain validation is
only valid up to 398 days. i.e. the ownership/control of the domain name
should be re-validated before the renewal cert is issued.

Currently Mozilla's policy and the BRs allow the CA to re-use domain
validation results for up to 825 days. (which is inline with the 825 day
certificate validity period currently allowed by the BRs)

Kathleen

[Paul Walsh]

Thanks for the clarification, Kathleen. I tried my best not to make assumptions.

- Paul

> On Mar 11, 2020, at 5:28 PM, Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

[Julien Cristau]

Hi Kathleen, all,

Is there a reason domain validation information needs to be reused for more
than, say, 30 days? For the manual parts of identity validation I
understand you don't want to repeat the process too often, but domain
validation can be entirely automated so it doesn't seem like long reuse
periods are warranted. (It's entirely possible I'm missing something and
there are significant hurdles to overcome for CAs and/or applicants in
confirming domain ownership more than once a year.)

Thanks,
Julien

[Doug Beattie]

Kathleen,

Changing the domain validation re-user period is a substantial change from the Apple proposed max validity period change and will place an additional burden on certificate Applicants to update their domain validation more than twice as frequently. This would be a sudden and large departure from the BRs. Certificate validity and domain validation re-use periods don’t necessarily need to be tied to the same value, so having certificate validity capped at 398 days and domain re-use set at 825 days isn’t contradictory.

Can you also provide, in a blog or a publicly posted article, the reasons for shortening the certificate validity? There are hundreds of comments and suggestions in multiple mail lists, but there is a lack of a documented formal security analysis of the recommended changes that we can point our customers to.

Doug

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Wednesday, March 11, 2020 8:29 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: About upcoming limits on trusted certificates

On 3/11/20 4:37 PM, Paul Walsh wrote:
>

>> On Mar 11, 2020, at 4:11 PM, Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>>
>> On 3/11/20 3:51 PM, Paul Walsh wrote:
>>> Can you provide some insight to why you think a shorter frequency in domain validation would be beneficial?

> [PW] If the owner’s identity has already been validated and that information is still valid, why ask them to validate again?

By "domain validation" I specifically mean verifying that the certificate requestor owns/controls the domain name(s) to be included in the TLS certificate.

> [PW] I believe it’s a good idea to ensure they’re still in control of the domain.

So I guess we are in agreement on this.

> My comment is in relation to the cost of validating their identity.

My proposal has nothing to do with identity validation.

> [PW] Thanks for this info. If this is already part of the CA/B Forum, is it your intention to potentially do something different/specific for Firefox, irrespective of what happens in that forum?
>

My proposal is that if we are going to update Mozilla's policy to require TLS certs to have validity period of 398 days or less, we should also update Mozilla's policy to say that re-use of domain validation is only valid up to 398 days. i.e. the ownership/control of the domain name should be re-validated before the renewal cert is issued.

Currently Mozilla's policy and the BRs allow the CA to re-use domain validation results for up to 825 days. (which is inline with the 825 day certificate validity period currently allowed by the BRs)

[Ryan Sleevi]

The Baseline Requirements allow a number of methods that aren’t easily
automated, such as validation via email. As a result, CAs don’t pursue
automation, or when they support it, neither promote nor require it. This
leads CAs to be opposed to efforts to shorten the reuse time, as they have
historically treated it as the same complexity as identity validation, even
when it doesn’t need to be.

There’s nothing intrinsically preventing it, although the practical effect
is it would encourage technically automatable methods, as opposed to manual
methods.

On Thu, Mar 12, 2020 at 4:45 AM Julien Cristau via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi Kathleen, all,
>
> Is there a reason domain validation information needs to be reused for more
> than, say, 30 days? For the manual parts of identity validation I
> understand you don't want to repeat the process too often, but domain
> validation can be entirely automated so it doesn't seem like long reuse
> periods are warranted. (It's entirely possible I'm missing something and
> there are significant hurdles to overcome for CAs and/or applicants in
> confirming domain ownership more than once a year.)
>
> Thanks,
> Julien
>

[Jeremy Rowley]

I think this statement is not accurate: "As a result, CAs don’t pursue automation, or when they support it, neither promote nor require it." I know very few CAs who want to spend extra resources on manual validations and just as few who don't support some level of automation. The manual methods are generally used because so many companies haven't automated this process or refuse to. The companies who contribute to these threads tend to be far more technical than most other companies (or the majority of cert requesters). The assumption that each company has the resources to set up automation ignores this. The opposition to shorter lifecycles and validation periods stems from knowing these work flows and the painful exercise of changing them.

The automated methods weren't even codified until ballot 169 which was late 2016. We're at less than 4 years for automation being a real option. Although I don't have empirical data for other CAs, the LE adoption rate (a billion certs since indicates a fairly rapid adoption of automated methods compared to other changes in the industry.

Jeremy

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, March 12, 2020 7:30 AM
To: Julien Cristau <jcri...@mozilla.com>
Cc: Mozilla <mozilla-dev-s...@lists.mozilla.org>; Kathleen Wilson <kwi...@mozilla.com>
Subject: Re: About upcoming limits on trusted certificates

[Ryan Sleevi]

On Thu, Mar 12, 2020 at 10:58 AM Jeremy Rowley <jeremy...@digicert.com>
wrote:

> I think this statement is not accurate: "As a result, CAs don’t pursue
> automation, or when they support it, neither promote nor require it." I
> know very few CAs who want to spend extra resources on manual validations
> and just as few who don't support some level of automation. The manual
> methods are generally used because so many companies haven't automated this
> process or refuse to.

I think it'd be hard pressed to find many CAs that, as part of their
sales/outreach, promote automation first. I don't deny that there are many
CAs that support automation (indeed, over 99% of issuance is from CAs that
support automation in some form), but when the first touch for many
organizations, large or small, remains manual validation methods such as
"paste a CSR", that's hardly an inaccurate statement.

It's equally rare to find a CA that states that manual methods may require
costs commiserate with their effort, or in any way indicate to a Subscriber
that the lack of automation represents a burden that the Subscriber has
some culpability in bearing. I certainly don't know of many CAs who
actively refuse to issue certain types of certificates, absent automation.

> The automated methods weren't even codified until ballot 169 which was
> late 2016. We're at less than 4 years for automation being a real option.
> Although I don't have empirical data for other CAs, the LE adoption rate (a
> billion certs since indicates a fairly rapid adoption of automated methods
> compared to other changes in the industry.
>

That's not at all true, even remotely. Ballot 169 hardly codified automated
methods, and a number of CAs had long offered automated solutions before
then. Especially under the pre-existing "Any other method" validation, CAs
had plenty of room for automation, and had been using so for some time
(this, in turn, influenced Ballot 169)

I hate to haggle in the weeds here, since the conversation is really about
lifetimes, but I think the record deserves correcting, because it cuts to
the heart: which is that automation has long been known, and supported, and
the only appreciable difference is not the difficulty, but the
recalcitrance to push forward on that. In many ways, this is because CAs
are a fungible commodity, and if one CA requires automation for their
issuance, a Subscriber can just as easily go to another CA that does not
require automation. As a consequence, CAs have strong negative
externalities towards security-positive improvements. The balance for those
externalities is the imposition of requirements by user agents, acting on
behalf of the user, to ensure that user's needs (of site operators and CAs)
are reflected, since the entirety of the Web PKI exists for the user's
benefit of being assured about the domain/origin.

[Kathleen Wilson]

On 3/12/20 5:52 AM, Doug Beattie wrote:


> Changing the domain validation re-user period is a substantial change from the Apple proposed max validity period change and will place an additional burden on certificate Applicants to update their domain validation more than twice as frequently.

Please elaborate about why re-verifying the domain name ownership is
difficult for the CA who is issuing the renewal TLS cert.
Or why the TLS certificate Applicant will face undue burden if they have
to prove domain name ownership when they renew their TLS cert to replace
the cert that was issued a year ago.

Or, is your concern about the date?
e.g. aligning the change with the date that Apple chose of September 1,
2020 for the one-year validity period?
I am not set on any particular date, so long as we are making forward
progress. So if the concern is about the date, please suggest
alternatives for when it would be reasonable to require CAs to re-verify
that the certificate Applicant still owns the domain name to be included
in their TLS cert to replace the cert that was issued a year ago.

> Certificate validity and domain validation re-use periods don’t necessarily need to be tied to the same value, so having certificate validity capped at 398 days and domain re-use set at 825 days isn’t contradictory.

BygoneSSL explains why domain ownership validation should be done more
frequently:

https://insecure.design/
""
This is the demo site for BygoneSSL. It outlines what can happen when a
SSL certificate can outlive one of its domains' ownerships into the next.
Why is this a problem?
Well, aside from the fact that the previous domain owner could
Man-in-the-Middle the new domain owner's SSL traffic for that domain, if
there are any domains that share alt-names with the domain, they can be
revoked, potentially causing a Denial-of-Service if they are still in use.

""


> Can you also provide, in a blog or a publicly posted article, the reasons for shortening the certificate validity? There are hundreds of comments and suggestions in multiple mail lists, but there is a lack of a documented formal security analysis of the recommended changes that we can point our customers to.
>

If folks think that it would be helpful, I (or someone at Mozilla) could
post in Mozilla's Security Blog to list some of the reasons for
shortening certificate validity periods and shortening the frequency of
re-validating domain name verification.


Thanks,
Kathleen

[Doug Beattie]

Hi Kathleen,

I think a clear description of why the change is needed is a great first step and will help explain why this change is needed and justify the timeline (and Ryan's ballot SC22 had a number of suggestions, some good and some weak, imo). When we moved to SHA2 knew of security risks so the timeline could be justified, however, I don’t see the same pressing need to move to annual domain revalidation and 1 year max validity for that matter. Here are a few points based on the email below.

Why is it hard for the CA to domain validation every year instead of every 2 years? It's not, it's the customers that push back. There was a lot of discussion around this on ballot SC22.

When we think about the issuance models, we need to keep the Enterprise approach in mind where domains are validated against a specific account or profile within an account and then issuance can happen using any valid domain or subdomain of those registered with the account. Splitting the domain validation from issuance permits different teams to handle this and to manage the overall policy. Domains can be validated at any time by anyone and not tied to the issuance of a specific certificate which makes issuance less prone to errors. Statements like this seem to omit the notion of enterprise accounts: "..when it would be reasonable to require CAs to re-verify that the certificate Applicant still owns the domain name to be included in their TLS cert to replace the cert that was issued a year ago."

While ACME supports domain validation, not all enterprises like to install agents on their production servers and delegate that level of control down to the admins. Plus some methods require the agent to update web content or change DNS which is often not something the enterprise wants to delegate to the agent. We continue to work with these enterprises to build tools to perform domain validation outside of web server ACME client, but that takes time.

If your driving requirement to reduce the domain validation reuse is the BygoneSSL, then the security analysis is flawed. There are so many things have to align to exploit domain ownership change that it's impactable, imo. Has this ever been exploited?


As certificate issuance increases and automation is embraced, we agree that moving to shorter periods is a good thing. We also know that there will be enterprise and industry laggards that delay delay delay and we can't be heavily influenced by them.

Would it make sense (if even possible) to track the level of automation and set a threshold for when the periods are changed? Mozilla and Google are tracking HTTPS adoption and plan to hard block HTTP when it reaches a certain threshold. Is there a way we can track issuance automation? I'm guessing not, but that would be a good way to reduce validity based on web site administrators embrace of automation tools.

If this is not possible, then I think I'd (begrudgingly) agree with some comments Ryan made several years ago (at SwissSign's F2F?) that we need to set a longer term plan for these changes, document the reasons/security threats, and publish the schedule (rip the band aid off). These incremental changes, one after another by BRs or the Root programs are painful for everyone, and it seems that the changes are coming weather the CABF agrees or not.

Recent history of validity period changes:
- June 2016: Reduced to 3 years
- March 2018: reduced to 825 days (27 months)
- April 2020: Ballot SC22 proposed an April 2020 effective date for 393 max validity and domain re-use

If (AND ONLY IF) the resulting security analysis shows the need to get to some minimum validity period and domain re-validation interval, then, in my personal capacity and not necessarily that of my employer, I toss out these dates:
April 2021: 13 month max: High motivates automation and gives everyone a 12 month heads up to plan accordingly
April 2023: 9 month max: Mandates some level of automation
April 2024: 6 month max: If you’re not using tools, then life is going to be painful
April 2025: 4 month max (final reduction): Dead in the water if you don’t use automation.
Leave enterprise data re-validation at 825 days.

This gives a 5-year plan that everyone can publish and get behind.

Doug




-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Thursday, March 12, 2020 4:29 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: About upcoming limits on trusted certificates

On 3/12/20 5:52 AM, Doug Beattie wrote:

> Changing the domain validation re-user period is a substantial change from the Apple proposed max validity period change and will place an additional burden on certificate Applicants to update their domain validation more than twice as frequently.

Please elaborate about why re-verifying the domain name ownership is difficult for the CA who is issuing the renewal TLS cert.
Or why the TLS certificate Applicant will face undue burden if they have to prove domain name ownership when they renew their TLS cert to replace the cert that was issued a year ago.

Or, is your concern about the date?
e.g. aligning the change with the date that Apple chose of September 1,
2020 for the one-year validity period?

I am not set on any particular date, so long as we are making forward progress. So if the concern is about the date, please suggest alternatives for when it would be reasonable to require CAs to re-verify that the certificate Applicant still owns the domain name to be included in their TLS cert to replace the cert that was issued a year ago.

> Certificate validity and domain validation re-use periods don’t necessarily need to be tied to the same value, so having certificate validity capped at 398 days and domain re-use set at 825 days isn’t contradictory.

BygoneSSL explains why domain ownership validation should be done more
frequently:

https://insecure.design/
""
This is the demo site for BygoneSSL. It outlines what can happen when a SSL certificate can outlive one of its domains' ownerships into the next.
Why is this a problem?
Well, aside from the fact that the previous domain owner could Man-in-the-Middle the new domain owner's SSL traffic for that domain, if there are any domains that share alt-names with the domain, they can be revoked, potentially causing a Denial-of-Service if they are still in use.
""

> Can you also provide, in a blog or a publicly posted article, the reasons for shortening the certificate validity? There are hundreds of comments and suggestions in multiple mail lists, but there is a lack of a documented formal security analysis of the recommended changes that we can point our customers to.
>

If folks think that it would be helpful, I (or someone at Mozilla) could post in Mozilla's Security Blog to list some of the reasons for shortening certificate validity periods and shortening the frequency of re-validating domain name verification.


Thanks,

[Santhan]

On Wednesday, March 11, 2020 at 4:11:56 PM UTC-7, Kathleen Wilson wrote:
> To start with, it is common for a domain name to be purchased for one
> year. A certificate owner that was able to prove ownership/control of
> the domain name last year might not have renewed the domain name. So why
> should they be able to get a renewal cert without having that re-checked?

I thought Domain control must be validated each time, or at least that use to be the case (as I remember it from a long time ago). So I went looking for the particular text and noted it was changed in BR 1.5.2.

BR 1.5.1 section 3.2.2.4, paragraph 2 states,

"The CA SHALL confirm that, as of the date the Certificate issues...".

BR 1.5.2 section 3.2.2.4, paragraph 2 states,

"The CA SHALL confirm that prior to issuance..."

I've always interpreted 3.2.2.4's "as of the date" to mean that regardless of the reuse allowance, domain validate must be performed every single time, which made a lot of sense. Why ballot 190 changed this is a mystery to me.

Thanks,
Santhan

[Ryan Sleevi]

On Fri, Mar 13, 2020 at 2:38 PM Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> When we moved to SHA2 knew of security risks so the timeline could be
> justified, however, I don’t see the same pressing need to move to annual
> domain revalidation and 1 year max validity for that matter.

I can understand, and despite several years of effort, it appears that we
will be just as unlikely to make forward progress.

> When we think about the issuance models, we need to keep the Enterprise
> approach in mind where domains are validated against a specific account or
> profile within an account and then issuance can happen using any valid
> domain or subdomain of those registered with the account. Splitting the
> domain validation from issuance permits different teams to handle this and
> to manage the overall policy. Domains can be validated at any time by
> anyone and not tied to the issuance of a specific certificate which makes
> issuance less prone to errors.

This is a security risk, not a benefit. It creates significant risk that
the CA systems, rather than strongly authenticating a request, move to a
model of weakly authenticating a user or account. I can understand why CAs
would prefer this, and potentially why Subscribers would too: it's
convenient for them, and they're willing to accept the risk individually.
However, we need to keep in mind the User approach in mind when thinking
about whether these are good. For users, this introduces yet more risk into
the system.

For example, if an account on a CA system is compromised, the attacker can
issue any certificate for any of the authorized domains. Compare this to a
model of fresh authentication for requests, in which the only certificates
that can be issued are the ones that can be technically verified.
Similarly, users must accept that a CA that deploys a weak authentication
system, any domains which use that CA are now at risk if the authentication
method used is weak.

When we put the user first, we can see that those Enterprise needs simply
shift the risk/complexity from the Enterprise and to the User. It's
understandable why the Enterprise might prefer that, but we must not fool
ourselves into thinking the risk is not there. Root Stores exist to balance
the risk (collectively) to users, and to reject such attempts to shift the
cost or burden onto them.

> If your driving requirement to reduce the domain validation reuse is the
> BygoneSSL, then the security analysis is flawed. There are so many things
> have to align to exploit domain ownership change that it's impactable, imo.
> Has this ever been exploited?

Yes, this was covered in BygoneSSL. If you meant to say impractical, then
your risk analysis is flawed, but I suspect we'll disagree. This sort of
concern has been the forefront of a number of new technologies, such as
HTTP/2, Signed Exchanges, and the ORIGIN frame. Heck, even APNIC has seen
these as _highly practical_ concerns:
https://blog.apnic.net/2019/01/09/be-careful-where-you-point-to-the-dangers-of-stale-dns-records/
.
Search PowerDNS.

> Would it make sense (if even possible) to track the level of automation
> and set a threshold for when the periods are changed? Mozilla and Google
> are tracking HTTPS adoption and plan to hard block HTTP when it reaches a
> certain threshold. Is there a way we can track issuance automation? I'm
> guessing not, but that would be a good way to reduce validity based on web
> site administrators embrace of automation tools.
>

I'm glad you appreciated the efforts of Google and Mozilla, as well as
others, to make effort here. However, I think suggesting transparency alone
is likely to have much impact is to ignore what actually happened. That
transparency was accompanied by meaningful change to promote HTTPS and
discourage HTTP, and included making the necessary, sometimes
controversial, changes to prioritize user security over enterprise needs.
For example, browsers would not launch new features over insecure HTTP,
insecure traffic was flagged and increasingly alerted on, and ultimately
blocked.

I think if that's the suggestion, then the quickest solution is to have the
CA indicate, within the certificate, that it was issued freshly and
automated. UAs can then make similar efforts as we saw with HTTPS, as can
CAs and other participants in the ecosystem. You'll recall I previously
proposed this in the CA/Browser Forum in 2017, and CAs were opposed then.
It'd be useful to understand what changed, so that future efforts aren't
stymied for three years.

> If this is not possible, then I think I'd (begrudgingly) agree with some
> comments Ryan made several years ago (at SwissSign's F2F?) that we need to
> set a longer term plan for these changes, document the reasons/security
> threats, and publish the schedule (rip the band aid off). These
> incremental changes, one after another by BRs or the Root programs are
> painful for everyone, and it seems that the changes are coming weather the
> CABF agrees or not.
>

You're absolutely correct that, in 2015, I outlined a plan for 1 year
certificates, with annual revalidation -
https://cabforum.org/2015/06/24/2015-06-24-face-to-face-meeting-35-minutes/

Thus, it's somewhat frustrating to see it suggested in 2020 that a plan was
not outlined. Your proposed approach, to get everyone to agree on a plan or
timeline, is exactly what browsers have been doing for years. That 2015
conversation was itself the culmination of over a year's effort to attempt
to a plan. What happens then is the same thing that happens now: a
reasonable timeframe is set forth, some participants drag out their
favorite saws and complaints, the discussion takes forever, now the
timeline is no longer reasonable, it gets updated, and we rinse repeat
until the timeframe is something approximating the heat death of the
universe and CAs are still concerned Enterprises may not have time to
adjust.

As such, I think at this point we can say with full confidence, the
probability of setting a "longer term plan for these changes, document the
reasons/security threats, and publish a schedule" is failed, because every
attempt results in the same circular discussion. Earnest, good faith
attempts were made, for years, and it vacillates between offering reasons
to be opposed (which are shown to be demonstrably false) or complaining
there's too much information about why and it needs to be summarized to be
understood. It's clear which side of the pendulum this is.

>
> If (AND ONLY IF) the resulting security analysis shows the need to get to
> some minimum validity period and domain re-validation interval, then, in my
> personal capacity and not necessarily that of my employer, I toss out these
> dates:
>

Counter proposal:

> April 2021: 395 day domain validation max
>
April 2021: 366 day organization validation max
April 2022: 92 day domain validation max
September 2022: 31 day domain validation max
April 2023: 3 day domain validation max
April 2023: 31 day organization validation max
September 2023: 6 hour domain validation max

This sets an entirely timeline that encourages automation of domain
validation, reduces the risk of stale organization data (which many
jurisdictions require annual review), and eventually moves to a system
where request-based authentication is the norm, and automated systems for
organization data is used. If there are jurisdictions that don't provide
their data in a machine readable format, yes, they're precluded. If there
are organizations that don't freshly authenticate their domains, yes,
they're precluded.

Now, it's always possible to consider shifting from an
account-authenticated model to a key-authenticated-model (i.e. has this key
been used with this domain), since that's a core objective of domain
revalidation, but I can't see wanting to get to an end state where that
duration is greater than 30 days, at most, of reuse, because of the
practical risks and realities of key compromises. Indeed, if you look at
the IETF efforts, such as Delegated Credentials or STAR, the industry
evaluation of risk suggests 7 days is likely a more realistic upper bound
for authorization of binding a key to a domain before requiring a fresh
challenge.

[Nick Lamb]

On Thu, 5 Mar 2020 14:15:17 +0000
Nick Lamb via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> There is some value in policy alone but there's also substantial
> independent value in writing the policy into the code. Would Mozilla
> accept third party work to implement something like #908125 ? I
> appreciate you don't work for them any more Wayne, perhaps Kathleen or
> somebody else who does can answer?

I never saw any reply on this topic and so my assumption is that at
best such a patch would be in the big pile of volunteer stuff maybe
nobody has time to look at.


After some further thought this gives me a real concern that maybe is
an error (in which case I'm sure somebody here will be delighted to
correct me)

As I understand it Apple's intent is that Safari will not accept a
certificate with a lifetime of (let's say for this example) 500 days,
but this would not necessarily become a violation of their root store
policy. Such a certificate could exist and (absent decisions here) it
would work in Firefox but not Safari. More practically, it would work
in some TLS-based internal system that trusts public roots, but not in
Safari, which would be just fine for a backend system that was never
actually intended to be used by web browsers.

This would make it like SCT enforcement in Safari or Chrome. Google
doesn't propose to distrust a CA which issues certificates without
logging them - it just ensures the Chrome browser doesn't trust those
certificates until it is shown proof they were logged, which might be
hours or weeks later. As I understand it Google's own CA deliberately
does this in fact.

If that understanding is correct (again the poor communication from
Apple which I already disapproved of doesn't help me) then in having an
unenforced root store policy about this, rather than enforcement but no
policy change, Mozilla would be standing alone.

That has much larger implications, so if that's what we're talking
about here we need to be clear about it.


Nick.

[Ryan Sleevi]

On Sat, Mar 14, 2020 at 2:54 PM Nick Lamb via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> On Thu, 5 Mar 2020 14:15:17 +0000
> Nick Lamb via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > There is some value in policy alone but there's also substantial
> > independent value in writing the policy into the code. Would Mozilla
> > accept third party work to implement something like #908125 ? I
> > appreciate you don't work for them any more Wayne, perhaps Kathleen or
> > somebody else who does can answer?
>
> I never saw any reply on this topic and so my assumption is that at
> best such a patch would be in the big pile of volunteer stuff maybe
> nobody has time to look at.

Writing code is usually the last step, and can be premature during the
discussion phase, because it tends to unnecessary anchor the conversation.

As I understand it Apple's intent is that Safari will not accept a
> certificate with a lifetime of (let's say for this example) 500 days,
> but this would not necessarily become a violation of their root store
> policy. Such a certificate could exist and (absent decisions here) it
> would work in Firefox but not Safari. More practically, it would work
> in some TLS-based internal system that trusts public roots, but not in
> Safari, which would be just fine for a backend system that was never
> actually intended to be used by web browsers.

That understanding does not seem consistent with past messaging.

This would make it like SCT enforcement in Safari or Chrome. Google
> doesn't propose to distrust a CA which issues certificates without
> logging them - it just ensures the Chrome browser doesn't trust those
> certificates until it is shown proof they were logged, which might be
> hours or weeks later.

Correct, in that like Apple, Chrome offers folks who own and administer the
device to configure exceptions regarding logging.

I think it’s important to highlight that these are meaningfully different,
however, in that lifetime (and reuse) can be objectively qualified
independent of policy, while policies like CT or “publicly trusted” are
semi-dependent upon policy (e.g. the set of trusted logs or CAs). Root
stores have fairly consistently treated violations of objectively
quantifiable criteria as root store program violations/incidents. A more
apt example is Mozilla policy with respect to signature algorithms.

As I understand it Google's own CA deliberately
> does this in fact.

No, that’s not correct.

If that understanding is correct (again the poor communication from
> Apple which I already disapproved of doesn't help me) then in having an
> unenforced root store policy about this, rather than enforcement but no
> policy change, Mozilla would be standing alone.

As an aside, the asides don’t help. Let’s at least recognize this is Apple
engaging more than they have in the past two decades, and appreciate that
they’ve been willing to discuss to the limits they have. Baby steps, and
positive changes should be recognized as such.

I do disagree the suggestion of “standing alone”. Policy and enforcement
are complementary yet independent actions.

[Kathleen Wilson]

On 3/14/20 11:53 AM, Nick Lamb wrote:
> On Thu, 5 Mar 2020 14:15:17 +0000
> Nick Lamb via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> Would Mozilla
>> accept third party work to implement something like #908125 ?

Hi Nick,

I apologize for my delay in replying to your question. I checked with
the Crypto Engineering team, and it turns out that they do have a plan
for addressing this bug. It sounds like the work will also include other
considerations such as configurability and testing.

Thanks,
Kathleen

[Gijs Kruitbosch]

On 14/03/2020 18:53, Nick Lamb wrote:
> my assumption is that at
> best such a patch would be in the big pile of volunteer stuff maybe
> nobody has time to look at.

Tangential: perhaps there's an aspect of phrasing here that is confusing
me, but this reads to me as suggesting we don't review/work with
volunteer code contributions, and I'd like to be explicit and say that
we do our best to do so and I am unaware of big piles of un-looked-at
volunteer-contributed patches (having been such a volunteer myself in
the past).

I can't speak for the crypto team (though it looks like Kathleen has
relayed an answer for the concrete bug you asked about), but if you know
of Firefox patches that are sitting without due attention, please feel
free to nudge me. And no, that approach might in theory not scale, which
is why other folks are building better tooling to ensure we don't end up
with trees falling in forests unheard, as it were. But in the meantime,
feel free to ping me (off-list).

~ Gijs

[Doug Beattie]

Ryan,



In your counter proposal, could you list your proposed milestone dates and then for each one specify the max validity period, domain re-use period and Org validation associated with those dates? As it stands, Org validation requires CA to verify that address is the Applicant’s address and that typically involves a direct exchange with a person at the organization via a Reliable Method of Communication. It’s not clear how we address that if we move to anything below a year.

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Friday, March 13, 2020 9:23 PM
To: Doug Beattie <doug.b...@globalsign.com>
Cc: Kathleen Wilson <kwi...@mozilla.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: About upcoming limits on trusted certificates

[Ryan Sleevi]

Hi Doug,

Perhaps it got mangled by your mail client, but I think I had that covered?

I've pasted it again, below.

Counter proposal:
April 2021: 395 day domain validation max
April 2021: 366 day organization validation max
April 2022: 92 day domain validation max
September 2022: 31 day domain validation max
April 2023: 3 day domain validation max
April 2023: 31 day organization validation max
September 2023: 6 hour domain validation max

As mentioned in the prior mail (and again, perhaps it was eaten by a
grueful mail-client)

> This sets an entirely timeline that encourages automation of domain
> validation, reduces the risk of stale organization data (which many
> jurisdictions require annual review), and eventually moves to a system
> where request-based authentication is the norm, and automated systems for
> organization data is used. If there are jurisdictions that don't provide
> their data in a machine readable format, yes, they're precluded. If there
> are organizations that don't freshly authenticate their domains, yes,
> they're precluded.
> Now, it's always possible to consider shifting from an
> account-authenticated model to a key-authenticated-model (i.e. has this key
> been used with this domain), since that's a core objective of domain
> revalidation, but I can't see wanting to get to an end state where that
> duration is greater than 30 days, at most, of reuse, because of the
> practical risks and realities of key compromises. Indeed, if you look at
> the IETF efforts, such as Delegated Credentials or STAR, the industry
> evaluation of risk suggests 7 days is likely a more realistic upper bound
> for authorization of binding a key to a domain before requiring a fresh
> challenge.

Hopefully that helps!

On Mon, Mar 16, 2020 at 9:53 AM Doug Beattie <doug.b...@globalsign.com>
wrote:

[Doug Beattie]

Are we to assume that the maximum certificate validity remains at 398 days?

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Monday, March 16, 2020 10:02 AM
To: Doug Beattie <doug.b...@globalsign.com>

Cc: ry...@sleevi.com; Kathleen Wilson <kwi...@mozilla.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: About upcoming limits on trusted certificates

Hi Doug,



Perhaps it got mangled by your mail client, but I think I had that covered?



I've pasted it again, below.



Counter proposal:

April 2021: 395 day domain validation max

April 2021: 366 day organization validation max

April 2022: 92 day domain validation max

September 2022: 31 day domain validation max

April 2023: 3 day domain validation max

April 2023: 31 day organization validation max

September 2023: 6 hour domain validation max



As mentioned in the prior mail (and again, perhaps it was eaten by a grueful mail-client)

This sets an entirely timeline that encourages automation of domain validation, reduces the risk of stale organization data (which many jurisdictions require annual review), and eventually moves to a system where request-based authentication is the norm, and automated systems for organization data is used. If there are jurisdictions that don't provide their data in a machine readable format, yes, they're precluded. If there are organizations that don't freshly authenticate their domains, yes, they're precluded.
Now, it's always possible to consider shifting from an account-authenticated model to a key-authenticated-model (i.e. has this key been used with this domain), since that's a core objective of domain revalidation, but I can't see wanting to get to an end state where that duration is greater than 30 days, at most, of reuse, because of the practical risks and realities of key compromises. Indeed, if you look at the IETF efforts, such as Delegated Credentials or STAR, the industry evaluation of risk suggests 7 days is likely a more realistic upper bound for authorization of binding a key to a domain before requiring a fresh challenge.



Hopefully that helps!

[Ryan Sleevi]

No, I don't think we should assume anything, since it doesn't say anything
about lifetime :)

The value of reduced certificate lifetimes is only fully realized with a
corresponding reduction in data reuse.

If you think about a certificate, there are three main pieces of
information that come from a subscriber:
- The public key
- The domain name
- (Optionally) The organization information

In addition, there are rules about how a CA validates this information
(e.g. the BR validation requirements)
This information is then collected, into a certificate, using a certificate
profile (e.g. what the BRs capture in Section 7).

Reducing the lifetime of certificates, in isolation, helps with the agility
of the public key and the agility of the profile, but does not necessarily
help with the agility of the validation requirements nor the accuracy of
the domain name or organization information. BygoneSSL is an example of the
former being an issue, while issuing certificates for organizations that no
longer exist/are legally recognized is an example of the latter being an
issue.

These knobs - lifetime, domain validation, org validation - can be tweaked
independently, but tweaking one without the others limits the value. For
example, reducing domain validation reuse, without reducing lifetime, still
allows for long-lived certs to be issued for otherwise-invalid domain
names, which means you're not getting the security benefits of the
validation reuse reduction. Introducing improved domain validation methods,
for example, isn't helped by reducing lifetime or organization data reuse,
because you can still reuse the 'old' validations using the less secure
means. So all three are linked, even if all three can be independently
adjusted.

I outlined a timetable on how to reduce the latter two (domain and
organization validation). Reducing the latter two helps meaningfully reduce
lifetimes, to take advantage of those reductions, but that can be
independently adjusted. In particular, reducing lifetimes makes the most
sense when folks are accustomed to regular validations, which is why it's
important to reduce domain validation frequency. That effort complements
reductions in lifetimes, and helps remove the concerns being raised.

On Mon, Mar 16, 2020 at 10:04 AM Doug Beattie <doug.b...@globalsign.com>
wrote:

> Are we to assume that the maximum certificate validity remains at 398 days?
>
>
>

> *From:* Ryan Sleevi <ry...@sleevi.com>
> *Sent:* Monday, March 16, 2020 10:02 AM
> *To:* Doug Beattie <doug.b...@globalsign.com>
> *Cc:* ry...@sleevi.com; Kathleen Wilson <kwi...@mozilla.com>;
> mozilla-dev-s...@lists.mozilla.org
> *Subject:* Re: About upcoming limits on trusted certificates

[Doug Beattie]

For clarity, I think we need to discuss all the knobs along with proposed effective dates and usage periods so we get the whole picture. The max validity period of the certificate has been the one receiving the most discussion recently, yet that’s missing from your counter proposal. Don’t you view that as a critical data item to put on the table, even if less important (in your opinion) than domain validation re-use?.



Did you add Public key as a new knob, meaning that Applicants must change their public key according to some rule?

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Monday, March 16, 2020 10:27 AM
To: Doug Beattie <doug.b...@globalsign.com>

Cc: ry...@sleevi.com; Kathleen Wilson <kwi...@mozilla.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: About upcoming limits on trusted certificates

No, I don't think we should assume anything, since it doesn't say anything about lifetime :)



The value of reduced certificate lifetimes is only fully realized with a corresponding reduction in data reuse.



If you think about a certificate, there are three main pieces of information that come from a subscriber:

- The public key

- The domain name

- (Optionally) The organization information



In addition, there are rules about how a CA validates this information (e.g. the BR validation requirements)

This information is then collected, into a certificate, using a certificate profile (e.g. what the BRs capture in Section 7).



Reducing the lifetime of certificates, in isolation, helps with the agility of the public key and the agility of the profile, but does not necessarily help with the agility of the validation requirements nor the accuracy of the domain name or organization information. BygoneSSL is an example of the former being an issue, while issuing certificates for organizations that no longer exist/are legally recognized is an example of the latter being an issue.



These knobs - lifetime, domain validation, org validation - can be tweaked independently, but tweaking one without the others limits the value. For example, reducing domain validation reuse, without reducing lifetime, still allows for long-lived certs to be issued for otherwise-invalid domain names, which means you're not getting the security benefits of the validation reuse reduction. Introducing improved domain validation methods, for example, isn't helped by reducing lifetime or organization data reuse, because you can still reuse the 'old' validations using the less secure means. So all three are linked, even if all three can be independently adjusted.



I outlined a timetable on how to reduce the latter two (domain and organization validation). Reducing the latter two helps meaningfully reduce lifetimes, to take advantage of those reductions, but that can be independently adjusted. In particular, reducing lifetimes makes the most sense when folks are accustomed to regular validations, which is why it's important to reduce domain validation frequency. That effort complements reductions in lifetimes, and helps remove the concerns being raised.

On Mon, Mar 16, 2020 at 10:04 AM Doug Beattie <doug.b...@globalsign.com <mailto:doug.b...@globalsign.com> > wrote:

Are we to assume that the maximum certificate validity remains at 398 days?

From: Ryan Sleevi <ry...@sleevi.com <mailto:ry...@sleevi.com> >
Sent: Monday, March 16, 2020 10:02 AM
To: Doug Beattie <doug.b...@globalsign.com>

Cc: ry...@sleevi.com <mailto:ry...@sleevi.com> ; Kathleen Wilson <kwi...@mozilla.com <mailto:kwi...@mozilla.com> >; mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: About upcoming limits on trusted certificates

Hi Doug,



Perhaps it got mangled by your mail client, but I think I had that covered?



I've pasted it again, below.



Counter proposal:

April 2021: 395 day domain validation max

April 2021: 366 day organization validation max

April 2022: 92 day domain validation max

September 2022: 31 day domain validation max

April 2023: 3 day domain validation max

April 2023: 31 day organization validation max

September 2023: 6 hour domain validation max



As mentioned in the prior mail (and again, perhaps it was eaten by a grueful mail-client)

This sets an entirely timeline that encourages automation of domain validation, reduces the risk of stale organization data (which many jurisdictions require annual review), and eventually moves to a system where request-based authentication is the norm, and automated systems for organization data is used. If there are jurisdictions that don't provide their data in a machine readable format, yes, they're precluded. If there are organizations that don't freshly authenticate their domains, yes, they're precluded.
Now, it's always possible to consider shifting from an account-authenticated model to a key-authenticated-model (i.e. has this key been used with this domain), since that's a core objective of domain revalidation, but I can't see wanting to get to an end state where that duration is greater than 30 days, at most, of reuse, because of the practical risks and realities of key compromises. Indeed, if you look at the IETF efforts, such as Delegated Credentials or STAR, the industry evaluation of risk suggests 7 days is likely a more realistic upper bound for authorization of binding a key to a domain before requiring a fresh challenge.



Hopefully that helps!

[Ryan Sleevi]

On Mon, Mar 16, 2020 at 11:13 AM Doug Beattie <doug.b...@globalsign.com>
wrote:

> For clarity, I think we need to discuss all the knobs along with proposed
> effective dates and usage periods so we get the whole picture.
>

I disagree with this framing, as I have pointed out it's been repeatedly
used disingenuously by some CAs in the past as a means to suggest no change
can be made sooner than a date. I refuse to engage in such a game that
suggests to take options off the table or suggests changes will not be made
sooner than X. While I appreciate the importance of setting milestones, I
don't think we need to set a hard milestone for lifetime in order to have a
productive and useful conversation about data reuse.

> The max validity period of the certificate has been the one receiving the
> most discussion recently, yet that’s missing from your counter proposal.
> Don’t you view that as a critical data item to put on the table, even if
> less important (in your opinion) than domain validation re-use?.
>

I don't view that as being necessary to nail down a timetable for, no. As I
previously explained, the ability to regularly revalidate the domain and
organization information makes it much easier to alter lifetime with no
impact. While it's been receiving the most attention, it's largely been
because the focus has been because the assumption is domain validation
reuse is or should be static, when we know that's quite the opposite from a
security perspective. It's true that reduced reuse does not guarantee that
reducing lifetimes are easier, but aligning with the previously provided
timeline will address the most vocal objections.

> Did you add Public key as a new knob, meaning that Applicants must change
> their public key according to some rule?
>

No, this is not a new knob. As I mentioned in my previous e-mail, which
addressed this, it's one of the pieces provided by the subscriber. This is
the knob that reducing lifetimes affects. Lifetimes, in the absence of
touching data reuse, only affords certainty with changes to the certificate
profile and the ability to replace public keys (e.g. in the event of
compromise / misissuance). You can see this most easily by examining TLS
Delegated Credentials, which intentionally creates a minimal-lifetime
"certificate-like" thing to ensure /the ability/ to timely rotate public
keys, even though it does not /require/ that rotation. That is, the reduced
lifetime of delegated credentials makes it possible, and it's otherwise not
possible without a reduced lifetime.

[Andrew Ayer]

On Wed, 11 Mar 2020 15:39:34 -0700

Kathleen Wilson via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> What do you all think about also limiting the re-use of domain
> validation?

I'm strongly in favor of this change, and think domain validation reuse
should eventually be limited to a period much shorter than one year (days
or even hours), even if certificates lifetimes remain capped at one year.

Others have already touched on the issue of domain ownership transfer
(BygoneSSL), but I'd like to highlight a related issue: if a domain's
DNS, email, or web infrastructure is ever compromised, even briefly,
then the attacker can obtain two-year-long domain validation
authorizations from any number of CAs. Then at any point in the next
two years, the attacker can obtain a one-year certificate, and ask the
CA not to log it to CT. Even if Firefox did enforce CT, the attacker
could wait to log the certificate until right before using it in an
attack.

The consequence of the above is that even if a website suffers a
fleeting compromise, they and their users are at risk of attack from
an illegitimate certificate for three entire years. Anecdotally, I've
found that website operators are surprised when they learn this. It's
intuitive that the attack window would be lower-bounded by certificate
lifetime, but the additional attack time from domain validation
reuse comes as an unpleasant surprise.

Therefore, Firefox should aim to make the attack window as close to the
maximum certificate lifetime as possible, which requires reducing
validation reuse time to the order of hours/days. Limiting to one year
is a good first step.

Regards,
Andrew

[Tim Hollebeek]

> On 3/11/20 3:51 PM, Paul Walsh wrote:

> > Can you provide some insight to why you think a shorter frequency in
> domain validation would be beneficial?
>

> To start with, it is common for a domain name to be purchased for one year.
> A certificate owner that was able to prove ownership/control of the domain
> name last year might not have renewed the domain name. So why should
> they be able to get a renewal cert without having that re-checked?

This has been a favorite point of Jeremy's for as long as I've been
participating
in the CA/Browser Forum and on this list. Tying certificate lifetimes more
closely to the lifetime and validity of the domains they are protecting would
actually make a lot of sense, and we'd support any efforts to do so.

-Tim

[Kathleen Wilson]

Thanks to all of you who have participated in this discussion. We plan
to begin work on a minor update (version 2.7.1) to Mozilla's Root Store
Policy soon. In response to this discussion, the following two issues
have been created and labelled for 2.7.1.

Wayne filed https://github.com/mozilla/pkipolicy/issues/204
"Limit TLS Certificates to 398 day validity after Aug 31, 2020"

And I filed https://github.com/mozilla/pkipolicy/issues/206
"Limit re-use of domain name verification to 395 days"
which says:
"When we update Mozilla's Root Store Policy to limit TLS certificate
validity periods to 398 days, we should also update the policy to limit
re-use of domain name verification results.
I started discussion about this in m.d.s.p, and consensus appears to
support the idea, with the two primary recommendations:
- Change the effective date to April 2021 to give CAs time to update
their processes.
- Provide a Mozilla Security Blog explaining the reasons for making this
change. The idea being to provide one place where people can go to read
about why it is important to frequently re-verify domain name ownership
and why it is important to reduce TLS cert validity periods."


Thanks,
Kathleen

[Jeremy Rowley]

Yeah - I've wanted to do this for a long time. If the domain is only good for 30 days, why would we issue even a 1-year cert? If it's good for 13 months, why not tie the cert validity to that? I guess because they could have transferred the domain (which just means you need additional caps)? It's odd not to have the domain registration as the maximum cap on the range since that's when you know the domain is most at risk for transfer.

Jeremy