Hi Kathleen, I think a clear description of why the change is needed is a great first step and will help explain why this change is needed and justify the timeline (and Ryan's ballot SC22 had a number of suggestions, some good and some weak, imo). When we moved to SHA2 knew of security risks so the timeline could be justified, however, I don’t see the same pressing need to move to annual domain revalidation and 1 year max validity for that matter. Here are a few points based on the email below.
Why is it hard for the CA to domain validation every year instead of every 2 years? It's not, it's the customers that push back. There was a lot of discussion around this on ballot SC22. When we think about the issuance models, we need to keep the Enterprise approach in mind where domains are validated against a specific account or profile within an account and then issuance can happen using any valid domain or subdomain of those registered with the account. Splitting the domain validation from issuance permits different teams to handle this and to manage the overall policy. Domains can be validated at any time by anyone and not tied to the issuance of a specific certificate which makes issuance less prone to errors. Statements like this seem to omit the notion of enterprise accounts: "..when it would be reasonable to require CAs to re-verify that the certificate Applicant still owns the domain name to be included in their TLS cert to replace the cert that was issued a year ago." While ACME supports domain validation, not all enterprises like to install agents on their production servers and delegate that level of control down to the admins. Plus some methods require the agent to update web content or change DNS which is often not something the enterprise wants to delegate to the agent. We continue to work with these enterprises to build tools to perform domain validation outside of web server ACME client, but that takes time. If your driving requirement to reduce the domain validation reuse is the BygoneSSL, then the security analysis is flawed. There are so many things have to align to exploit domain ownership change that it's impactable, imo. Has this ever been exploited? As certificate issuance increases and automation is embraced, we agree that moving to shorter periods is a good thing. We also know that there will be enterprise and industry laggards that delay delay delay and we can't be heavily influenced by them. Would it make sense (if even possible) to track the level of automation and set a threshold for when the periods are changed? Mozilla and Google are tracking HTTPS adoption and plan to hard block HTTP when it reaches a certain threshold. Is there a way we can track issuance automation? I'm guessing not, but that would be a good way to reduce validity based on web site administrators embrace of automation tools. If this is not possible, then I think I'd (begrudgingly) agree with some comments Ryan made several years ago (at SwissSign's F2F?) that we need to set a longer term plan for these changes, document the reasons/security threats, and publish the schedule (rip the band aid off). These incremental changes, one after another by BRs or the Root programs are painful for everyone, and it seems that the changes are coming weather the CABF agrees or not. Recent history of validity period changes: - June 2016: Reduced to 3 years - March 2018: reduced to 825 days (27 months) - April 2020: Ballot SC22 proposed an April 2020 effective date for 393 max validity and domain re-use If (AND ONLY IF) the resulting security analysis shows the need to get to some minimum validity period and domain re-validation interval, then, in my personal capacity and not necessarily that of my employer, I toss out these dates: April 2021: 13 month max: High motivates automation and gives everyone a 12 month heads up to plan accordingly April 2023: 9 month max: Mandates some level of automation April 2024: 6 month max: If you’re not using tools, then life is going to be painful April 2025: 4 month max (final reduction): Dead in the water if you don’t use automation. Leave enterprise data re-validation at 825 days. This gives a 5-year plan that everyone can publish and get behind. Doug -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> 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 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
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
