From: Ben Laurie <[email protected]> Date: Friday, March 27, 2015 at 8:47 AM To: Eran Messeri <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [Trans] AIA/cRL for logged certificates
> > > On 27 March 2015 at 12:45, Eran Messeri <[email protected]> wrote: >> I'd like to get opinions from the list on solutions to the following problem, >> which Ben originally pointed out. It applies to Precertificates currently, >> but would apply to X.509 certificates if ticket #4 is accepted. >> >> An "undesirable" certificate is issued and logged (without including >> Authority Information Access / CRL distribution point) and upon discovery is >> revoked - the CRL distribution point in the issuer or one of the intermediate >> certs will list it as revoked. >> That certificate would be signed a second time with the same issuer key, but >> not logged a second time (as the SCT produced for the first certificate is >> valid for the second one). When it is served, it is served together with a >> chain that is different than the one logged, and the issuer or intermediates >> in this chain point to a different AIA/CRL that does *not* show list this >> certificate as revoked (The implied assumption is that the attacker controls >> the private key of the issuer). >> >> Implication: A client believes it has a legitimate certificate by validating >> the SCT and performing an online revocation check. >> >> Potential mitigations: >> - Require that the client only use the AIA/CRL distribution point from the >> chain logged in the CT log (which forces the client to fetch it online, >> before completing the connection). > > Then its not a potential mitigation! This option would not necessarily work as the CRL referenced by the DP in the log may not cover the newly issued certificate. > >> - Require the presence of AIA/CRL distribution point in the end-entity >> certificate. >> >> Any other suggestions? >> Eran >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans >> > > _______________________________________________ Trans mailing list > [email protected] https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
