Ben,
...
If the CA that logged the bogus certificate fails to revoke it,
browser vendors might blacklist the certificate. However, as noted
above, the doppelganger, which was not logged, will match the SCT
created for the logged certificate. If remediation is effected by
blacklisting (instead of revocation by one of the malicious CAs)
then the ability of CT to deal with this sort of attack may be
diminished.
Once more, this problem is not CT's problem - it is a problem with RFC
5280 et al. That is, the problem exists regardless of the existence or
use of CT.
I assume we agree that the issue is not whether inclusion of the AIA
extension in all EE certs
should be a MUST in 5280, right? Is your point that no standard
specifies in detail how to manage
revocation status data? If so, then this lack of detail applies not only
to CRLs and OCSP but
also to browser blacklists, so it's not just a 5280 issue.
In any case, the discussion is an analysis of attacks in the context of
CT, so to that
extent it is a CT issue.
Does this mean 5280 should be updated?
I think not. As I noted in prior messages, 5820 is the general PKI spec
for Internet use of X.509 certs.
There is not always a need to mandate inclusion of AIA, hence it's
optional. It's appropriate to
profile 5280 for specific application contexts, like the Web PKI. There
was an IETF WG that was
trying to characterize that context (WPKOPS) but it failed.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
