On 30 March 2016 at 15:25, Stephen Kent <[email protected]> wrote: > 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? >
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. > It seems to me 5280 should at least explain the threat and potential mitigations (I assume that were you think AIA is not needed has some other mitigation that should also be documented). > > > Steve >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
