RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 13 records.

Status: Verified (3)

RFC 6844, "DNS Certification Authority Authorization (CAA) Resource Record", January 2013

Source of RFC: pkix (sec)

Errata ID: 3547

Status: Verified
Type: Editorial

Reported By: Sean Turner
Date Reported: 2013-03-15
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section s7.2 says:

auth         Reserved                [HB2011]
path         Reserved                [HB2011]
policy       Reserved                [HB2011]

It should say:

auth         Reserved                [RFC6844]
path         Reserved                [RFC6844]
policy       Reserved                [RFC6844]

Notes:

Better to use the datatracker history to find the values than the expired drafts.

Errata ID: 3528

Status: Verified
Type: Editorial

Reported By: Sean Turner
Date Reported: 2013-03-10
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section s7.3 says:

Reserved>

It should say:

Reserved

Notes:

The additional ">" is unnecessary.

Errata ID: 3532

Status: Verified
Type: Editorial

Reported By: Sean Turner
Date Reported: 2013-03-10
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section s7.3 says:

1-7          Reserved                 [RFC6844]

It should say:

1-7          Unassigned              [RFC6844]

Notes:

"Unassigned" is better than Reserved.

Status: Reported (2)

RFC 6844, "DNS Certification Authority Authorization (CAA) Resource Record", January 2013

Source of RFC: pkix (sec)

Errata ID: 5097

Status: Reported
Type: Technical

Reported By: Andrew Ayer
Date Reported: 2017-08-25

Section 4 says:

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.

It should say:

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
alias record specified at the label X.

Notes:

As currently worded, section 4 tells the CA to look up a DNAME record specified *at* the label X, and if one is found, look up a CAA record at the DNAME's target. This is contrary to the behavior of DNAME as specified in RFC 6672, which is to redirect names subordinate of the DNAME but not the DNAME itself.

Since DNAMEs cause CNAMEs to be synthesized for subordinate names, there is no need for implementers of CAA to care about the presence of DNAMEs at all, so this erratum simply removes any mention of DNAME.

Errata ID: 5200

Status: Reported
Type: Technical

Reported By: Richard Gibson
Date Reported: 2017-12-08

Section 3 says:

<Issuer Domain Name> [; <name>=<value> ]*

It should say:

<Issuer Domain Name> [; [ <name>=<value> ]* ]

Notes:

For values of the "issue" and "issuewild" property tags, section 3 specifies [; <name>=<value> ]* (which seems to indicate that every parameter is preceded by a semicolon) but the grammar in section 5.2 specifies [";" *(space parameter) space] (in which parameters are separated by whitespace and the entire list is preceded by a single semicolon). Presumably, the formal grammar is definitive and the preceding shorthand should be updated to better express it.

Status: Held for Document Update (5)

RFC 6844, "DNS Certification Authority Authorization (CAA) Resource Record", January 2013

Source of RFC: pkix (sec)

Errata ID: 4062

Status: Held for Document Update
Type: Technical

Reported By: Evan Hunt
Date Reported: 2014-07-24
Held for Document Update by: Kathleen Moriarty
Date Held: 2014-09-03

Section 5.1.1 says:

Value:  Is the <character-string> encoding of the value field as
specified in [RFC1035], Section 5.1.

It should say:

Value:  The value field, expressed as a contiguous set of characters
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.

Notes:

<character-string> is defined in RFC 1035 as being limited to 255 characters
preceded by a length byte. Saying the field is encoded as a <character-string>
creates ambiguity as to whether the value field is intended to be size-limited.

RFC author agreed that it was okay to make this more explicit with the proposed text.

Errata ID: 5065

Status: Held for Document Update
Type: Technical

Reported By: Phillip Hallam-Baker
Date Reported: 2017-07-10
Held for Document Update by: EKR
Date Held: 2017-08-22

Section 4 says:

   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.

It should say:

   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.

  ?O?therwise, 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.

Notes:

This is the updated errata to replace the ones previously deleted. It has been reviewed by all the parties concerned. Since this is a breaking change, this will have to go to hold for document update. The LAMPS working group is currently considering a more radical re-working of the CAA discovery scheme as a work item for its new charter.

I will be in Prague to discuss...

Errata ID: 4070

Status: Held for Document Update
Type: Editorial

Reported By: JINMEI Tatuya
Date Reported: 2014-08-05
Held for Document Update by: Kathleen Moriarty
Date Held: 2014-09-04

Section 3 says:

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

It should say:

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

Notes:

The original text is obviously incorrect (or at least something not really intended) in that the owner name is absolute. It just doesn't make sense to use $ORIGIN if we use an absolute owner name for the actual RR. The "corrected text" is one representation of what I guess the author really intended.

There are other instances of the same kind of this error in this section, but I don't bother to list all of them as it should be obvious and the sense of the "fix" should be the same.

From the verification of the errata:
The errata is correct as reported with the following caveat, some implementations of DNS presentation format assume all $ORIGIN statements are Fully Qualified Domain Names,
but others do not and those will take the domain name and append to it current origin.
Thus the trailing dot removes any ambiguity that the name specified is FQDN.

Errata ID: 5090

Status: Held for Document Update
Type: Editorial

Reported By: Mak Kolybabi
Date Reported: 2017-08-18
Held for Document Update by: Kathleen Moriarty
Date Held: 2017-08-22

Section 2.2 says:

   Resource Record Set (RRSet):  A set of Resource Records or a
      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 RRs in the RRSet.

It should say:

   Resource Record Set (RRSet):  A set of Resource Records for a
      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 RRs in the RRSet.

Notes:

Changed 'or' to 'for', the former not making sense in this context and being a likely typo.

Errata ID: 5091

Status: Held for Document Update
Type: Editorial

Reported By: Mak Kolybabi
Date Reported: 2017-08-18
Held for Document Update by: Kathleen Moriarty
Date Held: 2017-08-22

Section 4 says:

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

It should say:

   o  If CAA(X) is not empty, R(X) = CAA(X), otherwise

Notes:

Remove unnecessary space after second CAA, making appearances of CAA(X) consistent throughout the section.
This builds on errata 5065, where this error wasn't fixed.

Status: Rejected (3)

RFC 6844, "DNS Certification Authority Authorization (CAA) Resource Record", January 2013

Source of RFC: pkix (sec)

Errata ID: 4061

Status: Rejected
Type: Technical

Reported By: Evan Hunt
Date Reported: 2014-07-24
Rejected by: Kathleen Moriarty
Date Rejected: 2014-09-03

Section 5.1 says:

Tag values SHOULD NOT contain any other characters.

It should say:

Tag values MUST NOT contain any other characters.

Notes:

Since the text representation of the tag field is unquoted, spaces and other whitespace must be explicitly excluded. Otherwise, it is possible to create a CAA record whose text representation cannot be parsed.
--VERIFIER NOTES--
This really gets down to MUST/SHOULD theology and whether you consider
the zone file syntax at the same level of conformance as DNS protocol.

The author believes SHOULD is correct here. The protocol on the wire will work
just fine if someone breaks this advice.

Yes, it might well break some zone file parsers. But those aren't on
the wire and that type of incompatibility is exactly what I would
expect from violating a SHOULD.

Code has to work if someone creates a RR with a non conformant label,
therefore a MUST does not saves any work. And the only circumstance in
which the editor can imagine someone using it would be where they wanted a
label that could not be inserted through normal zone files.

Phil Hallam-Baker certainly doesn't want people writing parsers to strip out records
with non conformant labels. So, stick with SHOULD.

Errata ID: 4515

Status: Rejected
Type: Technical

Reported By: Tom Clegg
Date Reported: 2015-10-29
Rejected by: Kathleen Moriarty
Date Rejected: 2017-08-22

Section 4 says:

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =
      R(A(X)), otherwise

It should say:

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =
      CAA(A(X)), otherwise

Notes:

R is the algorithm being described here, so R(A(X)) means a recursive search on the CNAME target, including its parents. However, the example that follows, Parent(Alias(x.y.z)) is not part of the search. Either the algorithm is incorrectly specified, or the example is incomplete.

While this change is correct, it has already been accepted with HFDU in errata 5065.
--VERIFIER NOTES--
Errata 5065 was accepted first and covers this error.

Errata ID: 4922

Status: Rejected
Type: Technical

Reported By: Attila Bruncsák
Date Reported: 2017-02-03
Rejected by: Stephen Farrell
Date Rejected: 2017-02-03

Section 4 says:

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

It should say:

The search for a CAA record must not climb the DNS name tree from the
   specified label up.

Notes:

Obviously it does not make any sense to climb up. If there would be CAA record published for the "com" TLD, than it would make what relation to the CAA of the "example.com" domain? From an other viewpoint: all CAs are going to check the "com" TLD for CAA record if a given organization has no CAA record published in its own domain?
Another, more practical example: "example.com" needs a certificate for his top domain (https://example.com/), so it decides to publish the CAA record to enforce the security. Doing this it may unknowingly affect the renewal of the certificate for the wellhidden.hr.example.com where the hr.example.com domain is under different administrative authority than example.com domain itself.
--VERIFIER NOTES--
This would be a change and hence is not an erratum

Report New Errata