RFC 6844

DNS Certification Authority Authorization (CAA) Resource Record

📅 published January 2013, from ietf

RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record 🎀

Okay bestie, this is the spec for CAA records 💅 It's the DNS way for a domain owner to say which Certification Authorities are allowed to issue certificates for them. Here's the title block tea ✨

  • RFC number: 6844
  • Title: DNS Certification Authority Authorization (CAA) Resource Record
  • Authors: P. Hallam-Baker (Comodo Group, Inc.) and R. Stradling (Comodo CA, Ltd.)
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: January 2013
  • Obsoletes / Updates: The title block doesn't list anything this one obsoletes or updates 🌸

Abstract

The Certification Authority Authorization (CAA) DNS Resource Record lets a DNS domain name holder list one or more Certification Authorities (CAs) that are allowed to issue certificates for that domain 🦋 Publishing CAA records gives a public CA extra controls to lower the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and the rules certificate issuers follow when they process CAA records. 🧚

Status of This Memo

This is an Internet Standards Track document. ✨

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has had public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📚

For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6844 🔗

Copyright (c) 2013 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) as in effect on the date of publication. Please read these documents carefully, because they describe your rights and restrictions for 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 they are provided without warranty as described in the Simplified BSD License. 💜

Table of Contents

1. Introduction ....................................................2
2. Definitions .....................................................3
   2.1. Requirements Language ......................................3
   2.2. Defined Terms ..............................................3
3. The CAA RR Type .................................................5
4. Certification Authority Processing ..............................7
   4.1. Use of DNS Security ........................................8
5. Mechanism .......................................................8
   5.1. Syntax .....................................................8
        5.1.1. Canonical Presentation Format ......................10
   5.2. CAA issue Property ........................................10
   5.3. CAA issuewild Property ....................................12
   5.4. CAA iodef Property ........................................12
6. Security Considerations ........................................13
   6.1. Non-Compliance by Certification Authority .................13
   6.2. Mis-Issue by Authorized Certification Authority ...........13
   6.3. Suppression or Spoofing of CAA Records ....................13
   6.4. Denial of Service .........................................14
   6.5. Abuse of the Critical Flag ................................14
7. IANA Considerations ............................................14
   7.1. Registration of the CAA Resource Record Type ..............14
   7.2. Certification Authority Restriction Properties ............15
   7.3. Certification Authority Restriction Flags .................15
8. Acknowledgements ...............................................16
9. References .....................................................16
   9.1. Normative References ......................................16
   9.2. Informative References ....................................17

1. Introduction ✨

The Certification Authority Authorization (CAA) DNS Resource Record lets a DNS domain name holder specify the Certification Authorities (CAs) that are authorized to issue certificates for that domain. Publishing CAA records gives a public Certification Authority extra controls to reduce the risk of unintended certificate mis-issue. 💖

Like the TLSA record defined in DNS-Based Authentication of Named Entities (DANE) [RFC6698], CAA records are part of a mechanism for checking PKIX certificate data 🧚 The difference is when each one kicks in. CAA records describe an authorization control that a certificate issuer performs before issuing a certificate. TLSA records describe a verification control that a relying party performs after the certificate is issued. Two different jobs, same family, very cute 🫶

Conformance with a published CAA record is a necessary but not sufficient condition for issuing a certificate. Before issuing a certificate, a PKIX CA is required to validate the request according to the policies set out in its Certificate Policy. When a public CA validates certificate requests as a third party, the certificate will typically be issued under a public trust anchor certificate embedded in one or more relevant Relying Applications. 🔥

How trust anchor certificates get embedded in applications is outside the scope of this document. Usually those criteria require the CA to publish a Certification Practices Statement (CPS) that explains how the Certificate Policy (CP) requirements are met. It's also common for a CA to hire an independent third-party auditor to write an annual audit statement on how it's doing against its CPS 📋

A set of CAA records only describes current grants of authority to issue certificates for the matching DNS domain. A certificate is typically valid for at least a year, so a certificate that doesn't match the CAA records published today might still have matched the CAA records that were published when it was issued. Relying Applications MUST NOT use CAA records as part of certificate validation. 🙈

CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation. Such use SHOULD account for the possibility that the published CAA records changed between the time a certificate was issued and the time the Certificate Evaluator observed it. 👑

2. Definitions 🌈

2.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 [RFC2119]. 🎀

2.2. Defined Terms 📖

These are the terms used throughout this document, bestie. Read them once and you'll be fluent 🦋

  • Authorization Entry: An authorization assertion that grants or denies a specific set of permissions to a specific group of entities.
  • Certificate: An X.509 Certificate, as specified in [RFC5280].
  • Certificate Evaluator: A party other than a relying party that evaluates the trustworthiness of certificates issued by Certification Authorities.
  • Certification Authority (CA): An issuer that issues certificates in accordance with a specified Certificate Policy.
  • Certificate Policy (CP): Specifies the criteria that a Certification Authority undertakes to meet in its issue of certificates. See [RFC3647].
  • Certification Practices Statement (CPS): Specifies the means by which the criteria of the Certificate Policy are met. In most cases, this is the document the Certification Authority's operations get audited against. See [RFC3647].
  • Domain: A DNS Domain Name.
  • Domain Name: A DNS Domain Name as specified in [STD13].
  • Domain Name System (DNS): The Internet naming system specified in [STD13].
  • DNS Security (DNSSEC): Extensions to the DNS that provide authentication services as specified in [RFC4033], [RFC4034], [RFC4035], [RFC5155], and revisions.
  • Issuer: An entity that issues certificates. See [RFC5280].
  • Property: The tag-value 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.
  • Public Key Infrastructure X.509 (PKIX): Standards and specifications issued by the IETF that apply the [X.509] certificate standards specified by the ITU to Internet applications, as specified in [RFC5280] and related documents.
  • Resource Record (RR): A particular entry in the DNS including the owner name, class, type, time to live, and data, as defined in [STD13] and [RFC2181].
  • Resource Record Set (RRSet): A set of Resource Records for a particular owner name, class, and type. The time to live on all RRs within an RRSet is always the same, but the data may differ among the RRs in the RRSet.
  • Relying Party: A party that makes use of an application whose operation depends on use of a certificate for making a security decision. See [RFC5280].
  • Relying Application: An application whose operation depends on use of a certificate for making a security decision.

3. The CAA RR Type ✨

okay so a CAA RR is basically a flags byte plus a tag-value pair, and that pair is what the RFC calls a property 💅 Multiple properties MAY be associated with the same domain name by publishing multiple CAA RRs at that domain name. Only one flag is defined so far:

  • Issuer Critical 🚩: If set to '1', it means the corresponding property tag MUST be understood if an issuer is going to interpret the CAA record correctly.
    • Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set. That's a hard no, bestie 🙅‍♀️

The following property tags are defined:

  • issue <Issuer Domain Name> [; <name>=<value> ]*: this one authorizes the holder of the domain name <Issuer Domain Name>, or someone acting under the explicit authority of that holder, to issue certificates for the domain where the property is published 🎀
  • issuewild <Issuer Domain Name> [; <name>=<value> ]*: same energy as issue, but it's for wildcard certificates 🌸
  • iodef <URL>: this specifies a URL where an issuer MAY report certificate issue requests that don't match its Certification Practices or Certificate Policy. A Certificate Evaluator can also use it to report a possible policy violation 🚨 The format used here is the Incident Object Description Exchange Format (IODEF) [RFC5070].

Here's an example DNS zone file (see [RFC1035]) that tells CAs that certificates are NOT to be issued except by the holder of ca.example.net or an authorized agent of theirs. This policy covers all the subordinate domains under example.com 👑

$ORIGIN example.com
.       CAA 0 issue "ca.example.net"

If the domain name holder sets up one or more iodef properties, a certificate issuer MAY report invalid certificate requests to that address. In this next one, the holder says reports can come in by email with the IODEF data attached, through a Web service [RFC6546], or both 📬

$ORIGIN example.com
.       CAA 0 issue "ca.example.net"
.       CAA 0 iodef "mailto:security@example.com"
.       CAA 0 iodef "http://iodef.example.com/"

A certificate issuer MAY also specify additional parameters that let customers set extra stuff governing certificate issuance. That could be the Certificate Policy the cert gets issued under, the authentication process to use, or an account number the CA hands out so those parameters can be retrieved 🧾

For example, the CA ca.example.net asked its customer example.com to put the CA's account number 230123 in each of the customer's CAA records 💖

$ORIGIN example.com
.       CAA 0 issue "ca.example.net; account=230123"

The syntax of those additional parameters is a sequence of name-value pairs, as defined in Section 5.2. What the parameters actually mean is up to site policy and is outside the scope of this document 🤷‍♀️

The critical flag exists so that future versions of CAA can introduce new semantics that MUST be understood for the record to be processed correctly. That way, conforming CAs that don't recognize the new semantics can't issue certificates for the domains in question. It's giving safety net 🛟

In this example, the property tbs is flagged as critical. Neither the example.net CA nor any other issuer is authorized to issue under either policy unless they understand the processing rules for the tbs property tag 💀

$ORIGIN example.com
.       CAA 0 issue "ca.example.net; policy=ev"
.       CAA 128 tbs "Unknown"

Note that these restrictions only apply at certificate issue time 👀 An end entity certificate is usually valid for a year or more, so it's totally possible that the CAA records published at a domain change between when a cert was issued and when a relying party validates it. Plot twist 🌀

4. Certification Authority Processing 👑

Before issuing a certificate, a compliant CA MUST check whether a relevant CAA Resource Record set has been published. If such a record set exists, a CA MUST NOT issue a certificate unless it determines that either (1) the certificate request is consistent with the applicable CAA Resource Record set, or (2) an exception specified in the relevant Certificate Policy or Certification Practices Statement applies 🔍

A certificate request MAY specify more than one domain name, and it MAY specify wildcard domains. Issuers MUST verify authorization for every domain and wildcard domain in the request ✅

The search for a CAA record climbs the DNS name tree from the specified label, up to but NOT including the DNS root . 🌳

Given a request for a specific domain X, or a request for a wildcard domain *.X, the relevant record set R(X) is figured out like this:

Let CAA(X) be the record set returned when you do a CAA record query on the label X. Let P(X) be the DNS label sitting right above X in the DNS hierarchy, and let A(X) be the target of a CNAME or DNAME alias record specified at the label X.

  • If CAA(X) is not empty, then R(X) = CAA (X). Otherwise,
  • If A(X) is not null, and R(A(X)) is not empty, then R(X) = R(A(X)). Otherwise,
  • If X is not a top-level domain, then R(X) = R(P(X)). Otherwise,
  • R(X) is empty.

For example, if a certificate is requested for X.Y.Z, the issuer searches for the relevant CAA record set in this order 🪜

X.Y.Z

Alias (X.Y.Z)

Y.Z
Alias (Y.Z)

Z

Alias (Z)

Return Empty

4.1. Use of DNS Security 🔐

Using DNSSEC to authenticate CAA RRs is strongly RECOMMENDED, but it isn't required. An issuer MUST NOT issue certificates if doing so would conflict with the relevant CAA Resource Record set, whether or not the corresponding DNS records are signed. Big rule, no exceptions 💅

DNSSEC gives you a proof of non-existence for both DNS domains and RR sets within domains. So with DNSSEC verification, an issuer can tell whether a CAA record query came back empty because the RR set is actually empty, or whether it's non-empty but the response got suppressed 🕵️‍♀️

Using DNSSEC also lets an issuer acquire and archive proof that they were authorized to issue certificates for the domain. Verifying those archives MAY be an audit requirement for checking CAA record processing compliance, and publishing them MAY be a transparency requirement for the same purpose 📚

5. Mechanism ⚙️

5.1. Syntax 🧩

A CAA RR holds a single property entry, which is a tag-value pair. Each tag represents a property of the CAA record, and the value of a CAA property is whatever's in the corresponding value field 🎀

A domain name MAY have multiple CAA RRs associated with it, and a given property MAY be specified more than once. Iconic flexibility 🦋

The CAA data field contains one property entry. A property entry is made up of these data fields:

+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
| Flags          | Tag Length = n |
+----------------+----------------+...+---------------+
| Tag char 0     | Tag char 1     |...| Tag char n-1  |
+----------------+----------------+...+---------------+
+----------------+----------------+.....+----------------+
| Value byte 0   | Value byte 1   |.....| Value byte m-1 |
+----------------+----------------+.....+----------------+

Where n is the length given in the Tag Length field, and m is the number of octets left over in the Value field (m = d - n - 2), where d is the length of the RDATA section 🧮

Here's what each data field does:

  • Flags: One octet containing the following fields:
    • 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 record is going to be processed correctly by a certificate issuer 🚩
      • A Certification Authority MUST NOT issue certificates for any Domain that contains a CAA critical property for an unknown or unsupported property tag where the issuer critical flag is set. Respect the flag, periodt 🙅‍♀️

Note that according to the conventions set out in [RFC1035], bit 0 is the Most Significant Bit and bit 7 is the Least Significant Bit. So a Flags value of 1 means bit 7 is set, while a value of 128 means bit 0 is set, under this convention 🤓

All other bit positions are reserved for future use.

To keep things compatible with future CAA extensions, DNS records that follow this version of the CAA spec MUST clear (set to "0") all reserved flag bits. Applications that interpret CAA records MUST ignore the value of all reserved flag bits. Clean slate energy ✨

  • Tag Length: A single octet containing an unsigned integer that specifies the tag length in octets. The tag length MUST be at least 1, and it SHOULD be no more than 15 📏
  • Tag: The property identifier, which is a sequence of US-ASCII characters 🏷️
    • Tag values MAY contain the US-ASCII characters 'a' through 'z', 'A' through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT contain any other characters. Matching of tag values is case insensitive, so no stress 🫶
    • Tag values submitted for registration by IANA MUST NOT contain any characters other than the (lowercase) US-ASCII characters 'a' through 'z' and the numbers 0 through 9. Strict bouncer vibes for the registry 🧐
  • Value: A sequence of octets representing the property value. Property values are encoded as binary values, and they MAY employ sub-formats 🔢
    • The length of the value field is specified implicitly as the remaining length of the enclosing Resource Record data field 💡

5.1.1. Canonical Presentation Format 📝

The canonical presentation format of the CAA record looks like this:

CAA <flags> <tag> <value>

Where:

  • Flags: An unsigned integer between 0 and 255 🔢
  • Tag: A non-zero sequence of US-ASCII letters and numbers in lower case 🔡
  • Value: The <character-string> encoding of the value field, as specified in [RFC1035], Section 5.1 🧵

5.2. CAA issue Property ✨

Okay bestie, the issue property tag is the one that basically says "hey certificate issuers, please do CAA issue restriction processing for this domain" 💅 It also hands out permission to specific issuers, so it's giving main character energy 👑

The CAA issue property value has the following sub-syntax (specified in ABNF as per [RFC5234]) 🎀

issuevalue  = space [domain] space [";" *(space parameter) space]

domain = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))

space = *(SP / HTAB)

parameter =  tag "=" value

tag = 1*(ALPHA / DIGIT)

value = *VCHAR

ngl the domain names here are written in letter-digit-hyphen Label (LDH-Label) form 🦋 It's for consistency with the rest of DNS admin, so everything lines up nicely 🌸

A CAA record with an issue parameter tag that does not specify a domain name is a request that certificate issuers perform CAA issue restriction processing for the corresponding domain without granting authorization to any certificate issuer 🙈 This is the "nobody gets to issue" option, and it's perfect if you want zero certs for a domain 💀

Here's an example. The following CAA record set requests that no certificates be issued for the domain 'nocerts.example.com' by any certificate issuer 🧚

nocerts.example.com       CAA 0 issue ";"

A CAA record with an issue parameter tag that specifies a domain name is a request that certificate issuers perform CAA issue restriction processing for the corresponding domain and grants authorization to the certificate issuer specified by the domain name 🫶

For example, the following CAA record set requests that no certificates be issued for the domain 'certs.example.com' by any certificate issuer other than the example.net certificate issuer 🍓

certs.example.com       CAA 0 issue "example.net"

CAA authorizations are additive, so specifying both the empty issuer and a specified issuer is the same as specifying just the specified issuer alone 🔥 Literally no extra power from doubling up, so don't stress about it ✨

An issuer MAY choose to specify issuer-parameters that further constrain the issue of certificates by that issuer 💜 For example, that could mean certs are subject to specific validation polices, billed to certain accounts, or issued under specific trust anchors 🌈

The semantics of issuer-parameters are determined by the issuer alone 💅 Basically, the issuer decides what its own params mean, and nobody else gets a say 🙅‍♀️

5.3. CAA issuewild Property 🦋

The issuewild property has the same syntax and semantics as the issue property, except issuewild properties only grant authorization to issue certificates that specify a wildcard domain 🌸 Also, issuewild properties take precedence over issue properties when they're specified, so they're the VIP of the bunch 👑 Specifically:

  • issuewild properties MUST be ignored when processing a request for a domain that is not a wildcard domain. 🙈
  • If at least one issuewild property is specified in the relevant CAA record set, all issue properties MUST be ignored when processing a request for a domain that is a wildcard domain. 💀

5.4. CAA iodef Property 🚨

The iodef property is the "tell us when something goes wrong" option 🍓 It specifies a means of reporting certificate issue requests, or cases of certificate issue for the corresponding domain, that violate the security policy of the issuer or the domain name holder 🔥

The Incident Object Description Exchange Format (IODEF) [RFC5070] is used to present the incident report in machine-readable form 🤖

The iodef property takes a URL as its parameter. The URL scheme type decides the method used for reporting 🎀

  • mailto: The IODEF incident report is reported as a MIME email attachment to an SMTP email that is submitted to the mail address specified. The mail message sent SHOULD contain a brief text message to alert the recipient to the nature of the attachment 💌
  • http or https: The IODEF report is submitted as a Web service request to the HTTP address specified, using the protocol specified in [RFC6546] 🌐

6. Security Considerations 🔐

ok this section is serious, so read it with your whole brain 🧠 CAA records assert a security policy that the holder of a domain name wishes to be observed by certificate issuers. That means the effectiveness of CAA records as an access control mechanism depends on issuers actually observing the CAA constraints 💀

The objective of the CAA record properties described in this document is to reduce the risk of certificate mis-issue, rather than avoid reliance on a certificate that has been mis-issued 😭 DANE [RFC6698] describes a mechanism for avoiding reliance on mis-issued certificates, so go look at that too 🧚

6.1. Non-Compliance by Certification Authority 💅

CAA records offer CAs a cost-effective means of mitigating the risk of certificate mis-issue 💖 The cost of implementing CAA checks is very small, and the potential costs of a mis-issue event include the removal of an embedded trust anchor 😳 So it's a no-brainer for CAs, honestly 🫶

6.2. Mis-Issue by Authorized Certification Authority 🙈

Use of CAA records does not prevent mis-issue by an authorized Certification Authority, i.e., a CA that is authorized to issue certificates for the domain in question by CAA records 😭 CAA is not a magic shield, babe 🛡️

Domain name holders SHOULD verify that the CAs they authorize to issue certificates for their domains employ appropriate controls to ensure that certificates are issued only 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 🌸

6.3. 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 an issuer that was not authorized to issue for that domain name. This is the scary one, bestie 😱

Where possible, issuers SHOULD perform DNSSEC validation to detect missing or modified CAA record sets 🔒

In cases where DNSSEC is not deployed in a corresponding domain, an issuer 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 🎯 Data cached by third parties MUST NOT be relied on, but MAY be used to support additional anti-spoofing or anti-suppression controls 🧃

6.4. Denial of Service 🌧️

Introduction of a malformed or malicious CAA RR could, in theory, enable a Denial-of-Service (DoS) attack 😬

This specific threat is not considered to add significantly to the risk of running an insecure DNS service 🙄

An attacker could, in principle, perform a DoS attack against an issuer by requesting a certificate with a maliciously long DNS name. In practice, the DNS protocol imposes a maximum name length, and CAA processing does not exacerbate the existing need to mitigate DoS attacks to any meaningful degree 💅

6.5. Abuse of the Critical Flag 🚩

A Certification Authority could make use of the critical flag to trick customers into publishing records that prevent competing Certification Authorities from issuing certificates, even though the customer intends to authorize multiple providers 😤 That's messy behavior, and we don't do that here 🙅‍♀️

In practice, such an attack would be of minimal effect, since any competent competitor that found itself unable to issue certificates due to lack of support for a property marked critical SHOULD investigate the cause and report the reason to the customer 🕵️ The customer will thus discover that they had been deceived 😭

7. IANA Considerations 📋

7.1. Registration of the CAA Resource Record Type 🧾

IANA has assigned Resource Record Type 257 for the CAA Resource Record Type, and added the line depicted below to the registry named "Resource Record (RR) TYPEs" and QTYPEs, as defined in BCP 42 [RFC6195] and located at http://www.iana.org/assignments/dns-parameters 🌈

 RR Name      Value and meaning                                Reference
 -----------  ---------------------------------------------    ---------
 CAA          257 Certification Authority Restriction          [RFC6844]

7.2. Certification Authority Restriction Properties 🏷️

IANA has created the "Certification Authority Restriction Properties" registry with the following initial values ✨


Tag          Meaning                                Reference
-----------  -------------------------------------- ---------
issue        Authorization Entry by Domain          [RFC6844]
issuewild    Authorization Entry by Wildcard Domain [RFC6844]
iodef        Report incident by IODEF report        [RFC6844]
auth         Reserved                               [HB2011]
path         Reserved                               [HB2011]
policy       Reserved                               [HB2011]

Although [HB2011] has expired, deployed clients implement the CAA properties specified in the document, and reuse of these property tags for a different purpose could cause unexpected behavior 😬 So please don't do that 🙏

Addition of tag identifiers requires a public specification and Expert Review, as set out in [RFC6195], Section 3.1.1 📝

The tag space is designed to be sufficiently large that exhausting the possible tag space need not be a concern 🌌 The scope of Expert Review SHOULD be limited to the question of whether the specification provided is sufficiently clear to permit implementation, and to avoid unnecessary duplication of functionality 🧐

7.3. Certification Authority Restriction Flags 🚩

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 [RFC5226], Section 4.1 🔐

8. Acknowledgements 🫶

The authors would like to thank the following people who contributed to the design and documentation of this work item: Chris Evans, Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam Langley, Ben Laurie, James Manager, Chris Palmer, Scott Schmit, Sean Turner, and Ben Wilson 💖 Iconic cast, honestly ✨

9. References 📚

9.1. Normative References 💖

okay bestie, these are the docs this spec totally leans on 🫶 you can't really read the whole thing without them, so here they are, slay 💅

[RFC1035]  Mockapetris, P., "Domain names - implementation and
           specification", STD 13, RFC 1035, November 1987.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
           Specification", RFC 2181, July 1997.

[RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "DNS Security Introduction and Requirements",
           RFC 4033, March 2005.

[RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "Resource Records for the DNS Security Extensions",
           RFC 4034, March 2005.

[RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "Protocol Modifications for the DNS Security
           Extensions", RFC 4035, March 2005.

[RFC5070]  Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
           Object Description Exchange Format", RFC 5070,
           December 2007.

[RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
           Security (DNSSEC) Hashed Authenticated Denial of
           Existence", RFC 5155, March 2008.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008.

[RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234, January 2008.

[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.

[RFC6195]  Eastlake, D., "Domain Name System (DNS) IANA
           Considerations", BCP 42, RFC 6195, March 2011.

[RFC6546]  Trammell, B., "Transport of Real-time Inter-network
           Defense (RID) Messages over HTTP/TLS", RFC 6546,
           April 2012.

[RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
           of Named Entities (DANE) Transport Layer Security (TLS)
           Protocol: TLSA", RFC 6698, August 2012.

[STD13]    Mockapetris, P., "Domain names - concepts and facilities",
           STD 13, RFC 1034, November 1987.

           Mockapetris, P., "Domain names - implementation and
           specification", STD 13, RFC 1035, November 1987.

[X.509]    International Telecommunication Union, "ITU-T
           Recommendation X.509 (11/2008): Information technology -
           Open systems interconnection - The Directory: Public-key
           and attribute certificate frameworks", ITU-T
           Recommendation X.509, November 2008.

9.2. Informative References 🦋

these ones are more of a "good to know" vibe, like the background reading that makes you look smart in the group chat 🧚 ngl the work-in-progress one is giving main character energy 🌸

[HB2011]   Hallam-Baker, P., Stradling, R., and B. Laurie, "DNS
           Certification Authority Authorization (CAA) Resource
           Record", Work in Progress, May 2011.

[RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
           Wu, "Internet X.509 Public Key Infrastructure Certificate
           and Certification Practices Framework", RFC 3647,
           November 2003.

Authors' Addresses 🎀

and that's the whole crew, bestie 🫶 here's who wrote it, so you know who to thank for all of this 👑

Phillip Hallam-Baker
Comodo Group, Inc.

EMail: philliph@comodo.com


Rob Stradling
Comodo CA, Ltd.

EMail: rob.stradling@comodo.com
📦 where this page comes from