Or we can use something like Omnibroker. There are lots of ways to boil this bunny.
On Wed, Sep 12, 2012 at 10:37 AM, Ben Laurie <[email protected]> wrote: > On 12 September 2012 15:35, Phillip Hallam-Baker <[email protected]> wrote: > > 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. > > I think I've said before that I would welcome a move to embedding in > OCSP. Presumably they'd have to be stapled... > > > > > 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/ > > > -- Website: http://hallambaker.com/
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
