#4871 [RFE] Add support for new DNS RR type: Certificate Authority Authorization (CAA, RFC 6844)
Closed: wontfix 11 days ago by pspacek. Opened 3 years ago by pspacek.

New record type CAA was standardized by [6844]]([http://tools.ietf.org/html/rfc6844|RFC) so we should support add support for it to FreeIPA.


Use case

Taken form https://www.isc.org/blogs/certificate-authority-authorization-records/:
Certificate Authority Authorization (CAA, RFC 6844) is intended to reduce the risk of unintended SSL/TLS certificate mis-issuance, either by malicious actors or by honest mistake. The goal is to allow a DNS domain name holder to specify the certificate authority or authorities that the owner has authorized to issue SSL/TLS certificates for that domain.

For example, if you own example.com, and wish to express your preference that certificates for that domain should only be issued by Primary CA, Inc., you would create a record in DNS indicating such. If a malicious actor, or an employee who is not aware of your preference, engages a different CA, Secondary CA, Inc. to purchase a certificate, Secondary CA might first check in DNS. If they see that you have a CAA record that does not specify Secondary CA as a preferred certificate authority, Secondary CA could alert you of that. You could then choose to deny the certificate purchase, or change or add to DNS your preference to allow Secondary CA to issue certificates for your domain.

For this reason, we recommend use of the CAA record.

This should be easy enough to do in 4.2.

Processing leftovers from 4.2 backlog - this ticket was found as suitable for consideration in next big feature release - 4.4.

Metadata Update from @pspacek:
- Issue assigned to mbasti
- Issue set to the milestone: FreeIPA 4.5 backlog

2 years ago

We should increase priority for this ticket.

Currently CAA validation is optional but it will be mandratory for CAs since 2017-09-08, so users may want to use this type of RR.

https://scotthelme.co.uk/certificate-authority-authorization/

Metadata Update from @mbasti:
- Issue close_status updated to: None
- Issue set to the milestone: 0.0 NEEDS_TRIAGE (was: FreeIPA 4.5 backlog)

2 years ago

If I understand the article well, CA needs to support this DNS record. Given that IPA DNS is not meant to be standalone general DNS server, it will mostly serve domains only for IPA server which means in most cases dogtag CA.

@ftweedal does dogtag support mechanism related to CAA records?

Metadata Update from @pvoborni:
- Issue set to the milestone: FreeIPA 4.6 (was: 0.0 NEEDS_TRIAGE)

2 years ago

@pvoborni Dogtag does not support CAA validation.

The CAA requirement is part of the CA/B Forum Baseline Requirements for the public PKI. There is no such requirement for private PKIs, and the use case for it
is unclear.

I reckon we can triage this as FUTURE or even close WONTFIX (because we already have a huge backlog) until someone actually asks for it or demonstrates a clear and valuable use case.

EDIT: actually I see this ticket is for adding support for CAA record to IPA DNS, not for implementing CAA checking support. I think it is of more value because customers MAY expose IPA DNS on Internet. Whether we support CAA validation is a separate question/ticket.

Metadata Update from @mbasti:
- Assignee reset

a year ago

Metadata Update from @mbasti:
- Issue assigned to tkrizek

a year ago

Metadata Update from @tkrizek:
- Issue set to the milestone: FreeIPA 4.6.1 (was: FreeIPA 4.6)

a year ago

Metadata Update from @tkrizek:
- Issue set to the milestone: FreeIPA 4.6.2 (was: FreeIPA 4.6.1)

a year ago

Metadata Update from @tdudlak:
- Issue set to the milestone: FreeIPA 4.6.3 (was: FreeIPA 4.6.2)

a year ago

Metadata Update from @rcritten:
- Issue set to the milestone: FreeIPA 4.6.4 (was: FreeIPA 4.6.3)

11 months ago

FreeIPA 4.6.3 has been released, moving to FreeIPA 4.6.4 milestone

Metadata Update from @rcritten:
- Issue set to the milestone: FreeIPA 4.6.5 (was: FreeIPA 4.6.4)

6 months ago

Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.

Metadata Update from @rcritten:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

11 days ago

Login to comment on this ticket.

Metadata