Re: implementing testing of new CAA-record in DNS according RFC6844
- From: Bernhard Fröhlich <bernhard AT cacert.org>
- To: cacert-policy AT lists.cacert.org
- Subject: Re: implementing testing of new CAA-record in DNS according RFC6844
- Date: Tue, 20 Mar 2018 14:53:33 +0100
my opinion on the topic is
1. It would make some sense to implement such a CAA check before issuing a certificate, to give CAcert an improved credibility.
2. I don't see it as very high priority, just because AFAIK we are not even close to being a member in any of those clubs requiring this.
3. If we do implement this, it must be stated in the CPS, probably in 4.2.2, 4.3.1, and maybe others. But, of course, not before the check is in fact installed on the production system.
Note that RFC6844 states that a CAA check has to be before issuing a certificate. So checking when adding a domain/mail address to an account at CAcert will probably not suffice.
P.S.: I see some potential that CAA may be abused by big mail providers to exclude such "rogues" like CAcert for client certificate purposes. But given the current use of client certs this is not really probable at the moment.
Am 19.03.2018 um 17:25 schrieb Karl-Heinz Gödderz:
Dear policy-group members,
we were informed that
since september, 8th, 2017 CAs must check DNS' CAA records. Thisdoes anyone from this group know if we have to change one of our
decision was taken in spring 2017 by CA/Browser forum which CAcert is
I can't see that this is already implemented in CAcert's signing
software, therefore I would like to ask you to take care of.
policies to be allowed to implement this imperative?
I couldn't find any in CPS. Which more policies do apply?
* more information https://tools.ietf.org/html/rfc6844
Description: S/MIME Cryptographic Signature
- implementing testing of new CAA-record in DNS according RFC6844, Karl-Heinz Gödderz, 03/19/2018
- Re: implementing testing of new CAA-record in DNS according RFC6844, Eva Stöwe, 03/19/2018
- Re: implementing testing of new CAA-record in DNS according RFC6844, Bernhard Fröhlich, 03/20/2018
Archive powered by MHonArc 2.6.18.