On 11/19/12 5:30 AM, "Ben Laurie" <[email protected]> wrote: >On 18 November 2012 01:32, Carl Wallace <[email protected]> wrote: >> On 11/17/12 8:24 PM, "Paul Hoffman" <[email protected]> wrote: >> >>>>And you cannot say "The CA industry" either, which is the answer for >>>>the >>>> CT-PKIX version. >>> >>>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. > >The idea is that the log contains all certificates the browser might >otherwise say are valid. If the cert would not be validated by the >browser anyway, there's no real point it being in the log - and so, >for pragmatic reasons (i.e. spam prevention), our current plan is to >not allow such certificates to be logged.
That is only true for browsers that hard fail on missing/broken CT extensions. I've not followed why hard failing on this is expected to work but not for other existing mechanisms. We still have 15+ year olds extensions that don't cause hard failures. Pushing the extension into the certificate and only accepting certs that have it just makes this part of the issuance machinery. 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. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
