der, x509-cert: support for signed bigints, negative serial numbers#823
der, x509-cert: support for signed bigints, negative serial numbers#823tarcieri merged 6 commits intoRustCrypto:masterfrom
Conversation
| /// Get the encoded length for the given unsigned integer serialized as bytes. | ||
| /// Get the encoded length for the given signed integer serialized as bytes. | ||
| #[inline] | ||
| pub(super) fn encoded_len(bytes: &[u8]) -> Result<Length> { | ||
| Length::try_from(strip_leading_ones(bytes).len()) | ||
| } | ||
|
|
||
| /// Strip the leading all-ones bytes from the given byte slice. | ||
| fn strip_leading_ones(mut bytes: &[u8]) -> &[u8] { | ||
| pub(crate) fn strip_leading_ones(mut bytes: &[u8]) -> &[u8] { |
There was a problem hiding this comment.
N.B.: I updated these comments; based on the context and behavior it looks like they were incorrectly copy-pasted before.
Signed-off-by: William Woodruff <william@yossarian.net>
Signed-off-by: William Woodruff <william@yossarian.net>
|
This should be good for a review; I've added some basic tests and confirmed that no other tests have broken with Edit: Done. |
Signed-off-by: William Woodruff <william@yossarian.net>
woodruffw
changed the title
|
I'm a bit late but, here is the relevant rfc piece I found about this https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.2, anyway, this is in line with the rfc: |
|
Yep! I probably should have included a comment to that effect 🙂 |
|
I can ask some relevant X.509 experts on recommendations for interpreting that SHOULD. It would probably be best to have constructors only accept |
Yeah, that makes sense to me. The API change I'm thinking about in #826 (comment) would address this I think -- |
Per #823 and #827, making PKCS#7 work interoperably will involve supporting at limited number of BER productions, one of which is indefinite lengths. The current built-in `Length` type rejects them, as a proper DER parser is expected to. This commit adds a separate `IndefiniteLength` type as a newtype of `Option<Length>` with support for parsing indefinite lengths.
Per #823 and #827, making PKCS#7 work interoperably will involve supporting at limited number of BER productions, one of which is indefinite lengths. The current built-in `Length` type rejects them, as a proper DER parser is expected to. This commit adds a separate `IndefiniteLength` type as a newtype of `Option<Length>` with support for parsing indefinite lengths.
Per #823 and #827, making PKCS#7 work interoperably will involve supporting at limited number of BER productions, one of which is indefinite lengths. The current built-in `Length` type rejects them, as a proper DER parser is expected to. This commit adds a separate `IndefiniteLength` type as a newtype of `Option<Length>` with support for parsing indefinite lengths.
3 participants
WIP; needs unit tests. Just pushing up for visibility.N.B.: My editor made some automatic reformatting decisions (I use
cargo +nightly fmtby default), so let me know if you'd like me to revert them. They should be a superset of the existingcargo fmtstyle, however.Fixes #821.