Re: [lamps] AD Review: draft-ietf-lamps-rfc6844bis-04

[Jacob Hoffman-Andrews <[e-mail]>]

I've pushed changes to my working copy in git at 
https://github.com/jsha/caa-simplification/compare/draft-04...master. 
I'll publish a new draft once we've resolved the remaining questions.

On 12/24/18 1:32 PM, Eric Rescorla wrote:
>  >      iodef <URL> : Specifies a URL to which an issuer MAY report
> 
> I know that this seems nitpicky, but the rules here seem
> underspecified. Specifically,  you don't say that you can't issue of
> neither "issue" nor "issuewild" is present. Also, see below.

Actually, if neither "issue" nor "issuewild" is present you *can* issue. 
I've moved the clarification of that fact from the individual tag 
definitions to Section 4:

"If the relevant resource record set for a domain name or wildcard 
domain name contains no property tags that restrict issuance
(for instance, if it contains only iodef property tags, or only property 
tags unrecognized by the CA), CAA does not restrict issuance."

> S 4.1.
>  >   4.1.  Use of DNS Security
>  >
>  >      Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED 
> but not
>  >      required.  An issuer MUST NOT issue certificates if doing so would
>  >      conflict with the relevant CAA Resource Record set, irrespective of
>  >      whether the corresponding DNS records are signed.
> 
> what if I get a bogus record set which would preclude signing?

A bogus resource record set would return SERVFAIL from the authoritative 
resolver, which the CA should treat as an error.

> say we have "issuewild" for "example.com <http://example.com>", I know I 
> can issue for
> "*.example.com <http://example.com>", but how about "*.a.example.com 
> <http://a.example.com>"

I've added a definition for "wildcard domain name" and rephrased to make 
this clearer:

Wildcard Domain Name: A Domain Name consisting of a single asterisk
    character followed by a single full stop character (“*.”) followed
    by a Fully-Qualified Domain Name.

issuewild <Issuer Domain Name> \[; &lt;name>=&lt;value> ]* :  The issuewild
    property entry authorizes the holder of the domain name &lt;Issuer
    Domain Name> or a party acting under the explicit authority of the
    holder of that domain name to issue certificates for wildcard domain 
names
    **where this property tag is in the wildcard domain name's relevant 
resource
    record set.**

This combines with the processing rules:

Given a request for a specific domain name X, or a request for a 
wildcard domain
name *.X, the relevant resource record set RelevantCAASet(X) is 
determined as follows: [...]

> Wait, are you saying that "issue" allows wildcard issuance?

Yes, if there is just an "issue" property tag but no "issuewild" 
property tag, and the "issue" property tag matches a CA, that CA is 
allowed to issue wildcard certificates.

>  >      issuewild properties MUST be ignored when processing a request for a
>  >      domain that is not a wildcard domain.
> 
> What's the reasoning for this? In general, it seems like a wildcard
> domain is more powerful than a non-wildcard.

I'm not sure; this is carried over directly from RFC6844. My guess is 
that it's to ensure it's possible to specify a disjoint set of issuers 
for wildcard vs non-wildcard domain names.

> COMMENTS
> S 1.
>  >      sufficient condition for issuance of a certificate.  Before 
> issuing a
>  >      certificate, a PKIX CA is required to validate the request according
>  >      to the policies set out in its Certificate Policy.  In the case of a
>  >      public CA that validates certificate requests as a third party, the
>  >      certificate will typically be issued under a public trust anchor
>  >      certificate embedded in one or more relevant Relying Applications.
> 
> These two sentences don't really connect, as the Policy may just say
> nothing about CAA.

Deleted.

> This needs to be updated to RFC 8174.

Done.

>  >      Domain: A DNS Domain Name.
> 
> This probably needs a cite.

I replaced all instances of "domain" with "domain name" and deleted this 
definition. The definition of "domain name" has a cite already.

> S 3.
>  >
>  >      issue <Issuer Domain Name> [; <name>=<value> ]* : The issue property
>  >      entry authorizes the holder of the domain name <Issuer Domain Name>
>  >      or a party acting under the explicit authority of the holder of that
>  >      domain name to issue certificates for the domain in which the
>  >      property is published.
> 
> How about for subdomains?

Clarified by rewriting to refer to the "relevant resource record set" 
for a domain, which defines the relationship with subdomains.


>  >      issuewild <Issuer Domain Name> [; <name>=<value> ]* : The issuewild
>  >      property entry authorizes the holder of the domain name <Issuer
>  >      Domain Name> or a party acting under the explicit authority of the
>  >      holder of that domain name to issue wildcard certificates for the
>  >      domain in which the property is published.
> 
> This is not entirely clear. Say the CAA is at a.example.com 
> <http://a.example.com>, I assume
> that this means I can issue wildcards for "*.x.example.com 
> <http://x.example.com>" not
> "*example.com <http://example.com>"

This comment made me realize that Section 3 and Section 5 are 
essentially duplicates of each other. I'll add another commit deleting 
Section 3 and making Section 5 canonical.

> S 7.1.
>  >      This generally manifests as a timed-out DNS query, or a SERVFAIL 
> at a
>  >      local recursive resolver.
>  >
>  >      For deployability of CAA and future DNS record types, middleboxes
>  >      SHOULD block DNS packets by volume and size rather than by query
>  >      type.
> 
> This sentence doesn't seem appropriate for a doc in a SEC WG.

Deleted.

> What is the reader supposed to do with this sxn?
> I'm not sure what I'm supposed to do with this section either.. What's
> the take-home?

I've added a sentence to the top of "Deployment Considerations:"

 > A CA implementing CAA may find that they receive errors looking up 
CAA > records. The following are some common causes of such errors, so 
that > CAs may provide guidance to their subscribers on fixing the 
underlying > problems.


 > Acknowledgements
 >...
> Is this by any chance "James Manger"

Fixed.