|
|
|
/* v3_akey.c */
|
|
|
|
/*
|
|
|
|
* Written by Dr Stephen N Henson (steve@openssl.org) for the OpenSSL project
|
|
|
|
* 1999.
|
|
|
|
*/
|
|
|
|
/* ====================================================================
|
|
|
|
* Copyright (c) 1999 The OpenSSL Project. All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
*
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
* distribution.
|
|
|
|
*
|
|
|
|
* 3. All advertising materials mentioning features or use of this
|
|
|
|
* software must display the following acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
|
|
|
|
*
|
|
|
|
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
|
|
|
|
* endorse or promote products derived from this software without
|
|
|
|
* prior written permission. For written permission, please contact
|
|
|
|
* licensing@OpenSSL.org.
|
|
|
|
*
|
|
|
|
* 5. Products derived from this software may not be called "OpenSSL"
|
|
|
|
* nor may "OpenSSL" appear in their names without prior written
|
|
|
|
* permission of the OpenSSL Project.
|
|
|
|
*
|
|
|
|
* 6. Redistributions of any form whatsoever must retain the following
|
|
|
|
* acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
|
|
|
|
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
|
|
|
|
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
|
|
|
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
|
|
|
|
* OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
* ====================================================================
|
|
|
|
*
|
|
|
|
* This product includes cryptographic software written by Eric Young
|
|
|
|
* (eay@cryptsoft.com). This product includes software written by Tim
|
|
|
|
* Hudson (tjh@cryptsoft.com). */
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
#include <openssl/asn1.h>
|
|
|
|
#include <openssl/asn1t.h>
|
|
|
|
#include <openssl/conf.h>
|
|
|
|
#include <openssl/err.h>
|
|
|
|
#include <openssl/mem.h>
|
|
|
|
#include <openssl/obj.h>
|
|
|
|
#include <openssl/x509v3.h>
|
|
|
|
|
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
|
Use the correct function types in X509V3_EXT_METHODs.
While C allows function pointer casts, it is UB to call a function with
a different type than its actual type signature. That is, even though
`void f(int *)` and `void g(void *)` have the same ABI, it is UB to
cast `f` to a `void(*)(void *)` and then call it through that pointer.
Clang CFI will try to enforce this rule.
The recent CL to call X509_print in tests revealed that all the i2? and
?2i callbacks in X509V3_EXT_METHODs were implemented with functions of
the wrong type, out of some combination of missing consts and void*
turned into T*.
This CL fixes this. Where the function wasn't exported, or had no
callers, I just fixed the function itself. Where it had extension
callers, I added a wrapper function with a void* type.
I'm not positive whether the wrappers are the right call. On the one
hand, keeping the exported functions as-is is more type-safe and more
OpenSSL-compatible. However, most (but not all) uses of these are in
other code defining X509V3_EXT_METHODs themselves, so the void*
signature is more correct for them too. And the functions have a type
signature meant for X509V3_EXT_METHOD, complete with method pointer.
I've gone with leaving the exported ones as-is for now. Probably the
right answer anyway is to migrate the external callers, of either type
signature.
Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
3 years ago
|
|
|
static STACK_OF(CONF_VALUE) *i2v_AUTHORITY_KEYID(
|
|
|
|
const X509V3_EXT_METHOD *method, void *ext, STACK_OF(CONF_VALUE) *extlist);
|
|
|
|
static void *v2i_AUTHORITY_KEYID(const X509V3_EXT_METHOD *method,
|
|
|
|
X509V3_CTX *ctx, STACK_OF(CONF_VALUE) *values);
|
|
|
|
|
|
|
|
const X509V3_EXT_METHOD v3_akey_id = {
|
|
|
|
NID_authority_key_identifier,
|
|
|
|
X509V3_EXT_MULTILINE, ASN1_ITEM_ref(AUTHORITY_KEYID),
|
|
|
|
0, 0, 0, 0,
|
|
|
|
0, 0,
|
Use the correct function types in X509V3_EXT_METHODs.
While C allows function pointer casts, it is UB to call a function with
a different type than its actual type signature. That is, even though
`void f(int *)` and `void g(void *)` have the same ABI, it is UB to
cast `f` to a `void(*)(void *)` and then call it through that pointer.
Clang CFI will try to enforce this rule.
The recent CL to call X509_print in tests revealed that all the i2? and
?2i callbacks in X509V3_EXT_METHODs were implemented with functions of
the wrong type, out of some combination of missing consts and void*
turned into T*.
This CL fixes this. Where the function wasn't exported, or had no
callers, I just fixed the function itself. Where it had extension
callers, I added a wrapper function with a void* type.
I'm not positive whether the wrappers are the right call. On the one
hand, keeping the exported functions as-is is more type-safe and more
OpenSSL-compatible. However, most (but not all) uses of these are in
other code defining X509V3_EXT_METHODs themselves, so the void*
signature is more correct for them too. And the functions have a type
signature meant for X509V3_EXT_METHOD, complete with method pointer.
I've gone with leaving the exported ones as-is for now. Probably the
right answer anyway is to migrate the external callers, of either type
signature.
Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
3 years ago
|
|
|
i2v_AUTHORITY_KEYID,
|
|
|
|
v2i_AUTHORITY_KEYID,
|
|
|
|
0, 0,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
Use the correct function types in X509V3_EXT_METHODs.
While C allows function pointer casts, it is UB to call a function with
a different type than its actual type signature. That is, even though
`void f(int *)` and `void g(void *)` have the same ABI, it is UB to
cast `f` to a `void(*)(void *)` and then call it through that pointer.
Clang CFI will try to enforce this rule.
The recent CL to call X509_print in tests revealed that all the i2? and
?2i callbacks in X509V3_EXT_METHODs were implemented with functions of
the wrong type, out of some combination of missing consts and void*
turned into T*.
This CL fixes this. Where the function wasn't exported, or had no
callers, I just fixed the function itself. Where it had extension
callers, I added a wrapper function with a void* type.
I'm not positive whether the wrappers are the right call. On the one
hand, keeping the exported functions as-is is more type-safe and more
OpenSSL-compatible. However, most (but not all) uses of these are in
other code defining X509V3_EXT_METHODs themselves, so the void*
signature is more correct for them too. And the functions have a type
signature meant for X509V3_EXT_METHOD, complete with method pointer.
I've gone with leaving the exported ones as-is for now. Probably the
right answer anyway is to migrate the external callers, of either type
signature.
Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
3 years ago
|
|
|
static STACK_OF(CONF_VALUE) *i2v_AUTHORITY_KEYID(
|
|
|
|
const X509V3_EXT_METHOD *method, void *ext, STACK_OF(CONF_VALUE) *extlist)
|
|
|
|
{
|
Use the correct function types in X509V3_EXT_METHODs.
While C allows function pointer casts, it is UB to call a function with
a different type than its actual type signature. That is, even though
`void f(int *)` and `void g(void *)` have the same ABI, it is UB to
cast `f` to a `void(*)(void *)` and then call it through that pointer.
Clang CFI will try to enforce this rule.
The recent CL to call X509_print in tests revealed that all the i2? and
?2i callbacks in X509V3_EXT_METHODs were implemented with functions of
the wrong type, out of some combination of missing consts and void*
turned into T*.
This CL fixes this. Where the function wasn't exported, or had no
callers, I just fixed the function itself. Where it had extension
callers, I added a wrapper function with a void* type.
I'm not positive whether the wrappers are the right call. On the one
hand, keeping the exported functions as-is is more type-safe and more
OpenSSL-compatible. However, most (but not all) uses of these are in
other code defining X509V3_EXT_METHODs themselves, so the void*
signature is more correct for them too. And the functions have a type
signature meant for X509V3_EXT_METHOD, complete with method pointer.
I've gone with leaving the exported ones as-is for now. Probably the
right answer anyway is to migrate the external callers, of either type
signature.
Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
3 years ago
|
|
|
const AUTHORITY_KEYID *akeyid = ext;
|
|
|
|
int extlist_was_null = extlist == NULL;
|
|
|
|
if (akeyid->keyid) {
|
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>
3 years ago
|
|
|
char *tmp = x509v3_bytes_to_hex(akeyid->keyid->data,
|
|
|
|
akeyid->keyid->length);
|
|
|
|
int ok = tmp != NULL && X509V3_add_value("keyid", tmp, &extlist);
|
|
|
|
OPENSSL_free(tmp);
|
|
|
|
if (!ok) {
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (akeyid->issuer) {
|
|
|
|
STACK_OF(CONF_VALUE) *tmpextlist =
|
|
|
|
i2v_GENERAL_NAMES(NULL, akeyid->issuer, extlist);
|
|
|
|
if (tmpextlist == NULL) {
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
extlist = tmpextlist;
|
|
|
|
}
|
|
|
|
if (akeyid->serial) {
|
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>
3 years ago
|
|
|
if (!X509V3_add_value_int("serial", akeyid->serial, &extlist)) {
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return extlist;
|
|
|
|
|
|
|
|
err:
|
|
|
|
if (extlist_was_null) {
|
|
|
|
sk_CONF_VALUE_pop_free(extlist, X509V3_conf_free);
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Currently two options: keyid: use the issuers subject keyid, the value
|
|
|
|
* 'always' means its is an error if the issuer certificate doesn't have a
|
|
|
|
* key id. issuer: use the issuers cert issuer and serial number. The default
|
|
|
|
* is to only use this if keyid is not present. With the option 'always' this
|
|
|
|
* is always included.
|
|
|
|
*/
|
|
|
|
|
Use the correct function types in X509V3_EXT_METHODs.
While C allows function pointer casts, it is UB to call a function with
a different type than its actual type signature. That is, even though
`void f(int *)` and `void g(void *)` have the same ABI, it is UB to
cast `f` to a `void(*)(void *)` and then call it through that pointer.
Clang CFI will try to enforce this rule.
The recent CL to call X509_print in tests revealed that all the i2? and
?2i callbacks in X509V3_EXT_METHODs were implemented with functions of
the wrong type, out of some combination of missing consts and void*
turned into T*.
This CL fixes this. Where the function wasn't exported, or had no
callers, I just fixed the function itself. Where it had extension
callers, I added a wrapper function with a void* type.
I'm not positive whether the wrappers are the right call. On the one
hand, keeping the exported functions as-is is more type-safe and more
OpenSSL-compatible. However, most (but not all) uses of these are in
other code defining X509V3_EXT_METHODs themselves, so the void*
signature is more correct for them too. And the functions have a type
signature meant for X509V3_EXT_METHOD, complete with method pointer.
I've gone with leaving the exported ones as-is for now. Probably the
right answer anyway is to migrate the external callers, of either type
signature.
Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
3 years ago
|
|
|
static void *v2i_AUTHORITY_KEYID(const X509V3_EXT_METHOD *method,
|
|
|
|
X509V3_CTX *ctx, STACK_OF(CONF_VALUE) *values)
|
|
|
|
{
|
|
|
|
char keyid = 0, issuer = 0;
|
|
|
|
size_t i;
|
|
|
|
int j;
|
|
|
|
CONF_VALUE *cnf;
|
|
|
|
ASN1_OCTET_STRING *ikeyid = NULL;
|
|
|
|
X509_NAME *isname = NULL;
|
|
|
|
GENERAL_NAMES *gens = NULL;
|
|
|
|
GENERAL_NAME *gen = NULL;
|
|
|
|
ASN1_INTEGER *serial = NULL;
|
|
|
|
X509_EXTENSION *ext;
|
|
|
|
X509 *cert;
|
|
|
|
AUTHORITY_KEYID *akeyid;
|
|
|
|
|
|
|
|
for (i = 0; i < sk_CONF_VALUE_num(values); i++) {
|
|
|
|
cnf = sk_CONF_VALUE_value(values, i);
|
|
|
|
if (!strcmp(cnf->name, "keyid")) {
|
|
|
|
keyid = 1;
|
|
|
|
if (cnf->value && !strcmp(cnf->value, "always"))
|
|
|
|
keyid = 2;
|
|
|
|
} else if (!strcmp(cnf->name, "issuer")) {
|
|
|
|
issuer = 1;
|
|
|
|
if (cnf->value && !strcmp(cnf->value, "always"))
|
|
|
|
issuer = 2;
|
|
|
|
} else {
|
|
|
|
OPENSSL_PUT_ERROR(X509V3, X509V3_R_UNKNOWN_OPTION);
|
|
|
|
ERR_add_error_data(2, "name=", cnf->name);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ctx || !ctx->issuer_cert) {
|
|
|
|
if (ctx && (ctx->flags == CTX_TEST))
|
|
|
|
return AUTHORITY_KEYID_new();
|
|
|
|
OPENSSL_PUT_ERROR(X509V3, X509V3_R_NO_ISSUER_CERTIFICATE);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
cert = ctx->issuer_cert;
|
|
|
|
|
|
|
|
if (keyid) {
|
|
|
|
j = X509_get_ext_by_NID(cert, NID_subject_key_identifier, -1);
|
|
|
|
if ((j >= 0) && (ext = X509_get_ext(cert, j)))
|
|
|
|
ikeyid = X509V3_EXT_d2i(ext);
|
|
|
|
if (keyid == 2 && !ikeyid) {
|
|
|
|
OPENSSL_PUT_ERROR(X509V3, X509V3_R_UNABLE_TO_GET_ISSUER_KEYID);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((issuer && !ikeyid) || (issuer == 2)) {
|
|
|
|
isname = X509_NAME_dup(X509_get_issuer_name(cert));
|
Unwind M_ASN1_* macros for primitive types.
At one point in the SSLeay days, all the ASN1_STRING typedefs were
separate structs (but only in debug builds) and the M_ASN1_* macros
included type casts to handle this.
This is long gone, but we still have the M_ASN1_* macros. Remove the
casts and switch code within the library to call the macros. Some
subtleties:
- The "MSTRING" types (what OpenSSL calls its built-in CHOICEs
containing some set of string types) are weird because the M_FOO_new()
macro and the tasn_new.c FOO_new() function behave differently. I've
split those into a separate CL.
- ASN1_STRING_type, etc., call into the macro, which accesses the field
directly. This CL inverts the dependency.
- ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via
IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed
M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free
function is a no-op, but consistent.)
- The other macros like M_ASN1_BIT_STRING_dup largely do not have
corresponding functions. I've aligned with OpenSSL in just using the
generic ASN1_STRING_dup function. But some others, like
M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup
function. OpenSSL retained these, so I have too.
Update-Note: Some external code uses the M_ASN1_* macros. This should
remain compatible, but some type errors may have gotten through
unnoticed. This CL restores type-checking.
Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045
Reviewed-by: Adam Langley <agl@google.com>
4 years ago
|
|
|
serial = ASN1_INTEGER_dup(X509_get_serialNumber(cert));
|
|
|
|
if (!isname || !serial) {
|
|
|
|
OPENSSL_PUT_ERROR(X509V3, X509V3_R_UNABLE_TO_GET_ISSUER_DETAILS);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(akeyid = AUTHORITY_KEYID_new()))
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
if (isname) {
|
|
|
|
if (!(gens = sk_GENERAL_NAME_new_null())
|
|
|
|
|| !(gen = GENERAL_NAME_new())
|
|
|
|
|| !sk_GENERAL_NAME_push(gens, gen)) {
|
|
|
|
OPENSSL_PUT_ERROR(X509V3, ERR_R_MALLOC_FAILURE);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
gen->type = GEN_DIRNAME;
|
|
|
|
gen->d.dirn = isname;
|
|
|
|
}
|
|
|
|
|
|
|
|
akeyid->issuer = gens;
|
|
|
|
akeyid->serial = serial;
|
|
|
|
akeyid->keyid = ikeyid;
|
|
|
|
|
|
|
|
return akeyid;
|
|
|
|
|
|
|
|
err:
|
|
|
|
X509_NAME_free(isname);
|
Unwind M_ASN1_* macros for primitive types.
At one point in the SSLeay days, all the ASN1_STRING typedefs were
separate structs (but only in debug builds) and the M_ASN1_* macros
included type casts to handle this.
This is long gone, but we still have the M_ASN1_* macros. Remove the
casts and switch code within the library to call the macros. Some
subtleties:
- The "MSTRING" types (what OpenSSL calls its built-in CHOICEs
containing some set of string types) are weird because the M_FOO_new()
macro and the tasn_new.c FOO_new() function behave differently. I've
split those into a separate CL.
- ASN1_STRING_type, etc., call into the macro, which accesses the field
directly. This CL inverts the dependency.
- ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via
IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed
M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free
function is a no-op, but consistent.)
- The other macros like M_ASN1_BIT_STRING_dup largely do not have
corresponding functions. I've aligned with OpenSSL in just using the
generic ASN1_STRING_dup function. But some others, like
M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup
function. OpenSSL retained these, so I have too.
Update-Note: Some external code uses the M_ASN1_* macros. This should
remain compatible, but some type errors may have gotten through
unnoticed. This CL restores type-checking.
Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045
Reviewed-by: Adam Langley <agl@google.com>
4 years ago
|
|
|
ASN1_INTEGER_free(serial);
|
|
|
|
ASN1_OCTET_STRING_free(ikeyid);
|
|
|
|
return NULL;
|
|
|
|
}
|