draft-ietf-lamps-rfc6844bis-03.txt   draft-ietf-lamps-rfc6844bis-04.txt 
Network Working Group P. Hallam-Baker Network Working Group P. Hallam-Baker
Internet-Draft Comodo Group, Inc Internet-Draft Comodo Group, Inc
Obsoletes: 6844 (if approved) R. Stradling Obsoletes: 6844 (if approved) R. Stradling
Intended status: Standards Track Sectigo Intended status: Standards Track Sectigo
Expires: May 10, 2019 J. Hoffman-Andrews Expires: June 6, 2019 J. Hoffman-Andrews
Let's Encrypt Let's Encrypt
November 06, 2018 December 03, 2018
DNS Certification Authority Authorization (CAA) Resource Record DNS Certification Authority Authorization (CAA) Resource Record
draft-ietf-lamps-rfc6844bis-03 draft-ietf-lamps-rfc6844bis-04
Abstract Abstract
The Certification Authority Authorization (CAA) DNS Resource Record The Certification Authority Authorization (CAA) DNS Resource Record
allows a DNS domain name holder to specify one or more Certification allows a DNS domain name holder to specify one or more Certification
Authorities (CAs) authorized to issue certificates for that domain. Authorities (CAs) authorized to issue certificates for that domain.
CAA Resource Records allow a public Certification Authority to CAA Resource Records allow a public Certification Authority to
implement additional controls to reduce the risk of unintended implement additional controls to reduce the risk of unintended
certificate mis-issue. This document defines the syntax of the CAA certificate mis-issue. This document defines the syntax of the CAA
record and rules for processing CAA records by certificate issuers. record and rules for processing CAA records by certificate issuers.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 10, 2019. This Internet-Draft will expire on June 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. The CAA RR Type . . . . . . . . . . . . . . . . . . . . . . . 5 3. The CAA RR Type . . . . . . . . . . . . . . . . . . . . . . . 5
4. Certification Authority Processing . . . . . . . . . . . . . 7 4. Certification Authority Processing . . . . . . . . . . . . . 7
4.1. Use of DNS Security . . . . . . . . . . . . . . . . . . . 8 4.1. Use of DNS Security . . . . . . . . . . . . . . . . . . . 8
5. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Canonical Presentation Format . . . . . . . . . . . . 10 5.1.1. Canonical Presentation Format . . . . . . . . . . . . 10
5.2. CAA issue Property . . . . . . . . . . . . . . . . . . . 10 5.2. CAA issue Property . . . . . . . . . . . . . . . . . . . 11
5.3. CAA issuewild Property . . . . . . . . . . . . . . . . . 12 5.3. CAA issuewild Property . . . . . . . . . . . . . . . . . 12
5.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 12 5.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Non-Compliance by Certification Authority . . . . . . . . 13 6.1. Non-Compliance by Certification Authority . . . . . . . . 13
6.2. Mis-Issue by Authorized Certification Authority . . . . . 13 6.2. Mis-Issue by Authorized Certification Authority . . . . . 13
6.3. Suppression or Spoofing of CAA Records . . . . . . . . . 14 6.3. Suppression or Spoofing of CAA Records . . . . . . . . . 14
6.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 14 6.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 14
6.5. Abuse of the Critical Flag . . . . . . . . . . . . . . . 14 6.5. Abuse of the Critical Flag . . . . . . . . . . . . . . . 14
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 15
7.1. Blocked Queries or Responses . . . . . . . . . . . . . . 15 7.1. Blocked Queries or Responses . . . . . . . . . . . . . . 15
7.2. Rejected Queries and Malformed Responses . . . . . . . . 15 7.2. Rejected Queries and Malformed Responses . . . . . . . . 15
7.3. Delegation to Private Nameservers . . . . . . . . . . . . 15 7.3. Delegation to Private Nameservers . . . . . . . . . . . . 15
7.4. Bogus DNSSEC Responses . . . . . . . . . . . . . . . . . 15 7.4. Bogus DNSSEC Responses . . . . . . . . . . . . . . . . . 15
8. Differences versus RFC6844 . . . . . . . . . . . . . . . . . 16 8. Differences versus RFC6844 . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Certification Authority Restriction Flags . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Certification Authority Authorization (CAA) DNS Resource Record The Certification Authority Authorization (CAA) DNS Resource Record
allows a DNS domain name holder to specify the Certification allows a DNS domain name holder to specify the Certification
Authorities (CAs) authorized to issue certificates for that domain. Authorities (CAs) authorized to issue certificates for that domain.
Publication of CAA Resource Records allows a public Certification Publication of CAA Resource Records allows a public Certification
Authority to implement additional controls to reduce the risk of Authority to implement additional controls to reduce the risk of
unintended certificate mis-issue. unintended certificate mis-issue.
Like the TLSA record defined in DNS-Based Authentication of Named Like the TLSA record defined in DNS-Based Authentication of Named
Entities (DANE) [RFC6698], CAA records are used as a part of a Entities (DANE) [RFC6698], CAA records are used as a part of a
mechanism for checking PKIX certificate data. The distinction mechanism for checking PKIX certificate data. The distinction
between the two specifications is that CAA records specify an between the two specifications is that CAA records specify an
authorization control to be performed by a certificate issuer before authorization control to be performed by a certificate issuer before
issue of a certificate and TLSA records specify a verification issue of a certificate and TLSA records specify a verification
skipping to change at page 6, line 20 skipping to change at page 6, line 20
Certification Practices or Certificate Policy, or that a Certificate Certification Practices or Certificate Policy, or that a Certificate
Evaluator may use to report observation of a possible policy Evaluator may use to report observation of a possible policy
violation. The Incident Object Description Exchange Format (IODEF) violation. The Incident Object Description Exchange Format (IODEF)
format is used [RFC7970]. format is used [RFC7970].
The following example is a DNS zone file (see [RFC1035]) that informs 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 CAs that certificates are not to be issued except by the holder of
the domain name 'ca.example.net' or an authorized agent thereof. the domain name 'ca.example.net' or an authorized agent thereof.
This policy applies to all subordinate domains under example.com. This policy applies to all subordinate domains under example.com.
$ORIGIN example.com $ORIGIN example.com.
. CAA 0 issue "ca.example.net" CAA 0 issue "ca.example.net"
If the domain name holder specifies one or more iodef properties, a If the domain name holder specifies one or more iodef properties, a
certificate issuer MAY report invalid certificate requests to that certificate issuer MAY report invalid certificate requests to that
address. In the following example, the domain name holder specifies 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 that reports may be made by means of email with the IODEF data as an
attachment, a Web service [RFC6546], or both: attachment, a Web service [RFC6546], or both:
$ORIGIN example.com $ORIGIN example.com.
. CAA 0 issue "ca.example.net" CAA 0 issue "ca.example.net"
. CAA 0 iodef "mailto:security@example.com" CAA 0 iodef "mailto:security@example.com"
. CAA 0 iodef "http://iodef.example.com/" CAA 0 iodef "http://iodef.example.com/"
A certificate issuer MAY specify additional parameters that allow A certificate issuer MAY specify additional parameters that allow
customers to specify additional parameters governing certificate customers to specify additional parameters governing certificate
issuance. This might be the Certificate Policy under which the issuance. This might be the Certificate Policy under which the
certificate is to be issued, the authentication process to be used certificate is to be issued, the authentication process to be used
might be specified, or an account number specified by the CA to might be specified, or an account number specified by the CA to
enable these parameters to be retrieved. enable these parameters to be retrieved.
For example, the CA 'ca.example.net' has requested its customer For example, the CA 'ca.example.net' has requested its customer
'example.com' to specify the CA's account number '230123' in each of 'example.com' to specify the CA's account number '230123' in each of
the customer's CAA records. the customer's CAA records.
$ORIGIN example.com $ORIGIN example.com.
. CAA 0 issue "ca.example.net; account=230123" CAA 0 issue "ca.example.net; account=230123"
The syntax of additional parameters is a sequence of name-value pairs 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 as defined in Section 5.2. The semantics of such parameters is left
to site policy and is outside the scope of this document. to site policy and is outside the scope of this document.
The critical flag is intended to permit future versions of CAA to The critical flag is intended to permit future versions of CAA to
introduce new semantics that MUST be understood for correct introduce new semantics that MUST be understood for correct
processing of the record, preventing conforming CAs that do not processing of the record, preventing conforming CAs that do not
recognize the new semantics from issuing certificates for the recognize the new semantics from issuing certificates for the
indicated domains. indicated domains.
In the following example, the property 'tbs' is flagged as critical. In the following example, the property 'tbs' is flagged as critical.
Neither the example.net CA nor any other issuer is authorized to Neither the example.net CA nor any other issuer is authorized to
issue under either policy unless the processing rules for the 'tbs' issue under either policy unless the processing rules for the 'tbs'
property tag are understood. property tag are understood.
$ORIGIN example.com $ORIGIN example.com.
. CAA 0 issue "ca.example.net; policy=ev" CAA 0 issue "ca.example.net; policy=ev"
. CAA 128 tbs "Unknown" CAA 128 tbs "Unknown"
Note that the above restrictions only apply at certificate issue. Note that the above restrictions only apply at certificate issue.
Since the validity of an end entity certificate is typically a year 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 or more, it is quite possible that the CAA records published at a
domain will change between the time a certificate was issued and domain will change between the time a certificate was issued and
validation by a relying party. validation by a relying party.
4. Certification Authority Processing 4. Certification Authority Processing
Before issuing a certificate, a compliant CA MUST check for Before issuing a certificate, a compliant CA MUST check for
skipping to change at page 10, line 42 skipping to change at page 10, line 42
CAA <flags> <tag> <value> CAA <flags> <tag> <value>
Where: Where:
Flags: Is an unsigned integer between 0 and 255. Flags: Is an unsigned integer between 0 and 255.
Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower
case. case.
Value: Is the <character-string> encoding of the value field as Value: The value field, expressed as a contiguous set of characters
specified in [RFC1035], Section 5.1. without interior spaces, or as a quoted string. See the the
<character-string> format specified in [RFC1035], Section 5.1, but
note that the value field contains no length byte and is not limited
to 255 characters.
5.2. CAA issue Property 5.2. CAA issue Property
The issue property tag is used to request that certificate issuers The issue property tag is used to request that certificate issuers
perform CAA issue restriction processing for the domain and to grant perform CAA issue restriction processing for the domain and to grant
authorization to specific certificate issuers. authorization to specific certificate issuers.
The CAA issue property value has the following sub-syntax (specified The CAA issue property value has the following sub-syntax (specified
in ABNF as per [RFC5234]). in ABNF as per [RFC5234]).
skipping to change at page 16, line 40 skipping to change at page 16, line 46
This document clarifies the ABNF grammar for issue and issuewild tags This document clarifies the ABNF grammar for issue and issuewild tags
and resolves some inconsistencies with the document text. In and resolves some inconsistencies with the document text. In
particular, it specifies that parameters are separated with hyphens. particular, it specifies that parameters are separated with hyphens.
It also allows hyphens in property names. It also allows hyphens in property names.
This document also clarifies processing of a CAA RRset that is not This document also clarifies processing of a CAA RRset that is not
empty, but contains no issue or issuewild tags. empty, but contains no issue or issuewild tags.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. IANA is requested to add [[[ RFC Editor: Please replace with this RFC
]]] as a reference for the Certification Authority Restriction Flags
9.1. Certification Authority Restriction Flags and Certification Authority Restriction Properties registries.
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
[RFC8126], Section 4.1.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank the following people who contributed The authors would like to thank the following people who contributed
to the design and documentation of this work item: Chris Evans, to the design and documentation of this work item: Tim Hollebeek,
Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam Corey Bonnell, Chris Evans, Stephen Farrell, Jeff Hodges, Paul
Langley, Ben Laurie, James Manager, Chris Palmer, Scott Schmit, Sean Hoffman, Stephen Kent, Adam Langley, Ben Laurie, James Manager, Chris
Turner, and Ben Wilson. Palmer, Scott Schmit, Sean Turner, and Ben Wilson.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
skipping to change at page 18, line 41 skipping to change at page 18, line 26
[RFC6546] Trammell, B., "Transport of Real-time Inter-network [RFC6546] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", RFC 6546, Defense (RID) Messages over HTTP/TLS", RFC 6546,
DOI 10.17487/RFC6546, April 2012, DOI 10.17487/RFC6546, April 2012,
<https://www.rfc-editor.org/info/rfc6546>. <https://www.rfc-editor.org/info/rfc6546>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", RFC 6844,
DOI 10.17487/RFC6844, January 2013,
<https://www.rfc-editor.org/info/rfc6844>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange [RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970, Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <https://www.rfc-editor.org/info/rfc7970>. November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
11.2. Informative References 11.2. Informative References
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003, DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>. <https://www.rfc-editor.org/info/rfc3647>.
Authors' Addresses Authors' Addresses
 End of changes. 19 change blocks. 
55 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/