Subject: [pkix] I-D Action: draft-ietf-pkix-caa-14.txt

From: [email-masked]
Date: Sat, 06 Oct 2012 19:32:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : DNS Certification Authority Authorization (CAA) Resource Record
	Author(s)       : Phillip Hallam-Baker
                          Rob Stradling
	Filename        : draft-ietf-pkix-caa-14.txt
	Pages           : 18
	Date            : 2012-10-06

Abstract:
   The Certification Authority Authorization (CAA) DNS Resource Record
   allows a DNS domain name holder to specify one or more Certification
   Authorities (CAs) authorized to issue certificates for that domain.
   CAA resource records allow a public Certification Authority to
   implement additional controls to reduce the risk of unintended
   certificate mis-issue.  This document defines the syntax of the CAA
   record and rules for processing CAA records by certificate issuers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pkix-caa

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pkix-caa-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-caa-14

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 8 Oct 2012 12:27:25 +1100

Comments on draft-ietf-pkix-caa-14

3. The CAA RR type
<issue> and <iodef> tags are listed, but not <issuewild>.

5.2. CAA issue Property: ABNF typos
  <Property> is missing a ']';
  <parameter> has extraneous '/';
  <space> would be better just in <Property>, not also in <parameter>;
  <VCHAR> includes <DQUOTE> so <value> is ambiguous. 

WRONG:
  Property = space [domain] space [";" space * (parameter space)
  parameter =  / space tag "=" value
  value = *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE

RIGHT:
  Property = space [domain] space [";" *(space parameter) space]
  parameter = tag "=" value
  value = *VCHAR

Adding a quoting mechanism for <value> allows only one extra character SPACE. It's not worth it. A quoting mechanism would also interact awkwardly with the (under-specified) presentation format.

5.1.1. Canonical Presentation Format
The 'Value' part of a CAA record is specified as a "sequence of octets". The presentation format is specified as "the US-ASCII text Encoding of the value field". I’m not sure where that "text Encoding" is defined, perhaps RFC1035 "Domain Implementation and Specification" section 5.1. Master Files Format. Does it say always-wrap-in-double-quotes?

8.1. Normative References
RFC1034 and RFC1035 appear twice: once as themselves; then again as STD13

--
James Manger

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Oct 2012 11:26:52 -0400

> <issue> and <iodef> tags are listed, but not <issuewild>.

Fixed

> Adding a quoting mechanism for <value> allows only one extra character
> SPACE. It's not worth it. A quoting mechanism would also interact awkwardly
> with the (under-specified) presentation format
>

Fixed

> The 'Value' part of a CAA record is specified as a "sequence of octets".
> The presentation format is specified as "the US-ASCII text Encoding of the
> value field". I’m not sure where that "text Encoding" is defined, perhaps
> RFC1035 "Domain Implementation and Specification" section 5.1. Master Files
> Format. Does it say always-wrap-in-double-quotes?
>

No, it says that the quotes are optional unless there is a space in the
field:

http://www.ietf.org/rfc/rfc1035.txt

<character-string> is expressed in one or two ways: as a contiguous set
of characters without interior spaces, or as a string beginning with a "
and ending with a ".  Inside a " delimited string any character can
occur, except for a " itself, which must be quoted using \ (back slash).

              <t hangText="Value:">
                Is the &lt;character-string&gt; encoding of the value field
as specified in
                <xref target="RFC1035"/> section 5.1.

> RFC1034 and RFC1035 appear twice: once as themselves; then again as STD13

This is intentional.

STD13 is not simply the concatenation of RFC1034 and 1035, it tracks the
current status of the standard. The reference to STD13 is made in the
definitions because that is the standard.

The references to 1035 are made in the context of describing the peculiar
bit numbering convention and the specific description of the zone file. In
these cases it seems better to follow the convention of choosing one
specific edition of the document rather than the standard.

-- 
Website: http://hallambaker.com/