tree 38428ab94840ac5fa4bff54a6abe0eebb2d7b44d
parent e4b3e6afb63fd82e4157733723a9e7a450ae96cb
author David Benjamin <davidben@google.com> 1645420470 -0500
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1646694604 +0000

Use X509V3_add_value_int in i2v_AUTHORITY_KEYID.

Although the preceding CL fixes x509v3_bytes_to_hex to work with the
empty string, it's not really a good representation for zero. Zero as an
ASN1_INTEGER is sometimes the empty string (default-constructed) and
sometimes a single zero byte (parsed). bytes_to_hex also doesn't capture
the sign bit.

Instead, use X509V3_add_value_int, matching most of the other i2v, etc.,
functions in crypto/x509v3. X509V3_add_value_int calls i2s_ASN1_INTEGER,
which prints small values in decimal and large values in hexadecimal
with a 0x prefix.

It is unclear to me whether i2v and v2i are generally expected to be
inverses. i2v (or i2s or i2r) is used when printing an extension, while
v2i is used when using the stringly-typed config file APIs. However,
i2v_AUTHORITY_KEYID does not consume the "serial" key at all. It
computes the serial from the issuer cert.

Oddly, there is one ASN1_INTEGER,
PROXY_CERT_INFO_EXTENSION.pcPathLengthConstraint, which uses
i2a_ASN1_INTEGER instead. That one uses hexadecimal without the "0x"
prefix, and with newlines. Interestingly, its r2i function is not the
reverse of i2r and parses the s2i_ASN1_INTEGER format.

Between those, I'm assuming they're not necessarily invertible.

Change-Id: I6d813d1a93c5cd94a2bd06b22bcf1b80bc9d937b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51628
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>