Commit 2383eb52 authored by Evan Hunt's avatar Evan Hunt
Browse files

[master] add CAA rdata support

3056.	[protocol]	Added support for CAA record type (RFC 6844).
			[RT #36625]
parent 586db4a3
3056. [protocol] Added support for CAA record type (RFC 6844).
[RT #36625]
3900. [bug] Fix a crash in PostgreSQL DLZ driver. [RT #36637]
3899. [bug] "request-ixfr" is only applicable to slave and redirect
......
......@@ -15,8 +15,6 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: rdata_test.c,v 1.52 2011/08/28 09:10:41 marka Exp $ */
#include <config.h>
#include <stdlib.h>
......@@ -284,6 +282,11 @@ viastruct(dns_rdata_t *rdata, isc_mem_t *mctx,
result = dns_rdata_tostruct(rdata, sp = &uri, NULL);
break;
}
case dns_rdatatype_caa: {
static dns_rdata_caa_t caa;
result = dns_rdata_tostruct(rdata, sp = &caa, NULL);
break;
}
case dns_rdatatype_wks: {
static dns_rdata_in_wks_t in_wks;
result = dns_rdata_tostruct(rdata, sp = &in_wks, NULL);
......@@ -551,6 +554,11 @@ viastruct(dns_rdata_t *rdata, isc_mem_t *mctx,
result = dns_rdata_tostruct(rdata, sp = &uri, mctx);
break;
}
case dns_rdatatype_caa: {
static dns_rdata_caa_t caa;
result = dns_rdata_tostruct(rdata, sp = &caa, mctx);
break;
}
case dns_rdatatype_wks: {
static dns_rdata_in_wks_t in_wks;
result = dns_rdata_tostruct(rdata, sp = &in_wks, mctx);
......@@ -848,6 +856,11 @@ viastruct(dns_rdata_t *rdata, isc_mem_t *mctx,
result = dns_rdata_fromstruct(rdata2, rdc, rdt, &uri, b);
break;
}
case dns_rdatatype_caa: {
dns_rdata_caa_t caa;
result = dns_rdata_fromstruct(rdata2, rdc, rdt, &caa, b);
break;
}
case dns_rdatatype_wks: {
dns_rdata_in_wks_t in_wks;
result = dns_rdata_fromstruct(rdata2, rdc, rdt, &in_wks, b);
......
......@@ -305,6 +305,11 @@ eui64 EUI64 01-23-45-67-89-ab-cd-ef
uri01 URI 10 20 "https://www.isc.org/"
uri02 URI 30 40 "https://www.isc.org/HolyCowThisSureIsAVeryLongURIRecordIDontEvenKnowWhatSomeoneWouldEverWantWithSuchAThingButTheSpecificationRequiresThatWesupportItSoHereWeGoTestingItLaLaLaLaLaLaLaSeriouslyThoughWhyWouldYouEvenConsiderUsingAURIThisLongItSeemsLikeASillyIdeaButEnhWhatAreYouGonnaDo/"
; type 257
caa01 CAA 0 issue "ca.example.net; policy=ev"
caa02 CAA 128 tbs "Unknown"
; keydata (internal type used for managed-keys)
keydata TYPE65533 \# 0
keydata TYPE65533 \# 6 010203040506
keydata TYPE65533 \# 18 010203040506010203040506010203040506
......
......@@ -63,4 +63,5 @@ LP
EUI48
EUI64
URI
CAA
DLV
......@@ -9,6 +9,8 @@ a601.example. 3600 IN A6 127 ::1 foo.
a601.example. 3600 IN A6 128 .
afsdb01.example. 3600 IN AFSDB 0 hostname.example.
afsdb02.example. 3600 IN AFSDB 65535 .
caa01.example. 3600 IN CAA 0 issue "ca.example.net\; policy=ev"
caa02.example. 3600 IN CAA 128 tbs "Unknown"
cdnskey01.example. 3600 IN CDNSKEY 512 255 1 AQMFD5raczCJHViKtLYhWGz8hMY9UGRuniJDBzC7w0aRyzWZriO6i2od GWWQVucZqKVsENW91IOW4vqudngPZsY3GvQ/xVA8/7pyFj6b7Esga60z yGW6LFe9r8n6paHrlG5ojqf0BaqHT+8=
cds01.example. 3600 IN CDS 30795 1 1 310D27F4D82C1FC2400704EA9939FE6E1CEAA3B9
cert01.example. 3600 IN CERT 65534 65535 PRIVATEOID MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6V AuHAoNUz4YoU1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY=
......
......@@ -9,6 +9,8 @@ a601.example. 3600 IN A6 127 ::1 foo.
a601.example. 3600 IN A6 128 .
afsdb01.example. 3600 IN AFSDB 0 hostname.example.
afsdb02.example. 3600 IN AFSDB 65535 .
caa01.example. 3600 IN CAA 0 issue "ca.example.net\; policy=ev"
caa02.example. 3600 IN CAA 128 tbs "Unknown"
cdnskey01.example. 3600 IN CDNSKEY 512 255 1 AQMFD5raczCJHViKtLYhWGz8hMY9UGRuniJDBzC7w0aRyzWZriO6i2od GWWQVucZqKVsENW91IOW4vqudngPZsY3GvQ/xVA8/7pyFj6b7Esga60z yGW6LFe9r8n6paHrlG5ojqf0BaqHT+8=
cds01.example. 3600 IN CDS 30795 1 1 310D27F4D82C1FC2400704EA9939FE6E1CEAA3B9
cert01.example. 3600 IN CERT 65534 65535 PRIVATEOID MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6V AuHAoNUz4YoU1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY=
......
......@@ -27,7 +27,7 @@ status=0
echo "I:testing basic zone transfer functionality"
$DIG $DIGOPTS example. \
@10.53.0.2 axfr -p 5300 > dig.out.ns2 || status=1
grep ";" dig.out.ns2
grep "^;" dig.out.ns2
#
# Spin to allow the zone to tranfer.
......@@ -37,13 +37,13 @@ do
tmp=0
$DIG $DIGOPTS example. \
@10.53.0.3 axfr -p 5300 > dig.out.ns3 || tmp=1
grep ";" dig.out.ns3 > /dev/null
grep "^;" dig.out.ns3 > /dev/null
if test $? -ne 0 ; then break; fi
echo "I: plain zone re-transfer"
sleep 5
done
if test $tmp -eq 1 ; then status=1; fi
grep ";" dig.out.ns3
grep "^;" dig.out.ns3
$PERL ../digcomp.pl dig1.good dig.out.ns2 || status=1
......@@ -53,7 +53,7 @@ echo "I:testing TSIG signed zone transfers"
$DIG $DIGOPTS tsigzone. \
@10.53.0.2 axfr -y tsigzone.:1234abcd8765 -p 5300 \
> dig.out.ns2 || status=1
grep ";" dig.out.ns2
grep "^;" dig.out.ns2
#
# Spin to allow the zone to tranfer.
......@@ -64,13 +64,13 @@ tmp=0
$DIG $DIGOPTS tsigzone. \
@10.53.0.3 axfr -y tsigzone.:1234abcd8765 -p 5300 \
> dig.out.ns3 || tmp=1
grep ";" dig.out.ns3 > /dev/null
grep "^;" dig.out.ns3 > /dev/null
if test $? -ne 0 ; then break; fi
echo "I: plain zone re-transfer"
sleep 5
done
if test $tmp -eq 1 ; then status=1; fi
grep ";" dig.out.ns3
grep "^;" dig.out.ns3
$PERL ../digcomp.pl dig.out.ns2 dig.out.ns3 || status=1
......@@ -135,7 +135,7 @@ done
$DIG $DIGOPTS example. \
@10.53.0.3 axfr -p 5300 > dig.out.ns3 || tmp=1
grep ";" dig.out.ns3
grep "^;" dig.out.ns3
$PERL ../digcomp.pl dig2.good dig.out.ns3 || tmp=1
......@@ -151,11 +151,11 @@ tmp=0
$DIG $DIGOPTS master. \
@10.53.0.6 axfr -p 5300 > dig.out.ns6 || tmp=1
grep ";" dig.out.ns6
grep "^;" dig.out.ns6
$DIG $DIGOPTS master. \
@10.53.0.3 axfr -p 5300 > dig.out.ns3 || tmp=1
grep ";" dig.out.ns3 && cat dig.out.ns3
grep "^;" dig.out.ns3 && cat dig.out.ns3
$PERL ../digcomp.pl dig.out.ns6 dig.out.ns3 || tmp=1
......@@ -171,11 +171,11 @@ tmp=0
$DIG $DIGOPTS slave. \
@10.53.0.6 axfr -p 5300 > dig.out.ns6 || tmp=1
grep ";" dig.out.ns6
grep "^;" dig.out.ns6
$DIG $DIGOPTS slave. \
@10.53.0.1 axfr -p 5300 > dig.out.ns1 || tmp=1
grep ";" dig.out.ns1
grep "^;" dig.out.ns1
$PERL ../digcomp.pl dig.out.ns6 dig.out.ns1 || tmp=1
......@@ -200,11 +200,11 @@ tmp=0
$DIG $DIGOPTS slave. \
@10.53.0.1 axfr -p 5300 > dig.out.ns1 || tmp=1
grep ";" dig.out.ns1
grep "^;" dig.out.ns1
$DIG $DIGOPTS slave. \
@10.53.0.7 axfr -p 5300 > dig.out.ns7 || tmp=1
grep ";" dig.out.ns1
grep "^;" dig.out.ns1
$PERL ../digcomp.pl dig.out.ns7 dig.out.ns1 || tmp=1
......
Internet Engineering Task Force (IETF) P. Hallam-Baker
Request for Comments: 6844 Comodo Group, Inc.
Category: Standards Track R. Stradling
ISSN: 2070-1721 Comodo CA, Ltd.
January 2013
DNS Certification Authority Authorization (CAA) Resource Record
Abstract
The Certification Authority Authorization (CAA) DNS Resource Record
allows a DNS domain name holder to specify one or more Certification
Authorities (CAs) authorized to issue certificates for that domain.
CAA Resource Records allow a public Certification Authority to
implement additional controls to reduce the risk of unintended
certificate mis-issue. This document defines the syntax of the CAA
record and rules for processing CAA records by certificate issuers.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6844.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hallam-Baker & Stradling Standards Track [Page 1]
RFC 6844 Certification Authority Authorization January 2013
Table of Contents
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Requirements Language ......................................3
2.2. Defined Terms ..............................................3
3. The CAA RR Type .................................................5
4. Certification Authority Processing ..............................7
4.1. Use of DNS Security ........................................8
5. Mechanism .......................................................8
5.1. Syntax .....................................................8
5.1.1. Canonical Presentation Format ......................10
5.2. CAA issue Property ........................................10
5.3. CAA issuewild Property ....................................12
5.4. CAA iodef Property ........................................12
6. Security Considerations ........................................13
6.1. Non-Compliance by Certification Authority .................13
6.2. Mis-Issue by Authorized Certification Authority ...........13
6.3. Suppression or Spoofing of CAA Records ....................13
6.4. Denial of Service .........................................14
6.5. Abuse of the Critical Flag ................................14
7. IANA Considerations ............................................14
7.1. Registration of the CAA Resource Record Type ..............14
7.2. Certification Authority Restriction Properties ............15
7.3. Certification Authority Restriction Flags .................15
8. Acknowledgements ...............................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
1. Introduction
The Certification Authority Authorization (CAA) DNS Resource Record
allows a DNS domain name holder to specify the Certification
Authorities (CAs) authorized to issue certificates for that domain.
Publication of CAA Resource Records allows a public Certification
Authority to implement additional controls to reduce the risk of
unintended certificate mis-issue.
Like the TLSA record defined in DNS-Based Authentication of Named
Entities (DANE) [RFC6698], CAA records are used as a part of a
mechanism for checking PKIX certificate data. The distinction
between the two specifications is that CAA records specify an
authorization control to be performed by a certificate issuer before
issue of a certificate and TLSA records specify a verification
control to be performed by a relying party after the certificate is
issued.
Hallam-Baker & Stradling Standards Track [Page 2]
RFC 6844 Certification Authority Authorization January 2013
Conformance with a published CAA record is a necessary but not
sufficient condition for issuance of a certificate. Before issuing a
certificate, a PKIX CA is required to validate the request according
to the policies set out in its Certificate Policy. In the case of a
public CA that validates certificate requests as a third party, the
certificate will typically be issued under a public trust anchor
certificate embedded in one or more relevant Relying Applications.
Criteria for inclusion of embedded trust anchor certificates in
applications are outside the scope of this document. Typically, such
criteria require the CA to publish a Certificate Practices Statement
(CPS) that specifies how the requirements of the Certificate Policy
(CP) are achieved. It is also common for a CA to engage an
independent third-party auditor to prepare an annual audit statement
of its performance against its CPS.
A set of CAA records describes only current grants of authority to
issue certificates for the corresponding DNS domain. Since a
certificate is typically valid for at least a year, it is possible
that a certificate that is not conformant with the CAA records
currently published was conformant with the CAA records published at
the time that the certificate was issued. Relying Applications MUST
NOT use CAA records as part of certificate validation.
CAA records MAY be used by Certificate Evaluators as a possible
indicator of a security policy violation. Such use SHOULD take
account of the possibility that published CAA records changed between
the time a certificate was issued and the time at which the
certificate was observed by the Certificate Evaluator.
2. Definitions
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.2. Defined Terms
The following terms are used in this document:
Authorization Entry: An authorization assertion that grants or
denies a specific set of permissions to a specific group of
entities.
Certificate: An X.509 Certificate, as specified in [RFC5280].
Hallam-Baker & Stradling Standards Track [Page 3]
RFC 6844 Certification Authority Authorization January 2013
Certificate Evaluator: A party other than a relying party that
evaluates the trustworthiness of certificates issued by
Certification Authorities.
Certification Authority (CA): An issuer that issues certificates in
accordance with a specified Certificate Policy.
Certificate Policy (CP): Specifies the criteria that a Certification
Authority undertakes to meet in its issue of certificates. See
[RFC3647].
Certification Practices Statement (CPS): Specifies the means by
which the criteria of the Certificate Policy are met. In most
cases, this will be the document against which the operations of
the Certification Authority are audited. See [RFC3647].
Domain: A DNS Domain Name.
Domain Name: A DNS Domain Name as specified in [STD13].
Domain Name System (DNS): The Internet naming system specified in
[STD13].
DNS Security (DNSSEC): Extensions to the DNS that provide
authentication services as specified in [RFC4033], [RFC4034],
[RFC4035], [RFC5155], and revisions.
Issuer: An entity that issues certificates. See [RFC5280].
Property: The tag-value portion of a CAA Resource Record.
Property Tag: The tag portion of a CAA Resource Record.
Property Value: The value portion of a CAA Resource Record.
Public Key Infrastructure X.509 (PKIX): Standards and specifications
issued by the IETF that apply the [X.509] certificate standards
specified by the ITU to Internet applications as specified in
[RFC5280] and related documents.
Resource Record (RR): A particular entry in the DNS including the
owner name, class, type, time to live, and data, as defined in
[STD13] and [RFC2181].
Resource Record Set (RRSet): A set of Resource Records or a
particular owner name, class, and type. The time to live on all
RRs with an RRSet is always the same, but the data may be
different among RRs in the RRSet.
Hallam-Baker & Stradling Standards Track [Page 4]
RFC 6844 Certification Authority Authorization January 2013
Relying Party: A party that makes use of an application whose
operation depends on use of a certificate for making a security
decision. See [RFC5280].
Relying Application: An application whose operation depends on use
of a certificate for making a security decision.
3. The CAA RR Type
A CAA RR consists of a flags byte and a tag-value pair referred to as
a property. Multiple properties MAY be associated with the same
domain name by publishing multiple CAA RRs at that domain name. The
following flag is defined:
Issuer Critical: If set to '1', indicates that the corresponding
property tag MUST be understood if the semantics of the CAA record
are to be correctly interpreted by an issuer.
Issuers MUST NOT issue certificates for a domain if the relevant
CAA Resource Record set contains unknown property tags that have
the Critical bit set.
The following property tags are defined:
issue <Issuer Domain Name> [; <name>=<value> ]* : The issue property
entry authorizes the holder of the domain name <Issuer Domain
Name> or a party acting under the explicit authority of the holder
of that domain name to issue certificates for the domain in which
the property is published.
issuewild <Issuer Domain Name> [; <name>=<value> ]* : The issuewild
property entry authorizes the holder of the domain name <Issuer
Domain Name> or a party acting under the explicit authority of the
holder of that domain name to issue wildcard certificates for the
domain in which the property is published.
iodef <URL> : Specifies a URL to which an issuer MAY report
certificate issue requests that are inconsistent with the issuer's
Certification Practices or Certificate Policy, or that a
Certificate Evaluator may use to report observation of a possible
policy violation. The Incident Object Description Exchange Format
(IODEF) format is used [RFC5070].
The following example is a DNS zone file (see [RFC1035]) that informs
CAs that certificates are not to be issued except by the holder of
the domain name 'ca.example.net' or an authorized agent thereof.
This policy applies to all subordinate domains under example.com.
Hallam-Baker & Stradling Standards Track [Page 5]
RFC 6844 Certification Authority Authorization January 2013
$ORIGIN example.com
. CAA 0 issue "ca.example.net"
If the domain name holder specifies one or more iodef properties, a
certificate issuer MAY report invalid certificate requests to that
address. In the following example, the domain name holder specifies
that reports may be made by means of email with the IODEF data as an
attachment, a Web service [RFC6546], or both:
$ORIGIN example.com
. CAA 0 issue "ca.example.net"
. CAA 0 iodef "mailto:security@example.com"
. CAA 0 iodef "http://iodef.example.com/"
A certificate issuer MAY specify additional parameters that allow
customers to specify additional parameters governing certificate
issuance. This might be the Certificate Policy under which the
certificate is to be issued, the authentication process to be used
might be specified, or an account number specified by the CA to
enable these parameters to be retrieved.
For example, the CA 'ca.example.net' has requested its customer
'example.com' to specify the CA's account number '230123' in each of
the customer's CAA records.
$ORIGIN example.com
. CAA 0 issue "ca.example.net; account=230123"
The syntax of additional parameters is a sequence of name-value pairs
as defined in Section 5.2. The semantics of such parameters is left
to site policy and is outside the scope of this document.
The critical flag is intended to permit future versions CAA to
introduce new semantics that MUST be understood for correct
processing of the record, preventing conforming CAs that do not
recognize the new semantics from issuing certificates for the
indicated domains.
In the following example, the property 'tbs' is flagged as critical.
Neither the example.net CA nor any other issuer is authorized to
issue under either policy unless the processing rules for the 'tbs'
property tag are understood.
$ORIGIN example.com
. CAA 0 issue "ca.example.net; policy=ev"
. CAA 128 tbs "Unknown"
Hallam-Baker & Stradling Standards Track [Page 6]
RFC 6844 Certification Authority Authorization January 2013
Note that the above restrictions only apply at certificate issue.
Since the validity of an end entity certificate is typically a year
or more, it is quite possible that the CAA records published at a
domain will change between the time a certificate was issued and
validation by a relying party.
4. Certification Authority Processing
Before issuing a certificate, a compliant CA MUST check for
publication of a relevant CAA Resource Record set. If such a record
set exists, a CA MUST NOT issue a certificate unless the CA
determines that either (1) the certificate request is consistent with
the applicable CAA Resource Record set or (2) an exception specified
in the relevant Certificate Policy or Certification Practices
Statement applies.
A certificate request MAY specify more than one domain name and MAY
specify wildcard domains. Issuers MUST verify authorization for all
the domains and wildcard domains specified in the request.
The search for a CAA record climbs the DNS name tree from the
specified label up to but not including the DNS root '.'.
Given a request for a specific domain X, or a request for a wildcard
domain *.X, the relevant record set R(X) is determined as follows:
Let CAA(X) be the record set returned in response to performing a CAA
record query on the label X, P(X) be the DNS label immediately above
X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
alias record specified at the label X.
o If CAA(X) is not empty, R(X) = CAA (X), otherwise
o If A(X) is not null, and R(A(X)) is not empty, then R(X) =
R(A(X)), otherwise
o If X is not a top-level domain, then R(X) = R(P(X)), otherwise
o R(X) is empty.
For example, if a certificate is requested for X.Y.Z the issuer will
search for the relevant CAA record set in the following order:
X.Y.Z
Alias (X.Y.Z)
Y.Z
Hallam-Baker & Stradling Standards Track [Page 7]
RFC 6844 Certification Authority Authorization January 2013
Alias (Y.Z)
Z
Alias (Z)
Return Empty
4.1. Use of DNS Security
Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not
required. An issuer MUST NOT issue certificates if doing so would
conflict with the relevant CAA Resource Record set, irrespective of
whether the corresponding DNS records are signed.
DNSSEC provides a proof of non-existence for both DNS domains and RR
set within domains. DNSSEC verification thus enables an issuer to
determine if the answer to a CAA record query is empty because the RR
set is empty or if it is non-empty but the response has been
suppressed.
Use of DNSSEC allows an issuer to acquire and archive a proof that
they were authorized to issue certificates for the domain.
Verification of such archives MAY be an audit requirement to verify
CAA record processing compliance. Publication of such archives MAY
be a transparency requirement to verify CAA record processing
compliance.
5. Mechanism
5.1. Syntax
A CAA RR contains a single property entry consisting of a tag-value
pair. Each tag represents a property of the CAA record. The value
of a CAA property is that specified in the corresponding value field.
A domain name MAY have multiple CAA RRs associated with it and a
given property MAY be specified more than once.
The CAA data field contains one property entry. A property entry
consists of the following data fields:
Hallam-Baker & Stradling Standards Track [Page 8]
RFC 6844 Certification Authority Authorization January 2013
+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
| Flags | Tag Length = n |
+----------------+----------------+...+---------------+