There are lots of tricky problems here. * DNSSEC assertions are time limited * DNSSEC record signatures have to be rolled up into some sort of container before they could be used * TRANS assumes X.509v3 certs.
The simplest way to align things is to simply have a certificate issued for the DNSSEC zone KSK and plop that in the log as normal. The actual certificate could be self signed or signed by another hierarchy. I can't see any value in making specific requirements about the cert unless there is an ulterior motive to ram some other technology down people's throats. Which is a really bad move for trying to get adoption of a science lab stage technology. We did that with PGP (and S/MIME come to think of it). Given the Trans architecture, it probably makes most sense if someone is signing the certificate with some sort of key because the basic principle of Trans is that the log is holding the certificate issuer accountable for what they sign. But rolling up self signed certs into a trans log can also make sense. On Fri, May 9, 2014 at 5:31 PM, Nico Williams <[email protected]> wrote: > DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. > > It stands to reason that DNSSEC should have similar trust problems as > PKIX. I believe it does indeed. > > It follows that things like CT that we're applying to PKIX should be > applied to DNSSEC as well, where possible. > > I don't see any reason why CT couldn't be extended to DNSSEC. IMO, it > should be done. > > Note that DNSSEC needs CT independently of protocols like DANE, but > any protocol that allows a DNSSEC MITM to bypass PKIX CT (as DANE > effectively does) should increase the need for CT for DNSSEC. > > Note too that I'm not in any way saying that DANE and similar should > block on CT for DNSSEC. > > Sincerely, > > Nico > -- > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans -- Website: http://hallambaker.com/ _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
