On 09/24/2012 05:56 PM, Santosh Chokhani wrote: > Steve Ferrell,
Who's he? :-) I'm gonna guess you mean me though. > Help please. Does this belong here or in PKIX? I think this list is probably best devoted to issues related to CT for the moment. This topic seems tangential, but if folks think otherwise that's fine since we're in the process of figuring what is or is not the scope of CT (amongst other BoF questions). There's also a proposed BoF in the OPS area (wpkiops list) about operational aspects of PKI. Discussion about OCSP might be relevant there, if you're talking about what real deployed systems actually do that adheres to, or differs from, what's written in RFCs. As Sean said in Vancouver, he's closing PKIX when current work is done (a decision with which I agree). I don't know if your topic fits one of the existing close-out work items there or not. Cheers, S. > > Martin, > > I agree with Ben that this discussion is not related to CT and hence if you > want and Steve agrees, it is best carried out in PKIX. > > What you say below is not how the OCSP RFC and clients work. For security > and for simplicity, OCSP delegation is done by using the same CA key that > signed the target certificate in question. Thus, it does not matter where > the OCSP pointer is. If the CA key or CA is compromised, you should not rely > on OCSP to indicate mis-issued certificates. > > -----Original Message----- > From: Martin Rex [mailto:[email protected]] > Sent: Monday, September 24, 2012 11:26 AM > To: Santosh Chokhani > Cc: Ben Laurie; [email protected]; [email protected] > Subject: Re: [therightkey] Certificate Transparency Working Group? > > Santosh Chokhani wrote: >> >> Ben Laurie wrote: >>> >>> Martin Rex wrote: >>>> >>>> Locating the OCSP server through AIA in the EE cert might be the >>>> problem here. Maybe the OCSP responder ought to be located through >>>> an extension in the CA cert itself instead? >>> >>> That would make CT substantially harder, because then we'd have to >>> deal with authenticating chains instead of just EE certs - and EE >>> certs tend to have multiple authentication chains... >> >> Agree and also in that case the solution is not robust enough from >> security standpoint. The adversary needs to do DNS poisoning and then >> is in business. > > My comment was not directed at CT itself, but rather at the problem of > locating the OCSP server (plus determining authorized OCSP signers), because > it is entirely ignorant of mis-issued certificates. > > The key that signed an EE cert is static and hardwired into the CA > certificate, so I see exactly zero problems with hardwiring an > (a) OCSP distribution point into the same CA cert and (b) identifying a > different CA key within that CA cert extension that is authorized to issue > shortlive OCSP signer certs, so that the CA key that issues EE certs is no > longer an unavoidable single point of failure. > > > -Martin > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey > _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
