On Mon, Mar 16, 2020 at 11:13 AM Doug Beattie <doug.beat...@globalsign.com> wrote:
> For clarity, I think we need to discuss all the knobs along with proposed > effective dates and usage periods so we get the whole picture. > I disagree with this framing, as I have pointed out it's been repeatedly used disingenuously by some CAs in the past as a means to suggest no change can be made sooner than a date. I refuse to engage in such a game that suggests to take options off the table or suggests changes will not be made sooner than X. While I appreciate the importance of setting milestones, I don't think we need to set a hard milestone for lifetime in order to have a productive and useful conversation about data reuse. > The max validity period of the certificate has been the one receiving the > most discussion recently, yet that’s missing from your counter proposal. > Don’t you view that as a critical data item to put on the table, even if > less important (in your opinion) than domain validation re-use?. > I don't view that as being necessary to nail down a timetable for, no. As I previously explained, the ability to regularly revalidate the domain and organization information makes it much easier to alter lifetime with no impact. While it's been receiving the most attention, it's largely been because the focus has been because the assumption is domain validation reuse is or should be static, when we know that's quite the opposite from a security perspective. It's true that reduced reuse does not guarantee that reducing lifetimes are easier, but aligning with the previously provided timeline will address the most vocal objections. > Did you add Public key as a new knob, meaning that Applicants must change > their public key according to some rule? > No, this is not a new knob. As I mentioned in my previous e-mail, which addressed this, it's one of the pieces provided by the subscriber. This is the knob that reducing lifetimes affects. Lifetimes, in the absence of touching data reuse, only affords certainty with changes to the certificate profile and the ability to replace public keys (e.g. in the event of compromise / misissuance). You can see this most easily by examining TLS Delegated Credentials, which intentionally creates a minimal-lifetime "certificate-like" thing to ensure /the ability/ to timely rotate public keys, even though it does not /require/ that rotation. That is, the reduced lifetime of delegated credentials makes it possible, and it's otherwise not possible without a reduced lifetime. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
