On Tue, May 15, 2018 at 11:02 AM, Jürgen Brauckmann via dev-security-policy <[email protected]> wrote:
> > I don't see how this can be done on a CA level. > > How does example.org express "server certs from letsencrypt, S/MIME from > anybody" with current CAA syntax? CA-specific issue values don't help with > that problem. Sure they do. A CA that wished to do the right thing could define a syntax in the CA/Browser Forum that all issuers are supposed to understand, such as "scope=https" or even 'ekus=[foo,bar,baz]' Absent a scope issuer parameter, then it's presumed to be global scope. Present a scope parameter, it's syntax is defined. That's an application of policy - what to do when CAA restrictions exist - and that can be 'easily' defined. There is, of course, the route of adding new flags or properties, both with spec-required registries, but a security-positive CA can and should be exploring ways to issue scoped restrictions (e.g. could introduce an 'issueserverauth') > CAA was introduced by the BRs, and is thus felt as server-only and is used > as server-only. Changing that is absolutely possible, but should be done > with care, as there are use-cases which will break if CAA is adopted > naively for email certs. > Sure, and in the absence of a force that actually ensures CAs respect domain holders, we know there's not going to be any 'naive' adoption - that is, it's clear that unless and until Root Stores require it, CAs won't adopt it. > > This is all about responsible change. > CAA was introduced in the BRs because, despite 5 years of discussion, CAs were opposed to it, because it would restrict what they could issue. The same story is now playing out, with the same set of overwrought concerns. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
