|
|
From 620b1c9d90d0a59a0d892fef089ce4f5f6f61742 Mon Sep 17 00:00:00 2001 |
|
|
From: Tomas Hozza <thozza@redhat.com> |
|
|
Date: Fri, 1 Apr 2016 15:20:27 +0200 |
|
|
Subject: [PATCH] Added support for CAA records |
|
|
|
|
|
Signed-off-by: Tomas Hozza <thozza@redhat.com> |
|
|
--- |
|
|
bin/tests/rdata_test.c | 17 +- |
|
|
doc/rfc/rfc6844.txt | 1011 ++++++++++++++++++++++++++++++++++++++ |
|
|
lib/dns/rdata.c | 95 ++-- |
|
|
lib/dns/rdata/generic/caa_257.c | 370 ++++++++++++++ |
|
|
lib/dns/rdata/generic/caa_257.h | 32 ++ |
|
|
lib/dns/rdata/generic/gpos_27.c | 2 +- |
|
|
lib/dns/rdata/generic/hinfo_13.c | 4 +- |
|
|
lib/dns/rdata/generic/isdn_20.c | 4 +- |
|
|
lib/dns/rdata/generic/naptr_35.c | 6 +- |
|
|
lib/dns/rdata/generic/spf_99.c | 2 +- |
|
|
lib/dns/rdata/generic/txt_16.c | 2 +- |
|
|
lib/dns/rdata/generic/uri_256.c | 23 +- |
|
|
lib/dns/rdata/generic/x25_19.c | 2 +- |
|
|
13 files changed, 1478 insertions(+), 92 deletions(-) |
|
|
create mode 100644 doc/rfc/rfc6844.txt |
|
|
create mode 100644 lib/dns/rdata/generic/caa_257.c |
|
|
create mode 100644 lib/dns/rdata/generic/caa_257.h |
|
|
|
|
|
diff --git a/bin/tests/rdata_test.c b/bin/tests/rdata_test.c |
|
|
index 51cc406..0f25364 100644 |
|
|
--- a/bin/tests/rdata_test.c |
|
|
+++ b/bin/tests/rdata_test.c |
|
|
@@ -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); |
|
|
diff --git a/doc/rfc/rfc6844.txt b/doc/rfc/rfc6844.txt |
|
|
new file mode 100644 |
|
|
index 0000000..d923649 |
|
|
--- /dev/null |
|
|
+++ b/doc/rfc/rfc6844.txt |
|
|
@@ -0,0 +1,1011 @@ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+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 | |
|
|
+ +----------------+----------------+...+---------------+ |
|
|
+ | Tag char 0 | Tag char 1 |...| Tag char n-1 | |
|
|
+ +----------------+----------------+...+---------------+ |
|
|
+ +----------------+----------------+.....+----------------+ |
|
|
+ | Value byte 0 | Value byte 1 |.....| Value byte m-1 | |
|
|
+ +----------------+----------------+.....+----------------+ |
|
|
+ |
|
|
+ Where n is the length specified in the Tag length field and m is the |
|
|
+ remaining octets in the Value field (m = d - n - 2) where d is the |
|
|
+ length of the RDATA section. |
|
|
+ |
|
|
+ The data fields are defined as follows: |
|
|
+ |
|
|
+ Flags: One octet containing the following fields: |
|
|
+ |
|
|
+ Bit 0, Issuer Critical Flag: If the value is set to '1', the |
|
|
+ critical flag is asserted and the property MUST be understood |
|
|
+ if the CAA record is to be correctly processed by a certificate |
|
|
+ issuer. |
|
|
+ |
|
|
+ A Certification Authority MUST NOT issue certificates for any |
|
|
+ Domain that contains a CAA critical property for an unknown or |
|
|
+ unsupported property tag that for which the issuer critical |
|
|
+ flag is set. |
|
|
+ |
|
|
+ Note that according to the conventions set out in [RFC1035], bit 0 |
|
|
+ is the Most Significant Bit and bit 7 is the Least Significant |
|
|
+ Bit. Thus, the Flags value 1 means that bit 7 is set while a value |
|
|
+ of 128 means that bit 0 is set according to this convention. |
|
|
+ |
|
|
+ All other bit positions are reserved for future use. |
|
|
+ |
|
|
+ To ensure compatibility with future extensions to CAA, DNS records |
|
|
+ compliant with this version of the CAA specification MUST clear |
|
|
+ (set to "0") all reserved flags bits. Applications that interpret |
|
|
+ CAA records MUST ignore the value of all reserved flag bits. |
|
|
+ |
|
|
+ Tag Length: A single octet containing an unsigned integer specifying |
|
|
+ the tag length in octets. The tag length MUST be at least 1 and |
|
|
+ SHOULD be no more than 15. |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+Hallam-Baker & Stradling Standards Track [Page 9] |
|
|
+ |
|
|
+RFC 6844 Certification Authority Authorization January 2013 |
|
|
+ |
|
|
+ |
|
|
+ Tag: The property identifier, a sequence of US-ASCII characters. |
|
|
+ |
|
|
+ Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' |
|
|
+ through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT |
|
|
+ contain any other characters. Matching of tag values is case |
|
|
+ insensitive. |
|
|
+ |
|
|
+ Tag values submitted for registration by IANA MUST NOT contain any |
|
|
+ characters other than the (lowercase) US-ASCII characters 'a' |
|
|
+ through 'z' and the numbers 0 through 9. |
|
|
+ |
|
|
+ Value: A sequence of octets representing the property value. |
|
|
+ Property values are encoded as binary values and MAY employ sub- |
|
|
+ formats. |
|
|
+ |
|
|
+ The length of the value field is specified implicitly as the |
|
|
+ remaining length of the enclosing Resource Record data field. |
|
|
+ |
|
|
+5.1.1. Canonical Presentation Format |
|
|
+ |
|
|
+ The canonical presentation format of the CAA record is: |
|
|
+ |
|
|
+ CAA <flags> <tag> <value> |
|
|
+ |
|
|
+ Where: |
|
|
+ |
|
|
+ Flags: Is an unsigned integer between 0 and 255. |
|
|
+ |
|
|
+ Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower |
|
|
+ case. |
|
|
+ |
|
|
+ Value: Is the <character-string> encoding of the value field as |
|
|
+ specified in [RFC1035], Section 5.1. |
|
|
+ |
|
|
+5.2. CAA issue Property |
|
|
+ |
|
|
+ The issue property tag is used to request that certificate issuers |
|
|
+ perform CAA issue restriction processing for the domain and to grant |
|
|
+ authorization to specific certificate issuers. |
|
|
+ |
|
|
+ The CAA issue property value has the following sub-syntax (specified |
|
|
+ in ABNF as per [RFC5234]). |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+Hallam-Baker & Stradling Standards Track [Page 10] |
|
|
+ |
|
|
+RFC 6844 Certification Authority Authorization January 2013 |
|
|
+ |
|
|
+ |
|
|
+ issuevalue = space [domain] space [";" *(space parameter) space] |
|
|
+ |
|
|
+ domain = label *("." label) |
|
|
+ label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) |
|
|
+ |
|
|
+ space = *(SP / HTAB) |
|
|
+ |
|
|
+ parameter = tag "=" value |
|
|
+ |
|
|
+ tag = 1*(ALPHA / DIGIT) |
|
|
+ |
|
|
+ value = *VCHAR |
|
|
+ |
|
|
+ For consistency with other aspects of DNS administration, domain name |
|
|
+ values are specified in letter-digit-hyphen Label (LDH-Label) form. |
|
|
+ |
|
|
+ A CAA record with an issue parameter tag that does not specify a |
|
|
+ domain name is a request that certificate issuers perform CAA issue |
|
|
+ restriction processing for the corresponding domain without granting |
|
|
+ authorization to any certificate issuer. |
|
|
+ |
|
|
+ This form of issue restriction would be appropriate to specify that |
|
|
+ no certificates are to be issued for the domain in question. |
|
|
+ |
|
|
+ For example, the following CAA record set requests that no |
|
|
+ certificates be issued for the domain 'nocerts.example.com' by any |
|
|
+ certificate issuer. |
|
|
+ |
|
|
+ nocerts.example.com CAA 0 issue ";" |
|
|
+ |
|
|
+ A CAA record with an issue parameter tag that specifies a domain name |
|
|
+ is a request that certificate issuers perform CAA issue restriction |
|
|
+ processing for the corresponding domain and grants authorization to |
|
|
+ the certificate issuer specified by the domain name. |
|
|
+ |
|
|
+ For example, the following CAA record set requests that no |
|
|
+ certificates be issued for the domain 'certs.example.com' by any |
|
|
+ certificate issuer other than the example.net certificate issuer. |
|
|
+ |
|
|
+ certs.example.com CAA 0 issue "example.net" |
|
|
+ |
|
|
+ CAA authorizations are additive; thus, the result of specifying both |
|
|
+ the empty issuer and a specified issuer is the same as specifying |
|
|
+ just the specified issuer alone. |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+Hallam-Baker & Stradling Standards Track [Page 11] |
|
|
+ |
|
|
+RFC 6844 Certification Authority Authorization January 2013 |
|
|
+ |
|
|
+ |
|
|
+ An issuer MAY choose to specify issuer-parameters that further |
|
|
+ constrain the issue of certificates by that issuer, for example, |
|
|
+ specifying that certificates are to be subject to specific validation |
|
|
+ polices, billed to certain accounts, or issued under specific trust |
|
|
+ anchors. |
|
|
+ |
|
|
+ The semantics of issuer-parameters are determined by the issuer |
|
|
+ alone. |
|
|
+ |
|
|
+5.3. CAA issuewild Property |
|
|
+ |
|
|
+ The issuewild property has the same syntax and semantics as the issue |
|
|
+ property except that issuewild properties only grant authorization to |
|
|
+ issue certificates that specify a wildcard domain and issuewild |
|
|
+ properties take precedence over issue properties when specified. |
|
|
+ Specifically: |
|
|
+ |
|
|
+ issuewild properties MUST be ignored when processing a request for |
|
|
+ a domain that is not a wildcard domain. |
|
|
+ |
|
|
+ If at least one issuewild property is specified in the relevant |
|
|
+ CAA record set, all issue properties MUST be ignored when |
|
|
+ processing a request for a domain that is a wildcard domain. |
|
|
+ |
|
|
+5.4. CAA iodef Property |
|
|
+ |
|
|
+ The iodef property specifies a means of reporting certificate issue |
|
|
+ requests or cases of certificate issue for the corresponding domain |
|
|
+ that violate the security policy of the issuer or the domain name |
|
|
+ holder. |
|
|
+ |
|
|
+ The Incident Object Description Exchange Format (IODEF) [RFC5070] is |
|
|
+ used to present the incident report in machine-readable form. |
|
|
+ |
|
|
+ The iodef property takes a URL as its parameter. The URL scheme type |
|
|
+ determines the method used for reporting: |
|
|
+ |
|
|
+ mailto: The IODEF incident report is reported as a MIME email |
|
|
+ attachment to an SMTP email that is submitted to the mail address |
|
|
+ specified. The mail message sent SHOULD contain a brief text |
|
|
+ message to alert the recipient to the nature of the attachment. |
|
|
+ |
|
|
+ http or https: The IODEF report is submitted as a Web service |
|
|
+ request to the HTTP address specified using the protocol specified |
|
|
+ in [RFC6546]. |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+Hallam-Baker & Stradling Standards Track [Page 12] |
|
|
+ |
|
|
+RFC 6844 Certification Authority Authorization January 2013 |
|
|
+ |
|
|
+ |
|
|
+6. Security Considerations |
|
|
+ |
|
|
+ CAA records assert a security policy that the holder of a domain name |
|
|
+ wishes to be observed by certificate issuers. The effectiveness of |
|
|
+ CAA records as an access control mechanism is thus dependent on |
|
|
+ observance of CAA constraints by issuers. |
|
|
+ |
|
|
+ The objective of the CAA record properties described in this document |
|
|
+ is to reduce the risk of certificate mis-issue rather than avoid |
|
|
+ reliance on a certificate that has been mis-issued. DANE [RFC6698] |
|
|
+ describes a mechanism for avoiding reliance on mis-issued |
|
|
+ certificates. |
|
|
+ |
|
|
+6.1. Non-Compliance by Certification Authority |
|
|
+ |
|
|
+ CAA records offer CAs a cost-effective means of mitigating the risk |
|
|
+ of certificate mis-issue: the cost of implementing CAA checks is very |
|
|
+ small and the potential costs of a mis-issue event include the |
|
|
+ removal of an embedded trust anchor. |
|
|
+ |
|
|
+6.2. Mis-Issue by Authorized Certification Authority |
|
|
+ |
|
|
+ Use of CAA records does not prevent mis-issue by an authorized |
|
|
+ Certification Authority, i.e., a CA that is authorized to issue |
|
|
+ certificates for the domain in question by CAA records. |
|
|
+ |
|
|
+ Domain name holders SHOULD verify that the CAs they authorize to |
|
|
+ issue certificates for their domains employ appropriate controls to |
|
|
+ ensure that certificates are issued only to authorized parties within |
|
|
+ their organization. |
|
|
+ |
|
|
+ Such controls are most appropriately determined by the domain name |
|
|
+ holder and the authorized CA(s) directly and are thus out of scope of |
|
|
+ this document. |
|
|
+ |
|
|
+6.3. Suppression or Spoofing of CAA Records |
|
|
+ |
|
|
+ Suppression of the CAA record or insertion of a bogus CAA record |
|
|
+ could enable an attacker to obtain a certificate from an issuer that |
|
|
+ was not authorized to issue for that domain name. |
|
|
+ |
|
|
+ Where possible, issuers SHOULD perform DNSSEC validation to detect |
|
|
+ missing or modified CAA record sets. |
|
|
+ |
|
|
+ In cases where DNSSEC is not deployed in a corresponding domain, an |
|
|
+ issuer SHOULD attempt to mitigate this risk by employing appropriate |
|
|
+ DNS security controls. For example, all portions of the DNS lookup |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+Hallam-Baker & Stradling Standards Track [Page 13] |
|
|
+ |
|
|
+RFC 6844 Certification Authority Authorization January 2013 |
|
|
+ |
|
|
+ |
|
|
+ process SHOULD be performed against the authoritative name server. |
|
|
+ Data cached by third parties MUST NOT be relied on but MAY be used to |
|
|
+ support additional anti-spoofing or anti-suppression controls. |
|
|
+ |
|
|
+6.4. Denial of Service |
|
|
+ |
|
|
+ Introduction of a malformed or malicious CAA RR could in theory |
|
|
+ enable a Denial-of-Service (DoS) attack. |
|
|
+ |
|
|
+ This specific threat is not considered to add significantly to the |
|
|
+ risk of running an insecure DNS service. |
|
|
+ |
|
|
+ An attacker could, in principle, perform a DoS attack against an |
|
|
+ issuer by requesting a certificate with a maliciously long DNS name. |
|
|
+ In practice, the DNS protocol imposes a maximum name length and CAA |
|
|
+ processing does not exacerbate the existing need to mitigate DoS |
|
|
+ attacks to any meaningful degree. |
|
|
+ |
|
|
+6.5. Abuse of the Critical Flag |
|
|
+ |
|
|
+ A Certification Authority could make use of the critical flag to |
|
|
+ trick customers into publishing records that prevent competing |
|
|
+ Certification Authorities from issuing certificates even though the |
|
|
+ customer intends to authorize multiple providers. |
|
|
+ |
|
|
+ In practice, such an attack would be of minimal effect since any |
|
|
+ competent competitor that found itself unable to issue certificates |
|
|
+ due to lack of support for a property marked critical SHOULD |
|
|
+ investigate the cause and report the reason to the customer. The |
|
|
+ customer will thus discover that they had been deceived. |
|
|
+ |
|
|
+7. IANA Considerations |
|
|
+ |
|
|
+7.1. Registration of the CAA Resource Record Type |
|
|
+ |
|
|
+ IANA has assigned Resource Record Type 257 for the CAA Resource |
|
|
+ Record Type and added the line depicted below to the registry named |
|
|
+ "Resource Record (RR) TYPEs" and QTYPEs as defined in BCP 42 |
|
|
+ [RFC6195] and located at |
|
|
+ http://www.iana.org/assignments/dns-parameters. |
|
|
+ |
|
|
+ RR Name Value and meaning Reference |
|
|
+ ----------- --------------------------------------------- --------- |
|
|
+ CAA 257 Certification Authority Restriction [RFC6844] |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+Hallam-Baker & Stradling Standards Track [Page 14] |
|
|
+ |
|
|
+RFC 6844 Certification Authority Authorization January 2013 |
|
|
+ |
|
|
+ |
|
|
+7.2. Certification Authority Restriction Properties |
|
|
+ |
|
|
+ IANA has created the "Certification Authority Restriction Properties" |
|
|
+ registry with the following initial values: |
|
|
+ |
|
|
+ |
|
|
+ Tag Meaning Reference |
|
|
+ ----------- -------------------------------------- --------- |
|
|
+ issue Authorization Entry by Domain [RFC6844] |
|
|
+ issuewild Authorization Entry by Wildcard Domain [RFC6844] |
|
|
+ iodef Report incident by IODEF report [RFC6844] |
|
|
+ auth Reserved [HB2011] |
|
|
+ path Reserved [HB2011] |
|
|
+ policy Reserved [HB2011] |
|
|
+ |
|
|
+ |
|
|
+ Although [HB2011] has expired, deployed clients implement the CAA |
|
|
+ properties specified in the document and reuse of these property tags |
|
|
+ for a different purpose could cause unexpected behavior. |
|
|
+ |
|
|
+ Addition of tag identifiers requires a public specification and |
|
|
+ Expert Review as set out in [RFC6195], Section 3.1.1. |
|
|
+ |
|
|
+ The tag space is designed to be sufficiently large that exhausting |
|
|
+ the possible tag space need not be a concern. The scope of Expert |
|
|
+ Review SHOULD be limited to the question of whether the specification |
|
|
+ provided is sufficiently clear to permit implementation and to avoid |
|
|
+ unnecessary duplication of functionality. |
|
|
+ |
|
|
+7.3. Certification Authority Restriction Flags |
|
|
+ |
|
|
+ IANA has created the "Certification Authority Restriction Flags" |
|
|
+ registry with the following initial values: |
|
|
+ |
|
|
+ |
|
|
+ Flag Meaning Reference |
|
|
+ ----------- ---------------------------------- --------- |
|
|
+ 0 Issuer Critical Flag [RFC6844] |
|
|
+ 1-7 Reserved> [RFC6844] |
|
|
+ |
|
|
+ Assignment of new flags follows the RFC Required policy set out in |
|
|
+ [RFC5226], Section 4.1. |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+Hallam-Baker & Stradling Standards Track [Page 15] |
|
|
+ |
|
|
+RFC 6844 Certification Authority Authorization January 2013 |
|
|
+ |
|
|
+ |
|
|
+8. Acknowledgements |
|
|
+ |
|
|
+ The authors would like to thank the following people who contributed |
|
|
+ to the design and documentation of this work item: Chris Evans, |
|
|
+ Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam |
|
|
+ Langley, Ben Laurie, James Manager, Chris Palmer, Scott Schmit, Sean |
|
|
+ Turner, and Ben Wilson. |
|
|
+ |
|
|
+9. References |
|
|
+ |
|
|
+9.1. Normative References |
|
|
+ |
|
|
+ [RFC1035] Mockapetris, P., "Domain names - implementation and |
|
|
+ specification", STD 13, RFC 1035, November 1987. |
|
|
+ |
|
|
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
|
|
+ Requirement Levels", BCP 14, RFC 2119, March 1997. |
|
|
+ |
|
|
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS |
|
|
+ Specification", RFC 2181, July 1997. |
|
|
+ |
|
|
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
|
|
+ Rose, "DNS Security Introduction and Requirements", |
|
|
+ RFC 4033, March 2005. |
|
|
+ |
|
|
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
|
|
+ Rose, "Resource Records for the DNS Security Extensions", |
|
|
+ RFC 4034, March 2005. |
|
|
+ |
|
|
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
|
|
+ Rose, "Protocol Modifications for the DNS Security |
|
|
+ Extensions", RFC 4035, March 2005. |
|
|
+ |
|
|
+ [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident |
|
|
+ Object Description Exchange Format", RFC 5070, |
|
|
+ December 2007. |
|
|
+ |
|
|
+ [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS |
|
|
+ Security (DNSSEC) Hashed Authenticated Denial of |
|
|
+ Existence", RFC 5155, March 2008. |
|
|
+ |
|
|
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
|
|
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
|
|
+ May 2008. |
|
|
+ |
|
|
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax |
|
|
+ Specifications: ABNF", STD 68, RFC 5234, January 2008. |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+Hallam-Baker & Stradling Standards Track [Page 16] |
|
|
+ |
|
|
+RFC 6844 Certification Authority Authorization January 2013 |
|
|
+ |
|
|
+ |
|
|
+ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., |
|
|
+ Housley, R., and W. Polk, "Internet X.509 Public Key |
|
|
+ Infrastructure Certificate and Certificate Revocation List |
|
|
+ (CRL) Profile", RFC 5280, May 2008. |
|
|
+ |
|
|
+ [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA |
|
|
+ Considerations", BCP 42, RFC 6195, March 2011. |
|
|
+ |
|
|
+ [RFC6546] Trammell, B., "Transport of Real-time Inter-network |
|
|
+ Defense (RID) Messages over HTTP/TLS", RFC 6546, |
|
|
+ April 2012. |
|
|
+ |
|
|
+ [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication |
|
|
+ of Named Entities (DANE) Transport Layer Security (TLS) |
|
|
+ Protocol: TLSA", RFC 6698, August 2012. |
|
|
+ |
|
|
+ [STD13] Mockapetris, P., "Domain names - concepts and facilities", |
|
|
+ STD 13, RFC 1034, November 1987. |
|
|
+ |
|
|
+ Mockapetris, P., "Domain names - implementation and |
|
|
+ specification", STD 13, RFC 1035, November 1987. |
|
|
+ |
|
|
+ [X.509] International Telecommunication Union, "ITU-T |
|
|
+ Recommendation X.509 (11/2008): Information technology - |
|
|
+ Open systems interconnection - The Directory: Public-key |
|
|
+ and attribute certificate frameworks", ITU-T |
|
|
+ Recommendation X.509, November 2008. |
|
|
+ |
|
|
+9.2. Informative References |
|
|
+ |
|
|
+ [HB2011] Hallam-Baker, P., Stradling, R., and B. Laurie, "DNS |
|
|
+ Certification Authority Authorization (CAA) Resource |
|
|
+ Record", Work in Progress, May 2011. |
|
|
+ |
|
|
+ [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. |
|
|
+ Wu, "Internet X.509 Public Key Infrastructure Certificate |
|
|
+ Policy and Certification Practices Framework", RFC 3647, |
|
|
+ November 2003. |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+Hallam-Baker & Stradling Standards Track [Page 17] |
|
|
+ |
|
|
+RFC 6844 Certification Authority Authorization January 2013 |
|
|
+ |
|
|
+ |
|
|
+Authors' Addresses |
|
|
+ |
|
|
+ Phillip Hallam-Baker |
|
|
+ Comodo Group, Inc. |
|
|
+ |
|
|
+ EMail: philliph@comodo.com |
|
|
+ |
|
|
+ |
|
|
+ Rob Stradling |
|
|
+ Comodo CA, Ltd. |
|
|
+ |
|
|
+ EMail: rob.stradling@comodo.com |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+ |
|
|
+Hallam-Baker & Stradling Standards Track [Page 18] |
|
|
+ |
|
|
diff --git a/lib/dns/rdata.c b/lib/dns/rdata.c |
|
|
index a83dab4..9bf83a4 100644 |
|
|
--- a/lib/dns/rdata.c |
|
|
+++ b/lib/dns/rdata.c |
|
|
@@ -116,7 +116,7 @@ typedef struct dns_rdata_textctx { |
|
|
} dns_rdata_textctx_t; |
|
|
|
|
|
static isc_result_t |
|
|
-txt_totext(isc_region_t *source, isc_buffer_t *target); |
|
|
+txt_totext(isc_region_t *source, isc_boolean_t quote, isc_buffer_t *target); |
|
|
|
|
|
static isc_result_t |
|
|
txt_fromtext(isc_textregion_t *source, isc_buffer_t *target); |
|
|
@@ -130,9 +130,6 @@ multitxt_totext(isc_region_t *source, isc_buffer_t *target); |
|
|
static isc_result_t |
|
|
multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target); |
|
|
|
|
|
-static isc_result_t |
|
|
-multitxt_fromwire(isc_buffer_t *source, isc_buffer_t *target); |
|
|
- |
|
|
static isc_boolean_t |
|
|
name_prefix(dns_name_t *name, dns_name_t *origin, dns_name_t *target); |
|
|
|
|
|
@@ -1131,7 +1128,7 @@ name_length(dns_name_t *name) { |
|
|
} |
|
|
|
|
|
static isc_result_t |
|
|
-txt_totext(isc_region_t *source, isc_buffer_t *target) { |
|
|
+txt_totext(isc_region_t *source, isc_boolean_t quote, isc_buffer_t *target) { |
|
|
unsigned int tl; |
|
|
unsigned int n; |
|
|
unsigned char *sp; |
|
|
@@ -1146,13 +1143,20 @@ txt_totext(isc_region_t *source, isc_buffer_t *target) { |
|
|
n = *sp++; |
|
|
|
|
|
REQUIRE(n + 1 <= source->length); |
|
|
+ if (n == 0U) |
|
|
+ REQUIRE(quote == ISC_TRUE); |
|
|
|
|
|
- if (tl < 1) |
|
|
- return (ISC_R_NOSPACE); |
|
|
- *tp++ = '"'; |
|
|
- tl--; |
|
|
+ if (quote) { |
|
|
+ if (tl < 1) |
|
|
+ return (ISC_R_NOSPACE); |
|
|
+ *tp++ = '"'; |
|
|
+ tl--; |
|
|
+ } |
|
|
while (n--) { |
|
|
- if (*sp < 0x20 || *sp >= 0x7f) { |
|
|
+ /* |
|
|
+ * \DDD space (0x20) if not quoting. |
|
|
+ */ |
|
|
+ if (*sp < (quote ? 0x20 : 0x21) || *sp >= 0x7f) { |
|
|
if (tl < 4) |
|
|
return (ISC_R_NOSPACE); |
|
|
*tp++ = 0x5c; |
|
|
@@ -1163,8 +1167,13 @@ txt_totext(isc_region_t *source, isc_buffer_t *target) { |
|
|
tl -= 4; |
|
|
continue; |
|
|
} |
|
|
- /* double quote, semi-colon, backslash */ |
|
|
- if (*sp == 0x22 || *sp == 0x3b || *sp == 0x5c) { |
|
|
+ /* |
|
|
+ * Escape double quote, semi-colon, backslash. |
|
|
+ * If we are not enclosing the string in double |
|
|
+ * quotes also escape at sign. |
|
|
+ */ |
|
|
+ if (*sp == 0x22 || *sp == 0x3b || *sp == 0x5c || |
|
|
+ (!quote && *sp == 0x40)) { |
|
|
if (tl < 2) |
|
|
return (ISC_R_NOSPACE); |
|
|
*tp++ = '\\'; |
|
|
@@ -1175,10 +1184,12 @@ txt_totext(isc_region_t *source, isc_buffer_t *target) { |
|
|
*tp++ = *sp++; |
|
|
tl--; |
|
|
} |
|
|
- if (tl < 1) |
|
|
- return (ISC_R_NOSPACE); |
|
|
- *tp++ = '"'; |
|
|
- tl--; |
|
|
+ if (quote) { |
|
|
+ if (tl < 1) |
|
|
+ return (ISC_R_NOSPACE); |
|
|
+ *tp++ = '"'; |
|
|
+ tl--; |
|
|
+ } |
|
|
isc_buffer_add(target, tp - (char *)region.base); |
|
|
isc_region_consume(source, *source->base + 1); |
|
|
return (ISC_R_SUCCESS); |
|
|
@@ -1274,6 +1285,9 @@ txt_fromwire(isc_buffer_t *source, isc_buffer_t *target) { |
|
|
return (ISC_R_SUCCESS); |
|
|
} |
|
|
|
|
|
+/* |
|
|
+ * Conversion of TXT-like rdata fields without length limits. |
|
|
+ */ |
|
|
static isc_result_t |
|
|
multitxt_totext(isc_region_t *source, isc_buffer_t *target) { |
|
|
unsigned int tl; |
|
|
@@ -1292,9 +1306,8 @@ multitxt_totext(isc_region_t *source, isc_buffer_t *target) { |
|
|
*tp++ = '"'; |
|
|
tl--; |
|
|
do { |
|
|
- n0 = n = *sp++; |
|
|
- |
|
|
- REQUIRE(n0 + 1 <= source->length); |
|
|
+ n = source->length; |
|
|
+ n0 = source->length - 1; |
|
|
|
|
|
while (n--) { |
|
|
if (*sp < 0x20 || *sp >= 0x7f) { |
|
|
@@ -1346,17 +1359,11 @@ multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target) { |
|
|
|
|
|
do { |
|
|
isc_buffer_availableregion(target, &tregion); |
|
|
- t0 = tregion.base; |
|
|
+ t0 = t = tregion.base; |
|
|
nrem = tregion.length; |
|
|
if (nrem < 1) |
|
|
return (ISC_R_NOSPACE); |
|
|
- /* length byte */ |
|
|
- t = t0; |
|
|
- nrem--; |
|
|
- t++; |
|
|
- /* 255 byte character-string slice */ |
|
|
- if (nrem > 255) |
|
|
- nrem = 255; |
|
|
+ |
|
|
while (n != 0) { |
|
|
--n; |
|
|
c = (*s++) & 0xff; |
|
|
@@ -1390,39 +1397,9 @@ multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target) { |
|
|
} |
|
|
if (escape) |
|
|
return (DNS_R_SYNTAX); |
|
|
- *t0 = t - t0 - 1; |
|
|
- isc_buffer_add(target, *t0 + 1); |
|
|
- } while (n != 0); |
|
|
- return (ISC_R_SUCCESS); |
|
|
-} |
|
|
- |
|
|
-static isc_result_t |
|
|
-multitxt_fromwire(isc_buffer_t *source, isc_buffer_t *target) { |
|
|
- unsigned int n; |
|
|
- isc_region_t sregion; |
|
|
- isc_region_t tregion; |
|
|
- |
|
|
- isc_buffer_activeregion(source, &sregion); |
|
|
- if (sregion.length == 0) |
|
|
- return(ISC_R_UNEXPECTEDEND); |
|
|
- n = 256U; |
|
|
- do { |
|
|
- if (n != 256U) |
|
|
- return (DNS_R_SYNTAX); |
|
|
- n = *sregion.base + 1; |
|
|
- if (n > sregion.length) |
|
|
- return (ISC_R_UNEXPECTEDEND); |
|
|
|
|
|
- isc_buffer_availableregion(target, &tregion); |
|
|
- if (n > tregion.length) |
|
|
- return (ISC_R_NOSPACE); |
|
|
- |
|
|
- if (tregion.base != sregion.base) |
|
|
- memcpy(tregion.base, sregion.base, n); |
|
|
- isc_buffer_forward(source, n); |
|
|
- isc_buffer_add(target, n); |
|
|
- isc_buffer_activeregion(source, &sregion); |
|
|
- } while (sregion.length != 0); |
|
|
+ isc_buffer_add(target, t - t0); |
|
|
+ } while (n != 0); |
|
|
return (ISC_R_SUCCESS); |
|
|
} |
|
|
|
|
|
diff --git a/lib/dns/rdata/generic/caa_257.c b/lib/dns/rdata/generic/caa_257.c |
|
|
new file mode 100644 |
|
|
index 0000000..671f332 |
|
|
--- /dev/null |
|
|
+++ b/lib/dns/rdata/generic/caa_257.c |
|
|
@@ -0,0 +1,370 @@ |
|
|
+/* |
|
|
+ * Copyright (C) 2014 Internet Systems Consortium, Inc. ("ISC") |
|
|
+ * |
|
|
+ * Permission to use, copy, modify, and/or distribute this software for any |
|
|
+ * purpose with or without fee is hereby granted, provided that the above |
|
|
+ * copyright notice and this permission notice appear in all copies. |
|
|
+ * |
|
|
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH |
|
|
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY |
|
|
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, |
|
|
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM |
|
|
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE |
|
|
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR |
|
|
+ * PERFORMANCE OF THIS SOFTWARE. |
|
|
+ */ |
|
|
+ |
|
|
+#ifndef GENERIC_CAA_257_C |
|
|
+#define GENERIC_CAA_257_C 1 |
|
|
+ |
|
|
+#define RRTYPE_CAA_ATTRIBUTES (0) |
|
|
+ |
|
|
+static unsigned char const alphanumeric[256] = { |
|
|
+ /* 0x00-0x0f */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0x10-0x1f */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0x20-0x2f */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0x30-0x3f */ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0x40-0x4f */ 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, |
|
|
+ /* 0x50-0x5f */ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, |
|
|
+ /* 0x60-0x6f */ 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, |
|
|
+ /* 0x70-0x7f */ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, |
|
|
+ /* 0x80-0x8f */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0x90-0x9f */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0xa0-0xaf */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0xb0-0xbf */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0xc0-0xcf */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0xd0-0xdf */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0xe0-0xef */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+ /* 0xf0-0xff */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
|
|
+}; |
|
|
+ |
|
|
+static inline isc_result_t |
|
|
+fromtext_caa(ARGS_FROMTEXT) { |
|
|
+ isc_token_t token; |
|
|
+ isc_textregion_t tr; |
|
|
+ isc_uint8_t flags; |
|
|
+ unsigned int i; |
|
|
+ |
|
|
+ REQUIRE(type == 257); |
|
|
+ |
|
|
+ UNUSED(type); |
|
|
+ UNUSED(rdclass); |
|
|
+ UNUSED(origin); |
|
|
+ UNUSED(options); |
|
|
+ UNUSED(callbacks); |
|
|
+ |
|
|
+ /* Flags. */ |
|
|
+ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number, |
|
|
+ ISC_FALSE)); |
|
|
+ if (token.value.as_ulong > 255U) |
|
|
+ RETTOK(ISC_R_RANGE); |
|
|
+ flags = token.value.as_ulong & 255U; |
|
|
+ RETERR(uint8_tobuffer(flags, target)); |
|
|
+ |
|
|
+ /* |
|
|
+ * Tag |
|
|
+ */ |
|
|
+ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string, |
|
|
+ ISC_FALSE)); |
|
|
+ tr = token.value.as_textregion; |
|
|
+ for (i = 0; i < tr.length; i++) |
|
|
+ if (!alphanumeric[(unsigned char) tr.base[i]]) |
|
|
+ RETTOK(DNS_R_SYNTAX); |
|
|
+ RETERR(uint8_tobuffer(tr.length, target)); |
|
|
+ RETERR(mem_tobuffer(target, tr.base, tr.length)); |
|
|
+ |
|
|
+ /* |
|
|
+ * Value |
|
|
+ */ |
|
|
+ RETERR(isc_lex_getmastertoken(lexer, &token, |
|
|
+ isc_tokentype_qstring, ISC_FALSE)); |
|
|
+ if (token.type != isc_tokentype_qstring && |
|
|
+ token.type != isc_tokentype_string) |
|
|
+ RETERR(DNS_R_SYNTAX); |
|
|
+ RETERR(multitxt_fromtext(&token.value.as_textregion, target)); |
|
|
+ return (ISC_R_SUCCESS); |
|
|
+} |
|
|
+ |
|
|
+static inline isc_result_t |
|
|
+totext_caa(ARGS_TOTEXT) { |
|
|
+ isc_region_t region; |
|
|
+ isc_uint8_t flags; |
|
|
+ char buf[256]; |
|
|
+ |
|
|
+ UNUSED(tctx); |
|
|
+ |
|
|
+ REQUIRE(rdata->type == 257); |
|
|
+ REQUIRE(rdata->length >= 3U); |
|
|
+ REQUIRE(rdata->data != NULL); |
|
|
+ |
|
|
+ dns_rdata_toregion(rdata, ®ion); |
|
|
+ |
|
|
+ /* |
|
|
+ * Flags |
|
|
+ */ |
|
|
+ flags = uint8_consume_fromregion(®ion); |
|
|
+ sprintf(buf, "%u ", flags); |
|
|
+ RETERR(str_totext(buf, target)); |
|
|
+ |
|
|
+ /* |
|
|
+ * Tag |
|
|
+ */ |
|
|
+ RETERR(txt_totext(®ion, ISC_FALSE, target)); |
|
|
+ RETERR(str_totext(" ", target)); |
|
|
+ |
|
|
+ /* |
|
|
+ * Value |
|
|
+ */ |
|
|
+ RETERR(multitxt_totext(®ion, target)); |
|
|
+ return (ISC_R_SUCCESS); |
|
|
+} |
|
|
+ |
|
|
+static inline isc_result_t |
|
|
+fromwire_caa(ARGS_FROMWIRE) { |
|
|
+ isc_region_t sr; |
|
|
+ unsigned int len, i; |
|
|
+ |
|
|
+ REQUIRE(type == 257); |
|
|
+ |
|
|
+ UNUSED(type); |
|
|
+ UNUSED(rdclass); |
|
|
+ UNUSED(dctx); |
|
|
+ UNUSED(options); |
|
|
+ |
|
|
+ /* |
|
|
+ * Flags |
|
|
+ */ |
|
|
+ isc_buffer_activeregion(source, &sr); |
|
|
+ if (sr.length < 2) |
|
|
+ return (ISC_R_UNEXPECTEDEND); |
|
|
+ |
|
|
+ /* |
|
|
+ * Flags, tag length |
|
|
+ */ |
|
|
+ RETERR(mem_tobuffer(target, sr.base, 2)); |
|
|
+ len = sr.base[1]; |
|
|
+ isc_region_consume(&sr, 2); |
|
|
+ isc_buffer_forward(source, 2); |
|
|
+ |
|
|
+ /* |
|
|
+ * Zero length tag fields are illegal. |
|
|
+ */ |
|
|
+ if (sr.length < len || len == 0) |
|
|
+ RETERR(DNS_R_FORMERR); |
|
|
+ |
|
|
+ /* Check the Tag's value */ |
|
|
+ for (i = 0; i < len; i++) |
|
|
+ if (!alphanumeric[sr.base[i]]) |
|
|
+ RETERR(DNS_R_FORMERR); |
|
|
+ /* |
|
|
+ * Tag + Value |
|
|
+ */ |
|
|
+ isc_buffer_forward(source, sr.length); |
|
|
+ return (mem_tobuffer(target, sr.base, sr.length)); |
|
|
+} |
|
|
+ |
|
|
+static inline isc_result_t |
|
|
+towire_caa(ARGS_TOWIRE) { |
|
|
+ isc_region_t region; |
|
|
+ |
|
|
+ REQUIRE(rdata->type == 257); |
|
|
+ REQUIRE(rdata->length >= 3U); |
|
|
+ REQUIRE(rdata->data != NULL); |
|
|
+ |
|
|
+ UNUSED(cctx); |
|
|
+ |
|
|
+ dns_rdata_toregion(rdata, ®ion); |
|
|
+ return (mem_tobuffer(target, region.base, region.length)); |
|
|
+} |
|
|
+ |
|
|
+static inline int |
|
|
+compare_caa(ARGS_COMPARE) { |
|
|
+ isc_region_t r1, r2; |
|
|
+ |
|
|
+ REQUIRE(rdata1->type == rdata2->type); |
|
|
+ REQUIRE(rdata1->rdclass == rdata2->rdclass); |
|
|
+ REQUIRE(rdata1->type == 257); |
|
|
+ REQUIRE(rdata1->length >= 3U); |
|
|
+ REQUIRE(rdata2->length >= 3U); |
|
|
+ REQUIRE(rdata1->data != NULL); |
|
|
+ REQUIRE(rdata2->data != NULL); |
|
|
+ |
|
|
+ dns_rdata_toregion(rdata1, &r1); |
|
|
+ dns_rdata_toregion(rdata2, &r2); |
|
|
+ return (isc_region_compare(&r1, &r2)); |
|
|
+} |
|
|
+ |
|
|
+static inline isc_result_t |
|
|
+fromstruct_caa(ARGS_FROMSTRUCT) { |
|
|
+ dns_rdata_caa_t *caa = source; |
|
|
+ isc_region_t region; |
|
|
+ unsigned int i; |
|
|
+ |
|
|
+ REQUIRE(type == 257); |
|
|
+ REQUIRE(source != NULL); |
|
|
+ REQUIRE(caa->common.rdtype == type); |
|
|
+ REQUIRE(caa->common.rdclass == rdclass); |
|
|
+ REQUIRE(caa->tag != NULL && caa->tag_len != 0); |
|
|
+ REQUIRE(caa->value != NULL); |
|
|
+ |
|
|
+ UNUSED(type); |
|
|
+ UNUSED(rdclass); |
|
|
+ |
|
|
+ /* |
|
|
+ * Flags |
|
|
+ */ |
|
|
+ RETERR(uint8_tobuffer(caa->flags, target)); |
|
|
+ |
|
|
+ /* |
|
|
+ * Tag length |
|
|
+ */ |
|
|
+ RETERR(uint8_tobuffer(caa->tag_len, target)); |
|
|
+ |
|
|
+ /* |
|
|
+ * Tag |
|
|
+ */ |
|
|
+ region.base = caa->tag; |
|
|
+ region.length = caa->tag_len; |
|
|
+ for (i = 0; i < region.length; i++) |
|
|
+ if (!alphanumeric[region.base[i]]) |
|
|
+ RETERR(DNS_R_SYNTAX); |
|
|
+ RETERR(isc_buffer_copyregion(target, ®ion)); |
|
|
+ |
|
|
+ /* |
|
|
+ * Value |
|
|
+ */ |
|
|
+ region.base = caa->value; |
|
|
+ region.length = caa->value_len; |
|
|
+ return (isc_buffer_copyregion(target, ®ion)); |
|
|
+} |
|
|
+ |
|
|
+static inline isc_result_t |
|
|
+tostruct_caa(ARGS_TOSTRUCT) { |
|
|
+ dns_rdata_caa_t *caa = target; |
|
|
+ isc_region_t sr; |
|
|
+ |
|
|
+ REQUIRE(rdata->type == 257); |
|
|
+ REQUIRE(target != NULL); |
|
|
+ REQUIRE(rdata->length >= 3U); |
|
|
+ REQUIRE(rdata->data != NULL); |
|
|
+ |
|
|
+ caa->common.rdclass = rdata->rdclass; |
|
|
+ caa->common.rdtype = rdata->type; |
|
|
+ ISC_LINK_INIT(&caa->common, link); |
|
|
+ |
|
|
+ dns_rdata_toregion(rdata, &sr); |
|
|
+ |
|
|
+ /* |
|
|
+ * Flags |
|
|
+ */ |
|
|
+ if (sr.length < 1) |
|
|
+ return (ISC_R_UNEXPECTEDEND); |
|
|
+ caa->flags = uint8_fromregion(&sr); |
|
|
+ isc_region_consume(&sr, 1); |
|
|
+ |
|
|
+ /* |
|
|
+ * Tag length |
|
|
+ */ |
|
|
+ if (sr.length < 1) |
|
|
+ return (ISC_R_UNEXPECTEDEND); |
|
|
+ caa->tag_len = uint8_fromregion(&sr); |
|
|
+ isc_region_consume(&sr, 1); |
|
|
+ |
|
|
+ /* |
|
|
+ * Tag |
|
|
+ */ |
|
|
+ if (sr.length < caa->tag_len) |
|
|
+ return (ISC_R_UNEXPECTEDEND); |
|
|
+ caa->tag = mem_maybedup(mctx, sr.base, caa->tag_len); |
|
|
+ if (caa->tag == NULL) |
|
|
+ return (ISC_R_NOMEMORY); |
|
|
+ isc_region_consume(&sr, caa->tag_len); |
|
|
+ |
|
|
+ /* |
|
|
+ * Value |
|
|
+ */ |
|
|
+ caa->value_len = sr.length; |
|
|
+ caa->value = mem_maybedup(mctx, sr.base, sr.length); |
|
|
+ if (caa->value == NULL) |
|
|
+ return (ISC_R_NOMEMORY); |
|
|
+ |
|
|
+ caa->mctx = mctx; |
|
|
+ return (ISC_R_SUCCESS); |
|
|
+} |
|
|
+ |
|
|
+static inline void |
|
|
+freestruct_caa(ARGS_FREESTRUCT) { |
|
|
+ dns_rdata_caa_t *caa = (dns_rdata_caa_t *) source; |
|
|
+ |
|
|
+ REQUIRE(source != NULL); |
|
|
+ REQUIRE(caa->common.rdtype == 257); |
|
|
+ |
|
|
+ if (caa->mctx == NULL) |
|
|
+ return; |
|
|
+ |
|
|
+ if (caa->tag != NULL) |
|
|
+ isc_mem_free(caa->mctx, caa->tag); |
|
|
+ if (caa->value != NULL) |
|
|
+ isc_mem_free(caa->mctx, caa->value); |
|
|
+ caa->mctx = NULL; |
|
|
+} |
|
|
+ |
|
|
+static inline isc_result_t |
|
|
+additionaldata_caa(ARGS_ADDLDATA) { |
|
|
+ REQUIRE(rdata->type == 257); |
|
|
+ REQUIRE(rdata->data != NULL); |
|
|
+ REQUIRE(rdata->length >= 3U); |
|
|
+ |
|
|
+ UNUSED(rdata); |
|
|
+ UNUSED(add); |
|
|
+ UNUSED(arg); |
|
|
+ |
|
|
+ return (ISC_R_SUCCESS); |
|
|
+} |
|
|
+ |
|
|
+static inline isc_result_t |
|
|
+digest_caa(ARGS_DIGEST) { |
|
|
+ isc_region_t r; |
|
|
+ |
|
|
+ REQUIRE(rdata->type == 257); |
|
|
+ REQUIRE(rdata->data != NULL); |
|
|
+ REQUIRE(rdata->length >= 3U); |
|
|
+ |
|
|
+ dns_rdata_toregion(rdata, &r); |
|
|
+ |
|
|
+ return ((digest)(arg, &r)); |
|
|
+} |
|
|
+ |
|
|
+static inline isc_boolean_t |
|
|
+checkowner_caa(ARGS_CHECKOWNER) { |
|
|
+ |
|
|
+ REQUIRE(type == 257); |
|
|
+ |
|
|
+ UNUSED(name); |
|
|
+ UNUSED(type); |
|
|
+ UNUSED(rdclass); |
|
|
+ UNUSED(wildcard); |
|
|
+ |
|
|
+ return (ISC_TRUE); |
|
|
+} |
|
|
+ |
|
|
+static inline isc_boolean_t |
|
|
+checknames_caa(ARGS_CHECKNAMES) { |
|
|
+ |
|
|
+ REQUIRE(rdata->type == 257); |
|
|
+ REQUIRE(rdata->data != NULL); |
|
|
+ REQUIRE(rdata->length >= 3U); |
|
|
+ |
|
|
+ UNUSED(rdata); |
|
|
+ UNUSED(owner); |
|
|
+ UNUSED(bad); |
|
|
+ |
|
|
+ return (ISC_TRUE); |
|
|
+} |
|
|
+ |
|
|
+static inline int |
|
|
+casecompare_caa(ARGS_COMPARE) { |
|
|
+ return (compare_caa(rdata1, rdata2)); |
|
|
+} |
|
|
+ |
|
|
+#endif /* GENERIC_CAA_257_C */ |
|
|
diff --git a/lib/dns/rdata/generic/caa_257.h b/lib/dns/rdata/generic/caa_257.h |
|
|
new file mode 100644 |
|
|
index 0000000..79866a5 |
|
|
--- /dev/null |
|
|
+++ b/lib/dns/rdata/generic/caa_257.h |
|
|
@@ -0,0 +1,32 @@ |
|
|
+/* |
|
|
+ * Copyright (C) 2014 Internet Systems Consortium, Inc. ("ISC") |
|
|
+ * |
|
|
+ * Permission to use, copy, modify, and/or distribute this software for any |
|
|
+ * purpose with or without fee is hereby granted, provided that the above |
|
|
+ * copyright notice and this permission notice appear in all copies. |
|
|
+ * |
|
|
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH |
|
|
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY |
|
|
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, |
|
|
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM |
|
|
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE |
|
|
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR |
|
|
+ * PERFORMANCE OF THIS SOFTWARE. |
|
|
+ */ |
|
|
+ |
|
|
+#ifndef GENERIC_CAA_257_H |
|
|
+#define GENERIC_CAA_257_H 1 |
|
|
+ |
|
|
+/* $Id$ */ |
|
|
+ |
|
|
+typedef struct dns_rdata_caa { |
|
|
+ dns_rdatacommon_t common; |
|
|
+ isc_mem_t * mctx; |
|
|
+ isc_uint8_t flags; |
|
|
+ unsigned char * tag; |
|
|
+ isc_uint8_t tag_len; |
|
|
+ unsigned char *value; |
|
|
+ isc_uint8_t value_len; |
|
|
+} dns_rdata_caa_t; |
|
|
+ |
|
|
+#endif /* GENERIC_CAA_257_H */ |
|
|
diff --git a/lib/dns/rdata/generic/gpos_27.c b/lib/dns/rdata/generic/gpos_27.c |
|
|
index ce71822..5a90216 100644 |
|
|
--- a/lib/dns/rdata/generic/gpos_27.c |
|
|
+++ b/lib/dns/rdata/generic/gpos_27.c |
|
|
@@ -61,7 +61,7 @@ totext_gpos(ARGS_TOTEXT) { |
|
|
dns_rdata_toregion(rdata, ®ion); |
|
|
|
|
|
for (i = 0; i < 3; i++) { |
|
|
- RETERR(txt_totext(®ion, target)); |
|
|
+ RETERR(txt_totext(®ion, ISC_TRUE, target)); |
|
|
if (i != 2) |
|
|
RETERR(str_totext(" ", target)); |
|
|
} |
|
|
diff --git a/lib/dns/rdata/generic/hinfo_13.c b/lib/dns/rdata/generic/hinfo_13.c |
|
|
index 10b4fec..92038b7 100644 |
|
|
--- a/lib/dns/rdata/generic/hinfo_13.c |
|
|
+++ b/lib/dns/rdata/generic/hinfo_13.c |
|
|
@@ -58,9 +58,9 @@ totext_hinfo(ARGS_TOTEXT) { |
|
|
REQUIRE(rdata->length != 0); |
|
|
|
|
|
dns_rdata_toregion(rdata, ®ion); |
|
|
- RETERR(txt_totext(®ion, target)); |
|
|
+ RETERR(txt_totext(®ion, ISC_TRUE, target)); |
|
|
RETERR(str_totext(" ", target)); |
|
|
- return (txt_totext(®ion, target)); |
|
|
+ return (txt_totext(®ion, ISC_TRUE, target)); |
|
|
} |
|
|
|
|
|
static inline isc_result_t |
|
|
diff --git a/lib/dns/rdata/generic/isdn_20.c b/lib/dns/rdata/generic/isdn_20.c |
|
|
index 5aac73f..059c247 100644 |
|
|
--- a/lib/dns/rdata/generic/isdn_20.c |
|
|
+++ b/lib/dns/rdata/generic/isdn_20.c |
|
|
@@ -65,11 +65,11 @@ totext_isdn(ARGS_TOTEXT) { |
|
|
UNUSED(tctx); |
|
|
|
|
|
dns_rdata_toregion(rdata, ®ion); |
|
|
- RETERR(txt_totext(®ion, target)); |
|
|
+ RETERR(txt_totext(®ion, ISC_TRUE, target)); |
|
|
if (region.length == 0) |
|
|
return (ISC_R_SUCCESS); |
|
|
RETERR(str_totext(" ", target)); |
|
|
- return (txt_totext(®ion, target)); |
|
|
+ return (txt_totext(®ion, ISC_TRUE, target)); |
|
|
} |
|
|
|
|
|
static inline isc_result_t |
|
|
diff --git a/lib/dns/rdata/generic/naptr_35.c b/lib/dns/rdata/generic/naptr_35.c |
|
|
index 83439a5..be7d403 100644 |
|
|
--- a/lib/dns/rdata/generic/naptr_35.c |
|
|
+++ b/lib/dns/rdata/generic/naptr_35.c |
|
|
@@ -224,19 +224,19 @@ totext_naptr(ARGS_TOTEXT) { |
|
|
/* |
|
|
* Flags. |
|
|
*/ |
|
|
- RETERR(txt_totext(®ion, target)); |
|
|
+ RETERR(txt_totext(®ion, ISC_TRUE, target)); |
|
|
RETERR(str_totext(" ", target)); |
|
|
|
|
|
/* |
|
|
* Service. |
|
|
*/ |
|
|
- RETERR(txt_totext(®ion, target)); |
|
|
+ RETERR(txt_totext(®ion, ISC_TRUE, target)); |
|
|
RETERR(str_totext(" ", target)); |
|
|
|
|
|
/* |
|
|
* Regexp. |
|
|
*/ |
|
|
- RETERR(txt_totext(®ion, target)); |
|
|
+ RETERR(txt_totext(®ion, ISC_TRUE, target)); |
|
|
RETERR(str_totext(" ", target)); |
|
|
|
|
|
/* |
|
|
diff --git a/lib/dns/rdata/generic/spf_99.c b/lib/dns/rdata/generic/spf_99.c |
|
|
index 492e315..85594fd 100644 |
|
|
--- a/lib/dns/rdata/generic/spf_99.c |
|
|
+++ b/lib/dns/rdata/generic/spf_99.c |
|
|
@@ -64,7 +64,7 @@ totext_spf(ARGS_TOTEXT) { |
|
|
dns_rdata_toregion(rdata, ®ion); |
|
|
|
|
|
while (region.length > 0) { |
|
|
- RETERR(txt_totext(®ion, target)); |
|
|
+ RETERR(txt_totext(®ion, ISC_TRUE, target)); |
|
|
if (region.length > 0) |
|
|
RETERR(str_totext(" ", target)); |
|
|
} |
|
|
diff --git a/lib/dns/rdata/generic/txt_16.c b/lib/dns/rdata/generic/txt_16.c |
|
|
index e1bce6a..e0e8ea5 100644 |
|
|
--- a/lib/dns/rdata/generic/txt_16.c |
|
|
+++ b/lib/dns/rdata/generic/txt_16.c |
|
|
@@ -71,7 +71,7 @@ totext_txt(ARGS_TOTEXT) { |
|
|
dns_rdata_toregion(rdata, ®ion); |
|
|
|
|
|
while (region.length > 0) { |
|
|
- RETERR(txt_totext(®ion, target)); |
|
|
+ RETERR(txt_totext(®ion, ISC_TRUE, target)); |
|
|
if (region.length > 0) |
|
|
RETERR(str_totext(" ", target)); |
|
|
} |
|
|
diff --git a/lib/dns/rdata/generic/uri_256.c b/lib/dns/rdata/generic/uri_256.c |
|
|
index 799eb69..62bdd25 100644 |
|
|
--- a/lib/dns/rdata/generic/uri_256.c |
|
|
+++ b/lib/dns/rdata/generic/uri_256.c |
|
|
@@ -115,15 +115,12 @@ fromwire_uri(ARGS_FROMWIRE) { |
|
|
isc_buffer_activeregion(source, ®ion); |
|
|
if (region.length < 4) |
|
|
return (ISC_R_UNEXPECTEDEND); |
|
|
- RETERR(mem_tobuffer(target, region.base, 4)); |
|
|
- isc_buffer_forward(source, 4); |
|
|
|
|
|
/* |
|
|
- * Target URI |
|
|
+ * Priority, weight and target URI |
|
|
*/ |
|
|
- RETERR(multitxt_fromwire(source, target)); |
|
|
- |
|
|
- return (ISC_R_SUCCESS); |
|
|
+ isc_buffer_forward(source, region.length); |
|
|
+ return (mem_tobuffer(target, region.base, region.length)); |
|
|
} |
|
|
|
|
|
static inline isc_result_t |
|
|
@@ -178,8 +175,6 @@ compare_uri(ARGS_COMPARE) { |
|
|
static inline isc_result_t |
|
|
fromstruct_uri(ARGS_FROMSTRUCT) { |
|
|
dns_rdata_uri_t *uri = source; |
|
|
- isc_region_t region; |
|
|
- isc_uint8_t len; |
|
|
|
|
|
REQUIRE(type == 256); |
|
|
REQUIRE(source != NULL); |
|
|
@@ -203,18 +198,6 @@ fromstruct_uri(ARGS_FROMSTRUCT) { |
|
|
/* |
|
|
* Target URI |
|
|
*/ |
|
|
- len = 255U; |
|
|
- region.base = uri->target; |
|
|
- region.length = uri->tgt_len; |
|
|
- while (region.length > 0) { |
|
|
- REQUIRE(len == 255U); |
|
|
- len = uint8_fromregion(®ion); |
|
|
- isc_region_consume(®ion, 1); |
|
|
- if (region.length < len) |
|
|
- return (ISC_R_UNEXPECTEDEND); |
|
|
- isc_region_consume(®ion, len); |
|
|
- } |
|
|
- |
|
|
return (mem_tobuffer(target, uri->target, uri->tgt_len)); |
|
|
} |
|
|
|
|
|
diff --git a/lib/dns/rdata/generic/x25_19.c b/lib/dns/rdata/generic/x25_19.c |
|
|
index 6867fec..f9dfb8a 100644 |
|
|
--- a/lib/dns/rdata/generic/x25_19.c |
|
|
+++ b/lib/dns/rdata/generic/x25_19.c |
|
|
@@ -60,7 +60,7 @@ totext_x25(ARGS_TOTEXT) { |
|
|
REQUIRE(rdata->length != 0); |
|
|
|
|
|
dns_rdata_toregion(rdata, ®ion); |
|
|
- return (txt_totext(®ion, target)); |
|
|
+ return (txt_totext(®ion, ISC_TRUE, target)); |
|
|
} |
|
|
|
|
|
static inline isc_result_t |
|
|
-- |
|
|
2.4.3 |
|
|
|
|
|
|