Subject: [pkix] Concerns with draft-ietf-pkix-caa-10

From: "Jeremy Rowley" <[email-masked]>
Date: Mon, 6 Aug 2012 13:05:04 -0600

Hi everyone, 

Because there are a variety of instances where a DNS record might not
accurately reflect the appropriate issuing CA (such as improper updating, a
delay in display, etc.) and compliance with this RFC is entirely voluntary
by the CA community, the requirements in Section 3 should be changed from
"MUST" to "SHOULD" recommendations.  Changing this section would allow
implementing CAs to accommodate customers who do not have a streamlined DNS
record updating system and make implementation more practical.

I also think the section on using DNSSEC to authenticate CAA RRs needs
further development. The recommendation to use DNSSEC in connection with the
proposal would be strengthened significantly if the proposal required the
DNS record holder to maintain and make available an archive of DNS records
instead of issuing CAs.

My biggest concern would be addressing the potential abuse mentioned in
Section 5.5.  Many enterprises have separate roles or departments that
handle DNS records from those ordering digital certificates. In fact, these
roles are often not in the same country.  This creates a 

probable point of failure by the implementers.  This separation between
certificate requesters and DNS record controllers also increases the risk
that the criticality flag can be abused as the controllers may be unaware of
the variety of certificates uses within the enterprises.  A bad-acting CA
could lock the enterprise into a long term and exclusive agreement without
the enterprise fully realizing the practical impact of agreement.  The
document should address the issue further and provide a recommendation on
how to overcome this likely scenario.

Jeremy

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Aug 2012 15:26:52 -0400

Dear colleagues,

On Mon, Aug 06, 2012 at 01:05:04PM -0600, Jeremy Rowley wrote:

> "MUST" to "SHOULD" recommendations.

I strongly disagree with that.  The section is considering how CAA
works for implementers.  If a CA doesn't want to implement it, the
MUST just doesn't have any effect.  If there are problems with the
operation of the DNS zone, it seems to me that the MUST becomes yet
another constraint on that operation.

SHOULD does not mean "oughta do this except when you don't".  It means
"you better have pretty good reasons not to do this".  If the zone
you're querying is wrong, you can't tell whether that's because the
zone has been subverted, the zone is administered by numbskulls, or
what.  Therefore, if you're using CAA, you shouldn't issue (and if
you're not using CAA, the MUST doesn't apply to you anyway).

> DNS record holder to maintain and make available an archive of DNS records

I don't understand this claim.  What's the additional strength from
this?  What the zone looked like in the past is surely irrelevant to
the current CAA query, no?

> the variety of certificates uses within the enterprises.  

This sounds like an argument that, because people don't know how to
operate their zones, we should make the protocol less rigorous.  I
cannot agree with such a proposal (any more than I think the proposals
to use fudge-factor DNSSEC validation or, for that matter,
long-expired A RRs are good ideas).  If you want to put stuff in the
DNS, you need to make sure you do it correctly.  If you think your DNS
department is too incompetent to use CAA correctly in your zone, don't
use CAA at all.  (I acknowledge, however, that "Don't use CAA at all,"
would be much happier advice if the only place the CAA record was
checked was at the owner name itself, rather than using the
tree-climbing crud the WG seems to want.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Aug 2012 12:37:52 -0400

As with all specifications, MUST means 'you must do this to be in
compliance with this specification'.

Hence CAA specifies MUST since they are normative. CAA is no more
voluntary than any other IETF specification. CAs can choose to
implement it or not but they may well find it more difficult to get
their trust anchors embedded if they don't.

CAs are in any case subject to an audit regime and so if they claim
compliance and don't implement they can fail their audit.

On Mon, Aug 6, 2012 at 3:26 PM, Andrew Sullivan <[email-masked]> wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

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