Right, and to my point: Each transparency mechanism has to be specific to the problem it's trying to solve. CT is not a magic cureall for transparency - it's specific to, well, certificates, and more generally, TLS web certificates.
For things like S/MIME, you have "Key Transparency" (based on COINKS) For things like binaries, you have "Binary Transparency" For things like DNSSEC authority records, you could have "DNSSEC transparency" It would be a mistake to think CT is some cureall, just like it would be a mistake to think "blockchain" suddenly solves all problems. The design of the technology, and its assumptions about the ecosystem, are relevant. The general problem of any *Transparency system is you need a way to authenticate the data that is logged to some extent, and you need a way to independently verify or evaluate that data. Certificates provide both signatures and trust chains, so you get both. The constraints around privacy of S/MIME certificates (which are unique to them) lend themselves to a different technical solution, like Key Transparency. As it relates to DNS, DNS sans-DNSSEC has no way to authenticate the data. So either your authentication is to introduce TTPs that can log the data (whether it's the Log or some multi-perspective contractually trusted third-party) or you need to find a way to sign the data (which DNSSEC is). Yet all that does is create a merkle hash tree - the system for ensuring and validating consistency and accuracy of that is also going to depend on the specific case. I agree that the fact that a certificate must be disclosed to a log, and that logs are independent of CAs, make it very easy and appealing to suggest that logs should serve as the counterbalance to CAs. That's neither the design nor the goal - logs are meant to be neutral record-keepers with no trust afforded to them - with monitors/auditors/clients keeping them honest, and anyone (not just CAs) being able to ask them to record the facts. There's obviously a gray area right now because of spec violations being things you want to log, but you also don't want to normalize - and CT Policy Days discussions around that continue to be interesting. But as it relates to CAA Transparency, it's both confusing the purpose of CAA (a machine readable expression of intent) and CT (no TTPs) On Thu, Nov 30, 2017 at 4:16 PM, Tim Hollebeek <tim.holleb...@digicert.com> wrote: > 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> 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. > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
