Fix negative ENUMERATED values in multi-strings.

I noticed this while I was reading through the encoder. OpenSSL's ASN.1
library is very sloppy when it comes to reusing enums. It has...

- Universal tag numbers. These are just tag numbers from ASN.1

- utype. These are used in the ASN1_TYPE type field, as well as the
  ASN1_ITEM utype fields They are the same as universal tag numbers,
  except non-universal types map to V_ASN1_OTHER. I believe ASN1_TYPE
  types and ASN1_ITEM utypes are the same, but I am not positive.

- ASN1_STRING types. These are the same as utypes, except V_ASN1_OTHER
  appears to only be possible when embedded inside ASN1_TYPE, and
  negative INTEGER and ENUMERATED values get mapped to
  V_ASN1_NEG_INTEGER and V_ASN1_NEG_ENUMERATED. Additionally, some
  values like V_ASN1_OBJECT are possible in a utype but not possible in
  an ASN1_STRING (and will cause lots of problems if ever placed in

- Sometimes one of these enums is augmented with V_ASN1_UNDEF and/or
  V_ASN1_APP_CHOOSE for extra behaviors.

- Probably others I'm missing.

These get mixed up all the time. asn1_ex_i2c's MSTRING path converts
from ASN1_STRING type to utype and forgets to normalize V_ASN1_NEG_*.
This means that negative INTEGERs and ENUMERATEDs in MSTRINGs do not get
encoded right.

The negative INTEGER case is unreachable (unless the caller passes
the wrong ASN1_STRING to an MSTRING i2d function, but mismatching i2d
functions generally does wrong things), but the negative ENUMERATED case
is reachable. Fix this and add a test.

Change-Id: I762d482e72ebf03fd64bba291e751ab0b51af2a9
Commit-Queue: David Benjamin <>
Reviewed-by: Adam Langley <>
2 files changed
tree: 0b00c6528da1c0305ae8d50682739affce2d9028
  1. .github/
  2. crypto/
  3. decrepit/
  4. fuzz/
  5. include/
  6. ssl/
  7. third_party/
  8. tool/
  9. util/
  10. .clang-format
  11. .gitignore
  15. CMakeLists.txt
  16. codereview.settings
  19. go.mod
  20. go.sum
  26. sources.cmake


BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.

BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.

Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.

Project links:

There are other files in this directory which might be helpful: