draft-ietf-lamps-rfc6844bis-01.txt   draft-ietf-lamps-rfc6844bis-02.txt 
Network Working Group P. Hallam-Baker Network Working Group P. Hallam-Baker
Internet-Draft R. Stradling Internet-Draft R. Stradling
Obsoletes: RFC 6844 (if approved) Comodo Group, Inc Obsoletes: 6844 (if approved) Comodo Group, Inc
Intended status: Standards Track J. Hoffman-Andrews Intended status: Standards Track J. Hoffman-Andrews
Expires: April 13, 2019 Let's Encrypt Expires: May 8, 2019 Let's Encrypt
October 10, 2018 November 04, 2018
DNS Certification Authority Authorization (CAA) Resource Record DNS Certification Authority Authorization (CAA) Resource Record
draft-ietf-lamps-rfc6844bis-01 draft-ietf-lamps-rfc6844bis-02
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.
This document obsoletes RFC 6844.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 13, 2019. This Internet-Draft will expire on May 8, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . 10
5.3. CAA issuewild Property . . . . . . . . . . . . . . . . . 12 5.3. CAA issuewild Property . . . . . . . . . . . . . . . . . 12
5.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 12 5.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 2, line 39 skipping to change at page 2, line 41
6.5. Abuse of the Critical Flag . . . . . . . . . . . . . . . 14 6.5. Abuse of the Critical Flag . . . . . . . . . . . . . . . 14
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 14
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 9.1. Certification Authority Restriction Flags . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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.
skipping to change at page 3, line 24 skipping to change at page 3, line 26
Conformance with a published CAA record is a necessary but not Conformance with a published CAA record is a necessary but not
sufficient condition for issuance of a certificate. Before issuing a sufficient condition for issuance of a certificate. Before issuing a
certificate, a PKIX CA is required to validate the request according certificate, a PKIX CA is required to validate the request according
to the policies set out in its Certificate Policy. In the case of a to the policies set out in its Certificate Policy. In the case of a
public CA that validates certificate requests as a third party, the public CA that validates certificate requests as a third party, the
certificate will typically be issued under a public trust anchor certificate will typically be issued under a public trust anchor
certificate embedded in one or more relevant Relying Applications. certificate embedded in one or more relevant Relying Applications.
Criteria for inclusion of embedded trust anchor certificates in Criteria for inclusion of embedded trust anchor certificates in
applications are outside the scope of this document. Typically, such applications are outside the scope of this document. Typically, such
criteria require the CA to publish a Certificate Practices Statement criteria require the CA to publish a Certification Practices
(CPS) that specifies how the requirements of the Certificate Policy Statement (CPS) that specifies how the requirements of the
(CP) are achieved. It is also common for a CA to engage an Certificate Policy (CP) are achieved. It is also common for a CA to
independent third-party auditor to prepare an annual audit statement engage an independent third-party auditor to prepare an annual audit
of its performance against its CPS. statement of its performance against its CPS.
A set of CAA records describes only current grants of authority to A set of CAA records describes only current grants of authority to
issue certificates for the corresponding DNS domain. Since a issue certificates for the corresponding DNS domain. Since a
certificate is typically valid for at least a year, it is possible certificate is typically valid for at least a year, it is possible
that a certificate that is not conformant with the CAA records that a certificate that is not conformant with the CAA records
currently published was conformant with the CAA records published at currently published was conformant with the CAA records published at
the time that the certificate was issued. Relying Applications MUST the time that the certificate was issued. Relying Applications MUST
NOT use CAA records as part of certificate validation. NOT use CAA records as part of certificate validation.
CAA records MAY be used by Certificate Evaluators as a possible CAA records MAY be used by Certificate Evaluators as a possible
skipping to change at page 4, line 32 skipping to change at page 4, line 37
Authority undertakes to meet in its issue of certificates. See Authority undertakes to meet in its issue of certificates. See
[RFC3647]. [RFC3647].
Certification Practices Statement (CPS): Specifies the means by which Certification Practices Statement (CPS): Specifies the means by which
the criteria of the Certificate Policy are met. In most cases, this the criteria of the Certificate Policy are met. In most cases, this
will be the document against which the operations of the will be the document against which the operations of the
Certification Authority are audited. See [RFC3647]. Certification Authority are audited. See [RFC3647].
Domain: A DNS Domain Name. Domain: A DNS Domain Name.
Domain Name: A DNS Domain Name as specified in [STD13]. Domain Name: A DNS Domain Name as specified in [RFC1034].
Domain Name System (DNS): The Internet naming system specified in Domain Name System (DNS): The Internet naming system specified in
[STD13]. [RFC1034] and [RFC1035].
DNS Security (DNSSEC): Extensions to the DNS that provide DNS Security (DNSSEC): Extensions to the DNS that provide
authentication services as specified in RFC4033, RFC4034, RFC4035, authentication services as specified in [RFC4033], [RFC4034],
RFC5155, and revisions. [RFC4035], [RFC5155], and revisions.
Issuer: An entity that issues certificates. See [RFC5280]. Issuer: An entity that issues certificates. See [RFC5280].
Property: The tag-value portion of a CAA Resource Record. Property: The tag-value portion of a CAA Resource Record.
Property Tag: The tag portion of a CAA Resource Record. Property Tag: The tag portion of a CAA Resource Record.
Property Value: The value portion of a CAA Resource Record. Property Value: The value portion of a CAA Resource Record.
Public Key Infrastructure X.509 (PKIX): Standards and specifications Public Key Infrastructure X.509 (PKIX): Standards and specifications
issued by the IETF that apply the [X.509] certificate standards issued by the IETF that apply the X.509 certificate standards
specified by the ITU to Internet applications as specified in specified by the ITU to Internet applications as specified in
[RFC5280] and related documents. [RFC5280] and related documents.
Resource Record (RR): A particular entry in the DNS including the Resource Record (RR): A particular entry in the DNS including the
owner name, class, type, time to live, and data, as defined in owner name, class, type, time to live, and data, as defined in
[STD13] and [RFC2181]. [RFC1034] and [RFC2181].
Resource Record Set (RRSet): A set of Resource Records or a Resource Record Set (RRSet): A set of Resource Records of a
particular owner name, class, and type. The time to live on all RRs particular owner name, class, and type. The time to live on all RRs
with an RRSet is always the same, but the data may be different among with an RRSet is always the same, but the data may be different among
RRs in the RRSet. RRs in the RRSet.
Relying Party: A party that makes use of an application whose Relying Party: A party that makes use of an application whose
operation depends on use of a certificate for making a security operation depends on use of a certificate for making a security
decision. See [RFC5280]. decision. See [RFC5280].
Relying Application: An application whose operation depends on use of Relying Application: An application whose operation depends on use of
a certificate for making a security decision. a certificate for making a security decision.
skipping to change at page 6, line 6 skipping to change at page 6, line 13
property entry authorizes the holder of the domain name <Issuer property entry authorizes the holder of the domain name <Issuer
Domain Name> or a party acting under the explicit authority of the Domain Name> or a party acting under the explicit authority of the
holder of that domain name to issue wildcard certificates for the holder of that domain name to issue wildcard certificates for the
domain in which the property is published. domain in which the property is published.
iodef <URL> : Specifies a URL to which an issuer MAY report iodef <URL> : Specifies a URL to which an issuer MAY report
certificate issue requests that are inconsistent with the issuer's certificate issue requests that are inconsistent with the issuer's
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 [RFC5070]. 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
skipping to change at page 9, line 34 skipping to change at page 9, line 34
+----------------|----------------+.....+----------------+ +----------------|----------------+.....+----------------+
| Value byte 0 | Value byte 1 |.....| Value byte m-1 | | Value byte 0 | Value byte 1 |.....| Value byte m-1 |
+----------------|----------------+.....+----------------+ +----------------|----------------+.....+----------------+
Where n is the length specified in the Tag length field and m is the Where n is the length specified in the Tag length field and m is the
remaining octets in the Value field (m = d - n - 2) where d is the remaining octets in the Value field (m = d - n - 2) where d is the
length of the RDATA section. length of the RDATA section.
The data fields are defined as follows: The data fields are defined as follows:
Flags: One octet containing the following fields: Flags: One octet containing the following field:
Bit 0, Issuer Critical Flag: If the value is set to '1', the critical Bit 0, Issuer Critical Flag: If the value is set to '1', the critical
flag is asserted and the property MUST be understood if the CAA flag is asserted and the property MUST be understood if the CAA
record is to be correctly processed by a certificate issuer. record is to be correctly processed by a certificate issuer.
A Certification Authority MUST NOT issue certificates for any Domain A Certification Authority MUST NOT issue certificates for any Domain
that contains a CAA critical property for an unknown or unsupported that contains a CAA critical property for an unknown or unsupported
property tag that for which the issuer critical flag is set. property tag that for which the issuer critical flag is set.
Note that according to the conventions set out in [RFC1035], bit 0 is Note that according to the conventions set out in [RFC1035], bit 0 is
skipping to change at page 12, line 51 skipping to change at page 12, line 51
the corresponding wildcard domain, provided that no records in the the corresponding wildcard domain, provided that no records in the
CAA record set otherwise prohibit issuance. CAA record set otherwise prohibit issuance.
5.4. CAA iodef Property 5.4. CAA iodef Property
The iodef property specifies a means of reporting certificate issue The iodef property specifies a means of reporting certificate issue
requests or cases of certificate issue for the corresponding domain requests or cases of certificate issue for the corresponding domain
that violate the security policy of the issuer or the domain name that violate the security policy of the issuer or the domain name
holder. holder.
The Incident Object Description Exchange Format (IODEF) [RFC5070] is The Incident Object Description Exchange Format (IODEF) [RFC7970] is
used to present the incident report in machine-readable form. used to present the incident report in machine-readable form.
The iodef property takes a URL as its parameter. The URL scheme type The iodef property takes a URL as its parameter. The URL scheme type
determines the method used for reporting: determines the method used for reporting:
mailto: The IODEF incident report is reported as a MIME email mailto: The IODEF incident report is reported as a MIME email
attachment to an SMTP email that is submitted to the mail address attachment to an SMTP email that is submitted to the mail address
specified. The mail message sent SHOULD contain a brief text message specified. The mail message sent SHOULD contain a brief text message
to alert the recipient to the nature of the attachment. to alert the recipient to the nature of the attachment.
skipping to change at page 17, line 14 skipping to change at page 17, line 14
+------+----------------------+-----------+ +------+----------------------+-----------+
| Flag | Meaning | Reference | | Flag | Meaning | Reference |
+------+----------------------+-----------+ +------+----------------------+-----------+
| 0 | Issuer Critical Flag | [RFC6844] | | 0 | Issuer Critical Flag | [RFC6844] |
| | | | | | | |
| 1-7 | Reserved> | [RFC6844] | | 1-7 | Reserved> | [RFC6844] |
+------+----------------------+-----------+ +------+----------------------+-----------+
Assignment of new flags follows the RFC Required policy set out in Assignment of new flags follows the RFC Required policy set out in
[RFC5226], Section 4.1. [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: Chris Evans,
Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam
Langley, Ben Laurie, James Manager, Chris Palmer, Scott Schmit, Sean Langley, Ben Laurie, James Manager, Chris Palmer, Scott Schmit, Sean
Turner, and Ben Wilson. Turner, and Ben Wilson.
11. Normative References 11. References
11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>. <https://www.rfc-editor.org/info/rfc2181>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Rose, "DNS Security Introduction and Requirements",
Policy and Certification Practices Framework", RFC 3647, RFC 4033, DOI 10.17487/RFC4033, March 2005,
DOI 10.17487/RFC3647, November 2003, <https://www.rfc-editor.org/info/rfc4033>.
<https://www.rfc-editor.org/info/rfc3647>.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Object Description Exchange Format", RFC 5070, Rose, "Resource Records for the DNS Security Extensions",
DOI 10.17487/RFC5070, December 2007, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc5070>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
IANA Considerations Section in RFCs", RFC 5226, Rose, "Protocol Modifications for the DNS Security
DOI 10.17487/RFC5226, May 2008, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc4035>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
skipping to change at page 18, line 36 skipping to change at page 18, line 46
[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 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", RFC 6844, Authority Authorization (CAA) Resource Record", RFC 6844,
DOI 10.17487/RFC6844, January 2013, DOI 10.17487/RFC6844, January 2013,
<https://www.rfc-editor.org/info/rfc6844>. <https://www.rfc-editor.org/info/rfc6844>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/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
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>.
Authors' Addresses Authors' Addresses
Phillip Hallam-Baker Phillip Hallam-Baker
Comodo Group, Inc Comodo Group, Inc
Email: philliph@comodo.com Email: philliph@comodo.com
Rob Stradling Rob Stradling
Comodo Group, Inc Comodo Group, Inc
 End of changes. 23 change blocks. 
38 lines changed or deleted 69 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/