]> Comodo Group Inc.

philliph@comodo.com

Comodo CA Ltd.

rob.stradling@comodo.com

Google Inc.

benl@google.com

General Internet Engineering Task Force DNS DNSSEC PKIX The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) 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.

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 RFC 2119.

The following terms are used in this document: A notation for describing abstract types and values, as specified in X.680. An authorization assertion that grants or denies a specific set of permissions to a specific group of entities. A Domain Name that is not an alias. The value of a Canonical Domain Name. The value resulting from applying alias transformations to a Domain Name that is not canonical. An X.509 Certificate, as specified in RFC 5280. Specifies the criteria that a Certification Authority undertakes to meet in its issue of certificates. Specifies the means by which the criteria of the Certification Policy are met. In most cases this will be the document against which the operations of the Certification Authority are audited. An entity that issues Certificates in accordance with a specified Certification Policy. A set of rules for encoding ASN.1 objects, as specified in X.690. The set of resources associated with a DNS Domain Name. A DNS Domain name as specified in RFC 1035 and revisions. The Internet naming system specified in RFC 1035 and revisions. Extensions to the DNS that provide authentication services as specified in RFC 4033 and revisions. The most specific Issuer Authorization Set that is active for a domain. This is either the Issuer Authorization Set for the domain itself, or if that is empty, the Issuer Authorization Set for the corresponding Public Delegation Point. The set of Authorization Entries for a domain name that are flagged for use by Issuers. Analogous to an Access Control List but with no ordering specified. A Domain Name that is obtained from a public DNS registry as defined by a Certification Policy. Standards and specifications issued by the IETF that apply the X.509 certificate standards specified by the ITU to Internet applications as specified in RFC 5280 and related documents. A set of attributes bound to a Domain Name. A party that makes use of an application whose operation depends on use of a Certificate for making a security decision. An application whose operation depends on use of a Certificate for making a security decision. The set of Authorization Entries for a domain name that are flagged for use by Relying Party Applications. Analogous to an Access Control List but with no ordering specified.

The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities authorized to issue certificates for that domain. Publication of CAA resource records allow a public Certification Authority (CA) to implement additional controls to reduce the risk of unintended certificate mis-issue. Conformance with a published CAA record is a necessary but not sufficient condition for issue 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 Statement. In the case of a public CA that validates certificate requests as a third party, the certificate will be typically issued under a public root certificate embedded in one or more relevant reliant applications. Criteria for inclusion of embedded root certificates in applications are outside the scope of this document but typically require the CA to publish a Certificate Practices Statement (CPS) that specifies how the requirements of the Certificate Policy (CP) are achieved and provide an annual audit statement of their performance against their CPS performed by an independent third party auditor. It is the intention of the authors to propose the CAA record defined in this document as the basis for CA validation requirements to be proposed in organizations that publish validation requirements. CAA records only describe the current state of Certification Authority certificate issue authority. 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 it was issued. Thus Relying Applications MUST NOT use failure to conform to currently published CAA records as a rejection criteria for certificates unless the published records are flagged as being intended for that use.

A CAA RR (257) publishes a CAA property entry that corresponds to the specified domain name. Multiple property entries MAY be associated with the same domain name by publiching multiple CAA RRs at that domain name. Each property entry MAY be tagged with one or more of the following flag values: If set, indicates that the corresponding property entry tag MUST be understood if the semantics of the CAA record are to be correctly understood by the specified audience. Issuers MUST NOT issue certificates for a domain if the Extended Issuer Authorization Set contains unknown property entry tags that are flagged as critical. Relying Parties MUST NOT attempt to enforce CAA records if the Relying Party Authorization Set contains unknown property entry tags that are flagged as critical This bit is reserved for future use. Issuers MUST NOT issue certificates for a domain if the Extended Issuer Authorization Set contains property entries with the Must Be Zero Tag Set. Relying Parties MUST NOT attempt to enforce CAA records if the Relying Party Authorization Set contains property entries with the Must Be Zero Tag Set. Specifies that the corresponding Property Entry is to be used by Relying Party Applications and forms part of the Relying Party Authorization Set for the domain. Specifies that the corresponding Property Entry is to be used by Issuers and forms part of the Issuer Authorization Set for the domain. The following properties are defined: The policy property entry declares an authorization entry granting authorization to issue under the specified Certificate Policy. The path property entry declares an authorization entry granting authorization to issue end entity certificates under a trust path that includes the specified signing credential. An Object Digest Identifier (ODI) is a means of specifying a reference to an object instance by means of a cryptographic digest function. A CAA path property may use an ODI to specify a certificate trust path by means of: In either case a path Authorization Entry authorizes an issuer to issue an End Entity certificate to the corresponding domain if and only if it is possible to form a valid certificate path to it from the referenced certificate or key.

For convenience the examples are presented in the text format suggested in section The following example informs CAs that certificates must not be issued except under the Default Deny Security 'Example 1' Certificate Policy (1.3.6.1.4.1.35405.666.1). Since the policy is published at the Public Delegation Point, the policy applies to all subordinate domains under example.com.

The following example informs CAs that certificates must not be issued except under the Certificate Authority Root certificate specified in Appendix B.

A domain MAY authorize multiple CAs to issue certificates at the same time. The following example allows issue under the Default Deny Security certification policy 'Example 1' or 'Example 2':

If Authorization Entries using the path and policy properties are present at a given Domain, compatibility with either is sufficient to authorize the request. Future versions of this specification MAY use the critical flag to introduce new semantics that MUST be understood for correct processing of the record, preventing Certification Authorities that do not recognize the record from issuing certificates. In the following example, the property 'tbs' is flagged as critical. The Default Deny Security CA is not authorized to issue under either policy unless the processing rules for the 'tbs' property tag are understood.

Enforcement by Relying Party Applications follows the same general principles. A Relying Party Application MUST NOT enforce CAA records unless at least one Property Entry has the Relying Party flag set, that is the Relyin Party Authorization Set is not empty. In the following example, certificates must not be issued except under the Default Deny Security 'Example 1' Certificate Policy and Relying Party Applications MAY reject certificates presented that do not comply with this requirement:

In the ordinary course of business a Domain administrator may withdraw authorization for issue of new certificates before the previously issued certificates expire. In the following example, Relying Party Applications are informed that certificates issued under either the policy are to be considered to be authorized but new certificates can only be issued under the first.

Before issue of a certificate a compliant CA MUST check for publication of a relevant CAA Resource Record(s) and if such record(s) are published, that the certificate requested is consistent with them. If the certificate requested is not consistent with the relevant CAA RRs, the CA MUST NOT issue the certificate. The Issuer Authorization Set for a domain name consists of the set of all CAA Authorization Entries declared for the canonical form of the specified domain. The Extended Issuer Authorization Set for a domain name consists of the Issuer Authorization Set for that domain name if it is non-empty. Otherwise the Extended Issuer Authorization Set for a domain name consists of the Issuer Authorization Set for the corresponding Public Delegation Point for that domain name. If the Extended Issuer Authorization Set for a domain name is not empty, a Certification Authority MUST NOT issue a certificate unless it conforms to at least one authorization entry in the Extended Issuer Authorization Set. Note that while it MUST be possible to form a certificate validation path that contains at least one certificate that is so specified, it MAY also be possible to form valid certificate paths that are not. For example, a CA that has updated its root certificate to extend the expiry date is entitled to issue certificates for domains where the CAA record only specifies the older root certificate provided that the older root certificate has not actually expired and it is thus possible to form a valid certificate path.

The DNS defines the CNAME and DNAME mechanisms for specifying domain name aliases. The canonical name of a DNS name is the name that results from performing all DNS alias operations. A Certification Authority MUST perform CNAME and DNAME processing as defined in the DNS specifications 1035.

Use of DNSSEC to authenticate CAA RRs is strongly recommended but not required. A CA MUST NOT issue certificates if doing so would conflict with the corresponding extended issuer authorization set whether the corresponding DNS records are signed or not. Use of DNSSEC allows a CA to acquire and archive a non-repudiable proof that they were authorized to issue certificates for the domain.

A compliant CA SHOULD maintain an archive of the DNS transactions used to verify CAA eligibility. In particular a CA SHOULD ensure that where DNSSEC data is available that the corresponding signature and NSEC/NSEC3 records are preserved so as to enable later compliance audits.

Relying Party Applications MAY enforce CAA issue restrictions at their option, provided that the Relying Party Authorization set is not empty. The consequences of determining that a certificate is not compatible with the specified CAA relying party restrictions are outside the scope of this document. Domains that opt to flag records for use by Relying Party Applications SHOULD be aware that the Property Entries supported in this version of the specification are only designed to support the requirements of enforcing issuer restrictions. While these Property Entries MAY be sufficient to enable enforcement by Relying Party Applications in some circumstances, they are not intended to provide complete requirements coverage for this purpose. Domains containing CAA issue restrictions intended for use by Relying Party Applications SHOULD be authenticated using DNSSEC or other equivalent means. If DNSSEC is deployed in a domain Relying Party Applications MUST treat failure to authenticate signatures of CAA records or absence of CAA records whose presence is indicated as being equivalent to an inconsistent CAA record.

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:

Where n is the length specified in the tag length field and m is the remaining octets in the data field (m = d - n - 2) where d is the length of the data section. The data fields are defined as follows: One octet containing the following fields: If the value is set (1), the critical flag is asserted and the property MUST be understood if the CAA record is to be correctly processed. A Certification Authority MUST NOT issue certificates for any Domain that contains a CAA critical property for an unknown or unsupported property type. Bit 5 is reserved and MUST be set to zero. Processors that encounter a CAA record containing a property with this bit set MUST treat the record set as if the critical property was asserted for an unknown record. If set, the property entry contains an Authorization Entry that forms part of the Relying Application Authorization Set for the corresponding domain. If set, the property entry contains an Authorization Entry that forms part of the Issuer Application Authorization Set for the corresponding domain. Note that according to the conventions set out in RFC 1035 Bit 0 is the Most Significant Bit and Bit 7 is the Least Significant. Thus a flags value of 0x51 indicates a tag length of 5 octets and that the property entry is not critical and is not to be used for relying party processing. 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. The property identifier, a sequence of ASCII characters. Tag values MAY contain ASCII characters a through z and the numbers 0 through 9. Tag values MUST NOT contain any other characters. Matching of tag values is case insensitive. 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.

The canonical presentation format of the CAA record is as follows: CAA <flags> <tag> <data> Where: Is an unsigned integer between 0 and 15. Is a non-zero sequence of ASCII letter and numbers in lower case. Is the Base64 Encoding of the value field.

For convenience of administration, implementations MAY support ASN.1 Policy OID encoding at their option. The Base64 encoding of data never contains the period character '.', while the encoding of ASN.1 OID values specified in IETF GSER encoding will always incorporate at least one period character. It follows that a data decoder MAY unambiguously interpret data specified in the Base64 or GSER format without the need for additional disambiguation. Implementations MAY choose to allow use of both formats in both file and presentation formats.

The policy property value specifies an Authorization Entry by means of an ASN.1 OID specifying a Certification Policy. A Certification Authority is authorized to issue Certificates under a policy Authorization Entry if and only if The Certification Authority has the right to issue certificates under the specified policy, AND The certificate request is compliant with the requirements of the specified policy, AND The certificate request meets all the criteria under the Certification Policy under which the certificate is to be issued. Each policy property specifies a single ASN.1 OID value consisting of the ASN.1 type, length specifier and OID data. The policy property applies to the specified policy OID and all policy OIDs that fall within the same OID arc. If the OID arc 1.3.6.1.4.1.35405.666 is specified, then the policy OIDs 1.3.6.1.4.1.35405.666, 1.3.6.1.4.1.35405.666.1, 1.3.6.1.4.1.35405.666.2 etc. are all authorized. The Certificate that is issued MAY incorporate the specified policy OID itself but is not required to provided that the issue of the certificate is consistent with the requirements of the specified policy. For example, a CA that offers two levels of Certification Policy such that the higher level of assurance included all the requirements of the lower one MAY rely on a policy property specifying the lower assurance policy as authorization for issue under the higher assurance policy but not vice-versa.

The path property value specifies an Authorization Entry by means of a Certificate Signer Certificate or a Certificate Signing key. A Certification Authority is authorized to issue Certificates under a path Authorization Entry if and only if A valid PKIX trust path can be formed from the specified Certificate Signer Certificate or a Certificate Signing key to the certificate that is to be issued, AND The certificate request meets all the criteria under the Certification Policy under which the certificate is to be issued.

CAA Records provide an accountability control. They are intended to deter rather than prevent undesired behavior. While a Certification Authority can choose to ignore published CAA records, doing so increases the both the probability that they will mis-issue a certificate and the consequences of doing so. Once it is known that a CA observes CAA records, malicious registration requests will target disproportionately target the negligent CAs that do not, and so the mis-issue rate amongst the negligent CAs will increase. Since the CA could clearly have avoided the mis-issue by performing CAA processing, the likelihood of sanctions against the negligent CA is increased. Failure to observe CAA issue restrictions provides an objective criteria for excluding issuers from embedded roots of trust. In contrast, a Certification Authority that processes CAA records correctly can reasonably claim that any residual mis-issue event could have been avoided had the Domain Name holder published appropriate CAA records.

Use of CAA records does not provide protection against mis-issue by an authorized Certification Authority. Domain name holders SHOULD ensure that the CAs they authorize to issue certificates for their domains employ appropriate controls to ensure that certificates are only issued 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.

Suppression of the CAA record or insertion of a bogus CAA record could enable an attacker to obtain a certificate from a CA that was not authorized to issue for that domain name.

Applications performing CAA checking SHOULD mitigate the risk of suppresion or spoofing of CAA records by means of DNSSEC validation where present. In cases where DNSSEC validation is not available, CAA checking is of limited security value.

Since a certificate issued by a CA can be valid for several years, the consequences of a spoofing or suppression attack are much greater for Certification Authorities and so additional countermeasures are justified. A CA MUST mitigate this risk by employing DNSSEC verification whenever possible and rejecting certificate requests in any case where it is not possible to verify the non-existence or contents of a relevant CAA record. In cases where DNSSEC is not deployed in a corresponding domain, a CA SHOULD attempt to mitigate this risk by employing appropriate DNS security controls. For example all portions of the DNS lookup process SHOULD be performed against the authoritative name server. Cached data MUST NOT be relied on but MAY be used to support additional anti-spoofing or anti-suppression controls.

Introduction of a malformed or malicious CAA RR could in theory enable a Denial of Service attack. This specific threat is not considered to add significantly to the risk of running an insecure DNS service.

A Certification Authority could make use of the critical flag to trick customers into publishing records which 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 is going to investigate the cause and report the reason to the customer who was deceived. It is thus unlikely that the attack would succeed and the attempt might lay the perpetrator open to civil or criminal sanctions.

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 RFC 5395 [RFC5395] and located at http://www.iana.org/assignments/dns-parameters.

IANA has created the Certification Authority Authorization Properties registry with the following initial values:

Addition of tag identifiers requires a public specification and expert review as set out in RFC5395

&RFC1035; &RFC2119; &RFC4033; &RFC4055; &RFC5280; &RFC5395; International Telecommunication Union International Telecommunication Union International Telecommunication Union &RFC3642; &RFC4648; National Institute of Standards and Technology

An Object Digest is an ASN.1 structure with three components: An ASN.1 Object Identifier specifying the object type of the referenced object An ASN.1 Object Identifier specifying the digest algorithm An ASN.1 DER encoded data field containing the digest value of the referenced object processed using the specified digest algorithm.

The Object Digest Identifier construction is designed to facilitate implementation in applications that already require ASN.1 handling mechanisms (i.e. most cryptographic applications) without causing an undue coding burden in cases where ASN.1 code is not already supported. Appendix C provides all the necessary information to create a fully compliant Object Digest Identifier implementation.

The ODI of CA Certificate A (specified in Appendix B.1) is calculated as follows: ASN.1 Sequence tag: 3032 ASN.1 OID id-at-cACertificate (2.5.4.37): 0603550425 ASN.1 OID sha256 (2.16.840.1.101.3.4.2.1): 0609608648016503040201 SHA-256 Digest Value: 042017cc980f6a84fb15e5da3f32afea62360f4ca29627feed68739a13062defe804 The ODI in BASE64 format is MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaPzKv6mI2D0yilif+7WhzmhMGLe/oBA==.

The ODI of the signing key of CA Certificate A (specified in Appendix B.1) is calculated as follows: ASN.1 Sequence tag ASN.1 OID 'CA Signing Key' ASN.1 OID 'SHA-256' SHA-256 Digest Value

The following certificates are used in the examples.

CA Certificate A is a self signed certificate signed with a 2048 bit RSA key:

In binary form, the certificate data is:

The SHA-256 digest of the certificate data is:

Although the Object Digest Identifier form employs ASN.1 DER encoding only a small subset of ASN.1 features are used and a full ASN.1 stack is not necessary. This appendix provides sufficient information to implement an Object Digest Identifier constructor or parser.

In DER encoding, the enclosing SEQUENCE will always be represented by the type identifier x30 followed by the length specifier. Since the total length of the following data fields will almost certainly be less than 127 bytes, the single byte encoding mechanism in which bit 7 is clear and the length value is encoded in the lower 7 bits will be required.

OIDs have been defined in connection with the X.500 directory for user certificates, certification authority certificates, revocations of certification authority, and revocations of user certificates. The following table lists the OIDs, their DER encoding, and their type identifier and length-prefixed hex format for use in Object Digest Identifiers.

OIDs have been assigned by NIST for the SHA-2 digest algorithms Use of the SHA-1 digest algorithm is not recommended due to concerns for the security of the algorithm.

The rules of ASN.1 encoding state that every data value is preceded by a data type identifier and a length identifier. In the case of an Object Digest Identifier the data type identifier is always OCTET STRING (04) and the length for all currently defined digest algorithms will be less than 128 bytes (1024 bits) and thus use the single byte encoding form in which bit 7 is set to 0 and the lower 7 bits specify the length. The length prefixes for commonly used digest lengths in hexadecimal notation are thus: 04 14 04 1C 04 20 04 30 04 40