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