--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+/*
+ * 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;
+ 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 int) 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,
+ ISC_FALSE));
+ 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, ISC_FALSE));
+ 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);
+
+ /* Tag */
+ for (i = 0; i < sr.length; i++)
+ if (!alphanumeric[sr.base[i]])
+ RETERR(DNS_R_FORMERR);
+ RETERR(mem_tobuffer(target, sr.base, len));
+ isc_region_consume(&sr, len);
+ isc_buffer_forward(source, len);
+
+ /*
+ * Value
+ */
+ RETERR(multitxt_fromwire(source, target, ISC_FALSE));
+
+ return (ISC_R_SUCCESS);
+}
+
+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 */
projects / thirdparty / bind9.git / commitdiff
