Start basic SCT support

[djc]

No description provided.

[djc]

What kind of verification needs to happen? Thoughts on a testing strategy?

[ctz]

Verification here would be a separate feature, taking a set of valid CT logs (their IDs, public keys, etc) and checking each SCT purported to come from a valid known log is correctly signed. Doing this verification is a future upki feature, mainly because tracking "valid CT logs" requires ongoing, current knowledge.

[codecov]

Codecov Report

❌ Patch coverage is 96.73203% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.78%. Comparing base (7ee26a7) to head (b963a7c).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
src/verify_cert.rs	0.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #423      +/-   ##
==========================================
- Coverage   96.78%   96.78%   -0.01%     
==========================================
  Files          19       20       +1     
  Lines        3797     3950     +153     
==========================================
+ Hits         3675     3823     +148     
- Misses        122      127       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[djc]

Need to make sure to fuse the iterator if there's an unrecoverable error.

(Personally not sure I mind Result<Iter<Item = Result<_, _>>> all that much, and I don't think this API will be all that widely used?)

[ctz]

Need to make sure to fuse the iterator if there's an unrecoverable error.

(Personally not sure I mind Result<Iter<Item = Result<_, _>>> all that much, and I don't think this API will be all that widely used?)

What do you think about the opposite change -- Result<Iter<Item = Foo>>? It means it is two pass, but the error handling is much simplified as they happen up-front.

Anyway, not married to this either way.

I have one more addition to make on this PR then we can squash.

[djc]

Need to make sure to fuse the iterator if there's an unrecoverable error.
(Personally not sure I mind Result<Iter<Item = Result<_, _>>> all that much, and I don't think this API will be all that widely used?)

What do you think about the opposite change -- Result<Iter<Item = Foo>>? It means it is two pass, but the error handling is much simplified as they happen up-front.

Uh, do we allocate after the first pass, or unwrap() during the second? Neither sound all that appealing.

[ctz]

Uh, do we allocate after the first pass, or unwrap() during the second? Neither sound all that appealing.

I was thinking unwrap() -- I have dropped this commit just now.

[ctz]

This is not really great, but the alternatives don't seem great either:

• copying der::asn1_wrap into pki-types and having an accessor fn on TrustAnchor
• moving der::asn1_wrap into pki-types and then reexposing it (though perhaps as a SubjectPublicKeyInfoDer::from_interior_bytes() or whatever)

[djc]

Seems okay to me. Might be nice if we can move some of this reusable logic into pki-types some day -- I forget the other place recently where I was copying similar stuff around.

[djc]

✅ (I submitted the PR, so can't formally approve).