Matt,
However, Ben has noted that even if we use a different format for the
pre-cert data, the data MUST contain the serial number of the cert that is
eventually issued. This is almost as much of a problem for CAs, at least
in principle. Remember that the DigiNotar breach (which is a major
motivation for CT) was especially bad because the attackers were able
erase all evidence of the bogus certs that they issued. Countermeasures
to such attacks might preclude a CA from knowing what serial number will
appear in a cert until it is issued. (I mentioned one such counter-
measure in a FIPS level 3 HSM from long ago, in a prior post.)
I don't know all the specifics of the Diginotar breach, but I'm not
conceiving of a situation in which knowing the serial number of a
certificate in advance helps an attacker erase the evidence of a bogus cert
having been issued. Knowing a serial number in advance, or being able to
specify a serial (rather than having one auto-generated) shouldn't have any
impact on the tamper-proof log of CA operations which I would expect to be a
fundamental part of any CA. Also, it'll be awfully hard for a future
attacker to erase proof of issuance if the CA is logging all their certs to
a variety of CT servers.
Sorry if I was unclear. I intended to say that if the attackers had not
been able to erase evidence of the issuance of bogus certs, then the attack
might have been discovered quickly. Using an HSM that assigns serial
numbers,
helps with this concern, but such a design is precluded if one is
required to
issue two certs with the same serial number.
I suggest that the CT designers list which data items from a cert that is
being logged need to be in the SCT request, and why each item has to be
present. Maybe that will show us how to avoid the concern that I and
others have raised. It would also provide us with a starting point for
the format of a new data structure for the SCT request, and the set of
data that is input to the SCT hash computation.
I can't speak for Ben, Adam, or the others with significant input into the
CT spec, but for myself I would want to see *everything* that goes into the
final certificate. The goal of CT is to provide a publically available
database of the data which is being attested to by CAs. I wouldn't want to
limit what the public is capable of auditing because of a lack of
imagination at the time the specification was codified.
I don't recall seeing the goal you described above in the I-D. More
importantly
your statement is a description of a mechanism, not a security goal per se.
one would have to follow your statement of transparency with one that says,
then ....
I have suggested we need is a clear statement of the threat and a mapping
of CT to that threat model. I still think this is needed, and that it
may help
us decide what needs to be covered by the SCT.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
