Signed Certificate Timestamp verification #326
Conversation
| // TODO(tnytown): Migrate to const-oid's CT_PRECERT_SCTS when a new release is cut. | ||
| const CT_PRECERT_SCTS: ObjectIdentifier = ObjectIdentifier::new_unwrap("1.3.6.1.4.1.11129.2.4.2"); | ||
| const PRECERTIFICATE_SIGNING_CERTIFICATE: ObjectIdentifier = | ||
| ObjectIdentifier::new_unwrap("1.3.6.1.4.1.11129.2.4.4"); |
There was a problem hiding this comment.
const-oid 0.10 should include these OIDs, but isn't released yet
| }; | ||
|
|
||
| match (algo, params) { | ||
| // TODO(tnytown): should we also accept ed25519, p384, ... ? |
There was a problem hiding this comment.
I only saw p256 SCTs while testing this changeset against the public-good prod and staging, do we need to support other key types?
tnytown
force-pushed
the
ap/wip-sct
branch
3 times, most recently
from
0501ffc
to
be5f3fc
Compare
tnytown
force-pushed
the
ap/wip-sct
branch
2 times, most recently
from
773490d
to
2c8a320
Compare
|
This is ready for review, but we should get #311 in first. |
tnytown
force-pushed
the
ap/wip-sct
branch
3 times, most recently
from
739b4b4
to
4180b1f
Compare
tnytown
force-pushed
the
ap/wip-sct
branch
4 times, most recently
from
c9ad592
to
d4d74f7
Compare
|
@tnytown is this one ready to be reviewed? |
tnytown
force-pushed
the
ap/wip-sct
branch
3 times, most recently
from
310fff3
to
76992cd
Compare
| ), | ||
| fingerprint: { | ||
| let mut hasher = sha2::Sha256::new(); | ||
| spki.encode(&mut hasher).expect("failed to hash key!"); |
There was a problem hiding this comment.
This expect should be safe: the only error that encode should return in this context is IO-related (and hasher shouldn't ever refuse a write.)
| tbs_precert | ||
| .encode_to_vec(&mut tbs_precert_der) | ||
| .expect("failed to re-encode Precertificate!"); |
There was a problem hiding this comment.
This encode_to_vec shouldn't be fallible: all we've done to the tbsCertificate is removed an extension, and it previously decoded correctly.
Yes, thanks for the ping @flavio! |
Co-authored-by: Alex Cameron <alex.cameron@trailofbits.com> Signed-off-by: Andrew Pan <andrew.pan@trailofbits.com>
Blocked on #311.Summary
Adds Signed Certificate Timestamp verification and hooks it up to the bundle signing flow. SCT verification ensures that the signing certificate in a given operation has been submitted to the Certificate Transparency log, which aids in the detection of malicious certificates and keeps Certificate Authorities like Fulcio honest.
Release Note
Documentation
No user-facing documentation needed, we automatically perform SCT validation when public
signandverifyAPIs are used.