On Fri, Oct 11, 2019 at 3:14 PM Doug Beattie <doug.beat...@globalsign.com>
wrote:

> Ryan,
>
> Are you recommending that:
> a) we need a new domain validation method that describes this, or
> b)  those CAs that want to play with fire can go ahead and do that based on
> their own individual security analysis, or
> c) we need a clear policy/guideline in the BRs or root program that MUST be
> followed when the CAs (maybe other entities) are updating DNS with random
> values?
>
> I'm pretty sure I know the answer (none of the above).
>

I'm suggesting the BRs forbid this (and the other examples) from being done
by CAs today, so (b) is not an option. This is the same as the BRs
forbidding a CA from, say, using the serial number in a certificate they
issue to act as a 'continuous authorization' for issuance.

I'm totally open for a discussion about (a)/(c) - done correctly, it would
allow us to achieve the ideal property, that:
1) We constantly go back to the DNS as the source of truth. For example, we
could remove the reuse of validation data entirely here / reduce it to
something small (like 5 minutes).
2) The domain name owner can voluntarily decide to make a continual
authorization to a CA /for their account/, just like they can make a
continual authorization to their hosting provider or other authorized entity

There are a variety of challenges that could cause things to go wrong. We'd
need to address those. They might be insurmountable, but it's worth
discussing. This seems like potentially something suited for the IETF ACME
WG, especially for the nuances of the security properties and ensuring wide
review, not just among CAs and a few browsers.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to