On 24 September 2012 16:25, Martin Rex <[email protected]> wrote: > 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.
The problem is that if the OCSP server is not identified in the EE cert, then a misissued cert can be revoked according to one chain and not revoked according to another. This defeats the purpose of CT. There is a question of what to do if the CA issues a cert with the wrong OCSP server in it - the answer, IMO, is you revoke the CA cert, since it clearly cannot be trusted. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
