Subject: Re: [pkix] WGLC for draft-ietf-pkix-caa-07

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Jun 2012 16:49:08 -0700

On May 31, 2012, at 11:55 AM, Stephen Kent wrote:

> Having read through the backlog of mail I see that PHB has requested
> WGLC for draft-ietf-pkix-caa-07.
> 
> So, the WGLC begins tomorrow (6/1) and completes on 6/15.

I have read the latest version of the document and it seems fine.

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Sat, 2 Jun 2012 19:13:53 -0400

> WGLC for draft-ietf-pkix-caa-07.

In summary:

Terminology is used inconsistently, and in some cases new terms are
created when existing ones would do (or so it seems, as I don't fully
understand this I-D).  Terms are also defined unclearly, or have
examples (apparently) inconsistent with the definitions.

Most of this document is unclear on first reading. Terms, formats, etc
are used before they are defined.  I suppose if I read this again, I
might understand it better, but I shouldn't have to. As it is, I had to
re-read many sections 2-4 times before I got to where I thought I
understood them.

I'm especially confused about where I'm allowed/supposed to place CAA
records in the DNS, and what effect it will have if I do so (largely due
to section 3 being very unclear). I'm also unclear how binary data/value
fields are handled in presentation format.

Most everything else I think I understood eventually.

Now for the specifics:

Section 1.2:

From 2.1:
>  Critical  If set, indicates that the corresponding property entry tag
>     MUST be understood if the semantics of the CAA record are to be
>     correctly understood by the specified audience.
>
>     Issuers MUST NOT issue certificates for a domain if the Extended
>     Issuer Authorization Set contains unknown property entry tags that
>     have both the Issuer and Critical bits set.

What "Issuer" bit/flag? There is no such bit/flag defined.

>  The following properties are defined:
>
>  issue <Domain Name> [; <tag=value> ]*  The issue property entry
>     declares an authorization entry granting authorization to issue to
                                                                      ^^
>     the holder of the specified domain name or a party acting under
>     the express written authority of the holder of the domain name.

...

>  The following example informs CAs that certificates MUST NOT be
>  issued except by the holder of the domain name 'ca.example.net' or an
                 ^^                                ^^^^^^^^^^^^^^
>  authorized agent thereof.  Since the policy is published at the
>  Public Delegation Point, the policy applies to all subordinate
>  domains under example.com.
>
>  $ORIGIN example.com
>  .       CAA 0 issue "ca.example.net"

This appears to contradictory.

I'm guessing that the latter is correct, and the "specified domain name"
in the earlier paragraph isn't referring to the "<Domain Name>" field.

It should probably be "issue <CA Domain Name>" and the following text
should clarify between the CA domain name and the domain that the record
is for.

I'm not sure I like that examples of CAA RRs are provided before the
syntax of the CAA record has actually been defined--it's making this
very hard to understand.

The definition for Public Delegation Point is unhelpful to me. What's a
"Top Level Directory"? Is this a TLD? (TLD expands to Top-Level Domain,
not Directory). Apparently not, since example.com isn't a TLD, so what
is it?  How does an issuer know if a given domain is a registry/public
delegation point or not? If you mean to say that parent domains can set
CAA records for their subdomains, just say so--don't invent new terms
for it.

Honestly, the document is a mess of terminology and jargon.

In section 2.1, we have "property entries", "flags", "properties", and
"tag-value pairs".  In section 3, we also have "[CAA] Authorization
Entry", "Extended Issuer Authorization Set", and "Issuer Authorization
Set", etc which are defined, but not in the same terms as in section
2.1.  They seem to overlap in meaning with the terms in section 2.1, but
might not. I don't know.

Section 3:

The definition of Extended Issuer Authorization Set (EIAS) is
unnecessarily complex. The definition in 1.2 implies that my parent
domain (or PDP) can set CAA records that apply to me (otherwise the
"extended" terminology doesn't make any sense) but a straightforward
reading of the definition in this section says that CAA records can only
be set on domains immediately below a TLD (or a CCTLD SLD). (I think
that's what you mean by PDP.)

That's conveniently the same set of entities that public CAs will issue
certificates for (AFAICT)--domains with entries in a whois database.

So why all this convoluted terminology & indirection for determining if
a CAA record is valid or not when what it really comes down to is "CAA
records on the domain that an issuer is willing to consider issuing
certs for"? Or if you don't want to be that loose about it for some
reason, then say "CAA records are only valid on domains delegated to by
registries". That should save at least a page of text.

But your example in section 3 implies I've misread again, because
according to your rules, caa.example.com's EIAS is empty, but your
example claims otherwise. I'll let someone explain where I misparsed.

Section 3.1

You went through the trouble of defining canonical names abstractly (I
thought to make it possible to handle future BNAME, SHADOW, or whatever
records in the future), but then explicitly call out CNAME and DNAME
here. If a future BNAME comes about, there is no requirement to process
such records correctly. Therefore you don't need the definitions in 1.2.

Section 4.1:

I think you're mixing up "tag value pairs" and "properties" compared to
the discussion of this in section 2.1--the syntax shown there allow
there to be zero or more tag-value pairs.  However, the first sentence
here say that there is only one per RR. In 2.1-speak, you have one
property per RR.

>  +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  |
>  +----------------+----------------+...+---------------+
>  +----------------+----------------+.....+---------------+
>  | Data byte 0    | Data byte 1    |.....| Data byte m-1 |
>  +----------------+----------------+.....+---------------+

The formatting of the wire format causes me to overlook the flags & tag
length fields. Even when I know they're there, I still tend to ignore
them.

>  Where n is the length specified in the tag length field and m is the
>  remaining octets in the data field (m = d - n - 2) where d is the
>  length of the data section.

d is never used in the figure. What is "the length of the data section"?
Is it the size of the RDATA (RDLENGTH) or the number of data bytes?
Assuming your equation is right, it's the former.

I'd recommend a presentation more like what's shown in RFC 1035:

>                                   1  1  1  1  1  1
>     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>   |                                               |
>   /                                               /
>   /                      NAME                     /
>   |                                               |
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>   |                      TYPE                     |
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>   |                     CLASS                     |
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>   |                      TTL                      |
>   |                                               |
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>   |                   RDLENGTH                    |
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
>   /                     RDATA                     /
>   /                                               /
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

(Especially since your RRtype is mostly variable-length fields.)

The critical flag is called Issuer Critical Flag here, but just
"Critical [Flag]" in section 2.1.

>  Tag  The property identifier, a sequence of ASCII characters.
>
>     Tag values MAY contain ASCII characters a through z and the
>     numbers 0 through 9.  Tag values MUST NOT contain any other
>     characters.  Matching of tag values is case insensitive.

Are you sure you don't want to include dashes? What if you want to
define a tag with multiple words in it in the future? I guess you could
just do camelcase.

>  Tag Length  A single octet containing an unsigned integer specifying
>     the tag length in octets.  The tag length MUST be at least 1 and
>     SHOULD be no more than 15.

Making the max tag length a SHOULD seems useless to me.  If I'm
implementing software that parses the RR (but doesn't process it), I
must assume that the tag length could be 255, or I'll break if another
CAA specification comes out that creates a tag > 15 bytes long.  If I'm
processing the record, I could ignore CAA records with tag lengths not
equal to the lengths of any tags I recognize (I won't be able to process
the records anyway), but then the limitation on tag length doesn't
really help me out either.

>  Value  A sequence of octets representing the property value.
>     Property values are encoded as binary values and MAY employ sub-
>     formats.

Ok, so above, in your wire format, there is nothing labeled "Value" or
even "Value byte". Below, in your presentation format, there is no
"Value" either--just data.

Section 4.1.1:
Again, "tag" isn't defined consistently with section 2.1.

Assuming that data = "Value" above, data can be a binary field.

>  CAA <flags> <tag> <data>
...
>  data  Is the ascii text Encoding of the value field

What does "ascii text Encoding of the value field" mean? Does that mean
that it'll be one of "US-ASCII", "UTF-8", etc? If so, where does the
value go?  If data = Value, then since Value can be binary data, what
encoding is it?  That either means (to me) that non-printable characters
aren't allowed or that there's some kind of encoding of the binary data
into printable ascii that's required, but that encoding isn't defined.

Section 4.2:

Underscores aren't legal in domain names. Is there an existing ABNF
production for a domain name that you could use instead (in case the set
is expanded later?) You should also probably specify that this is in
A-label form.

>  value = *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE

"|" isn't a legal ABNF operator. Also, DQUOTE is included by VCHAR.  For
the record, how do quotes needed to delimit the data field of a CAA
record presentation format interact with quotes in a parameter value? Is
that worth allowing quotes in a value?

(Again, you've mixed up "tag" and "property" and "value" throughout the
document, making the prior sentence ambiguous.)

By the way, how should issuers process malformed CAA records? Ignore
them? Not issue?

What's an "issuer-parameter"?

Section 5:

I debate the correctness of the last paragraph -- if Google had
published CAA records, DigiNotar would still have issued those certs.

Section 5.2:

If the record is signed, bogus records had better be ignored. That
needs to be added as a requirement in section 3.2 -- if DNSSEC is used,
the record MUST not be bogus (ditto for denial of existence).  Oh, I see
that you say that in 5.2.1, but that probably is better placed in 3.2.

I realize this section is ignoring DNSSEC, but it should be clear that
this only applies for insecure domains. 

Section 5.2.1:

You say that lookup SHOULD be via authoritative servers, but then that
you MUST NOT use cached data. Which is it?

What additional anti-spoofing or anti-suppression controls are you
referring to? Not looking for an exhaustive list, but some examples
would be nice.

Section 5.3:

A CAA record can be malformed and yet secure. What are issuers supposed
to do?

Section 6.1/6.2:

You don't label the first column. Which makes your direction to IANA
about how to add to the registry ambiguous--especially in light of
inconsistent wording.

I hope this helps.

-- 
Scott Schmit

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Jun 2012 13:39:20 -0400

> examples (apparently) inconsistent with the definitions.

Can you give examples? I don't know which terminology you are referring to here.

> What "Issuer" bit/flag? There is no such bit/flag defined.

Ah, this seems to be an artifact of having removed the issuer flag.
Suggest the following instead.

Critical

If set, indicates that the corresponding property entry tag MUST be
understood if
the semantics of the CAA record are to be correctly interpreted.

Issuers MUST NOT issue certificates for a domain if the Extended Issuer
Authorization Set contains unknown property entry tags that have the
Critical bit set.

>>  issued except by the holder of the domain name 'ca.example.net' or an

I don't see any inconsistency. In both cases the text appears to me to
read the same.

In the first case the text refers to an access control entry and so is
a GRANT of a right, in the second the text refers to an ACL and so
describes an exclusive right.

> should clarify between the CA domain name and the domain that the record

Does this make it clearer?

                            The issue property entry declares an
authorization entry
                            granting authorization to issue to the
holder of the
                            domain name <Domain Name> or a party
acting under the express
                            written authority of the holder of that domain name.

> syntax of the CAA record has actually been defined--it's making this

I think I have used that particular approach in pretty much every spec
I have written in the past ten years. I find that the majority of
readers work from the examples rather than the syntax. This is
particularly common in W3C and OASIS specs where the sections tend to
be marked as normative or non-normative.

> CAA records for their subdomains, just say so--don't invent new terms

That is a well known term of art that a CA is already required to
track in their practices. A public delegation point is NOT a TLD
because many CC TLDs delegate from SLDs e.g. '.co.uk'

> registries". That should save at least a page of text.

Because several parties pointed out that they have a need to apply
specific controls to particular subdomains.

> example claims otherwise. I'll let someone explain where I misparsed.

Ah, there is a bug here, 'is empty' should have been 'is not empty'.

If the Issuer Authorization Set for the domain is not empty, the Extended Issuer
Authorization Set is the Issuer Authorization Set for the domain.

If the immediately superior node in the DNS hierarchy is a Public Delegation
Point, the Extended Issuer Authorization Set is empty.

Otherwise the Extended Issuer Authorization Set is that of the immediately
superior node in the DNS hierarchy.

> such records correctly. Therefore you don't need the definitions in 1.2.

I don't see the logic there. If BNAME is added, so what? It is not
going to replace CNAME or DNAME in our life times.

The CAA spec cannot require CAs to process DNS records that have yet
to be invented.

An issuer MUST perform CNAME and DNAME processing as defined in the
DNS specifications
[RFC1035] to resolve CAA records.

Where n is the length specified in the tag length field and m is the
remaining octets in the
data field (m = d - n - 2) where d is the length of the RDATA section.

> (Especially since your RRtype is mostly variable-length fields.)

I have always found those confusing because they suggest to me that
the data sections are aligned on word or quadword boundaries.

ASCII art is a bad way to present data.

> "Critical [Flag]" in section 2.1.

OK, will make it issuer criticality in both places.

> define a tag with multiple words in it in the future? I guess you could

The properties have to fit in the DNS which is pretty much constrained
to 500 bytes. So I don't see much call for enormous tags.

I did think of putting dashes in but the code for various DNS servers
persuaded me that was probably not a good plan.

> really help me out either.

The reason for the SHOULD is just to try to persuade folk not to bloat
the tag and make the records unnecessarily long. It is a performance
issue and hence a SHOULD is appropriate.

> "Value" either--just data.

I will change the diagram to read Value so that then there is no
confusion between Data and RDATA.

> into printable ascii that's required, but that encoding isn't defined.

ASCII to me means ASCII which would imply to me NOT UNICODE. I changed
it to US-ASCII

Here there is a divergence between the code and the spec.

My patch for BIND allows records to use binary field values and we use
this for certificate hashes and such. But these properties are not
specified in the spec and in fact our only records we have spec for
are ascii records and I am tending to think we might end up going all
ascii.

> published CAA records, DigiNotar would still have issued those certs.

If DigiNotar had processed anything correctly they wouldn't have

> this only applies for insecure domains.

There is no need for the subsection, I merged 5.2 and 5.2.1

> referring to? Not looking for an exhaustive list, but some examples

                    In cases where DNSSEC is not deployed in a
corresponding domain, a
                    CA 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.

> A CAA record can be malformed and yet secure. What are issuers supposed

Manual exception processing - tell the customer to fix their DNS
before they can get a cert.

Should probably add a section to mention this.

> about how to add to the registry ambiguous--especially in light of

Thanks, I will print out the current edit copy and then go through and
audit the tag/property issue.

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

---

From: Scott Schmit <[email-masked]>
Date: Thu, 21 Jun 2012 01:16:05 -0400

On Wed, Jun 20, 2012 at 01:39:20PM -0400, Phillip Hallam-Baker wrote:
> On Sat, Jun 2, 2012 at 7:13 PM, Scott Schmit wrote:
> > Now for the specifics:
> >
> Critical
> 

That works.

> The issue property entry declares an authorization entry granting
> authorization to issue to the holder of the domain name <Domain Name>
> or a party acting under the express written authority of the holder of
> that domain name.

Not really. The problem is that I can read that two ways:

<domain name> = the domain held by the entity inserting this record into
the DNS

i.e., "The issue property entry is an ACL allowing an unnamed issuer to
issue a certificate with subject <domain name> to <domain name>"

or

<domain name> = the domain held by/associated with the entity processing
this record

i.e., "The issue property entry is an ACL allowing an issuer that owns
<domain name> to issue certificates with subject <DNS RR NAME> to
<DNS RR NAME>"

Granted, the latter is the only one that makes sense, but my brain went
straight to the former and assumed there was something wrong with your
text.

Since I'm not an issuer, I read this spec as about how a holder of a
domain name can protect the integrity of the domain with the cooperation
of issuers, not as a spec for issuers where the holder of the domain
name is a third party.  It's both, of course, but if you're not an
issuer, you'll probably read it the former way.  Hence my suggestion
that you be more specific about whose domain you're talking about in the
template text.

Your text seems like an overly-complex way of saying:
  The issue property entry authorizes an issuer identified by <CA Domain
  Name> (or a party acting under the authority of that issuer) to issue
  a certificate to the holder of the domain name.

> be marked as normative or non-normative.

Ok, but keep in mind that if you've never seen this spec before, you
don't know anything about the number in the example.  I felt that I was
led to believe that the prior property definitions were the entirety of
the record format.

You do explain the critical flag, but the way you described it, it
sounds like it's specified in the [; <tag=value>]* part of the syntax.
("...tagged with...")

So, when I saw the example, I didn't know what the number is for, which
called into question whether I understand the syntax at all, and how
much else I didn't know about this new RR type.

Hence my feeling that the example hurt more than it helped.

The easy way to fix this is to explain that every record starts with a
number representing the flags that are set, if any, followed by the
property entry. (And be careful about how you use the word "tag".)

> because many CC TLDs delegate from SLDs e.g. '.co.uk'

Ok, now I understand, but if it's well-known, it's not very well-used
where Google can see it.  A google search for '"public delegation point"
dns' only gets hits for your draft and discussions of it.

"Public Suffix" seems to be a much more widespread name, just going by
the Google search results for that term.  See
https://en.wikipedia.org/wiki/Public_Suffix_List.  Apparently "effective
TLD" is also used. http://publicsuffix.org/list/ might not be a
bad informative reference, just in case someone is looking for an
authoritative list.

I'd also suggest that in the definition, you say something like: "such
as .com or .co.uk" and NOT use example.com as an example of one later
(though you may be able to avoid specific examples using the reference
above).

> specific controls to particular subdomains.

Ok, I'll have to re-look at this when I have more time available, but in
the meantime I'd strongly suggest coming up with a way of defining how
to use a CAA record without inventing new terms like "Extended Issuer
Authorization Set" -- I'm not convinced you need to, and it really hurts
readability.

> going to replace CNAME or DNAME in our life times.

My logic is that you go out of your way to define canonical domain name,
etc in a more abstract sense and then never use it in an abstract sense.
If your readers are expected to know what CNAMEs and DNAMEs are (and
that makes perfect sense to me), you don't need to redefine that for
them.

> the data sections are aligned on word or quadword boundaries.

Fair enough, but your existing example implies an alignment but then
breaks it, leaving it a little unclear what you intended.

This works better, IMHO:

    0  1  2  3  4  5  6  7
  +--+--+--+--+--+--+--+--+
  |     Flags             |
  +--+--+--+--+--+--+--+--+
  |     Tag Length        |
  +--+--+--+--+--+--+--+--+
  /     Tag               /
  /                       /
  +--+--+--+--+--+--+--+--+
  /     Value             /
  /                       /
  +--+--+--+--+--+--+--+--+

That implies no alignment, but clarifies that some parts are
variable-length.

> to 500 bytes. So I don't see much call for enormous tags.

Ok, that makes sense. Probably wouldn't hurt to state that as rationale
for the SHOULD (it wasn't obvious to me).

> persuaded me that was probably not a good plan.

Oh, I didn't think of that.  That said, you could always pave the way for
others...  That, and it shouldn't be *that* hard to factor out the
"parse LDH" code from "parse domain name."  But it's a reasonable
choice, I just thought I'd point out alternatives that might help later.

By the way, I just noticed that section 4.1 says that "tag values"
(tags?) are case-insensitive, but section 4.1.1 says that tags are
lower-case.

> issue and hence a SHOULD is appropriate.

I'd recommend that you put that rationale in the document so that future
spec-writers understand the rationale.

> confusion between Data and RDATA.

Sounds good.

> ASCII to me means ASCII which would imply to me NOT UNICODE. I changed

Sorry, my brain translated that to "text" -- too used to sloppy language
at work.  US-ASCII should override my autocorrect nicely. :)

> are ascii records and I am tending to think we might end up going all

That's probably for the best--otherwise you need to specify how to
tell straight text apart from encoded binary (and how the binary is
encoded).  That just makes things more complicated for little gain,
IMHO.  (You can always define a specific tag's value to be a BASE64
encoding of a binary value if there's a compelling need for transmission
of binary data--it won't be quite as efficient, but it'll be
unambiguous).

> If DigiNotar had processed anything correctly they wouldn't have

Just saying that you're slightly overselling CAA here.

> In cases where DNSSEC is not deployed in a corresponding domain, a CA
> 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.

That works.

> Should probably add a section to mention this.

Agreed.

-- 
Scott Schmit