Method and device for public key management using blockchain

Abstract

To use a blockchain network to improve public-key infrastructure by providing fast and secure registration, revocation and update of digital certificates.SOLUTION: A public key may be recorded on a blockchain by a certificate authority in such a manner that any third party may quickly and easily verify that the public key is certified by the certificate authority and that the certificate has not been revoked. The certificate authority may be able to call the certificate nearly instantaneously and / or may be able to simultaneously certify a new key for the same entity while revoking the old key. In some cases, the ability to revoke a certification may be given to the owner of the public key or, in some cases, to one or even a group of other entities.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to blockchain networks, and more particularly to the use of blockchain to provide public key management for public key infrastructures. [Background technology]

[0002] In a public key infrastructure, a computing device may have a public-private key pair to enable secure communications, digital signatures, non-repudiation, and other functions. As part of the public key infrastructure, a computing device may have its public key registered with a certification authority. The certification authority provides the computing device with a digital signature that verifies the ownership and authorization of the public key.

[0003] The problem with the use of certification authorities is that once they issue a digital signature, it remains valid until its specified end date. However, public keys can be compromised, making revocation of the certificate necessary. To solve that problem, certification authorities maintain "revocation lists" detailing which digital certificates should be considered revoked, and periodically update and publish these lists. Entities wishing to verify a public key may rely on a digital certificate, but must therefore obtain and examine the corresponding certificate revocation list to know if the digital certificate has been revoked by the certification authority. This system and its inherent delays mean that some digital certificates may be revoked, and that revocations may not yet have been issued or are available to entities seeking to rely on the digital certificate. [Brief description of the drawings]

[0004] By way of example, reference is made to the following accompanying drawings which illustrate exemplary embodiments of the present application:

[0005] [Figure 1] 1 illustrates an example block structure of a blockchain network.

[0006] [Diagram 2] 1 shows a flowchart of an exemplary method of block propagation.

[0007] [Diagram 3] One exemplary method for verifying a public key is illustrated in the form of a flow chart.

[0008] [Figure 4] A simple example of a mining node is shown in block diagram form.

[0009] Like reference numbers in the figures are used to denote like elements and features. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] In one aspect, a computer-implemented method for managing a public key infrastructure using a blockchain may be provided, the method may include generating a digital certificate of a first entity, The first entity includes: generating an attestation transaction, the attestation transaction including a digital signature from a certification authority, a first output to an address based on a second public key, and a second output having an information field including the first public key; determining an attestation transaction identifier from a hash of the attestation transaction; The attestation transaction is propagated on the blockchain network to have a first public key, the digital attestation including the first public key and the attestation transaction identifier.

[0011] In some implementations, the second output includes an OP_RETURN field that includes at least the first public key. In some implementations, the first output includes a pay-to-public-key-hash (P2PKH) operation that references an address obtained as a hash of the second public key. In some implementations, the certificate authority holds a second private key that corresponds to the second public key.

[0012] In some implementations, the method may further include verifying the digital signature, the verifying step comprising: obtaining a copy of the attestation transaction from a blockchain based on the attestation transaction identifier in the digital certificate; determining that the first output is an unspent transaction output; determining that the first public key included in the second output in the attestation transaction matches a public key in the digital certificate; In some such implementations, determining that the first output is an unspent transaction output includes determining that the first output is in a pool of unspent transaction outputs of the blockchain network. In some such implementations, the attestation transaction may further include a certification authority public key, and verifying the digital certificate may further include determining that the attestation transaction is signed by the certification authority based on the certification authority public key.

[0013] In some such implementations, the method may further include revoking the digital attestation by generating a revocation transaction that includes an input and the first output of the attestation transaction and propagating the revocation transaction on the blockchain network.

[0014] In some implementations, the method may further include replacing the digital certificate with a new digital certificate of a new public key. generating a new attestation transaction, the new attestation transaction including as input the first output of the attestation transaction, a first new output to a new address based on a third public key, and a second new output having the information field, the information field including the new public key; determining a new attestation transaction identifier from hashing the new attestation transaction; propagating the new attestation transaction onto the blockchain network; The new digital certificate may include the new public key and the certification transaction identifier.

[0015] In some implementations, the information field is an OP_RETURN output.

[0016] In some implementations, the attestation transaction includes an input referencing an unused transaction outpoint address obtained from a hash of a certification authority public key, and the attestation transaction includes an unlock script for the unused transaction outpoint address that includes the certification authority public key and the digital signature, the digital signature being generated based on a private key corresponding to the certification authority public key.

[0017] In some implementations, the first output includes a multi-siglock script that allows one of two or more private keys to utilize the first output.

[0018] In a further aspect, the present application describes a computer-implemented method for verifying a digital certificate using a blockchain network, the digital certificate including a first public key and a certificate transaction identifier, the method comprising: receiving the digital certificate from a first entity; obtaining a copy of the attestation transaction from a blockchain based on the attestation transaction identifier in the digital certificate; wherein the certification transaction includes a digital signature from a certification authority, a first output to an address based on a second public key, and a second output having an information field. determining that the information field contains a public key that matches the first public key in the digital certificate; querying a pool of unspent transaction outputs to determine that the first output in the attestation transaction has not been spent in any royal transaction; verifying that the first public key is certified as valid based on the results; Includes.

[0019] In another aspect, a computing device implementing a node in a network may be provided, the computing device may include memory, one or more processors, and computer-executable instructions that, when executed, cause the processors to perform one or more of the methods described herein.

[0020] In yet another aspect, a computer-readable medium may be provided having processor-executable instructions stored thereon for differentiating nodes in a network, the processor-executable instructions, when executed by one or more processors, causing the processors to perform at least one of the methods described herein.

[0021] Other exemplary embodiments of the present disclosure will become apparent to those skilled in the art from a reading of the following detailed description in conjunction with the drawings.

[0022] As used herein, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including the listed elements alone, any subcombination, or all of the elements, and does not necessarily exclude additional elements.

[0023] As used herein, the term "at least one of ... or ..." is intended to cover all possible combinations and subcombinations of the recited elements, including the recited elements alone, any subcombination, or all of the elements, and does not necessarily exclude additional elements, and does not necessarily require all of the elements.

[0024] This application refers to hashing or hash function, which is intended to include any one of a number of cryptographic hash functions that, when applied to any data set or "message," deterministically produces a unique fixed-length alphanumeric string. The result of a hash function may be referred to as a hash value, fingerprint, hash result, or equivalents thereof. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2.

[0025] As used herein, the term "blockchain" is understood to encompass all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin, as exemplified by the Bitcoin SV protocol, may be referenced herein for convenience and illustrative purposes, although it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0026] A blockchain is a peer-to-peer electronic ledger implemented using a computer-based decentralized distributed system. Blockchains are composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes, among other things, the transfer of control of a digital asset between participants in a blockchain system, and contains at least one input and at least one output. Each block header contains a summary of the block's contents, such as in the form of a Merkle root, and each block header contains a hash of the previous block header. As a result, blocks become strung together to create a permanent, immutable record of all transactions written to the blockchain since inception. Transactions contain small programs, known as scripts, that embed their inputs and outputs and specify how and by whom the transaction's outputs are accessible. In the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0027] A blockchain is implemented by a network of nodes. Each node is a computing device with a network connection and running software that implements the applicable blockchain protocol. The nodes validate transactions and propagate them to other nodes in the network. Dedicated network nodes, called "mining nodes" or "miners," collect a set of unconfirmed or pending transactions into a block and attempt to "mine" the block. Mining, in these examples, refers to solving a proof-of-work (POW) before other miners in the network succeed in solving their respective block's proof-of-work. In the Bitcoin example, the POW involves hashing a block header containing a nonce until the result is below a threshold set by a mining difficulty parameter. The nonce is repeatedly incremented and hashing is repeated until the result is below the threshold or the miner receives a nonce that another miner has succeeded in. Variations in the mining process are well known to those skilled in the art.

[0028] Among other things checked, when validating a transaction, a node determines whether the inputs to the transaction are valid. In particular, the node evaluates whether the unlock script evaluates to true and determines whether the inputs reference an "unspent transaction output" (UTXO) from a previous transaction. Some nodes may maintain a running list or pool of UTXOs to allow for fast determination of whether a referenced transaction output is in a UTXO. A transaction may be identified by its unique transaction identifier TxID, which in some implementations is a hash of the transaction. Some transactions may have more than one output, and thus a unique transaction output (i.e., outpoint) may be identified by the TxID and an index, where the index points to one of the outputs in an ordered set of outputs from the transaction. If a transaction output is in the UTXO pool, the transaction output is "unspent" and can serve as an input.

[0029] The unlock script of a transaction outpoint defines how to prove "control" over the output in order to be executed. Often the address associated with a transaction output is a hash of a public key. To prove control over the output, the unlock script often requires a public key and a digital signature generated with the corresponding private key. In this way, the node that controls the private key can control when and how the transaction output is used in any subsequent input. As discussed further below, this has the inference that a transaction input corresponding to a particular public key includes a digital signature generated with the corresponding private key, and thus the entity associated with that particular public key has effectively signed or attested to the contents of the transaction.

[0030] Public key cryptography is ubiquitous in online communications. In many instances, processes and policies are required to provide certainty that a public key is owned in association with a particular entity. The most common approach to ensure that a public key is authentic and has not been compromised is the public key infrastructure (PKI). PKI relies on trusted third parties that "certify" public keys as valid. These entities are "certificate authorities (CAs)." CAs provide registration and issuance of digital certificates that confirm the binding between a public key and a particular owner. A public key holder provides its public key and its digital certificate to another entity. The other entity may then verify the authenticity of the public key by verifying that a trusted CA has digitally signed the public key as belonging to the holder.

[0031] One of the problems with existing PKIs is that sometimes public keys are compromised if a private key is lost or disclosed before the specified end date of a certificate. For that reason, CAs may maintain certificate revocation lists. Any entity that wishes to rely on a certificate associated with a public key must therefore locate and review the associated certificate revocation list to ensure that the certificate has been revoked by the CA. This compromises the ability to authenticate keys offline, creating risks due to the delay, sometimes 24 hours or more, between revocation and the issuance of a new certificate revocation list.

[0032] According to one aspect of the present application, a blockchain network may be used to improve public key infrastructure by providing fast and secure verification, revocation, and renewal of digital certificates. Public keys may be recorded on the blockchain by a certification authority so that a third party can quickly and easily verify that the public key has been certified by the certification authority and that the certification has not been revoked. By recording the public key in the manner described below, the certification authority can nearly instantly recall the certification or revoke the old key while simultaneously certifying a new key for the same entity. In some cases, the ability to revoke the certification may be given to the owner of the public key, or in some cases to one or a group of other entities.

[0033] Referring to FIG. 1, an exemplary system 100 for managing a public key infrastructure is illustrated. The example system 100 includes a first computing device 102, a second computing device 104, and a server 106. The first computing device 102 and the second computing device 104 may be implemented by any network-enabled computing device, including a server, a personal computer, a tablet, a smartphone, a connected car, an Internet of Things device, or any other such device. The server 106 is operated by a certificate authority (CA) and is configured to receive and respond to requests for digital certificates. Although the CA is shown as implemented by the server 106, it will be understood that the CA functionality may be implemented by one or more servers or other computing devices.

[0034] The system 100 further includes a blockchain network 108. The blockchain network 108 includes a network of nodes that operate according to an applicable blockchain protocol. In some implementations, one or more of the first computing device 102, the second computing device 104, and / or the server 106 may be nodes in the blockchain network 108, but in this example they are shown to be separate nodes from the blockchain network 108 for ease of explanation.

[0035] In this example system 100, a first computing device 102 is labeled "Alice" and has a public-private key pair for use in asymmetric cryptographic communications. In order to use the public key in some cryptographic scenarios, Alice may need to have a corresponding digital certificate that authenticates the public key and its association with Alice. Thus, at operation 110, Alice submits her public key, PK, to the CA along with a request to register. AThe CA may engage in some level of authentication to vouch for Alice's identity as the owner of the public key. In some examples, this authentication may be an automated online operation performed by server 106 based on the data provided in operation 110. In some examples, this authentication may additionally or alternatively include an offline authentication operation. Two-factor authentication and other such techniques may be utilized.

[0036] The CA issues the public key PK A When it decides that a token should be certified, it creates a blockchain transaction called a certification transaction (CTX). This transaction includes the public key PK A and is signed by the CA. The attestation transaction further includes an output controlled by the CA. As indicated by operation 112, the transaction is submitted to the blockchain network 108. At operation 114, the CA then sends to Alice the attestation transaction identifier TxID CTX _ PKA In some implementations, Alice obtains a copy of the attestation transaction from the blockchain network 108 based on the transaction identifier and checks whether it meets the expectations and provides the public key PK A It may be confirmed that the

[0037] Transaction Identifier TxID CTX _ PKA is the public key PK A Together, these effectively form a digital certificate for Alice. In connection with any communication with the second computing device 104, which in this example is labeled "Bob," Alice may send her digital certificate to Bob in operation 116. Bob then sends the public key PK A and verify that the attestation has not been revoked based on a blockchain maintained by the blockchain network 108.

[0038] In particular, at acts 118 and 120, Bob may request and receive a copy of the attestation transaction. From the attestation transaction, Bob knows that it is Alice's purported public key, PK A and that it is signed by a trusted certification authority. As shown by operations 122 and 124, Bob can further verify that the proof has not been revoked by querying the blockchain network 108 whether the transaction output controlled by the CA remains "unspent", i.e., the transaction output point is in the UTXO pool 130. The UTXO pool 130 is a pool of "unspent" transaction output points maintained by any of the multiple nodes of the blockchain network 108.

[0039] 2, an exemplary method 200 for registering a public key with a certification authority is illustrated in flow chart form. The exemplary method 200 may be performed by a certified certification authority and may be performed by one or more servers suitably programmed to perform the functions described.

[0040] In operation 202, the certification authority receives the public key PK A The certification authority receives a request from Alice for certification of . The certification authority may perform an authentication or authorization protocol in accordance with its applicable policies, which may include automated computer-implemented actions and / or administrator-implemented actions. Regardless of the particular authentication action, in operation 204 a determination is made as to whether to certify the public key for Alice. If not, the method ends. If the certification is approved, in operation 306 the certification authority generates a certification transaction. As discussed above, the certification transaction involves inputs including the certification authority's public key and a digital signature from the certification authority, outputs controlled by the certification authority, and the public key PK. ATo provide a specific example, the input may be a UTXO of some normalized or arbitrary value for which the attestation authority has a private key to generate a signature in a valid unlock script. The UTXO may be associated with sufficient digital value to offset any transaction fees for mining the attestation transaction.

[0041] An attestation transaction may contain two outputs: the CA public key PK, which is selected and controlled by the certification authority; CTX_PKA Based on this, the second is to put the public key PK in the non-operational information field, for example. A An example of the latter is the OP_RETURN function in Bitcoin, which is effectively an output where any data may be placed into the blockchain to be recorded once the transaction has been mined.

[0042] The first output may be, for example, a pay to public key hash (P2PKH) operation specifying a transfer to a public key hash (eg, a Bitcoin address) selected and controlled by the certification authority.

[0043] By its digital signature in the transaction, the attesting authority authenticates the input of the UTXO to the transaction, thereby satisfying the unlock script, and the attesting authority's public key PK that appears in the OP_RETURN output. A This provides verifiable evidence that Alice has authenticated the request. Note that in some implementations, additional information from Alice may appear in the OP_RETURN output field, such as a digital signature or other such information.

[0044] Once the attestation transaction has been generated, in operation 208 the attestation authority hashes the transaction to generate a transaction identifier TxID CTX _ PKAand propagates the transaction across the blockchain network, as shown in operation 210. It is understood that "propagating" a transaction includes submitting the transaction to a node in the blockchain network, where it is verified and sent to all other nodes, and verifying and resending the transaction until it has reached substantially all nodes in the network. In some embodiments, the attestation authority is itself one of the nodes in the blockchain network.

[0045] In operation 212, the attestation authority waits for the mining of a block containing the attestation transaction, i.e., the “confirmation” of the transaction, and then in operation 214, the transaction identifier TxID CTX _ PKA to Alice. In some implementations, the certificate authority may provide Alice with a transaction identifier before the transaction is mined.

[0046] Alice then sends her public key, PK, to any third party. A and the proof transaction identifier TxID CTX _ PKA From this, a third party may verify that Alice's public key is certified by the CA.

[0047] A simple example of a proof transaction is shown below: [Table 1]

[0048] Note that the unlock script for input contains the public key of the signing authority and the signature generated by the certification authority. Alice's public key PK A appears in the OP_RETURN field as the second output. The first output is an arbitrary public key hash controlled by the certificate authority.

[0049] Referring to Figure 3, an exemplary method 300 for verifying a public key is shown. The operations illustrated in the exemplary method 300 may be performed by a computing device that seeks to verify a public key that is intended to be certified using the process illustrated in Figure 2. Exemplary computing devices include any network-enabled computing device.

[0050] The method 300 includes receiving a digital certificate for another entity, such as the first computing device 102 (FIG. 1) labeled “Alice,” at operation 302. The digital certificate includes at least a public key, PK A , and a proof transaction identifier TxID CTX _ PKA At operation 304, the attestation transaction is retrieved from the blockchain network using the attestation transaction identifier. It is understood that the attestation transaction may be retrieved from a copy of the blockchain, whether the copy is local to the computing device or maintained by a node in the blockchain network. If the transaction is not confirmed, i.e., not yet in a mined block, the transaction may reside in a mempool of unconfirmed transactions. However, in many implementations, the authentication authority only needs to provide the attestation transaction identifier to Alice after the attestation transaction has been mined.

[0051] From the attestation transaction, the computing device may verify certain things. In particular, at operation 306, the computing device may verify that the attestation transaction is signed by a certification authority. The computing device may have, or may have access to, a list of certified or trusted trust authorities and their respective public keys. This may allow the computing device to verify the digital signature. The digital signature may form part of the input to the attestation transaction as described. By verifying that the attestation transaction is signed by a trusted or certified certification authority, the computing device can verify that the attestation is valid. Note that if the transaction is in the blockchain, it has been established and verified by miners, so the computing device does not necessarily need to verify the digital signature in the input. Rather, the computing device may simply verify that the public key identified in the input is associated with a certification authority.

[0052] As indicated by operation 308, the computing device may further verify that one of the output points of the attestation transaction remains “unspent”, i.e., the output point can be found in the UTXO pool. This verifying operation confirms that the attestation remains valid and unrevoked. As mentioned above, in many embodiments (alternatives are described below), this output point is controlled by the attestation authority. This allows the attestation authority to revoke the attestation if the key is compromised, terminated, or no longer valid. Revocation or cancellation is easily accomplished by having the attestation authority “spend” the output point, thereby removing it from the UTXO pool. Verification that the output point is in the UTXO pool may be performed by querying the UTXO pool, for example, based on the TxID number and the output index. In some examples, the computing device may query the UTXO pool through an intermediary, such as a node of a blockchain network.

[0053] At operation 310, the computing device detects the public key PK in the second output of the attestation transaction. A is the public key PK received as part of a digital certificate from Alice A Verify that it matches.

[0054] If operations 306, 308, and 310 are all verified, then in operation 312 the computing device validates the public key PK in the digital certificate received from Alice. A is determined to be valid.

[0055] By using the blockchain network to record the public key attestation, the attestation authority can quickly and easily revoke the signature by "using" the output point, resulting in a failed validation in operation 308. Thus, the attestation authority may revoke the public key attestation by generating and propagating a transaction that uses the first output of the attestation transaction. As described above, the first output may be a P2PKH operation that transfers a nominal digital asset to the public key hash address specified in the first output. The unlock script for that first output, in these examples, is the CA public key PK used in the P2PKH operation. CTX_PKA The RSA may require a digital signature from a certification authority that claims control over the private key corresponding to the RSA.

[0056] In some instances, a certification authority may not revoke a certification, but may be asked to replace / update a certified public key. For example, if a private key is lost or compromised, the owner (e.g., Alice) may renew a public key previously certified by the certification authority as a new public key, PK A_new The CA may request that the certificate be renewed or replaced with a new attestation transaction CTX. The CA will authenticate the request using whatever online or offline authentication mechanism is in place, and if it determines that a renewal action should occur, it will issue a new attestation transaction CTX. new to revoke the old certificate and issue a new certificate.

[0057] The new proof transaction will generate the same type of output, i.e., PK CTX_new A new public key and PK selected by the CA such as A_new However, the input is the original proof transaction TxID. CTX _ PKAThe revocation may include a CA-controlled output point from the UTXO pool. Revocation is performed by removing the output point from the UTXO pool by "using" that output as an input into a new attestation transaction. Advantageously, the revocation of the old public key certificate and the registration of the new public key certificate occur in a single transaction. Furthermore, a separate periodically published list of certificate revocations does not need to be maintained and made available to certification authorities.

[0058] As mentioned above, in many cases, the first output point of the attestation transaction may be controlled by the certification authority, so that only the certification authority can revoke the certification of the public key. Revocation is based on "using" the first output point with the private key that corresponds to that output point. In some instances, however, it may be advantageous to configure the attestation transaction to allow other entities to revoke the certification.

[0059] For example, in some situations, the owner of the public key, e.g., Alice, may have the authority to revoke their public key. In this configuration, the first output point in the attestation transaction is controlled by Alice, i.e., it references a public key (public key hash) for which Alice has the corresponding private key. That is, the unlock script for the first output point requires a digital signature from Alice. This configuration may be advantageous in some public key attestation scenarios, such as registration for an online service. One example of an online service is a social media account on a social media platform. Using the mechanism described above, the platform may register a user's public key for use with the platform, allowing the user to interact with the platform and / or other users of the platform based on trust in their digital certificates that are backed up via the attestation transaction. The user can then revoke the attestation to terminate their account without the cooperation of the platform.

[0060] In another scenario, more than one output point may be provided, one of which may be "used" to complete the proof, in which case the third party may be configured to test both (or all) such output points of the proof transaction for their presence as unspent transaction outputs in the UTXO pool.

[0061] Alternatively, if revocation from any one of multiple parties is to be achieved, the first output may be configured to use multiple signatures, i.e., any of a number of signatures may be used to "spend" the output. For this purpose, multisig may be used in the output.

[0062] In yet another scenario, a multisig may be configured to ensure that at least a threshold number of entities agree to revoke the attestation. A multisig may be configured to require n out of m signatures to unlock an output, where n≦m. By way of example, in the case of an organization such as a business, partnership, or other such collection of individuals, a signed public key associated with the organization may be revokable only if all or at least a threshold number of the particular entities, such as the CEO, COO, CTO, or other executive or business-related individual, sign the revocation.

[0063] It will be understood that some or all of the above operations of the various above-described exemplary methods may be performed in an order different from that shown and / or may be performed simultaneously without changing the overall operation of the methods.

[0064] 4, a simplified computing device 400 according to an example of the present application is illustrated in block diagram form. The computing device 400 may perform one or more of the functions described above. In this sense, it may function as the first computing device 102 (FIG. 1), the second computing device 104 (FIG. 1), or the server 106 (FIG. 1) in some implementations.

[0065] Computing device 400 includes a processor 402, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. Computing device 400 may further include memory 404, which may include permanent and non-permanent memory for storing values, variables, and in some examples, processor-executable program instructions, and a network interface 406.

[0066] Computing device 400 may include processor-executable applications 408 that include processor-executable instructions that, when executed, cause processor 402 to perform one or more of the functions or operations described herein.

[0067] The various embodiments described above are merely examples and are not meant to limit the scope of the present application. Various innovations described herein will be apparent to those skilled in the art, as will variations within the intended scope of the present application. In particular, features from one or more of the exemplary embodiments described above may be selected to generate alternative exemplary embodiments, including combinations of features not explicitly shown above. Furthermore, features from one or more of the exemplary embodiments described above may be selected and combined to generate alternative exemplary embodiments, including combinations of features not explicitly shown above. Features suitable for such combinations and combinations will be readily apparent to those skilled in the art upon review of the present application as a whole. The subject matter described in the present specification and claims covers and encompasses all appropriate technical modifications.

Claims

1. 1. A computer-implemented method comprising: receiving a digital certificate for a first entity, the digital certificate including a first public key of the first entity and an attestation transaction identifier generated from a hash of a attestation transaction, the attestation transaction including a digital signature from a certification authority, a first output to an address based on a second public key, and a second output having an information field including the first public key; obtaining a copy of the attestation transaction from a blockchain network based on the attestation transaction identifier in the digital certificate; determining that the first output is an unspent transaction output; determining that the first public key included in the second output of the attestation transaction matches the first public key in the digital certificate; The method includes:

2. The method of claim 1 , wherein the second output includes an OP_RETURN field that contains at least the first public key.

3. 3. The method of claim 1 or 2, wherein the first output comprises a pay-to-public-key-hash (P2PKH) operation referencing an address obtained as a hash of the second public key.

4. The method of any one of claims 1 to 3, wherein the second public key corresponds to a second private key held by the certification authority.

5. 2. The method of claim 1 , wherein determining that the first output is an unspent transaction output comprises determining that the first output is in a pool of unspent transaction outputs of the blockchain network.

6. 6. The method of claim 1, wherein the input to the certification transaction further comprises a certification authority public key, and wherein verifying the digital certificate further comprises determining that the certification transaction has been signed by the certification authority based on the certification authority public key.

7. The method according to any one of claims 1 to 6, wherein the information field is an OP_RETURN output.

8. A method according to any one of claims 1 to 7, wherein the attestation transaction includes an input referencing an unused transaction outpoint address obtained from a hash of a certification authority public key, the attestation transaction includes an unlock script for the unused transaction outpoint address including the certification authority public key and the digital signature, and the digital signature is generated based on a private key corresponding to the certification authority public key.

9. 9. The method of claim 1, wherein the first output comprises a multi-siglock script that allows one of two or more private keys to utilize the first output.

10. 1. A computing device comprising: one or more processors; Memory, computer-executable instructions stored in said memory, which, when executed by said one or more processors, cause said processors to perform a method according to any one of claims 1 to 9; 2. A computing device comprising:

11. A computer readable medium storing processor executable instructions which, when executed by one or more processors, cause the processors to perform the method of any one of claims 1 to 9.

Images