I don't see why that would be the case. The requirement could be applied to new certs going forward. Or the proofs could be embedded in OCSP tokens rather than the certs themselves.
On Wed, Sep 12, 2012 at 10:22 AM, Ben Laurie <[email protected]> wrote: > On 12 September 2012 02:37, Phillip Hallam-Baker <[email protected]> wrote: > > Thinking through some baby steps here. Perhaps one of the first steps > might > > be to apply transparency to intermediate certs since those are the ones > that > > have the highest risk associated? > > You'd have to either re-issue them all, or upgrade all the servers > using certs chained from them... > > > In particular I really hope that there is nobody out there issuing > intercept > > certs on public roots. > > > > > > > > On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas <[email protected]> wrote: > >> > >> > >> On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote: > >> > >> > > >> > Hiya, > >> > > >> > If you want a BoF, then you need to do the required dance;-) > >> > > >> > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area > >> > Directors at UTC 24:00. To request a BOF, please see instructions on > >> > Requesting a BOF." [1] > >> > > >> > Sean and I remain interested in folks' opinions about having this > >> > BoF. So far I've seen about a dozen-ish "I'm interested in > >> > something here" responses, a good chunk from folks who do good > >> > work around the IETF; one negative comment off-list (saying its > >> > not baked), and have seen a just a couple of folks say they'd > >> > do work. > >> > > >> > That's not bad, but nowhere near overwhelming either, so more > >> > input would be appreciated, preferably on the list. > >> > >> Stephen, > >> > >> I am very supportive of the BoF. > >> > >> Certificate Transparency addresses a real problem that no other public > key > >> infrastructure tweaks do. It permits any party to survey the landscape > of > >> public certificates and do meaningful security analysis. It is also a > modest > >> protocol that doesn't interfere with existing operations. > >> > >> Many of us doubt the public web certificate infrastructure runs without > >> someone cheating. We take as an article of faith that someone somewhere > is > >> issuing bogus certificates for whatever nefarious purpose. Usually that > is > >> some vague surveillance, if not outright espionage. (For what it's > worth, I > >> subscribe to that faith.) > >> > >> CT has the value that CAs, relying parties, end users, and interested > >> third parties can look at the landscape of certificates and catch > >> inconsistencies. It allows us put some actual faith into trust. It > allows us > >> to see what is going on in a system that we all use. We need CT. It > would be > >> good to have it develop under the aegis of the IETF. > >> > >> Jon > >> > >> _______________________________________________ > >> therightkey mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/therightkey > > > > > > > > > > -- > > Website: http://hallambaker.com/ > > > -- Website: http://hallambaker.com/
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
