On 19 November 2012 11:49, Carl Wallace <[email protected]> wrote: > 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.
What is only true? That there's no point it being in the log if the browser would reject it anyway? I don't understand that. > 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. The extension does not have to be in the certificate, it can also be in the TLS handshake. > 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? _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
