Ben Laurie wrote:
> 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.
Huh? It would be silly if CT would depend on that.
Different to the CRL distribution point extension,
the OCSP AIA information is pretty irrelevant to OCSP, and does
not affect the "acceptable" OCSP signers at a..
There are efforts underway to send around stapled OCSP responses
where the OCSP AIA information will be completely ignored.
So it would be flawed to make anything dependent on the OCSP AIA
information in the EE cert.
>
> 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.
Wrong OCSP AIA information in a cert is at most a functional defect,
but by itself not a security problem.
However, I believe we're talking past each other.
The original concept in X.509 about revocation is that
(a) it is assumed that mis-issuance can not possibly happen
(b) if it happens anyhow, you'll have to nuke the whole PKI immediately
and rekey every entity
(a) is dumb and (b) is an unnecessary royal PITA.
There are CAs that sign thousands and thousands of certs.
The US DoD seems to operate several CAs that have > 1 million certs
listed on their CRLs. I assume that the number of their active certs
is in the same range. A CA with 1 Million active certs with a lifetime
of 3 years each would have to issue ~1000 certs per day (when issuing
certs on holidays as well). So that will likely be an online CA.
I believe it would be sensible to manage revocation with a key that
is distinct from the CA key, so that when an attacker manages to get
certs mis-issued with the CA key, determining whether an EE cert&credential
is valid can be alternatively performed through that seperate revocation key.
It seems easier to secure a CA key for revocation that needs to be used
only around once per week and can work on a cert push model exclusively,
than to secure a CA key that needs to be used ~1000x/day in online CA
scenarios.
-Martin
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
