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 <r...@sleevi.com> Sent: Monday, March 16, 2020 10:27 AM To: Doug Beattie <doug.beat...@globalsign.com> Cc: r...@sleevi.com; Kathleen Wilson <kwil...@mozilla.com>; 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 <doug.beat...@globalsign.com <mailto:doug.beat...@globalsign.com> > wrote: Are we to assume that the maximum certificate validity remains at 398 days? From: Ryan Sleevi <r...@sleevi.com <mailto:r...@sleevi.com> > Sent: Monday, March 16, 2020 10:02 AM To: Doug Beattie <doug.beat...@globalsign.com> Cc: r...@sleevi.com <mailto:r...@sleevi.com> ; Kathleen Wilson <kwil...@mozilla.com <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 that duration is greater than 30 days, at most, of reuse, because of the practical risks and realities of key compromises. Indeed, if you look at the IETF efforts, such as Delegated Credentials or STAR, the industry evaluation of risk suggests 7 days is likely a more realistic upper bound for authorization of binding a key to a domain before requiring a fresh challenge. Hopefully that helps! On Mon, Mar 16, 2020 at 9:53 AM Doug Beattie <doug.beat...@globalsign.com <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
