| TOC |
|
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. In additon, the CAA mechanism may be extended in future revisions to allow for use client enforcement of issuing restrictions.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on April 21, 2011.
Copyright (c) 2010 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.
1.
Definitions
1.1.
Requirements Language
2.
Requirements
2.1.
The CAA RR type
2.2.
Certification Authority Processing
2.2.1.
Corresponding Domain Name
2.2.2.
Archive
2.3.
Application Processing
3.
Mechanism
3.1.
Syntax
3.1.1.
dauth Property value
3.1.1.1.
Object Digest Identifier Calculation
3.1.2.
pauth Property value
3.1.3.
app Property value
3.2.
Use of DNS Security
4.
Security Considerations
4.1.
Mis-Issue by Authorized Certification Authority
4.2.
Suppression or spoofing of CAA records
4.2.1.
Applications
4.2.2.
Certification Authorities
4.3.
Denial of Service
5.
IANA Considerations
5.1.
Registration of the CAA Resource Record Type
5.2.
Certification Authority Authorization Properties
5.3.
Certification Authority Authorization Application Properties
6.
References
6.1.
Normative References
6.2.
Non Normative References
Appendix A.
ASN.1 Values (Non-Normative)
A.1.
Object Identifiers for Certificate Types
A.2.
Object Identifiers for Digest Algorithms
A.3.
DER Data Encoding Prefixes
A.3.1.
Examples
A.3.1.1.
SHA2-256 Bit
A.3.1.2.
SHA2-512 Bit
§
Authors' Addresses
| TOC |
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
| TOC |
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 (CA) to implement additional controls to reduce the risk of unintended certificate mis-issue.
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 such as the CA-Browser forum.
| TOC |
A CAA RR consists of a sequence of properties. The following properties are defined:
- dauth
- Identifies authorized issuers or end entity certificates by means of an Object Digest Identifier
- An issuer is identified by means of an Object Digest Identifier that corresponds to a certificate signing certificate under which the issuer is authorized to issue certificates. An end entity certificate is identified by the digest of the certificate itself.
- pauth
- Identifies authorized issuers or end entity certificates by means of a PKIX certificate policy OID.
- A pauth property states that an issuer is authorized to issue certificates for the corresponding domain that contain a policy OID within the specified polic arc, provided that this is consitent with both the CPS of the issuer and the requirements of the specified policy.
- app
- Is used to inform clients that they MAY or MUST NOT use information in the CAA record to enforce CA issuing restrictions at the application level.
Authorization to act as an issuer for a domain does not entail authorization to issue a certificate in response to a specific request. An authorized issuer MUST comply with the requirements of its Certificate Policy and Certificate Practices Statement regardless of whether a CAA record is specified in a corresponding DNS domain or not.
The authorizations specified in the dauth and pauth properties are additive. If multiple authorization properties are specified it is sufficient for a single authorization property to match. If no authorization property grants an issuer authorization, an issuer is not authorized and MUST NOT issue a certificate for that domain.
For efficiency, certificates are identified in the dauth property by means of an Object Digest Identifier, a triple consisting of an ASN.1 object identifier specifying the type of the referenced object, an ASN.1 object identifier specifying a digest algorithm and the digest value obtained by applying the specified digest algorithm to the referenced object.
| TOC |
Before issue of a certificate a compliant CA MUST check for publication of a relevant CAA Resource Record and if a record is published that the certificate requested is consistent with it. If the certificate requested is not consistent with the CAA RR authorization, the CA MUST NOT issue the certificate.
A certificate request is consistent with a relevant CAA Resource Record if and only if a valid certificate chain can be formed that:
Includes the certificate to be issued as an end entity certificate.
Contains at least one certificate specified as the object digest identifier value in an auth property.
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.
| TOC |
A CA MUST observe constraints published in a CAA record corresponding to any domain name specified as a subject name or subjectAltName in the requested certificate.
A CA MUST observe constraints published in any CAA record that corresponds to a public DNS domain name issuing point for any domain name superior in the DNS hierarchy to any domain name specified as a subject name or subjectAltName in the requested certificate.
For example, if a certificate is for an SSL server for the domain name www.example.com the CA MUST observe the constraints of any CAA record published at www.example.com and observe the constraints of any CAA record published at example.com.
| TOC |
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.
| TOC |
While it is in theory possible to apply information contained in a CAA record to enforce certificate issue constraints at the application level, support for such processing is not a design goal for this version of the specification.
The information provided in the CAA record MAY be used for application level enforcement of the CA authorization restrictions if the CAA RR property app=true is specified.
An application MUST NOT use the information specified in a CAA RR if the app property is not specified or has the value false. Use of app property values other than true or false is not defined.
Application level enforcement of CAA restrictions faces the practical difficulty that different clients frequently use different trust chains to verify the same certificate chain.
For example, a CA root embedded in 1995 might be replaced by a 'roll-over' certificate for the same subject and public key and a later expiry date in 2000, 2005 and 2010.
While tracking such details is a requirement for a well run CA, a certificate subject rarely knows if or when a public CA root their certificate is issued under has been rolled over and has no means of predicting when it might be rolled over in the future.
| TOC |
| TOC |
A CAA RR contains a sequence of tag value pairs. 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 each CAA RR MAY have multiple properties and a given property MAY be specified more than once.
This version of the specification makes no distinction as to whether properties are expressed as one record or many, nor are the properties defined sensitive with respect to order.
The CAA data field consists of a sequence of at least one property entry. Each property entry consists of a sequence of:
- Tag Length
- One octet containing an unsigned integer specifying the tag length in octets. The tag length MUST be 15 octets or less.
- Tag
- The property identifier, a sequence of lower case ascii characters
- Value Length
- Two octets containing an unsigned integer in network byte order specifying the length of the value field in octets.
- Value
- A sequence of octets representing the property value. Property values are encoded as binary values and MAY employ sub-formats.
It is suggested that CAA records be represented in DNS configuration files (somehow).
Implementations MUST allow CAA records to specify unknown tag values provided that they meet the tag length criteria. In such cases implementations MUST allow tag values to be specified as Base64 representations of binary strings and SHOULD allow tag values to be encoded as ASCII strings.
Examples...
| TOC |
Each dauth property specifies a single Object Digest Identifier value. If dauth properties are to be declared for multiple certificates, a separate dauth property is required for each one.
| TOC |
An Object Digest is a binary 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.
Examples...
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 A provides all the necessary information to create a fully compliant Object Digest Identifier implementation.
| TOC |
Each pauth property specifies a single ASN.1 OID value consisting of the ASN.1 type, length specifier and OID data.
The pauth property applies to the specified policy OID and all policy OIDs that fall within the same OID arc. If the OID arc 1.2.3 is specified, then the policy OIDs 1.2.3, 1.2.3.1, 1.2.3.1.2 etc. are all authorized.
| TOC |
Tha app property is a case insensitive ASCII string. Currently defined values are:
- true
- Applications MAY use the pauth and dauth properties to enforce issuer authorization restrictions as certificate validity restrictions.
- false (default)
- Applications MUST NOT use the data specified in the CAA record to enforce issuer authorization restrictions as certificate validity restrictions.
| TOC |
Use of DNSSEC to authenticate CAA RRs is strongly recommended but not required. A CA MUST observe a CAA RR that is returned whether it is signed using DNSSEC 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
| TOC |
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
| TOC |
IANA has assigned Resource Record Type TBD1 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.
< Value and meaning Reference ----------- --------------------------------------------- --------- CAA TBD1 Certification Authority Restriction [RFCXXXX]
| TOC |
IANA has created the Certification Authority Authorization Properties registry with the following initial values:
<
Meaning Reference
----------- ----------------------------------------------- ---------
dauth Object digest of authorized signing certificate [RFCXXXX]
pauth Object Identifier of authorized policy [RFCXXXX]
app Application Processing Flag [RFCXXXX]
Addition of tag identifiers requires a public specification and expert review.
| TOC |
IANA has created the Certification Authority Authorization Application Properties registry with the following initial values:
<
Meaning Reference
----------- ----------------------------------------------- ---------
true Applications MAY process pauth and dauth data [RFCXXXX]
false Applications MUST NOT process CAA records [RFCXXXX]
Addition of tag identifiers requires a public specification and expert review.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC4055] | Schaad, J., Kaliski, B., and R. Housley, “Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 4055, June 2005 (TXT). |
| TOC |
| [NIST-ALGS] | National Institute of Standards and Technology, “Cryptographic Algorithm Registration,” March 2009. |
| [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 (TXT). |
| TOC |
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 for the common
| TOC |
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 BER encoding, and their type identifier and length-prefixed hex format for use in Object Digest Identifiers.
== 06 03 55 04 24
== 06 03 55 04 25
| TOC |
OIDS have been assigned by NIST for the SHA2 digest algorithms [NIST‑ALGS] (National Institute of Standards and Technology, “Cryptographic Algorithm Registration,” March 2009.) [RFC4055] (Schaad, J., Kaliski, B., and R. Housley, “Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” June 2005.) Use of the SHA1 digest algorithm is not recommended due to concerns for the security of the algorithm.
The OID arc in each case is hashAlgs OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs (2)}
== 06 09 60 86 48 01 65 03 04 02 01
== 06 09 60 86 48 01 65 03 04 02 02
== 06 09 60 86 48 01 65 03 04 02 03
== 06 09 60 86 48 01 65 03 04 02 04
| TOC |
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:
- 160 bits
- 04 14
- 224 bits
- 04 1C
- 256 bits
- 04 20
- 384 bits
- 04 30
- 512 bits
- 04 40
| TOC |
The following examples demonstrate the formation of Object Digest Identifiers for the string 'test' using the ASN.1 OID value id-at-description = { joint-iso-ccitt(2) ds(5) at(4) 13 }
| TOC |
The SHA2-256 digest value is 9F 86... 08
The OID data in hexadecimal notation is:
06 03 55 04 0D
06 09 60 86 48 01 65 03 04 02 01
04 20 9F 86 D0 81 88 4C 7D 65 9A 2F EA A0 C5 5A D0 15 A3 BF 4F 1B 2B 0B 82 2C D1 5D 6C 15 B0 F0 0A 08
The Base64 encoded digest value is:
BgNVBA0GCWCGSAFlAwQCAQMgn4bQgYhMfWWaL+qgxVrQFaO /TxsrC4Is0V1sFbDwCgg=
| TOC |
The SHA2-256 digest value is EE 26 ... FF
The OID data in hexadecimal notation is:
06 03 55 04 0D
06 09 60 86 48 01 65 03 04 02 03
04 40 EE 26 B0 DD 4A F7 E7 49 AA 1A 8E E3 C1 0A E9 92 3F 61 89 80 77 2E 47 3F 88 19 A5 D4 94 0E 0D B2 7A C1 85 F8 A0 E1 D5 F8 4F 88 BC 88 7F D6 7B 14 37 32 C3 04 CC 5F A9 AD 8E 6F 57 F5 00 28 A8 FF
The Base64 encoded digest value is:
BgNVBA0GCWCGSAFlAwQCAwNA7iaw3Ur350mqGo7jwQrpkj9 hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUNzLDBM xfqa2Ob1f1ACio/w==
| TOC |
| Phillip Hallam-Baker | |
| Comodo Group Inc. | |
| Email: | philliph@comodo.com |
| Rob Stradling | |
| Comodo CA, Ltd. | |
| Email: | rob.stradling@comodo.com |