Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC

On 18 November 2012 03:57, Paul Wouters <paul@nohats.ca> 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
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey