Skip to content

Commit

Permalink
Replace RFC 6844 with RFC 8659
Browse files Browse the repository at this point in the history 
Closes cabforum#168
  • Loading branch information
@sleevi
sleevi committed Jul 27, 2020
1 parent 9da1f65 commit ab9d1b2
Showing 1 changed file with 23 additions and 83 deletions.
106 changes: 23 additions & 83 deletions docs/BR.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -236,7 +236,7 @@ No stipulation.

**Base Domain Name**: The portion of an applied-for FQDN that is the first domain name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. "example.co.uk" or "example.com"). For FQDNs where the right-most domain name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name.

**CAA**: From RFC 6844 (<http://tools.ietf.org/html/rfc6844>): "The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain. Publication of CAA Resource Records allows a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue."
**CAA**: From RFC 8659 (<http://tools.ietf.org/html/rfc8659>): "The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain. Publication of CAA Resource Records allows a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue."

**Certificate**: An electronic document that uses a digital signature to bind a public key and an identity.

Expand Down Expand Up @@ -264,13 +264,13 @@ No stipulation.

**Delegated Third Party**: A natural person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.

**DNS CAA Email Contact**: The email address defined in section B.1.1.
**DNS CAA Email Contact**: The email address defined in Section A.1.1.

**DNS CAA Phone Contact**: The phone number defined in section B.1.2.
**DNS CAA Phone Contact**: The phone number defined in Section A.1.2.

**DNS TXT Record Email Contact**: The email address defined in section B.2.1.
**DNS TXT Record Email Contact**: The email address defined in Section A.2.1.

**DNS TXT Record Phone Contact**: The phone number defined in section B.2.2.
**DNS TXT Record Phone Contact**: The phone number defined in Section A.2.2.

**Domain Authorization Document**: Documentation provided by, or a CA's documentation of a communication with, a Domain Name Registrar, the Domain Name Registrant, or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service) attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.

Expand Down Expand Up @@ -484,7 +484,7 @@ RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status P

RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile, Cooper et al, May 2008.

RFC6844, Request for Comments: 6844, DNS Certification Authority Authorization (CAA) Resource Record, Hallam-Baker, Stradling, January 2013.
RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record, Hallam-Baker, Stradling, Hoffman-Andrews, November 2019.

RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Santesson, Myers, Ankney, Malpani, Galperin, Adams, June 2013.

Expand Down Expand Up @@ -579,7 +579,7 @@ This section defines the permitted processes and procedures for validating the A
The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate as follows:

1. When the FQDN does not contain "onion" as the rightmost label, the CA SHALL validate the FQDN using at least one of the methods listed below; and
1. When the FQDN contains "onion" as the rightmost label, the CA SHALL validate the FQDN in accordance with Appendix C.
1. When the FQDN contains "onion" as the rightmost label, the CA SHALL validate the FQDN in accordance with Appendix B.

Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as Section 4.2.1 of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate.

Expand Down Expand Up @@ -685,7 +685,7 @@ Confirming the Applicant's control over the FQDN by validating the Applicant is

##### 3.2.2.4.13: Email to DNS CAA Contact

Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS CAA Email Contact. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 6844 Section 4, as amended by Errata 5065 (Appendix A).
Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS CAA Email Contact. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659, Section 3.

Each email MAY confirm control of multiple FQDNs, provided that each email address is a DNS CAA Email Contact for each Authorization Domain Name being validated. The same email MAY be sent to multiple recipients as long as all recipients are DNS CAA Email Contacts for each Authorization Domain Name being validated.

Expand Down Expand Up @@ -728,7 +728,7 @@ The Random Value SHALL remain valid for use in a confirming response for no more
**Note:** Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

##### 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact
Confirm the Applicant's control over the FQDN by calling the DNS CAA Phone Contact’s phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS CAA Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 6844 Section 4, as amended by Errata 5065 (Appendix A).
Confirm the Applicant's control over the FQDN by calling the DNS CAA Phone Contact’s phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS CAA Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659 Section 3.

The CA MUST NOT be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation.

Expand Down Expand Up @@ -855,13 +855,13 @@ Databases maintained by the CA, its owner, or its affiliated companies do not qu

#### 3.2.2.8. CAA Records

As part of the issuance process, the CA MUST check for CAA records and follow the processing instructions found, for each dNSName in the subjectAltName extension of the certificate to be issued, as specififed in RFC 6844 as amended by Errata 5065 (Appendix A). If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.
As part of the issuance process, the CA MUST check for CAA records and follow the processing instructions found, for each dNSName in the subjectAltName extension of the certificate to be issued, as specififed in RFC 8659. If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.

This stipulation does not prevent the CA from checking CAA records at any other time.

When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 6844, although they are not required to act on the contents of the iodef property tag. Additional property tags MAY be supported, but MUST NOT conflict with or supersede the mandatory property tags set out in this document. CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property tag with this flag set. CAs MAY treat a non-empty CAA Resource Record Set that does not contain any issue property tags (and also does not contain any issuewild property tags when performing CAA processing for a Wildcard Domain Name) as permission to issue, provided that no records in the CAA Resource Record Set otherwise prohibit issuance.
When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 8659, although they are not required to act on the contents of the iodef property tag. Additional property tags MAY be supported, but MUST NOT conflict with or supersede the mandatory property tags set out in this document. CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property tag with this flag set.

RFC 6844 requires that CAs "MUST NOT issue a certificate unless 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." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following:
RFC 8659 requires that CAs "MUST NOT issue a certificate unless 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." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following:

* CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked.
* CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in Baseline Requirements section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant.
Expand Down Expand Up @@ -2084,75 +2084,13 @@ Any modification to CA practice enabled under this section MUST be discontinued

## 9.17 Other provisions

# APPENDIX A – RFC 6844 Errata 5065

The following errata report has been held for document update for RFC6844, "DNS Certification Authority Authorization (CAA) Resource Record".

-----

You may review the report below and at: http://www.rfc-editor.org/errata/eid5065

-----

Status: Held for Document Update
Type: Technical

Reported by: Phillip Hallam-Baker <philliph@comodo.com>
Date Reported: 2017-07-10
Held by: EKR (IESG)

Section: 4

Original Text
-------------
```
Let CAA(X) be the record set returned in response to performing a CAA
record query on the label X, P(X) be the DNS label immediately above X in
the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record
specified at the label X.
o If CAA(X) is not empty, R(X) = CAA (X), otherwise
o If A(X) is not null, and R(A(X)) is not empty, then R(X) = R(A(X)),
otherwise
o If X is not a top-level domain, then R(X) = R(P(X)), otherwise
o R(X) is empty.
```

Corrected Text
--------------
```
Let CAA(X) be the record set returned in response to performing a CAA
record query on the label X, P(X) be the DNS label immediately above X in
the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record
chain specified at the label X.
o If CAA(X) is not empty, R(X) = CAA (X), otherwise
o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = CAA(A(X)),
otherwise
o If X is not a top-level domain, then R(X) = R(P(X)), otherwise
o R(X) is empty.
Thus, when a search at node X returns a CNAME record, the CA will follow the
CNAME record chain to its target. If the target label contains a CAA record,
it is returned.
Otherwise, the CA continues the search at the parent of node X.
Note that the search does not include the parent of a target of a CNAME
record (except when the CNAME points back to its own path).
To prevent resource exhaustion attacks, CAs SHOULD limit the length of CNAME
chains that are accepted. However CAs MUST process CNAME chains that contain
8 or fewer CNAME records.
```

# APPENDIX B – CAA Contact Tag
# APPENDIX A – CAA Contact Tag

These methods allow domain owners to publish contact information in DNS for the purpose of validating domain control.

## B.1. CAA Methods
## A.1. CAA Methods

### B.1.1. CAA contactemail Property
### A.1.1. CAA contactemail Property

SYNTAX: `contactemail <rfc6532emailaddress>`

Expand All @@ -2167,7 +2105,7 @@ $ORIGIN example.com.

The contactemail property MAY be critical, if the domain owner does not want CAs who do not understand it to issue certificates for the domain.

### B.1.2. CAA contactphone Property
### A.1.2. CAA contactphone Property

SYNTAX: `contactphone <rfc3966 Global Number>`

Expand All @@ -2180,16 +2118,17 @@ $ORIGIN example.com.

The contactphone property MAY be critical if the domain owner does not want CAs who do not understand it to issue certificates for the domain.

## B.2. DNS TXT Methods
## A.2. DNS TXT Methods

### B.2.1. DNS TXT Record Email Contact
### A.2.1. DNS TXT Record Email Contact

The DNS TXT record MUST be placed on the "`_validation-contactemail`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid email address as defined in RFC 6532 section 3.2, with no additional padding or structure, or it cannot be used.

### B.2.2. DNS TXT Record Phone Contact
### A.2.2. DNS TXT Record Phone Contact
The DNS TXT record MUST be placed on the "`_validation-contactphone`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid Global Number as defined in RFC 3966 section 5.1.4, or it cannot be used.

# APPENDIX C – Issuance of Certificates for .onion Domain Names
# APPENDIX B – Issuance of Certificates for .onion Domain Names

This appendix defines permissible verification procedures for including one or more RFC 7686 ".onion" special-use Domain Names in a Certificate.

1. The Domain Name MUST contain at least two labels, where the right-most label is "onion", and the label immediately preceding the right-most "onion" label is a valid Version 3 Onion Address, as defined in section 6 of the Tor Rendezvous Specification - Version 3 located at <https://spec.torproject.org/rend-spec-v3>.
Expand Down Expand Up @@ -2222,4 +2161,5 @@ cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
The CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 3.2.2.6 of these Requirements.

3. When a Certificate includes an FQDN where "onion" is in the right-most label of the Domain Name, the Domain Name shall not be considered an Internal Name provided that the Certificate was issued in compliance with this Appendix C.
3. When a Certificate includes an FQDN where "onion" is in the right-most label of the Domain Name, the Domain Name shall not be considered an Internal Name provided that the Certificate was issued in compliance with this Appendix B.

0 comments on commit ab9d1b2

Please sign in to comment.