Rob,
On 14/03/16 21:39, Ben Laurie wrote:
On 14 March 2016 at 14:39, Stephen Kent <[email protected]> wrote:
The logged bogus certificate can be detected by a Monitor (third
party or
self), that is watching the log(s) to which the certificate was
posted. Thus
the detection aspect of CT still works with regard to this
certificate. When
this certificate is detected, the CA that logged the certificate may
revoke
it, i.e., place it on a CRL or create an OCSP response for it.
However, a
browser checking a CRL or OCSP response will not match this revocation
status data against the other, not-logged bogus certificate. (This is
because revocation status checking is performed in the context of a
certificate path and the two bogus certificates have different
certificate
paths.) Revoking a detected, bogus certificate may be the best
strategy for
the malicious CAs. It makes issuance of the bogus certificate appear
to be
an accident, and thus browser vendors may not feel the need to make
an entry
on their blacklists for the bogus certificate or the CA that issued it.
I do not believe this is correct. And if it is, it is a serious bug in
revocation that has nothing to do with certificate transparency.
Also, I don't get the logic of the "not-logged bogus certificate",
which is identical to the logged certificate - and is therefore
logged. And not bogus.
+1
The "two" bogus certificates are one and the same. They will contain
the same CRL and/or OCSP URLs. The outcome of a CRL/OCSP check will
be exactly the same for both certs.
There is no requirement for a cert to contain a back pointer to the CRL on
which it would be listed or to provide OCSP info. The extension (AIA) that
enables these capabilities is not required by 5280 and because it is not
marked
critical, there is no requirement for all relyng parties to be able to
process it.
4.2.2.1. Authority Information Access
The authority information access extension indicates how to access
information and services for the issuer of the certificate in which
the extension appears. Information and services may include on-line
validation services and CA policy data. (The location of CRLs is not
specified in this extension; that information is provided by the
cRLDistributionPoints extension.) This extension may be included in
end entity or CA certificates. Conforming CAs MUST mark this
extension as non-critical.
AIUI, for DKG's attack to work, it is necessary for:
- the "two" bogus certificates to _not_ be revoked.
disagree, see above.
- one of the doppelganger intermediates to be logged and revoked.
logged, yes. blacklisted, maybe.
- the other one (or more) of the doppelganger intermediates to be
neither logged nor revoked.
agreed.
I think that there are two possible ways to thwart this attack:
1. Redefine SCTs so that they become SCCTs (Signed Certificate Chain
Timestamps) - i.e. the signature is calculated over the entire chain
submitted. I think this is unworkable, because there are too many
cases where different chains are legitimate and even expected.
2. Declare that this is not a problem with CT. It's a problem with
using CRL and/or OCSP to revoke intermediates.
my example does not assume that an intermediate CA cert was revoked. It
suggests
that a clever, malicious CA might revoke the bogus EE cert to deflect
suspicion from
itself and to avoid having browser vendors blacklist the CA or the bogus
cert.
So we (where "we" may or may not be TRANS) need to fix revocation!
Revoking an intermediate _certificate_ just isn't sufficient.
To be effective, the intermediate _public key_ needs to be revoked
somehow.
One does not revoke keys in a PKI. One revokes certs.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
