Zero-copy, extracting slices of input?

[g2p]

I'm considering the rasn crates because many protocols are already implemented in a fairly readable way. For the specific case of OCSP, and I suppose PKIX is similar, I'd like to extract views over parsed data so that I can verify that signatures over the tbs parts are valid.
(I could reserialize to get bytes again but that would be a dubious hack, especially for something security relevant).
Zero-copy parsers would make this possible, and I don't think the trait would need much tweaking. But some things would still need to be fairly manual, using the concrete der::de::Decoder struct, with some decode/encode asymmetry (so that encoding doesn't require providing the extra view).
While on the topic of zero copy, other bits of data would benefit from these kinds of encoded data views, like certids which are better compared in binary.
I haven't explored this much more, is this a use case you would give consideration?

[XAMPPRocky]

Thank you for question! Zero-copy is something I've considered, but right now it's been on the back burner over other work, for a couple of reasons. One is that zero-copy is usually not as fast as copying parsers (the reason being that, you have to hold both the parsed structure and the original source which may be much larger in memory.)

The second reason is that zero-copy makes things a lot more complicated on the trait boundary and in the implementations. With zero-copy there would need to a lot of changes to the traits, because currently the Decoder trait requires returning an owned type (e.g. Vec<u8>), and supporting zero-copy would require adding borrowed types to the trait definition. It would also require adding owned and borrowed versions of all the types.

(I could reserialize to get bytes again but that would be a dubious hack, especially for something security relevant)

This is not true, DER is canonical, which means that it must always produce the same encoded data for the same value, so there should be no concern for re-encoding the value.

[g2p]

Ah, I see that the Decoder trait builds owned values. I personally wouldn't need zero-copy to be used everywhere possible, just to make sure that a custom Decode impl can keep a reference to the input.

Re re-encoding values and canonicity, I have doubts in practice.
What is canonical depends on the schema, and due to historical accidents some standards require handling multiple variants of a schema: https://security.stackexchange.com/questions/110330/encoding-of-optional-null-in-der

Which means that either the decoder enforces canonicity and rejects certain certs that appear in the wild, or some DER data won't actually round trip.

[XAMPPRocky]

What is canonical depends on the schema, and due to historical accidents some standards require handling multiple variants of a schema: https://security.stackexchange.com/questions/110330/encoding-of-optional-null-in-der

I don't think that's correct, what's happening here, is that you have two different values that could be considered equal, but to ASN.1 they are different values, and thus have different encodings. There needs to be an additional check to see if the algortihms are semantically equivalent but they are still different values and will have a different encoding. Canonicity in ASN.1 is different from normalised in X.509.