RE: About upcoming limits on trusted certificates

[Jeremy Rowley via dev-security-policy]

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

-Original Message-
From: dev-security-policy  On 
Behalf Of Tim Hollebeek via dev-security-policy
Sent: Tuesday, March 17, 2020 10:00 AM
To: Kathleen Wilson ; Mozilla 

Subject: RE: About upcoming limits on trusted certificates


> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: About upcoming limits on trusted certificates

[Tim Hollebeek via dev-security-policy]

> 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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Andrew Ayer via dev-security-policy]

On Wed, 11 Mar 2020 15:39:34 -0700
Kathleen Wilson via dev-security-policy
 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Ryan Sleevi via dev-security-policy]

On Mon, Mar 16, 2020 at 11:13 AM Doug Beattie 
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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: About upcoming limits on trusted certificates

[Doug Beattie via dev-security-policy]

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  
Sent: Monday, March 16, 2020 10:27 AM
To: Doug Beattie 
Cc: r...@sleevi.com; Kathleen Wilson ; 
mozilla-dev-security-pol...@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 mailto:doug.beat...@globalsign.com> > wrote:

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

 

From: Ryan Sleevi mailto:r...@sleevi.com> > 
Sent: Monday, March 16, 2020 10:02 AM
To: Doug Beattie 
Cc: r...@sleevi.com <mailto:r...@sleevi.com> ; Kathleen Wilson 
mailto:kwil...@mozilla.com> >; 
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@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

Re: About upcoming limits on trusted certificates

[Ryan Sleevi via dev-security-policy]

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 
wrote:

> Are we to assume that the maximum certificate validity remains at 398 days?
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Monday, March 16, 2020 10:02 AM
> *To:* Doug Beattie 
> *Cc:* r...@sleevi.com; Kathleen Wilson ;
> mozilla-dev-security-pol...@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!
>
>
>
> On Mon, Mar 16, 2020 at 9:53 AM Doug Beattie 
> wrote:
>
> 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 

RE: About upcoming limits on trusted certificates

[Doug Beattie via dev-security-policy]

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

 

From: Ryan Sleevi  
Sent: Monday, March 16, 2020 10:02 AM
To: Doug Beattie 
Cc: r...@sleevi.com; Kathleen Wilson ; 
mozilla-dev-security-pol...@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!

 

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

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.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Ryan Sleevi via dev-security-policy]

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 
wrote:

> 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.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: About upcoming limits on trusted certificates

[Doug Beattie via dev-security-policy]

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  
Sent: Friday, March 13, 2020 9:23 PM
To: Doug Beattie 
Cc: Kathleen Wilson ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: About upcoming limits on trusted certificates

 

On Fri, Mar 13, 2020 at 2:38 PM Doug Beattie via dev-security-policy 
mailto:dev-security-policy@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 certi

Re: About upcoming limits on trusted certificates

[Gijs Kruitbosch via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Ryan Sleevi via dev-security-policy]

On Sat, Mar 14, 2020 at 2:54 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, 5 Mar 2020 14:15:17 +
> Nick Lamb via dev-security-policy
>  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Nick Lamb via dev-security-policy]

On Thu, 5 Mar 2020 14:15:17 +
Nick Lamb via dev-security-policy
 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Ryan Sleevi via dev-security-policy]

On Fri, Mar 13, 2020 at 2:38 PM Doug Beattie via dev-security-policy <
dev-security-policy@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 

Re: About upcoming limits on trusted certificates

[Santhan via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: About upcoming limits on trusted certificates

[Doug Beattie via dev-security-policy]

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  On 
Behalf Of Kathleen Wilson via dev-security-policy
Sent: Thursday, March 12, 2020 4:29 PM
To: mozilla-dev-security-pol...@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

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 12, 2020 at 10:58 AM Jeremy Rowley 
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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: About upcoming limits on trusted certificates

[Jeremy Rowley via dev-security-policy]

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  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, March 12, 2020 7:30 AM
To: Julien Cristau 
Cc: Mozilla ; Kathleen Wilson 

Subject: Re: About upcoming limits on trusted certificates

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-security-policy@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
>
> On Wed, Mar 11, 2020 at 11:39 PM Kathleen Wilson via 
> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
>
> > 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

Re: About upcoming limits on trusted certificates

[Ryan Sleevi via dev-security-policy]

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-security-policy@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
>
> On Wed, Mar 11, 2020 at 11:39 PM Kathleen Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > 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
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: About upcoming limits on trusted certificates

[Doug Beattie via dev-security-policy]

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  On 
Behalf Of Kathleen Wilson via dev-security-policy
Sent: Wednesday, March 11, 2020 8:29 PM
To: mozilla-dev-security-pol...@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 
>>  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




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Julien Cristau via dev-security-policy]

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

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

> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Paul Walsh via dev-security-policy]

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 
>  wrote:
> 
> On 3/11/20 4:37 PM, Paul Walsh wrote:
 On Mar 11, 2020, at 4:11 PM, Kathleen Wilson via dev-security-policy 
  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
> 
> 
> 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

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



On Mar 11, 2020, at 4:11 PM, Kathleen Wilson via dev-security-policy 
 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




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Paul Walsh via dev-security-policy]

> On Mar 11, 2020, at 4:11 PM, Kathleen Wilson via dev-security-policy 
>  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

> 
> 
> Thanks,
> Kathleen
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Paul Walsh via dev-security-policy]

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


> On Mar 11, 2020, at 3:39 PM, Kathleen Wilson via dev-security-policy 
>  wrote:
> 
> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Nicholas Knight via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Nick Lamb via dev-security-policy]

On Wed, 4 Mar 2020 16:41:09 -0700
Wayne Thayer via dev-security-policy
 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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Wayne Thayer via dev-security-policy]

On Wed, Mar 4, 2020 at 11:48 AM Nick Lamb  wrote:

> On Tue, 3 Mar 2020 13:27:59 -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)?
>
> 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.


> †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.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: About upcoming limits on trusted certificates

[Doug Beattie via dev-security-policy]

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  On
Behalf Of Clint Wilson via dev-security-policy
Sent: Tuesday, March 3, 2020 2:55 PM
To: mozilla-dev-security-pol...@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Nick Lamb via dev-security-policy]

On Tue, 3 Mar 2020 13:27:59 -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)?

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Matt Palmer via dev-security-policy]

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 
>  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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Clint Wilson via dev-security-policy]

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

> On Mar 3, 2020, at 1:41 PM, Matt Palmer via dev-security-policy 
>  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.
> 
> - Matt
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Matt Palmer via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Matt Palmer via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Wayne Thayer via dev-security-policy]

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/

On Tue, Mar 3, 2020 at 12:55 PM Clint Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy