Brad,
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.
The serial number needs to be part of the logged proof because that is the key
on which existing revocation mechanisms operate. Transparently identifying
that a certificate has been issued incorrectly is of little utility unless that
certificate can be revoked.
I agree that the serial number is critical if one plans to revoke the
cert. But ,
the I-D makes no mention of remediation mechanisms, an omission I noted
in my review
a while ago. In some cases it appears that CT plans to shame CAs into
submission, in
which case revocation may not be needed ;-).
The alternatives are revoking the issuing CA on any leaf mis-issuance or
inventing alternate revocation mechanisms.
I agree that those mechanisms would effect revocation of the offending
cert, but they
may be overkill, and so should be avoided if possible.
The latter may be less of an obstacle than it appears since the major
implementers of CT are also in the process of inventing and deploying their own
(currently) proprietary revocation systems alongside CT.
I didn't know that. Since the WG does not know how these might work, we
also don't
know if the cert serial number is required.
Nevertheless, one would need something stable to uniquely identify the
certificate for these purposes, which ends up looking a lot like a serial
number however you slice it. (You can't use a cryptograhpic hash of the final
cert for this, either, because that would require a preimage in the log.)
I agree that something that uniquely identifies the evil cert is needed,
which is why
I suggested that we revisit this problem and look at each cert component
to see what
we need, and why.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
