Subject: [Trans] AIA/cRL for logged certificates

From: Eran Messeri <[email-masked]>
Date: Fri, 27 Mar 2015 12:45:04 +0000

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).
- Require the presence of AIA/CRL distribution point in the end-entity
certificate.

Any other suggestions?
Eran

---

From: Ben Laurie <[email-masked]>
Date: Fri, 27 Mar 2015 12:47:43 +0000

> before completing the connection).

Then its not a potential mitigation!

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
>

---

From: Carl Wallace <[email-masked]>
Date: Fri, 27 Mar 2015 08:51:20 -0400

From:  Ben Laurie <[email-masked]>
Date:  Friday, March 27, 2015 at 8:47 AM
To:  Eran Messeri <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [Trans] AIA/cRL for logged certificates

>> 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.
>> 
>> 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:

This option would not necessarily work as the CRL referenced by the DP in
the log may not cover the newly issued certificate.

> _______________________________________________ Trans mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/trans

---

From: Rob Stradling <[email-masked]>
Date: Fri, 27 Mar 2015 13:50:32 +0000

On 27/03/15 12:45, Eran Messeri wrote:
> 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.

RFC5280 Section 5 says:
   "If the scope of the CRL includes one or more certificates issued by
    an entity other than the CRL issuer, then it is an indirect CRL.  The
    scope of an indirect CRL may be limited to certificates issued by a
    single CA or may include certificates issued by multiple CAs."

I don't think I've ever encountered an indirect CRL before, and I have 
no idea how widely supported they are.

Since the scope of a "normal" CRL typically only includes "child" certs, 
not "grandchild" certs, the CRLs pointed to by the CDP in the 
issuer/intermediate certs will _not_ list the "undesirable" certificate 
as revoked.

> 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

There's nothing to stop a TLS server from serving a logged cert plus a 
different set of issuer/intermediate certs than the set that was logged. 
  Re-signing but not re-logging makes no difference here, AFAICT.

> (The implied assumption is that the attacker controls the private key of
> the issuer).

If they control the private key, then there's a good chance they control 
the CRL/OCSP servers too.  Until we have Revocation Transparency, 
nothing prevents this attacker (or an evil CA, for that matter) from 
creating a split view of revocation information served from the same 
revocation server URL.

> - 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).

Didn't we decide long ago that fixing revocation is out of scope for CT?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online