On 18 November 2012 03:57, Paul Wouters <[email protected]> wrote: > On Sat, 17 Nov 2012, Carl Wallace wrote: > >>> OK, so maybe you haven't been following the mailing list or reading the >>> draft. In the CT-for-PKIX proposal, individuals can submit their own >>> certificate. >> >> >> Under this approach, how does the log come to have certificates that a >> legitimate owner would like to be made aware of? I understand the utility >> of including the CT in the certificate and having an individual submit >> their certificate (or the CA on their behalf) but locking down a log to >> these sorts of inputs would seem to limit their usefulness for detecting >> rogue certs. > > > But allowing anyone to submit "new" certificates, allows hackers to do > the same. How is this authenticated?
Your questions confuse me. Have you read the draft? Or any of the various informal descriptions? > For the TLS cert, the "out of band" was via DNS its the MX record. Which > has in fact reduced the security of the CA vouching system. With DNSSEC, > and compromise there, it means even less. > > From my remote participation, I understood the CT audits were > restricted, and that only CAs could submit entries for the audit log, > which is why when this was mentioned I channeled via jabber about > "security through money", and that I thought this was an invalid approach. > (especially for CT-DNSSEC, as publishing DS records is free, unlike > getting a "recognised" PKIX certificate) > > On the lists I now hear anyone can submit, which also raises issues. > Perhaps there are very different thoughts for CT-PKIX-CA versus > CT-PKIX-selfsigned that I'm not aware of. > > CT-PKIX addresses an issue where there are 600 roots and you can't > trust all of them (although TLSA solves that too). I'm still unsure > what CT-DNSSEC would solve, as just pulling history from DNS does not > add anything, and I have no idea how to authenticate to the CT-DNSSEC > audit log to start an alternative path of trust, especially if you are > defendining against a rogue root or rogue .com key being used secretly > to sign alternative records, or a compromised DNSSEC private key. > > Paul > > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
