On 27/03/15 12:45, Eran Messeri 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.
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.
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
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.
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?
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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
