[Ach] Proposed contribution on CAA records

[Maarten Van Horenbeeck]

Sure! I'll do a PR in the next days.

Cheers,
Maarten


On Sat, Jun 18, 2016 at 12:57 PM, Aaron Zauner <azet at azet.org> wrote:

>
> > On 18 Jun 2016, at 11:16, Maarten Van Horenbeeck <maarten.vhb at gmail.com>
> wrote:
> >
> > Hi everyone,
> >
> > I'd like to contribute some text around the use of CAA records, as this
> is a helpful technology to improve an organization's use of X.509 PKI.
> Before I do a pull request, I though I'd share my proposed text on the list
> for discussion. Let me know if you have any edits or change requests, or if
> you feel this is out of scope of the document.
> >
> > Thanks!
> > Maarten
> >
> >
> > Proposed contribution:
>
> Excellent contribution.
>
>
> >
> >
> > Certificate Authority Authorization Records (CAA)
> >
> >
> > RFC 6844 describes Certification Authorization Records, a mechanism for
> domain name owners to signal which Certificate Authorities are authorized
> to issue certificates for their domain.
> >
> >
> > When a CAA record is defined for a particular domain, it specifies that
> the domain owner requests Certificate Authorities to validate any request
> against the CAA record. If the certificate issuer is not listed in the CAA
> record, it should not issue the certificate.
> >
> >
> > The RFC also permits Certificate Evaluators to test an issued
> certificate against the CAA record, but should exercise caution, as the CAA
> record may change during the lifetime of a certificate, without affecting
> its validity.
> >
> >
> > CAA also supports an iodef property type which can be requested by a
> Certificate Authority to report certificate issue requests which are
> inconsistent with the issuer’s Certificate Policy.
> >
> >
> > Configuration
> >
> >
> > BIND supports CAA records as of version 9.9.6.
> >
> >
> > A CAA record can be configured by adding it to the zone file:
> >
> >
> > $ORIGIN example.com
> >
> >        CAA 0 issue "ca1.org"
> >        CAA 0 iodef “mailto:security at example.com”
> >
> >
> > If your organization uses multiple CA’s, you can configure multiple
> records:
> >
> >
> >       CAA 0 issue "ca1.org"
> >
> >       CAA 0 issue "ca2.org"
> >
> >
> > “ca1.org” and “ca2.org” are unique identifiers for the CA you plan on
> using. These strings can be obtained from your Certificate Authority, and
> typically are its top level domain. An example is “letsencryptorg” for the
> Let’s Encrypt CA operated by the Internet Security Research Group.
> >
> >
> > Knot-DNS supports CAA records as of version 2.2.0.
> >
> >
> >
> > Validation
> >
> >
> >
> > Once a CAA record is deployed, it can be validated using the following
> dig query:
> >
> >
> > user at system:~$ dig CAA google.com
> >
> >
> > ; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com
> >
> >
> > ;; ANSWER SECTION:
> >
> > google.com.          3600 IN   CAA  0 issue "symantec.com"
> >
> >
> >
> >
> > On older versions of Dig, which do not support CAA records, you can
> query the record type manually:
> >
> >
> > dig +short -t TYPE257 google.com
>
> Would you be willing to open a Pull Request on GitHub for that? If not
> we'll find someone to typeset this for you.
>
> Aaron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20160618/b01a574e/attachment.html>