Internet Engineering Task Force P. Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended status: Experimental R. Stradling
Expires: April 21, 2011 Comodo CA, Ltd.
October 18, 2010
DNS Certification Authority Authorization (CAA) Resource Record
draft-hallambaker-donotissue-00
Abstract
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.
Status of this Memo
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 Notice
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
Hallam-Baker & Stradling Expires April 21, 2011 [Page 1]
Internet-Draft Certification Authority Authorization October 2010
(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.
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. The CAA RR type . . . . . . . . . . . . . . . . . . . . . 3
2.2. Certification Authority Processing . . . . . . . . . . . . 4
2.2.1. Corresponding Domain Name . . . . . . . . . . . . . . 5
2.2.2. Archive . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Application Processing . . . . . . . . . . . . . . . . . . 5
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. dauth Property value . . . . . . . . . . . . . . . . . 7
3.1.1.1. Object Digest Identifier Calculation . . . . . . . 7
3.1.2. pauth Property value . . . . . . . . . . . . . . . . . 8
3.1.3. app Property value . . . . . . . . . . . . . . . . . . 8
3.2. Use of DNS Security . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Mis-Issue by Authorized Certification Authority . . . . . 8
4.2. Suppression or spoofing of CAA records . . . . . . . . . . 9
4.2.1. Applications . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Certification Authorities . . . . . . . . . . . . . . 9
4.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. Registration of the CAA Resource Record Type . . . . . . . 9
5.2. Certification Authority Authorization Properties . . . . . 10
5.3. Certification Authority Authorization Application
Properties . . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Non Normative References . . . . . . . . . . . . . . . . . 11
Appendix A. ASN.1 Values (Non-Normative) . . . . . . . . . . . . 11
A.1. Object Identifiers for Certificate Types . . . . . . . . . 11
A.2. Object Identifiers for Digest Algorithms . . . . . . . . . 11
A.3. DER Data Encoding Prefixes . . . . . . . . . . . . . . . . 12
A.3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 12
A.3.1.1. SHA2-256 Bit . . . . . . . . . . . . . . . . . . . 13
A.3.1.2. SHA2-512 Bit . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Hallam-Baker & Stradling Expires April 21, 2011 [Page 2]
Internet-Draft Certification Authority Authorization October 2010
1. Definitions
1.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 RFC 2119 [RFC2119].
2. Requirements
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.
2.1. The CAA RR type
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
Hallam-Baker & Stradling Expires April 21, 2011 [Page 3]
Internet-Draft Certification Authority Authorization October 2010
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.
2.2. Certification Authority Processing
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:
Hallam-Baker & Stradling Expires April 21, 2011 [Page 4]
Internet-Draft Certification Authority Authorization October 2010
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.
2.2.1. Corresponding Domain Name
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.
2.2.2. Archive
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.
2.3. Application Processing
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.
Hallam-Baker & Stradling Expires April 21, 2011 [Page 5]
Internet-Draft Certification Authority Authorization October 2010
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.
3. Mechanism
3.1. Syntax
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
Hallam-Baker & Stradling Expires April 21, 2011 [Page 6]
Internet-Draft Certification Authority Authorization October 2010
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...
3.1.1. dauth Property value
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.
3.1.1.1. Object Digest Identifier Calculation
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.
Hallam-Baker & Stradling Expires April 21, 2011 [Page 7]
Internet-Draft Certification Authority Authorization October 2010
3.1.2. pauth Property value
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.
3.1.3. app Property value
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.
3.2. Use of DNS Security
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
4. Security Considerations
4.1. Mis-Issue by Authorized Certification Authority
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.
Hallam-Baker & Stradling Expires April 21, 2011 [Page 8]
Internet-Draft Certification Authority Authorization October 2010
4.2. 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 a CA that was
not authorized to issue for that domain name.
4.2.1. Applications
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.
4.2.2. Certification Authorities
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.
4.3. Denial of Service
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.
5. IANA Considerations
5.1. Registration of the CAA Resource Record Type
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
Hallam-Baker & Stradling Expires April 21, 2011 [Page 9]
Internet-Draft Certification Authority Authorization October 2010
[RFC5395] and located at
http://www.iana.org/assignments/dns-parameters.
< Value and meaning Reference
----------- --------------------------------------------- ---------
CAA TBD1 Certification Authority Restriction [RFCXXXX]
5.2. Certification Authority Authorization Properties
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.
5.3. Certification Authority Authorization Application Properties
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.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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,
Hallam-Baker & Stradling Expires April 21, 2011 [Page 10]
Internet-Draft Certification Authority Authorization October 2010
June 2005.
6.2. Non Normative References
[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.
Appendix A. ASN.1 Values (Non-Normative)
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
A.1. Object Identifiers for Certificate Types
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
A.2. Object Identifiers for Digest Algorithms
OIDS have been assigned by NIST for the SHA2 digest algorithms
[NIST-ALGS] [RFC4055] 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)
Hallam-Baker & Stradling Expires April 21, 2011 [Page 11]
Internet-Draft Certification Authority Authorization October 2010
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
A.3. DER Data Encoding Prefixes
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
A.3.1. Examples
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 }
Hallam-Baker & Stradling Expires April 21, 2011 [Page 12]
Internet-Draft Certification Authority Authorization October 2010
A.3.1.1. SHA2-256 Bit
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=
A.3.1.2. SHA2-512 Bit
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==
Authors' Addresses
Phillip Hallam-Baker
Comodo Group Inc.
Email: philliph@comodo.com
Hallam-Baker & Stradling Expires April 21, 2011 [Page 13]
Internet-Draft Certification Authority Authorization October 2010
Rob Stradling
Comodo CA, Ltd.
Email: rob.stradling@comodo.com
Hallam-Baker & Stradling Expires April 21, 2011 [Page 14]