Remove section 3 "The CAA RR Type" #5
Conversation
The definitions in this section overlapped with the definitions in the Mechanism section significantly and created potential for confusion and conflict. Most of the necessary information was already in the Mechanism section, so this is mostly a straight-up delete. In a few places I incorporated information that was only in "The CAA RR Type". I've also added a number of examples, switched to using "ca1.example.net" and "ca2.example.org" as the examples, moved the DNSSEC section into Security Considerations, and renamed "Certification Authority Processing" to "Relevant Resource Record Set".
Use "property", "property tag", and "property value" more consistently. Remove "data field" which sounds like a specific term but just means "field" in this context. Replace it with "RDATA section" when that is what is meant.
This brings back the language about the "holder" of the issuer domain name that used to be in the "CAA RR Type" section. It also splits out the two roles of the issue property tag more clearly since they are important to note as separate things.
There was a problem hiding this comment.
@jsha: (Out of scope for this particular PR) Something I noticed whilst reviewing this PR is the inconsistent use of Defined Terms. For example, there's a definition for "Wildcard Domain Name" in section 2.2, but there are 8 instances of "wildcard domain name" in the document.
draft-ietf-lamps-rfc6844bis.md
Outdated
| The issuewild property has the same syntax and semantics as the issue | ||
| property except that issuewild properties only grant authorization to | ||
| The issuewild property tag has the same syntax and semantics as the issue | ||
| property tag except that they only grant authorization to |
There was a problem hiding this comment.
s/they only grant/it only grants/
draft-ietf-lamps-rfc6844bis.md
Outdated
| certificates for "\*.wild3.example.com" or "\*.sub.wild3.example.com". No issuer | ||
| is permitted to issue for "wild3.example.com" or "sub.wild3.example.com". | ||
|
|
||
| wild3.example.com CAA 0 issue "ca2.example.org" |
There was a problem hiding this comment.
This example and its description do not match.
To match the description, I think the example RRset should look like this:
wild3.example.com CAA 0 issuewild "ca2.example.org"
wild3.example.com CAA 0 issue ";"
There was a problem hiding this comment.
Thanks for the catch! I think the issue ";" is not actually required to achieve the listed semantics. I think this also matches the description:
wild3.example.com CAA 0 issuewild "ca2.example.org"
There was a problem hiding this comment.
No, that doesn't match the description. "issuewild" is only relevant for Wildcard Domain Names. If there's no "issue" property, then any CA can issue non-wildcard certs. Therefore, with that single issuewild property alone, it is not the case that 'No issuer is permitted to issue for "wild3.example.com" or "sub.wild3.example.com"'.
There was a problem hiding this comment.
Ah, re-reading I see that you're right:
issuewild properties MUST be ignored when processing a request for
a domain name that is not a wildcard domain name.
I'll update to include two examples, one with the issue ";" and one without.
draft-ietf-lamps-rfc6844bis.md
Outdated
| that violate the security policy of the issuer or the domain name | ||
| holder. | ||
| The iodef property specifies a means by which an issuer MAY report | ||
| certificate issuance requests or certificate issuance |
There was a problem hiding this comment.
In RFC6844 and in rfc6844bis-04, there's no restriction on which parties may use a CAA iodef record. Both documents say (in the Introduction) that "CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation."
Adding "by which an issuer" seems at odds with "MAY be used by Certificate Evaluators".
I suggest either:
(1) s/by which an issuer/by which an issuer or Certificate Evaluator/
or
(2) Use the previous "...specifies a means of reporting certificate issue requests or cases of certificate issue..." language.
There was a problem hiding this comment.
Also, your "MAY report" clause doesn't specify any reasons why an issuer (or a certificate evaluator) might want to send a report, whereas Section 3 (which this PR removes) said:
iodef <URL> : Specifies a URL to which an issuer MAY report
certificate issue requests that are inconsistent with the issuer's
Certification Practices or Certificate Policy, or that a Certificate
Evaluator may use to report observation of a possible policy
violation.
I think this PR's statement "by which an issuer MAY report certificate issuance requests" could be taken to mean that a CA MAY report every cert request to the iodef URL - both the completely valid requests and the potentially suspicious requests. But clearly the intent is that a report should only be sent when there's an (actual or suspected) "incident" (the "i" of "iodef").
There was a problem hiding this comment.
Section 3 (which this PR removes) says:
In the following example, the domain name holder specifies
that reports may be made by means of email with the IODEF data as an
attachment, 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/"
Could you add those example "iodef" records to the "CAA iodef Property" section?
There was a problem hiding this comment.
Excellent point about the IODEF language. I'm updating the first paragraph to say:
CAA iodef Property
The iodef property specifies a means of reporting certificate issue
requests or cases of certificate issue for domains for which the property
appears in the relevant resource record set, when those requests or issuances
violate the security policy of the issuer or the domain name holder.
I think that addresses the concerns. Thoughts?
And yep, will add that example back in.
To be clear, you're saying that all Defined Terms should appear in title case in the text? I had been treating the lowercase version as equivalent to the Defined Term, but that does seem like a good clarification. It seems like it might hurt readability a bit though. |
|
Yeah, I was suggesting using title case everywhere, although I'm happy to leave as is if that's the consensus. |
draft-ietf-lamps-rfc6844bis.md
Outdated
|
|
||
| report.example.com CAA 0 issue "ca1.example.net" | ||
| report.example.com CAA 0 iodef "mailto:security@example.com" | ||
| report.example.com CAA 0 issue "http://iodef.example.com/" |
|
LGTM. |
Section 3 "The CAA RR Type" duplicated a lot of definitions from Section 5 "Mechanism." Both sections contained normative references, so it was not always clear which version to refer to, and the definitions were sometimes inconsistent.
This PR merges the two sections. In most cases, this was a no-op due to duplication. "The CAA RR Type" had two "MUSTs" and one "MUST NOT." I believe I have preserved those semantics.
This PR also moves "Use of DNS Security" under "Security Considerations."
This PR also tidies up some definitions under "Mechanism" that use "property", "value", and "parameter" in their informal sense, which was confusing because these terms also have specific technical meaning in the CAA spec.