Hi Stephen,
On Mon, Sep 08, 2014 at 04:16:16PM -0400, Stephen Kent wrote:
> Thus, I suggest we use a different format. I suggest sticking with ASN.1,
> since the data used to compute the SCT will come from a cert, and ASN.1 is
> the native cert format description language. DER encoding is also good for
> creating a canonical representation for signature generation.
I'm in agreement that ASN.1/DER should be used wherever we're dealing with
"certificate-like" data. I know of the concerns regarding the, uh,
"elevated potential", shall we say, for security bugs in DER-handling code,
but that's got to be weighed against the potential for bugs in whatever code
has to be custom-written to deal with whatever *other* encoding format is
used for the data.
> 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.
On the other hand, I can certainly empathise with the sentiment that
removing/modifying reasonable safety checks that prevent a given CA from
issuing two certificates with the same serial is a scary proposition.
The CT spec has a way to avoid that, though, by issuing pre-certs from a
separate CA to that of the CA issuing the eventual certificate. That avoids
the need for duplicate serials.
> 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.
- Matt
--
New Yankee Workshop isn't a "how to" for home hobbyists, it's "Baywatch" for
powertool fetishists.
-- Geoff Kinnel, ASR
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
