kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
156edfe536
boringssl/crypto/x509/x_pubkey.c

367 lines
10 KiB
C
Raw Normal View History

Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
* All rights reserved.
*
* This package is an SSL implementation written
* by Eric Young (eay@cryptsoft.com).
* The implementation was written so as to conform with Netscapes SSL.
*
* This library is free for commercial and non-commercial use as long as
* the following conditions are aheared to. The following conditions
* apply to all code found in this distribution, be it the RC4, RSA,
* lhash, DES, etc., code; not just the SSL code. The SSL documentation
* included with this distribution is covered by the same copyright terms
* except that the holder is Tim Hudson (tjh@cryptsoft.com).
*
* Copyright remains Eric Young's, and as such any Copyright notices in
* the code are not to be removed.
* If this package is used in a product, Eric Young should be given attribution
* as the author of the parts of the library used.
* This can be in the form of a textual message at program startup or
* in documentation (online or textual) provided with the package.
*
* 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 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 acknowledgement:
* "This product includes cryptographic software written by
* Eric Young (eay@cryptsoft.com)"
* The word 'cryptographic' can be left out if the rouines from the library
* being used are not cryptographic related :-).
* 4. If you include any Windows specific code (or a derivative thereof) from
* the apps directory (application code) you must include an acknowledgement:
* "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
*
* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
* ANY EXPRESS 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 AUTHOR OR 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.
*
* The licence and distribution terms for any publically available version or
* derivative of this code cannot be changed. i.e. this code cannot simply be
* copied and put under another distribution licence
* [including the GNU Public Licence.] */
Fix build when using Visual Studio 2015 Update 1. Many of the compatibility issues are described at https://msdn.microsoft.com/en-us/library/mt612856.aspx. The macros that suppressed warnings on a per-function basis no longer work in Update 1, so replace them with #pragmas. Update 1 warns when |size_t| arguments to |printf| are casted, so stop doing that casting. Unfortunately, this requires an ugly hack to continue working in MSVC 2013 as MSVC 2013 doesn't support "%zu". Finally, Update 1 has new warnings, some of which need to be suppressed. --- Updated by davidben to give up on suppressing warnings in crypto/x509 and crypto/x509v3 as those directories aren't changed much from upstream. In each of these cases, upstream opted just blindly initialize the variable, so do the same. Also switch C4265 to level 4, per Microsoft's recommendation and work around a bug in limits.h that happens to get fixed by Google include order style. (limits.h is sensitive to whether corecrt.h, pulled in by stddef.h and some other headers, is included before it. The reason it affected just one file is we often put the file's header first, which means base.h is pulling in stddef.h. Relying on this is ugly, but it's no worse than what everything else is doing and this doesn't seem worth making something as tame as limits.h so messy to use.) Change-Id: I02d1f935356899f424d3525d03eca401bfa3e6cd Reviewed-on: https://boringssl-review.googlesource.com/7480 Reviewed-by: David Benjamin <davidben@google.com>
2016-01-18 08:21:42 +00:00
#include <openssl/x509.h>
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
#include <limits.h>
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#include <openssl/asn1.h>
#include <openssl/asn1t.h>
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
#include <openssl/bytestring.h>
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#include <openssl/err.h>
#include <openssl/evp.h>
#include <openssl/mem.h>
#include <openssl/obj.h>
Eliminate unnecessary includes from low-level crypto modules. Beyond generally eliminating unnecessary includes, eliminate as many includes of headers that declare/define particularly error-prone functionality like strlen, malloc, and free. crypto/err/internal.h was added to remove the dependency on openssl/thread.h from the public openssl/err.h header. The include of <stdlib.h> in openssl/mem.h was retained since it defines OPENSSL_malloc and friends as macros around the stdlib.h functions. The public x509.h, x509v3.h, and ssl.h headers were not changed in order to minimize breakage of source compatibility with external code. Change-Id: I0d264b73ad0a720587774430b2ab8f8275960329 Reviewed-on: https://boringssl-review.googlesource.com/4220 Reviewed-by: Adam Langley <agl@google.com>
2015-03-28 07:12:01 +00:00
#include <openssl/thread.h>
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
Remove remaining calls to the old lock functions. |SSL_CTX| and |X509_STORE| have grown their own locks. Several static locks have been added to hack around not being able to use a |CRYPTO_once_t| in public headers. Lastly, support for calling |SSL_CTX_set_generate_session_id| concurrently with active connections has been removed. No other property of an |SSL_CTX| works like that. Change-Id: Iff5fe3ee3fdd6ea9c9daee96f850b107ad8a6bca Reviewed-on: https://boringssl-review.googlesource.com/4775 Reviewed-by: Adam Langley <agl@google.com>
2015-05-15 23:29:21 +01:00
#include "../internal.h"
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
/* Minor tweak to operation: free up EVP_PKEY */
static int pubkey_cb(int operation, ASN1_VALUE **pval, const ASN1_ITEM *it,
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
void *exarg)
{
if (operation == ASN1_OP_FREE_POST) {
X509_PUBKEY *pubkey = (X509_PUBKEY *)*pval;
EVP_PKEY_free(pubkey->pkey);
}
return 1;
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
ASN1_SEQUENCE_cb(X509_PUBKEY, pubkey_cb) = {
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
ASN1_SIMPLE(X509_PUBKEY, algor, X509_ALGOR),
ASN1_SIMPLE(X509_PUBKEY, public_key, ASN1_BIT_STRING)
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
} ASN1_SEQUENCE_END_cb(X509_PUBKEY, X509_PUBKEY)
IMPLEMENT_ASN1_FUNCTIONS(X509_PUBKEY)
int X509_PUBKEY_set(X509_PUBKEY **x, EVP_PKEY *pkey)
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
{
X509_PUBKEY *pk = NULL;
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
uint8_t *spki = NULL;
size_t spki_len;
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
if (x == NULL)
return (0);
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
CBB cbb;
if (!CBB_init(&cbb, 0) ||
!EVP_marshal_public_key(&cbb, pkey) ||
!CBB_finish(&cbb, &spki, &spki_len) ||
spki_len > LONG_MAX) {
CBB_cleanup(&cbb);
OPENSSL_PUT_ERROR(X509, X509_R_PUBLIC_KEY_ENCODE_ERROR);
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
goto error;
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
}
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
const uint8_t *p = spki;
pk = d2i_X509_PUBKEY(NULL, &p, (long)spki_len);
if (pk == NULL || p != spki + spki_len) {
OPENSSL_PUT_ERROR(X509, X509_R_PUBLIC_KEY_DECODE_ERROR);
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
goto error;
}
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
OPENSSL_free(spki);
X509_PUBKEY_free(*x);
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
*x = pk;
return 1;
error:
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
X509_PUBKEY_free(pk);
OPENSSL_free(spki);
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
return 0;
}
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
/* g_pubkey_lock is used to protect the initialisation of the |pkey| member of
* |X509_PUBKEY| objects. Really |X509_PUBKEY| should have a |CRYPTO_once_t|
* inside it for this, but |CRYPTO_once_t| is private and |X509_PUBKEY| is
* not. */
Remove remaining calls to the old lock functions. |SSL_CTX| and |X509_STORE| have grown their own locks. Several static locks have been added to hack around not being able to use a |CRYPTO_once_t| in public headers. Lastly, support for calling |SSL_CTX_set_generate_session_id| concurrently with active connections has been removed. No other property of an |SSL_CTX| works like that. Change-Id: Iff5fe3ee3fdd6ea9c9daee96f850b107ad8a6bca Reviewed-on: https://boringssl-review.googlesource.com/4775 Reviewed-by: Adam Langley <agl@google.com>
2015-05-15 23:29:21 +01:00
static struct CRYPTO_STATIC_MUTEX g_pubkey_lock = CRYPTO_STATIC_MUTEX_INIT;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
EVP_PKEY *X509_PUBKEY_get(X509_PUBKEY *key)
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
{
EVP_PKEY *ret = NULL;
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
uint8_t *spki = NULL;
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
if (key == NULL)
goto error;
CRYPTO_STATIC_MUTEX_lock_read(&g_pubkey_lock);
if (key->pkey != NULL) {
Split unlock functions into read/write variants. Windows SRWLOCK requires you call different functions here. Split them up in preparation for switching Windows from CRITICAL_SECTION. BUG=37 Change-Id: I7b5c6a98eab9ae5bb0734b805cfa1ff334918f35 Reviewed-on: https://boringssl-review.googlesource.com/8080 Reviewed-by: Adam Langley <agl@google.com>
2016-05-24 16:28:36 +01:00
CRYPTO_STATIC_MUTEX_unlock_read(&g_pubkey_lock);
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
return EVP_PKEY_up_ref(key->pkey);
}
Split unlock functions into read/write variants. Windows SRWLOCK requires you call different functions here. Split them up in preparation for switching Windows from CRITICAL_SECTION. BUG=37 Change-Id: I7b5c6a98eab9ae5bb0734b805cfa1ff334918f35 Reviewed-on: https://boringssl-review.googlesource.com/8080 Reviewed-by: Adam Langley <agl@google.com>
2016-05-24 16:28:36 +01:00
CRYPTO_STATIC_MUTEX_unlock_read(&g_pubkey_lock);
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
/* Re-encode the |X509_PUBKEY| to DER and parse it. */
int spki_len = i2d_X509_PUBKEY(key, &spki);
if (spki_len < 0) {
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
goto error;
}
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
CBS cbs;
CBS_init(&cbs, spki, (size_t)spki_len);
ret = EVP_parse_public_key(&cbs);
if (ret == NULL || CBS_len(&cbs) != 0) {
OPENSSL_PUT_ERROR(X509, X509_R_PUBLIC_KEY_DECODE_ERROR);
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
goto error;
}
/* Check to see if another thread set key->pkey first */
CRYPTO_STATIC_MUTEX_lock_write(&g_pubkey_lock);
if (key->pkey) {
Split unlock functions into read/write variants. Windows SRWLOCK requires you call different functions here. Split them up in preparation for switching Windows from CRITICAL_SECTION. BUG=37 Change-Id: I7b5c6a98eab9ae5bb0734b805cfa1ff334918f35 Reviewed-on: https://boringssl-review.googlesource.com/8080 Reviewed-by: Adam Langley <agl@google.com>
2016-05-24 16:28:36 +01:00
CRYPTO_STATIC_MUTEX_unlock_write(&g_pubkey_lock);
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
EVP_PKEY_free(ret);
ret = key->pkey;
} else {
key->pkey = ret;
Split unlock functions into read/write variants. Windows SRWLOCK requires you call different functions here. Split them up in preparation for switching Windows from CRITICAL_SECTION. BUG=37 Change-Id: I7b5c6a98eab9ae5bb0734b805cfa1ff334918f35 Reviewed-on: https://boringssl-review.googlesource.com/8080 Reviewed-by: Adam Langley <agl@google.com>
2016-05-24 16:28:36 +01:00
CRYPTO_STATIC_MUTEX_unlock_write(&g_pubkey_lock);
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
}
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
OPENSSL_free(spki);
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
return EVP_PKEY_up_ref(ret);
error:
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
OPENSSL_free(spki);
EVP_PKEY_free(ret);
return NULL;
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
}
/*
* Now two pseudo ASN1 routines that take an EVP_PKEY structure and encode or
* decode as X509_PUBKEY
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
*/
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
EVP_PKEY *d2i_PUBKEY(EVP_PKEY **a, const unsigned char **pp, long length)
{
X509_PUBKEY *xpk;
EVP_PKEY *pktmp;
xpk = d2i_X509_PUBKEY(NULL, pp, length);
if (!xpk)
return NULL;
pktmp = X509_PUBKEY_get(xpk);
X509_PUBKEY_free(xpk);
if (!pktmp)
return NULL;
if (a) {
EVP_PKEY_free(*a);
*a = pktmp;
}
return pktmp;
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
int i2d_PUBKEY(const EVP_PKEY *a, unsigned char **pp)
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
{
X509_PUBKEY *xpk = NULL;
int ret;
if (!a)
return 0;
if (!X509_PUBKEY_set(&xpk, (EVP_PKEY *)a))
return 0;
ret = i2d_X509_PUBKEY(xpk, pp);
X509_PUBKEY_free(xpk);
return ret;
}
/*
* The following are equivalents but which return RSA and DSA keys
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
*/
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
RSA *d2i_RSA_PUBKEY(RSA **a, const unsigned char **pp, long length)
{
EVP_PKEY *pkey;
RSA *key;
const unsigned char *q;
q = *pp;
pkey = d2i_PUBKEY(NULL, &q, length);
if (!pkey)
return NULL;
key = EVP_PKEY_get1_RSA(pkey);
EVP_PKEY_free(pkey);
if (!key)
return NULL;
*pp = q;
if (a) {
RSA_free(*a);
*a = key;
}
return key;
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
int i2d_RSA_PUBKEY(const RSA *a, unsigned char **pp)
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
{
EVP_PKEY *pktmp;
int ret;
if (!a)
return 0;
pktmp = EVP_PKEY_new();
if (!pktmp) {
OPENSSL_PUT_ERROR(X509, ERR_R_MALLOC_FAILURE);
return 0;
}
EVP_PKEY_set1_RSA(pktmp, (RSA *)a);
ret = i2d_PUBKEY(pktmp, pp);
EVP_PKEY_free(pktmp);
return ret;
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#ifndef OPENSSL_NO_DSA
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
DSA *d2i_DSA_PUBKEY(DSA **a, const unsigned char **pp, long length)
{
EVP_PKEY *pkey;
DSA *key;
const unsigned char *q;
q = *pp;
pkey = d2i_PUBKEY(NULL, &q, length);
if (!pkey)
return NULL;
key = EVP_PKEY_get1_DSA(pkey);
EVP_PKEY_free(pkey);
if (!key)
return NULL;
*pp = q;
if (a) {
DSA_free(*a);
*a = key;
}
return key;
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
int i2d_DSA_PUBKEY(const DSA *a, unsigned char **pp)
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
{
EVP_PKEY *pktmp;
int ret;
if (!a)
return 0;
pktmp = EVP_PKEY_new();
if (!pktmp) {
OPENSSL_PUT_ERROR(X509, ERR_R_MALLOC_FAILURE);
return 0;
}
EVP_PKEY_set1_DSA(pktmp, (DSA *)a);
ret = i2d_PUBKEY(pktmp, pp);
EVP_PKEY_free(pktmp);
return ret;
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#endif
EC_KEY *d2i_EC_PUBKEY(EC_KEY **a, const unsigned char **pp, long length)
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
{
EVP_PKEY *pkey;
EC_KEY *key;
const unsigned char *q;
q = *pp;
pkey = d2i_PUBKEY(NULL, &q, length);
if (!pkey)
return (NULL);
key = EVP_PKEY_get1_EC_KEY(pkey);
EVP_PKEY_free(pkey);
if (!key)
return (NULL);
*pp = q;
if (a) {
EC_KEY_free(*a);
*a = key;
}
return (key);
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
int i2d_EC_PUBKEY(const EC_KEY *a, unsigned char **pp)
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
{
EVP_PKEY *pktmp;
int ret;
if (!a)
return (0);
if ((pktmp = EVP_PKEY_new()) == NULL) {
OPENSSL_PUT_ERROR(X509, ERR_R_MALLOC_FAILURE);
return (0);
}
EVP_PKEY_set1_EC_KEY(pktmp, (EC_KEY *)a);
ret = i2d_PUBKEY(pktmp, pp);
EVP_PKEY_free(pktmp);
return (ret);
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
int X509_PUBKEY_set0_param(X509_PUBKEY *pub, const ASN1_OBJECT *aobj,
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
int ptype, void *pval,
unsigned char *penc, int penclen)
{
if (!X509_ALGOR_set0(pub->algor, aobj, ptype, pval))
return 0;
if (penc) {
if (pub->public_key->data)
OPENSSL_free(pub->public_key->data);
pub->public_key->data = penc;
pub->public_key->length = penclen;
/* Set number of unused bits to zero */
pub->public_key->flags &= ~(ASN1_STRING_FLAG_BITS_LEFT | 0x07);
pub->public_key->flags |= ASN1_STRING_FLAG_BITS_LEFT;
}
return 1;
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
int X509_PUBKEY_get0_param(ASN1_OBJECT **ppkalg,
OpenSSL reformat x509/, x509v3/, pem/ and asn1/. OpenSSL upstream did a bulk reformat. We still have some files that have the old OpenSSL style and this makes applying patches to them more manual, and thus more error-prone, than it should be. This change is the result of running util/openssl-format-source -v -c . in the enumerated directories. A few files were in BoringSSL style and have not been touched. This change should be formatting only; no semantic difference. Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e Reviewed-on: https://boringssl-review.googlesource.com/6904 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2016-01-14 19:25:12 +00:00
const unsigned char **pk, int *ppklen,
X509_ALGOR **pa, X509_PUBKEY *pub)
{
if (ppkalg)
*ppkalg = pub->algor->algorithm;
if (pk) {
*pk = pub->public_key->data;
*ppklen = pub->public_key->length;
}
if (pa)
*pa = pub->algor;
return 1;
}
Reference in New Issue Copy Permalink