der: make `Length` a newtype of `usize`

[tarcieri]

Length is currently a newtype of u32. This is because the Decode and Encode impls are specialized to 32-bit integers:

• decode: https://github.com/RustCrypto/formats/blob/bd84063/der/src/length.rs#L272-L273
• encode: https://github.com/RustCrypto/formats/blob/bd84063/der/src/length.rs#L309-L315

If the implementation could support any usize, we could change the internal type to usize which would allow infallible conversions to/from usize.

[dishmaker]

which would allow fallible conversions from usize.

Did you mean infallible?

[dishmaker]

Is there any real use-case for 4 GB+ DER-encoded objects?

My arguments against infallible Length(usize) is that:

• on 64-bit Header struct will be larger, therefore slower (see https://github.com/mbrubeck/mediumvec )
• usize::MAX as indefinite length would be architecture-dependent (0xFFFF on 16-bit)
• adding the usize::MAX indefinite trick would make it fallible again, anyway der: Tracking issue for deoptimiztions since v0.7 #1934 (comment)

[tarcieri]

Supporting larger objects is a non-goal. Length used to constrain a maximum size specifically to avoid that, but we removed those constraints.

The others are valid arguments against this change, however.

[turbocool3r]

Some vendors (like Apple, see IMG4 file format) put firmware images into DER-encoded containers so that's a usecase. Another one would be to construct large objects to test security of systems accepting DER blobs.

Imo this change will simplify handling of byte slices and lengths and is a good thing to do. Larger size of the Header structure on 64-bit systems won't consume a lot of memory and I honestly see little benefit in crates like mediumvec unless you really have to store a lot of vectors.