Wrap TrustAnchor array items in AsRef<T>

[b-stime]

There are some places that take a borrowed array of owned TrustAnchors e.g.,

E.g.,

webpki/src/verify_cert.rs

Line 39 in 34e8f9e

pub(crate) trust_anchors: &'p [TrustAnchor<'p>],

webpki/src/end_entity.rs

Line 106 in 2879b2c

trust_anchors: &'p [TrustAnchor<'_>],

I believe the array sub-type can be wrapped in AsRef in many of these cases e.g.,
trust_anchors: &'p [AsRef<TrustAnchor<'_>>],

In some of the uses, the implementation doesn't seem to actually need ownership of the TrustAnchor and just reads from it a bit. Optionally accepting a borrowed reference should be helpful for cases e.g., where one or more of the TrustAnchors are cached and re-used.

[djc]

What problem are you trying to solve, exactly?

[b-stime]

What problem are you trying to solve, exactly?

Outer problem: Validating certificate paths from Apple App Store signed JWS receipts. The trust anchor (from Apple) only changes on rare occasions.

Inner problem: Avoid cloning the TrustAnchor before passing it to a verify...() method from rustls-webpki. It should be more efficient to pass a reference and just keep re-using the cached TrustAnchor without copying the certificate bytes for each verification.

[djc]

I think you could have an Arc<[TrustAnchor]> and dereference it?

[ctz]

copying the certificate bytes for each verification.

I think this can be avoiding by having a TrustAnchor which borrows its storage?

(which is something the type can already do, which explains its lifetime parameter.)

[b-stime]

I resolved the issue in my project by caching a [single-element] array as a wrapper. The array owns the TrustAnchor and I can lend the array to verify_for_usage().

It still seems like it'd be useful (principle of least astonishment) for callers to be able to pass a borrowed array of borrowed TrustAnchor items without having to clone or reparse certificate bytes. I don't think verify_for_usage() (or various other methods in the crate) actually need the array to own the TrustAnchors. Sometimes that can be convenient, though, so I guess the ideal would be to accept any of the following combos:

• &[&TrustAnchor]
• [&TrustAnchor]
• &[TrustAnchor]
• [TrustAnchor]

...and treat any of them as the first type internally, assuming there's some maintainable way to implement that 🤞.