On Wed, Apr 25, 2018 at 7:28 AM, Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Hi Ryan! > > The "multiple perspective validations" is an interesting idea. Did you > think about combining it with CAA checking? I could imagine having a new > tag, e.g. "allowedMethods", in which the legitimate owner of a domain can > specify the set of allowed methods to validate his domain. As an example > the value "(3.2.2.4.1 AND 3.2.2.4.5) OR 3.2.2.4.9" in the new > "allowedMethods" tag could mean, that a certificate may only be issued, if > two validations acc. 3.2.2.4.1 and 3.2.2.4.1 were successful or if one > validation acc. 3.2.2.4.9 was successful. Any other method of validation > would be not allowed. I see here the benefit, that the owner of a domain > can choose how to verify according his business needs and select the > appropriate level of security for his domains. > I'm not really sure this is related to any of the problems at hand - that is, for example, DNSSEC or CAA has zero impact on the set of problems raised. I'm saddened, but not surprised, to see those discussions derail otherwise useful conversations. The discussion of using CAA to restrict validation methods is one that has been floated in the CA/Browser Forum several times now - along with a method of disclosing the validation method used within a certificate, so that both site operators and the community can ensure correctness. In the past, some members with adamantly and vocally opposed to such improvements, but hopefully, such opposition is in the decline. As a practical matter, I'm suspect about needing to introduce a complex combinatorial syntax. The complexity and risk such a system imposes is likely not worth the cost, especially when such concerns can be mitigated through other methods (for example, limiting the set of CAs that can issue for your domain, and then entering in side-agreements with them). The proposals for restricting validation methods are precisely to allow flexibility in CA choice, while allowing a baseline of security methods that are valid. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
