On 22/02/16 11:01, Ben Laurie wrote:
<snip>
Note that in this scenario, it's unlikely that space-constrained
blacklist-style client updates (e.g. CRLset) will include every leaf
certificate that chains to A after A is known-compromised. So TLS
clients won't necessarily be warned off of C directly.
It seems to me there are multiple solutions here. The easiest is to not
blacklist A_X, but instead to blacklists A_X's subject, which will also
blacklist B_X.
I think that blacklisting the shared issuer public key would be better
than blacklisting the shared issuer name.
AIUI, MS CryptoAPI prefers to build certificate chains using the
Authority/Subject Key Identifiers, and it only cares about whether or
not the Issuer/Subject Names match if AKI/SKI are absent.
<snip>
How to fix this? A few ideas come to mind, but i'm not convinced of
either of them yet:
* recommend that clients who care about transparency should expect
that
all intermediate certs themselves are logged -- 6962bis already
permits this, though it seems to be mainly in contemplation of
name-constrained intermediate authorities. This expands the number
of SCTs or inclusion proofs that need to accompany a chain, and
makes
verification logic slightly more complicated.
Regardless of the argument above and mitigation thereof, I think this
would be a good idea.
If we expect to (eventually) have an effective revocation mechanism
(e.g. blacklisting the issuer public key), then why would we need to
increase the TLS handshake size (by sending additional SCTs/proofs) just
so that we can solve the same problem twice?
If we do want CT to handle this though, then I suggest that we:
- require intermediate certs to be logged in the same logs as the
end-entity certs they issue.
- don't require SCTs or inclusion proofs for intermediates to be sent
by TLS servers (except for the name-constrained case).
- say that TLS clients SHOULD fetch and verify inclusion proofs for
all intermediate certs that they rely on.
<snip>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
