On 01/09/2016 09:30, Ryan Sleevi wrote:
On Thursday, September 1, 2016 at 12:07:48 AM UTC-7, Hanno Böck wrote:
Good thing: Can be easily tested by others whether a CA implements it
and it may reduce misissuances.
I'm inclined to say every CA should implement CAA, but it seems last
time this was discussed in the CA/Browser-Forum they agreed to make
this a SHOULD, not a MUST.
There's still concern about how the practical implementation would work. That's
the curse of some WGs - due to a variety of externalities, rough consensus may
be formed, but running code - especially operational - leads to practical
challenges. We see this with RFC 6962 (and RFC 6962-bis), we saw this with
HPKP, and I would argue, we see this with CAA as well.
What was discussed in the Forum is the lack of defined policies for what it means to
"implement CAA". For example, if Trustwave were to see a CAA record for
"symantec.com", could it issue the cert? Why or why not? To what forms does the CAA
record apply with regards to issuance - for example, if a CA were to go in person, sit down in
front of the CTO/COO, verify their passport, verify with their lawyers that the CTO was duly
authorized, then even if the CAA record said otherwise, could they issue then? During the Forum
discussion, it was clear that Symantec's representative had some confusion about CAA, which
similarly suggests that we will likely see the same implementation issues in CAs that have lead to
the many RFC 5280 violations, but as CAA is designed as an issuer-side check, at time of issuance,
there will be no way for the community to evaluate such compliance.
I would say, the CAA check should stop them even before they go to that
CTO meeting. A CAA record would be an *absolute* ban, and if the CTO
really want the certificate and really have the authority, they also
have the authority (in a very direct way) to have their own CAA record
changed to allow the certificate before ordering.
Of cause a CA could have a "grace" policy to allow the customer to fix
its CAA record then resume the process without paying the full fee
again, or to check the CAA record automatically before requesting
payment for a more expensive certificate type (such as EV). Of cause
in either case they must recheck for a CAA record late in the issuance
process, to detect if a contrary CAA record was created while the
requestor fiddled with their credit card or while the manual vetting
was in progress (This could happen if something bad is happening
in/around the customer organization, such as that CTO getting fired for
cause two minutes after the vetting team left).
To be clear: I'm an ardent supporter of CAA. I, ideally, want to see CAs
leading the way in thinking through the issues related to CAA, and the risks
their businesses may face, and how best to address them. I'd like to avoid
policy by fiat if possible, but support it if that's what it takes to solve the
current first mover problem.
The first mover advantage would be quicker rejection of some bad
requests, saving the manpower to even begin asking for paper documents
etc. Consider the economic advantage of getting $$$ from crooks and
just rejecting them without doing actual work. Of cause to reduce
support calls, rejection messages should be very clear such as:
example> Your certificate request #12345 for domain example.org was
example> rejected because the operators of example.org have published
example> the following CAA record, explicitly prohibiting any CA except
example> example.com and example.edu from issuing certificates for
example> example.org. Therefore we (the example.net CA) are prohibited
example> from issuing the requested certificate.
example>
example> example.org. 7300 IN TXT "WHATEVER example.com example.edu"
example> (retrieved on 2017-02-29T01:02:03 UTC from your official
example> DNS server at ns1.example.org, this record was not DNSSEC
example> signed).
example>
example> Of cause if you are genuinely the operator of example.org and
example> actually want to permit example.net to issue a certificate
example> such as the one just rejected, you could change your CAA
example> record to permit it, wait at least 26 hours, 1 minute and 20
example> seconds (the 7300 seconds stated in your old CAA record plus
example> 24 hours), and then place a new order.
example>
example> For guidance on how to set up a correct CAA record please
example> refer to our knowledge base article at
example> https://support.example.net/kb/42/
(Notice how every item in the example message was trivially computed
from data used in the rejection calculation, restated in plain language
in accordance with how the CA scripts interpreted the data to cause
that rejection).
(Since this is a hypothetical example, the details of this message does
not reflect the CAA specification requirements regarding how CAs are
named in CAA records, the relationship with DNSSEC etc.)
But I think that if we do entertain this option, and if it does come to needing
root store fiat, there definitely needs to be a clear consensus on the
appropriate policies for implementation, and it may take some delicate
hand-holding of CAs (... with ample publicly available test cases) to help them
evaluate their issuance systems.
As a testbed/handholding service, mozilla.org could set up some test
sub-domains with various CAA records that should/should not allow
each of the mozilla-trusted CAs CAs to issue certificates for those,
then work with the CA/B forum to do zero cost/repaid test requests to
check that those are rejected/accepted as appropriate.
For example the subdomain symantecandcomodotest.mozilla.org could have
a CAA record allowing only Symantec and Comodo to issue certificates
for it, providing a test case for Symantec and Comodo (that they accept
CAA records listing themselves and a competitor as permitted, typical
case for a domain switching CAs) and for everyone else (that they
reject CAA records listing only other CAs). CAs can then test their
new scripts against these domains (outside the production environment,
so no trusted certificate issued regardless of bugs).
Similarly, as a public audit, someone could routinely set up throw-away
domains with CAA records, then request banned certificates to name and
shame bad issuance if actually issued (A "Mystery shopper" test
strategy). Of cause this should involve some checks against bad faith
testing (such as not actually publishing those test CAA records until
after issuance).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
