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

Ben Laurie <benl@google.com> Mon, 19 November 2012 13:34 UTC

MIME-Version: 1.0
In-Reply-To: <CCCF9A14.36504%carl@redhoundsoftware.com>
References: <CABrd9SQrtaKTupOhPRyuomHaEXRopCE+vw_aqaYjC-F7uEKfwA@mail.gmail.com> <CCCF9A14.36504%carl@redhoundsoftware.com>
Date: Mon, 19 Nov 2012 13:34:15 +0000
Message-ID: <CABrd9SRv9Xcpos7jPFpFmfwo3cdopEWR7_tXX_p_MBpuh7bTqw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: therightkey@ietf.org, Paul Wouters <paul@nohats.ca>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC
Precedence: list

On 19 November 2012 13:20, Carl Wallace <carl@redhoundsoftware.com> wrote:
> On 11/19/12 8:08 AM, "Ben Laurie" <benl@google.com> wrote:
>>> In any case, I have a hard time seeing why you would reject certificates
>>> signed by a public CA (or any other CA that is covered by the log).  CA
>>> operators and legitimate domain owners should be interested in these and
>>> the signature check ought to be good enough for spam prevention unless
>>> things are more broken than is commonly reported.
>>
>>We would not reject them. Why do you think we would?
>
> A misunderstanding I hope.  If you are saying that browsers/observers
> can/would submit certificates that chain through a CA covered by the log
> then I have no issue.  If (as I had come to think) the log is fed during
> issuance, then I think a significant part of the potential value is lost.

Anyone can submit to the log. The log (at least our log!) will accept
any certificate chained through a public CA.

> Part of the problem in tracking this right now is the TBD in section 3 of
> the draft.  I'll refrain from further comment until that text is present,
> since that should clarify things.

I will at least outline what will be in the messages soon.

[therightkey] Defining CT-for-PKIX and CT-for-DNS… Paul Hoffman
Re: [therightkey] Defining CT-for-PKIX and CT-for… Shumon Huque
Re: [therightkey] Defining CT-for-PKIX and CT-for… Richard L. Barnes
Re: [therightkey] Defining CT-for-PKIX and CT-for… Paul Hoffman
Re: [therightkey] Defining CT-for-PKIX and CT-for… Carl Wallace
Re: [therightkey] Defining CT-for-PKIX and CT-for… Paul Wouters
Re: [therightkey] Defining CT-for-PKIX and CT-for… Paul Hoffman
Re: [therightkey] Defining CT-for-PKIX and CT-for… Carl Wallace
Re: [therightkey] Defining CT-for-PKIX and CT-for… Paul Wouters
Re: [therightkey] Defining CT-for-PKIX and CT-for… Carl Wallace
Re: [therightkey] Defining CT-for-PKIX and CT-for… Ben Laurie
Re: [therightkey] Defining CT-for-PKIX and CT-for… Ben Laurie
Re: [therightkey] Defining CT-for-PKIX and CT-for… Carl Wallace
Re: [therightkey] Defining CT-for-PKIX and CT-for… Ben Laurie
Re: [therightkey] Defining CT-for-PKIX and CT-for… Carl Wallace
Re: [therightkey] Defining CT-for-PKIX and CT-for… Ben Laurie
Re: [therightkey] Defining CT-for-PKIX and CT-for… Tom Ritter
Re: [therightkey] Defining CT-for-PKIX and CT-for… Ben Laurie