Wayne, your last point is closest to my thinking, and I whole-heartedly agree there may be better solutions. My suggestion was that if CAA transparency is a desired thing, and it is clear that at least a few people think it is worth considering, it’s probably better to do it with existing transparency mechanisms instead of making up new ones.
There’s a lot of CAA debugging going on in private right now, and there isn’t necessarily an a priori reason why it has to be private. -Tim From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Thursday, November 30, 2017 2:07 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: r...@sleevi.com; douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Paul Wouters <p...@nohats.ca>; Ben Laurie <b...@google.com>; Jeremy Rowley <jeremy.row...@digicert.com> Subject: Re: Anomalous Certificate Issuances based on historic CAA records What problem(s) are you trying to solve? - Subscribers already (or soon will) have CT logs and monitors available to detect mis-issued certs. They don't need CAA Transparency. - This thread started as a discussion over possible mis-issuance that was determined to be false positives. As has been stated, without DNSSEC there is no such thing as a coherent view of DNS and Ryan described a legitimate example where a domain owner may consciously update CAA records briefly to permit issuance. It's unclear to me how CAA Transparency could solve this problem and thus provide a mechanism to confirm mis-issuance, if that is the goal. - The goal of reducing the risk of mis-issuance from well-behaved CAs who have bad or manipulated CAA data seems most worthwhile to me. To Ryan's point (I think), there may be better ways of achieving this one such as requiring CAs to "gossip" CAA records, or requiring CAA checks be performed from multiple network locations. Wayne On Thu, Nov 30, 2017 at 2:00 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: I think there’s value in publicly logging things even if that isn’t the basis for trust. So I disagree that what I wrote boils down to what I didn’t write.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
