Melinda,
The problem is bigger than just the choice of format for the SCT response.
The current pre-cert model requires a CA to be able to issue two certs with
the same serial number. This would, in general, be a very bad thing for a CA
to do. So, mandating this behavior is very worrisome. And, as you noted, it
clearly violates 4.1.2.2 of 5280. (Thanks, I should have noted that.)
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.
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 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.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
