On Tue, May 15, 2018 at 3:53 AM Jürgen Brauckmann <brauckm...@dfn-cert.de> wrote:
> Ryan Sleevi via dev-security-policy wrote on 14.05.2018 20:52: > > And that still moves to an 'insecure-by-default', by making every site > > operator that has taken steps to actually restrict issuance not have > those > > wishes respected. > > Today, site operators have taken steps to secure issuance of server > certificates, following the guidance of the BRs. > > Email certificates are a different use case with different internal > requirements. > > Current CAA syntax lacks the possibility to distinguish between those > two, which will come as a big surprise for organisations who whish to > limit issuance of server certificates, but want to set different (or > none at all) policies for email certificates. > > Mandating CAA checks in its current form also for email certificates > destroys or at least greatly hinders the rather creative technique of > having a general "no-issuance" CAA record and setting short-lived > issue-properties, as described in 6.3 of > https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/caa17.pdf > > Isn’t this exactly what I said? That CAs need to work out how to describe “disallow for server auth, allow for S/MIME?” I feel like proponents of the minimally scoped CAA interpretation are in an indefensible position - and the very self-same arguments that it “only” applies to server auth could be made, just as incorrectly, that CAA only applies to HTTPS certs and not SMTPS or the like. We absolutely have to take CAA as an expression of CA restriction. It’s in the very name! If you want to allow some CAs for some use cases, you need a syntax to describe that. But you cannot make a reasonable argument that “Just because they locked the door, they didn’t mean for us to not break a window” - which is what every proposal to suggest CAA is server-only fundamentally amounts to. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
