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.] */
|
|
|
|
|
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>
|
|
|
|
|
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>
|
2014-06-20 20:00:00 +01:00
|
|
|
#include <openssl/err.h>
|
|
|
|
#include <openssl/evp.h>
|
|
|
|
#include <openssl/mem.h>
|
|
|
|
#include <openssl/obj.h>
|
2015-03-28 07:12:01 +00:00
|
|
|
#include <openssl/thread.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
#include <openssl/x509.h>
|
|
|
|
|
2015-05-15 23:29:21 +01:00
|
|
|
#include "../internal.h"
|
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,
|
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;
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
ASN1_SEQUENCE_cb(X509_PUBKEY, pubkey_cb) = {
|
2016-01-14 19:25:12 +00:00
|
|
|
ASN1_SIMPLE(X509_PUBKEY, algor, X509_ALGOR),
|
|
|
|
ASN1_SIMPLE(X509_PUBKEY, public_key, ASN1_BIT_STRING)
|
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)
|
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;
|
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);
|
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
|
|
|
}
|
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);
|
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);
|
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);
|
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. */
|
2015-05-15 23:29:21 +01:00
|
|
|
static struct CRYPTO_STATIC_MUTEX g_pubkey_lock = CRYPTO_STATIC_MUTEX_INIT;
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
EVP_PKEY *X509_PUBKEY_get(X509_PUBKEY *key)
|
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;
|
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) {
|
|
|
|
CRYPTO_STATIC_MUTEX_unlock(&g_pubkey_lock);
|
|
|
|
return EVP_PKEY_up_ref(key->pkey);
|
|
|
|
}
|
|
|
|
CRYPTO_STATIC_MUTEX_unlock(&g_pubkey_lock);
|
|
|
|
|
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) {
|
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);
|
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) {
|
|
|
|
CRYPTO_STATIC_MUTEX_unlock(&g_pubkey_lock);
|
|
|
|
EVP_PKEY_free(ret);
|
|
|
|
ret = key->pkey;
|
|
|
|
} else {
|
|
|
|
key->pkey = ret;
|
|
|
|
CRYPTO_STATIC_MUTEX_unlock(&g_pubkey_lock);
|
|
|
|
}
|
|
|
|
|
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);
|
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;
|
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
|
2014-06-20 20:00:00 +01:00
|
|
|
*/
|
|
|
|
|
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;
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
int i2d_PUBKEY(const EVP_PKEY *a, unsigned char **pp)
|
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
|
2014-06-20 20:00:00 +01:00
|
|
|
*/
|
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;
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
int i2d_RSA_PUBKEY(const RSA *a, unsigned char **pp)
|
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;
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
#ifndef OPENSSL_NO_DSA
|
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;
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
int i2d_DSA_PUBKEY(const DSA *a, unsigned char **pp)
|
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;
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
#endif
|
|
|
|
|
|
|
|
EC_KEY *d2i_EC_PUBKEY(EC_KEY **a, const unsigned char **pp, long length)
|
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);
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
int i2d_EC_PUBKEY(const EC_KEY *a, unsigned char **pp)
|
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);
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
int X509_PUBKEY_set0_param(X509_PUBKEY *pub, const ASN1_OBJECT *aobj,
|
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;
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
int X509_PUBKEY_get0_param(ASN1_OBJECT **ppkalg,
|
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;
|
|
|
|
}
|