Method and device for automated digital certificate validation - Patents.com

Abstract

The public key may be recorded on the blockchain by the certificate authority so that any third party can quickly and easily verify that the public key has been certified by the certificate authority and that the certification has not expired. The certificate authority may be able to revoke the certification almost instantly and / or certify a new key for the same entity while simultaneously revoking the old key. Validation may be built into new transactions so that there is no gap between reliance on a certificate and verification of its validity. In some cases, each transaction in which a certificate is used may also serve as a linked certificate transaction that updates the certificate to enable subsequent use.

Description

[Technical field]

[0001] The present disclosure relates to blockchain networks, and in particular to the use of blockchain to facilitate digital certificate validation. [Background technology]

[0002] In a public key infrastructure, a computing device may have a public-private key pair to facilitate secure communications, digital signatures, non-repudiation, and other functions. As part of a public key infrastructure, a computing device may register its public key with a certificate authority, which provides the computing device with a digital certificate that confirms the ownership and authorization of the public key.

[0003] A problem with the use of certification authorities is that once a digital certificate is issued, it remains valid until its specified expiration date. However, public keys can be compromised, making revocation of the certificate necessary. To address this problem, certification authorities maintain "revocation lists" that detail which digital certificates should be considered revoked, and periodically update and publish these lists. Entities wishing to validate a public key can rely on the digital certificate, but must obtain and consult the corresponding certificate revocation list to see if the digital certificate has been revoked by the certification authority. This system and its inherent delays mean that some digital certificates may have been revoked, and that the revocation may not yet have been published or available to entities wishing to rely on the digital certificate. [Brief description of the drawings]

[0004] Reference will now be made, by way of example, to the accompanying drawings which illustrate exemplary embodiments of the present application. [Figure 1] 1 illustrates generally an exemplary system for managing a public key infrastructure. [Diagram 2]1 illustrates, in flow chart form, one exemplary method for registering a public key with a certificate authority. [Diagram 3] 1 illustrates, in flow chart form, one exemplary method for verifying a public key. [Figure 4] 1 illustrates, in flow chart form, an exemplary method for validating a digital certificate. [Diagram 5] 1 illustrates, in flow chart form, another exemplary method for validating a digital certificate. [Figure 6] 1 illustrates, in flow chart form, a further exemplary method for validating a digital certificate using linked attestation transactions. [Figure 7] 1 illustrates, in block diagram form, a simplified example of a node that may implement at least a portion of one of the described methods.

[0005] In the drawings, like reference numbers are used to denote like elements and features. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] In one aspect, a computer-implemented method for managing a public key infrastructure using a blockchain network may be provided. The method may include generating a digital certificate for a first entity having a first public key by creating an attestation transaction, where the attestation transaction includes a digital signature from a certificate 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, and propagating the attestation transaction on the blockchain network. The digital certificate includes the first public key and the attestation transaction identifier.

[0007] 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.

[0008] In some implementations, the method may further include verifying the digital certificate. Verifying the digital certificate may include obtaining a copy of the attestation transaction from the blockchain based on the attestation transaction identifier in the digital certificate, determining that the first output is an unspent transaction output, and determining that a first public key included in the second output in the attestation transaction matches the 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 an unspent transaction output pool of the blockchain network. In some such implementations, the input to the attestation transaction may further include a certificate authority public key, and verifying the digital certificate may further include determining that the attestation transaction is signed by a certificate authority based on the certificate authority public key.

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

[0010] In some implementations, the method may further include replacing the digital certificate with a new digital certificate for the new public key. The replacing may include creating a new attestation transaction, where the new attestation transaction includes as input a 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 an information field, where the information field includes the new public key, determining a new attestation transaction identifier from hashing the new attestation transaction, and propagating the new attestation transaction on the blockchain network. The new digital certificate may include the new public key and the new attestation transaction identifier.

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

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

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

[0014] In a further aspect, the present application describes a computer-implemented method of verifying a digital certificate using a blockchain network. The digital certificate includes a first public key and an attestation transaction identifier. The method may include receiving a digital certificate from a first entity and obtaining a copy of an attestation transaction from the blockchain based on the attestation transaction identifier in the digital certificate, the attestation transaction including a digital signature from a certificate authority, a first output to an address based on the second public key, and a second output having an information field. The method may further include determining that the information field includes a public key that matches the first public key in the digital certificate, querying an unspent transaction output pool to determine that the first output in the attestation transaction has not been used in any subsequent transaction, and based on these determinations, verifying that the first public key has been attested as valid.

[0015] In yet another aspect, the present application describes a computer-implemented method of validating a certificate associated with a first node. The method may include receiving a transaction template from the first node, where the transaction template references a proof transaction output and includes a first input signed by a proof transaction key, obtaining a copy of the proof transaction, determining that the proof transaction includes a certificate associated with the first node and that the proof transaction is signed by a certificate authority key, and propagating the transaction template on a blockchain network, where the propagated transaction template includes a second input that transfers a resource to an output address. The transaction template is validated by a node on the blockchain network if the proof transaction output is included within a set of unspent transaction outputs.

[0016] In some implementations, the transaction template includes an input from a first public key associated with the first node and the certificate includes the first public key. In some cases, propagating includes adding an output to a second public key associated with the second node to the transaction template prior to propagating.

[0017] In some implementations, the transaction template includes an output to a first public key associated with the first node and the certificate includes the first public key. In some cases, propagating includes adding an input from a second public key associated with the second node to the transaction template prior to propagating.

[0018] In some implementations, the attestation transaction output includes a pay-to-public-key output in the attestation transaction. In some cases, the attestation transaction output is one of multiple pay-to-public-key outputs in the attestation transaction, each of the pay-to-public-key outputs in the attestation transaction involving a different respective public key.

[0019] In some implementations, obtaining includes identifying a last transaction in the series of linked transactions based on the last transaction including the attestation transaction output, and tracing back through the series of linked transactions to identify the attestation transaction. In some cases, obtaining further includes verifying that the attestation transaction output is a multi-signature output where an authorized signer includes a certificate authority key.

[0020] In some implementations, the set of unspent transaction outputs includes all transaction outputs that have not yet been used as inputs to further transactions, and the set of unspent transaction outputs is maintained by the blockchain network.

[0021] In some implementations, the attestation transaction output is within a transaction having a transaction identifier, a first input in the transaction template references the transaction identifier, and the attestation transaction key is a private key associated with the transaction identifier and the index.

[0022] In some implementations, obtaining includes sending a request for the attestation transaction to a node in the blockchain network and receiving a response including the attestation transaction.

[0023] In some implementations, the obtaining includes receiving a copy of the attestation transaction and a Merkle path associated with the attestation transaction from the first node, and the method further includes verifying that the attestation transaction exists on the blockchain based on the copy of the attestation transaction, the Merkle path, and the set of block headers of the blockchain.

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

[0025] In yet another aspect, a computer-readable medium may be provided that stores processor-executable instructions for operating a node in a network, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processor to perform at least one of the methods described herein.

[0026] Other exemplary embodiments of the present disclosure will become apparent to those of ordinary skill in the art from the following detailed description considered in conjunction with the drawings.

[0027] In this application, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, but not necessarily excluding additional elements.

[0028] As used in this application, the phrase "at least one of ... or ..." is intended to cover any one or more of the listed elements, including only any one of the listed elements, any subcombination, or all of the elements, but not necessarily excluding any additional elements, and not necessarily requiring all of the elements.

[0029] This application refers to hashing or a hash function, which is intended to include any one of several cryptographic hash functions that, when applied to any set of data 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, etc. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2.

[0030] As used herein, the term "blockchain" is understood to include 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. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. For convenience and illustration, reference may be made herein to Bitcoin as exemplified by the Bitcoin SV protocol, but 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.

[0031] A blockchain is a peer-to-peer electronic ledger implemented using a computer-based decentralized distributed system. A blockchain is composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes, among other possible information, the transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output. Each block header includes a summary of the block's contents, for example in the form of a Merkle root, and each block header includes a hash of the previous block header, so that blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions include small programs, known as scripts, embedded in their inputs and outputs that specify how and by whom the transaction's outputs can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0032] A blockchain is implemented on a network of nodes. Each node is a computing device with network connectivity and running software implementing the applicable blockchain protocol. The nodes validate transactions and propagate them to other nodes in the network. Specialized network nodes, called "mining nodes" or "miners," collect a set of unconfirmed, or pending, transactions into a block and attempt to "mine" that block. Mining, in these examples, refers to solving a Proof of Work (POW) before any other miner in the network succeeds in solving the Proof of Work for the respective block. In the Bitcoin example, the POW involves hashing the block header, including the nonce, until the result falls below a threshold set by a difficulty parameter. The nonce is repeatedly incremented and the hashing is repeated until the result falls below the threshold or the miner receives notification that another miner has succeeded. Variations of the mining process are familiar to those skilled in the art.

[0033] Among the various 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 prior 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. The list or pool of UTXOs may be referred to as an “unspent transaction output set.” Blockchain networks are configured to update and maintain the unspent transaction output set to prevent double-spend attacks. 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, so 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 the ordered set of outputs from the transaction. If a transaction output is present in the UTXO pool or set, the transaction output is “unspent” and available to serve as an input.

[0034] The unlocking script for a transaction outpoint defines how "control" over its output must be proven in order for it to be executed. Often, the address associated with a transaction output is a hash of a public key. To prove control over its output, the unlocking script often requires a public key and a digital signature generated using the corresponding private key. In this way, the node that controls the private key can control how and when the transaction output is used in any subsequent inputs. As explained further below, this has the consequence that if a transaction input corresponding to a particular public key contains a digital signature generated using the corresponding private key, then the entity associated with that particular public key has effectively signed or attested the transaction contents.

[0035] Public key cryptography has become ubiquitous in online communications. In many cases, processes and policies are required to provide certainty that a public key is owned by one associated 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 to "certify" public keys as valid. These entities are "Certification 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.

[0036] One problem with existing PKIs is that public keys can be compromised if, for example, the private key is lost or disclosed prior to the certificate's specified expiration date. For that reason, CAs may maintain certificate revocation lists. Entities that wish to rely on a certificate associated with a public key must also locate and consult the associated certificate revocation list to ensure that the certificate has not been revoked by the CA. This compromises the ability to authenticate keys offline and introduces risks due to the delay between revocation and the issuance of a new certificate revocation list, which is often 24 hours or more.

[0037] According to one aspect of the present application, a blockchain network may be used to improve public key infrastructure by providing fast and secure validation, revocation, and renewal of digital certificates. A public key may be recorded on a blockchain by a certificate authority so that any third party can quickly and easily verify that the public key has been certified by the certificate authority and that the certification has not been revoked. By recording the public key in the manner described below, the certificate authority may be able to revoke a certification almost instantly, 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 a group of other entities.

[0038] Referring now to FIG. 1, an exemplary system 100 for managing a public key infrastructure is illustrated in schematic form. The system 100 in this example 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 illustrated as being 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.

[0039] 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 100, the second computing device 104, and / or the server 106 may be nodes in the blockchain network 108, but in this example, for ease of explanation, they are shown as separate nodes from the blockchain network 108.

[0040] In this example system 100, a first computing device 102, labeled "Alice," has a public-private key pair for use in asymmetric cryptographic communications. 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, in operation 110, Alice submits her public key, PK, along with a request to register. Ato the CA. The CA may engage in some level of authentication to ensure Alice's identity as the owner of the public key. In some cases, this authentication may be an automated online operation performed by server 106 based on the data provided in operation 110. In some cases, this authentication may also, or alternatively, include an offline authentication operation. Two-factor authentication and other such techniques may be employed.

[0041] The CA issues the public key PK A If it is decided that should be certified, the public key PK A The CA then generates a blockchain transaction, an "attestation transaction" (CTX), which includes the attestation transaction identifier TxID, and is signed by the CA. The attestation transaction further includes an output controlled by the CA. As shown by operation 112, the transaction is submitted to the blockchain network 108. Then, in operation 114, the CA generates an 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 can be confirmed that the formula includes

[0042] 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 communication device 104, labeled "Bob" in this example, Alice may send that digital certificate to Bob in operation 116. Bob may then send the public key PK A The certificate can be authenticated and verified to have not been revoked based on the blockchain maintained by the blockchain network 108.

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

[0044] 2, there is shown in flow chart form one exemplary method 200 for registering a public key with a certificate authority. The exemplary method 200 may be implemented by an authorized certificate authority and by one or more servers suitably programmed to perform the functions described.

[0045] In operation 202, the certificate authority receives the public key PK A The method 200 then receives from Alice a request for certification of Alice's public key. The certification authority may perform authentication or authorization protocols in accordance with its applicable policies. These protocols may include automated computer-implemented and / or administrator-facilitated operations. Regardless of the particular authentication operation, in operation 204 a determination is made as to whether to certify Alice's public key. If not, method 200 ends. If certification is permitted, in operation 206 the certification authority creates 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 give a specific example, the input may be a UTXO of some nominal or arbitrary value for which the certificate authority has a private key to generate a signature on a valid unlock script. The UTXO may be associated with a digital value sufficient to offset any transaction fees that would be paid to mine the attestation transaction.

[0046] The attestation transaction uses the CA public key, PK, which is selected and controlled by the certification authority. CTX_PKA and a public key PK A An example of the latter is the OP_RETURN function in Bitcoin. OP_RETURN is effectively an output where arbitrary data can be placed for recording on the blockchain once the transaction has been mined.

[0047] The first output may be, for example, a pay to public key hash (P2PKH) operation that specifies a transfer to a public key hash (e.g., a Bitcoin address) selected and controlled by the certificate authority.

[0048] By its digital signature on the transaction, the CA not only authorizes the input of a UTXO into the transaction, thereby satisfying the unlocking script, but also the public key PK that appears in the OP_RETURN output. A OP_RETURN provides verifiable evidence that the certificate authority has certified the OP_RETURN request. Note that in some implementations, additional information may appear in the OP_RETURN output field, such as a digital signature from Alice or other such data.

[0049] When the attestation transaction is created, the certificate authority generates a transaction identifier TxID in operation 208. CTX_PKA, and propagates the transaction on the blockchain network, as indicated by operation 210. It will be understood that "propagating" a transaction includes submitting it to a node in the blockchain network, where it is validated and then sent to all other nodes, which then validate and resend it, until the transaction has reached substantially all nodes in the network. In some embodiments, the certificate authority is itself one of the nodes in the blockchain network.

[0050] In operation 212, the certificate 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 a transaction identifier to Alice before the transaction is mined.

[0051] Alice then sends her public key, PK, to any third party. A and the attestation transaction identifier TxID CTX_PKA From this, a third party can verify that Alice's public key is certified by the CA.

[0052] A simplified example of a proof transaction is shown below: [Table 1]

[0053] Note that the input to the unlock script includes the public key of the certificate authority and the signature generated by the certificate 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.

[0054]

[0023] Referring now to Figure 3, one exemplary method 300 for verifying a public key is shown. The operations described in the exemplary method 300 may be performed by a computing device attempting to verify a public key that it claims to be certified using the process illustrated in Figure 2. Exemplary computing devices include any network-enabled computing device.

[0055] The method 300 includes, at operation 302, receiving a digital certificate for another entity, such as the first computing device 102 (FIG. 1) labeled “Alice.” The digital certificate includes at least a public key, PK A and the attestation transaction identifier TxID CTX_PKA Using the attestation transaction identifier, the attestation transaction is obtained from the blockchain network in operation 304. It will be appreciated that the attestation transaction may be obtained from a copy of the blockchain, whether that copy is local to the computing device or whether it is maintained by a node in the blockchain network. Should the transaction not yet be confirmed, i.e., not yet in a mined block, the transaction may be in a mempool of unconfirmed transactions, but in many implementations, the certificate authority may provide the attestation transaction identifier to Alice only after the attestation transaction has been mined.

[0056] From the attestation transaction, the computing device may verify certain things. In particular, in operation 306, the computing device may verify that the attestation transaction is signed by a certificate authority. The computing device may have, or may have access to, a list of recognized or certified certificate authorities and their respective public keys, which may enable the computing device to validate 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 recognized certificate authority, the computing device can verify that the attestation is valid. Note that the computing device does not necessarily need to verify the digital signature in the input, since if the transaction is on the blockchain, it will be verified and verified by miners. Rather, the computing device may simply verify that the public key identified in the input is associated with a certificate authority.

[0057] The computing device may further verify that one of the output points of the attestation transaction remains “unused”, i.e., the output point is found in the UTXO pool, as indicated by operation 308. This verifying operation confirms that the attestation remains valid and has not expired. As mentioned above, in most embodiments (alternatives are described below), this output point is controlled by the certificate authority, which allows the certificate authority to revoke the attestation if the key is compromised, expires, or is no longer valid for other reasons. Revocation or revocation is easily facilitated by having the certificate authority “spend” the output point and remove it from the UTXO pool. Verification that the output point is in the UTXO pool may be performed, for example, by querying the UTXO pool 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.

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

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

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

[0061] In some cases, a certificate authority may be required to replace / update a certified public key rather than simply revoking the certificate. For example, if a private key is lost or compromised, the owner (e.g., Alice) may request that the certificate authority replace the previously certified public key with a new public key, PK A_new The CA may request that the certificate be updated or replaced with a new attestation transaction CTX. The CA authenticates the request using the online or offline attestation mechanism in place, and if it determines that the update action should be taken, it sends a new attestation transaction CTX. new to revoke the old certificate and issue a new one.

[0062] The new proof transaction will generate the same type of output, i.e., PK CTX_new A new public key selected by the CA, such as PK A_new However, the input is the original proof transaction TxID. CTX_PKAThe UXTO pool may include a CA-controlled output point from the UXTO pool. Revocation is accomplished by removing that output point from the UXTO pool by "using" that output as input to a new certification 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 by the certification authority.

[0063] As mentioned above, in many cases the first output point of an attestation transaction may be controlled by the certificate authority such that only the certificate authority can revoke the public key certification. Revocation is based on "using" the first output point using the private key that corresponds to that output point. However, in some cases it may be advantageous to structure the attestation transaction to allow other entities to revoke the certification.

[0064] For example, in some situations, the owner of the public key, e.g., Alice, may have the authority to revoke their own public key. In this configuration, the first output point in the certification 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 for some public key certification scenarios, such as registration for an online service. One example of an online service is a social media account on a social media platform. The platform can use the mechanism described above to register a user's public key for use on the platform, which allows the user to interact with the platform and / or other users of the platform in a trusted manner with their own digital certificate backed up via the certification transaction. The user can then revoke the certificate to terminate the account without the cooperation of the platform.

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

[0066] Alternatively, if revocation from any one of multiple parties is to be facilitated, the first output may be configured to use multiple signatures, i.e., any one of several signatures may be used to "use" the output. For this purpose, a Multi-sig may be used on the output.

[0067] In yet another scenario, a multi-sig may be configured to ensure that at least a threshold number of entities agree to revoke the attestation. A multi-sig may be configured to require n of m signatures to unlock the output, where n≦m. As an example, in the case of an organization such as a corporation, partnership, or other such collection of individuals, a certified public key associated with the organization may be revocable only if all or at least a threshold number of certain entities, such as the CEO, COO, CTO, or other officers or individuals involved in the corporation, approve the revocation.

[0068] It will be understood that some or all of the above-described operations of the various above-described exemplary methods may be performed in orders other than those illustrated and / or may be performed simultaneously without changing the overall operation of the methods.

[0069] Automated Certificate Verification The above method provides a mechanism for issuing digital certificates secured by a blockchain network. The mechanism allows for fast verification of the validity of the digital certificate and the ability to revoke the digital certificate almost instantly. As described above, to verify the validity of a digital certificate, a node seeking validation of the certificate checks to see if the outpoint of the certificate transaction is within the UTXO set and to verify that the public key in the digital certificate being validated matches the public key in the OP_RETURN field of the certificate transaction.

[0070] One potential drawback of the described method is that there may be a time delay between the validation of a digital certificate and any subsequent transaction that relies on that validation. During that interval, the digital certificate may be revoked for any reason. Furthermore, validation of a digital certificate relies on accessing and checking the UXTO set, which may be difficult or impossible for some nodes, such as lightweight SPV (simplified payment verification) nodes (e.g., digital wallets). This raises security and reliability concerns, as those nodes may need to rely on third-party nodes to perform their validation. Furthermore, the node that validates that an outpoint is in the UXTO set must be online with active access to the blockchain network, which many nodes, such as lightweight SPVs, may not have at any given time.

[0071] According to another aspect of the present application, digital certificate validation may be incorporated into transactions such that the transaction only moves forward if the digital certificate is valid. This allows lightweight SPVs and similar nodes to collaborate with other nodes in generating transactions that incorporate automatic digital certificate validation. Advantageously, this may eliminate the time gap between digital certificate validation and reliance on that validation when committing to a transaction.

[0072] In some of the following examples, a node may have its public key certified by a certificate authority node in the form of an attestation transaction, which may take the form of this example: [Table 2]

[0073] In the above example, node A's public key PK A The OP_RETURN output is the public key PK A Note that the OP_RETURN output includes a certificate for the public key. In some instances, this may simply be the public key itself. In some cases, it may be a hash of the public key. In some cases, the certificate included in the OP_RETURN output may include additional data along with the public key.

[0074] Note also that the input is the transaction outpoint controlled by the certificate authority, and the unlock script is signed by the certificate authority. The output is the proof transaction public key.

number

number

number

[0075] Such a certificate is a proof transaction public key

number

[0076] As mentioned above, attestation transactions can be used to automate the validation of digital certificates. In particular, the automation consists in checking the UXTO set. For example, a new transaction, such as a payment transaction, includes as a precondition that the outpoint of the attestation transaction is present in the UXTO set. This ensures that the new transaction is only valid if the certificate is still valid and has not been revoked.

[0077] In general, a node (e.g., Alice) with a digital certificate attesting to its public key generates a transaction template that includes the outpoint of the certificate as input. The input is signed with the attest transaction key, e.g., using the private key corresponding to the P2PKH output of the attest transaction. This transaction template is provided to another node (e.g., Bob) participating in the transaction. The other node, Bob, retrieves the attest transaction based on a reference to the TXID for the attest transaction in the input to the transaction template and provides the intended public key, PK Ais indeed attested by the attest transaction and adds any inputs / outputs that complete the transaction template. The transaction template can then be propagated on the blockchain network. If the input signed by the attest transaction key fails because the output is already used in another transaction, i.e. the output is not in the UTXO set, the entire transaction fails and is not propagated or mined. If the input signed by the attest transaction key is valid because it is in the UTXO set, the transaction is validated, propagated, goes into the mempool and eventually into a block to be mined.

[0078] In one example, this mechanism may be used to verify a recipient's address. For example, in a situation where Alice requests a digital asset or some other transfer from Bob, Bob may want to validate that Alice's identity, e.g., her intended public key, is attested before committing to such a transaction. In such a situation, Alice may prepare a transaction template that includes a payment for Alice's public key along with an input that references an attestation transaction for that public key. Upon receiving the transaction template, Bob may retrieve the attestation transaction from the blockchain, verify that it attests to Alice's public key, and confirm that it is digitally signed by a certificate authority. Bob may then add an input to the transaction template that transfers the digital asset, and the transaction template may then be propagated on the blockchain. If Alice's digital certificate is still valid, i.e., it has not expired, the transaction proceeds. An example of such a transaction is shown below: [Table 3]

[0079] In the example transaction above, Bob:

number

[0080] In another example, this mechanism may be used to verify a sender's address, for example to satisfy Know Your Customer (KYC) requirements. For example, Alice is transferring assets to Bob, and Bob wants to verify Alice's identity before accepting the transfer. In this case, Alice transfers digital assets and sends her public key, PK A , which also includes a attestation transaction that attests to its public key as an input. Upon receiving the transaction template, Bob may take the attestation transaction, verify that it is signed by a certificate authority, and verify that it attests to Alice's public key. If so, Bob completes the transaction template by adding an output to transfer the digital asset to a public key address controlled by Bob. Such an example transaction may take the following form: [Table 4]

[0081] In each of the two above detailed examples, it will be understood that as soon as a digital certificate is used in a transaction to prove the validity of a public key, it becomes invalid. That is, the certificate may only be used once and will automatically expire after one use. This may be applied in some cases, such as for one-off transfers of large asset values ​​to or from a verified address. Such transactions may be used in the case of car transfers, real estate transactions, stock sales, or other such high value transfers. However, for lower value everyday transactions, it may be cumbersome to go back to the certificate authority for a new certificate each time the certificate is used. Therefore, as described below, multi-use certificates may be constructed.

[0082] Referring first to Figure 4, one exemplary method 400 of validating a certificate associated with a first node is illustrated in flow chart form. The method may be implemented by a computing device such as a mobile phone, tablet, personal computer, etc. The computing device includes one or more processor units and associated memory that stores computer-executable instructions that, when executed by the processing unit, cause the processing unit to perform the described operations. In some cases, the computer-executable instructions may be stored in the form of an application, such as, for example, a wallet application.

[0083] Method 400 provides an example of automated certificate validation to verify the identity of a recipient. In this example transaction, node A is the recipient and node B is the sender. The nodes may communicate over wired and / or wireless networks. In some cases, the nodes may communicate using short-range communications, e.g., via point-of-sale terminals. Method 400 begins in operation 402 with node A creating a transaction template. The transaction template includes a public key, e.g., node A's public key PK, that attests to node A's identity. AThe attestation transaction includes an input that references an attestation transaction output from a attestation transaction that attests to the attestation transaction. The output in the attestation transaction is the attestation transaction public key

number

number

[0084] As indicated by operation 404, node A sends this transaction template to node B. The transaction template does not yet include input from node B and / or has not been signed by node B if input is included.

[0085] Upon receiving the transaction template, in operation 406, node B identifies the attestation transaction based on the reference to the attestation transaction in the input to the transaction template. Because the reference includes the transaction identifier of the attestation transaction, node B can retrieve a copy of the attestation transaction. If node B stores a local copy of the blockchain, node B may obtain the attestation transaction by looking it up in the local copy. If not, node B may send a query or request to a blockchain node for a copy of the attestation transaction based on the transaction identifier. In some cases, this verification may be done as a proof of the existence of the attestation transaction. That is, when node B is provided with a copy of the attestation transaction and a Merkle proof (Merkle path), node B may verify that the attestation transaction exists in the blockchain from the block header. An SPV node or other lightweight implementation may have a copy of the block header available to it even if it is offline, which allows node B to verify the existence and contents of the attestation transaction without necessarily needing live access to the blockchain network. Thus, node A may provide node B with a copy of the attestation transaction and its Merkle path along with the transaction template.

[0086] Once Node B has a copy of the attestation transaction, it verifies in operation 408 that the attestation transaction was signed by the certificate authority using the certificate authority key. It also verifies that Node A’s public key PK A appears in the OP_RETURN output field of the attest transaction, thereby verifying that the certification authority has attested to the authenticity of Node A's public key. Node B may further validate the structure of the attest transaction, in particular verifying that the attest transaction public key,

number

[0087] It will be appreciated that if these checks fail, for example if node A's public key cannot be verified as attested, or if the attestation transaction is not structured as expected, then method 400 terminates as node B does not complete the transaction. However, assuming node B verifies that the attestation transaction is valid, then in operation 410 node B modifies the transaction template to add an input from an address controlled by node B. That is, node B adds a resource input to the transaction template and signs the input. This completes the transaction template, which node B may then propagate on the blockchain network. Alternatively, node B may send the completed transaction template to node A, which may propagate it on the blockchain network.

[0088] In either case, as indicated by operation 412, one of two things occurs.

number

number

[0089]

[0023] Referring now to Figure 5, another exemplary method 500 for automatically validating a digital certificate is illustrated in flow chart form. Similar to Figure 4, the method 500 illustrated in Figure 5 may be performed by a computing device implementing a first node, node A, and a second node, node B. In the example method 500, a transaction is generated to transfer a resource from node A to node B. Node B attempts to validate the identity of node A, e.g., as part of a "know-your-customer" or anti-fraud record-keeping requirement, before accepting the transfer of the resource.

[0090] Node A creates a transaction template in operation 502 and includes an input that references an attestation transaction output from a attestation transaction that attests to Node A's public key. The input is signed by Node A using an attestation transaction key that corresponds to the attestation transaction public key referenced in the attestation transaction output. Node A also uses its attested public key PK A In operation 504, node A sends the transaction template to node B.

[0091] At operation 506, Node B retrieves a copy of the attestation transaction from the blockchain, whether stored locally or remotely. The attestation transaction is identified by the transaction identifier referenced in the input to the transaction template.

[0092] In operation 508, node B verifies that the attestation transaction was signed by the certificate authority using the certificate authority key. It also verifies that node A's public key PK A appears in the OP_RETURN output field of the attest transaction, thereby verifying that the certification authority has attested to the authenticity of Node A's public key. Node B may further validate the structure of the attest transaction, in particular verifying that the attest transaction public key,

number

[0093] It will be appreciated that if these checks fail, for example if node A's public key cannot be verified as attested or if the attestation transaction is not structured as expected, method 500 terminates as node B does not complete the transaction. However, assuming node B verifies that the attestation transaction is valid, in operation 510 node B may modify the transaction template to add an output to an address controlled by node B. In some cases, node A may have already added an output to transfer resources to node B, in which case node B need only verify that the output is correct in operation 510. This completes the transaction template, which node B may then propagate on the blockchain network. Alternatively, node B may send the completed transaction template to node A, which may propagate it on the blockchain network.

[0094] After the transaction is sent to a node in the blockchain network, one of two things happen, as indicated by operation 512.

number

number

[0095] Multiple Use Certificate As noted above, in the above examples, it was assumed that a digital certificate becomes invalid once it has been used in a transaction to prove the validity of a public key, as the attestation transaction output becomes "used." That is, a certificate can only be used once, and once used, it is automatically revoked. In some situations, it may be desirable to have a certificate that can be used multiple times, without requiring a node to obtain an unused certificate from a certificate authority after each use.

[0096] In one example, a multi-use certificate may be created by providing multiple attestation transaction outputs to a certificate transaction. The attestation transaction may be structured to provide m possible uses. Each output may be used only once in a validation operation. Once an output has been "used", it is no longer available. An example of such a certificate transaction is shown below: [Table 5]

[0097] Public Key

number

[0098] Node A may revoke its own certificate by submitting a transaction that uses all of the certificate's remaining unused transaction outputs. A certificate authority may do the same to revoke a certificate, but if the certificate authority does not have reliable knowledge of which of the outputs in the attestation transaction have already been used, the certificate authority submits a separate transaction for each output to ensure revocation of the certificate.

[0099] The exemplary multi-use certificate above is advantageous in that it can be used by node A up to m times, but after all outputs are exhausted, node A must obtain a new certificate from the certificate authority. In another example, the certificate validation process may be constructed such that each validation further generates a new outgoing point linked to the certificate transaction, thereby building a chain of transactions back to the original attestation transaction.

[0100] In one example implementation, where a certificate authority does not require the ability to revoke certificates, the form of certificates described above may be used: Each time node A uses a certificate in a transaction, node A ensures that the transaction generates a new pay-to-public-key output, which it then uses as the attestation transaction output in any subsequent transactions that use that certificate.

[0101] In another exemplary implementation, to ensure that the CA can revoke the certificate, the attestation transaction and each subsequent transaction in the chain use a multi-sig output. The multi-sig output allows a 1-of-2 signature to unlock the output, which includes the public keys for both the CA and node A. One illustrative example is shown below: [Table 6]

[0102] Proof Transaction Public Key

number

[0103] To use the certificate, node A must create a new certificate transaction key with the certificate authority.

number

[0104] As an example, consider node A entering into a transaction with node B, where node B transfers a resource to node A, and node A uses its digital certificate to prove the validity of its public key. Such a transaction may take the following form: [Table 7]

[0105] In the example transaction above, one of the inputs is the public key PK controlled by Node B. B Note that the input is from . This input is added to the transaction template by node B after it verifies that the structure of the transaction template is valid and the certificate for node A is verified.

[0106] The transaction begins with the exchange of resource y BSV with public key PK as indicated by the first outgoing point. A Another input is the proof transaction output.

number

number

[0107] Node B may provide an updated attestation key to Node A and optionally further evaluate whether Node A has properly structured the attestation transaction output in the current transaction template so that the certificate authority can revoke the attestation if necessary, although Node B does not necessarily need to confirm this in order to proceed with the transaction.

[0108] After the above transaction is submitted to the blockchain network, node A then creates a new linked public key

number

number

number

number

number

number

number

[0109] Subsequent transactions involving node A's proof are executed in the same way, with other nodes tracing back through the chain of linked transactions to ensure that their proof transaction outputs are correctly structured, until they arrive at the original proof transaction.

[0110] 6, a portion of a method 600 for validating a digital certificate using linked transactions is illustrated in flow chart form. Method 600 provides an example of automated certificate validation to verify the identity of a recipient. In this example transaction, node A is the recipient and node B is the sender. Method 600 begins with node A creating a transaction template in operation 602. In this example, the transaction template verifies the identity of node A, e.g., node A's public key PK A The input includes a proof transaction output from the last transaction in a chain of linked proof transactions going back to the original proof transaction that proves

number

number

[0111] Node A sends this transaction template to node B in operation 604. The transaction template does not yet include input from node B and / or has not been signed by node B if it does include input.

[0112] In operation 606, upon receiving the transaction template, node B obtains a copy of the transaction referenced in the input to the transaction template. The transaction may be an original attestation transaction if node A has not used the certificate before, or it may be a linked attestation transaction. In operation 608, node B evaluates whether it is an original attestation transaction. An original attestation transaction is a transaction that has been verified using the PK A , and the linked attestation transaction includes two or more signed inputs that reference a prior transaction outpoint, one of which may be a previous attestation transaction and the other of which may be an input resource to the linked attestation transaction. If Node B determines that the retrieved transaction is a linked attestation transaction and not the original attestation transaction, then in operation 610 it determines whether the referenced outpoint is validly structured. For example, if the outpoint does not contain a referenced attestation public key, e.g.

number

number

[0113] Once the original attestation transaction has been identified, in operation 612, node B verifies that the attestation transaction was signed by the certificate authority using the certificate authority key. Also, node A's public key PK A appears in the OP_RETURN output field of the attest transaction, thereby verifying that the CA has attested to the authenticity of node A's public key. This is because the attest transaction output contains the attest transaction public key

number

[0114] Once node B is satisfied that the original attestation transaction is valid, in operation 614 it authenticates node A's public key PK A It then, in operation 614, submits the completed transaction template to the blockchain network, and, as shown by operation 616, the attestation transaction public key in the last attestation transaction in the chain of attestation transactions.

number

[0115] In one implementation, the value transferred to each attestation transaction output in the series of attestation transaction outputs may be a fixed value x that the validator node checks when evaluating the format and content of each transaction in the series. In another implementation, to put an upper limit on the number of times a proof can be reused, the value may start out as a fixed amount in the original attestation transaction and may be decremented by a fixed amount with each use, such that at some point no further updates occur. In some implementations, the decremented amount may match the amount of the transaction fee.

[0116] It will be appreciated that the certificate authority may revoke this certificate by identifying the most recent transaction in a chain of certification transactions and using a 1-of-2 multi-sig output using the certificate authority's key.

[0117] 7, a simplified computing device 700 according to an example of the present application is shown in block diagram form. The computing device 700 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.

[0118] Computing device 700 includes a processor 702, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. Computing device 700 may further include memory 704, which may include persistent and non-persistent memory for storing values, variables, and in some cases processor-executable program instructions, and a network interface 706.

[0119] Computing device 700 may include processor-executable applications 708 that include processor-executable instructions that, when executed, cause processor 702 to perform one or more of the functions or operations described herein.

[0120] The various embodiments presented above are merely examples and are not meant to limit the scope of the present application in any way. Variations of the innovations described herein will be apparent to those skilled in the art, and such variations are within the intended scope of the present application. In particular, features from one or more of the above exemplary embodiments may be selected to create alternative exemplary embodiments including subcombinations of features that may not be explicitly described above. In addition, features from one or more of the above exemplary embodiments may be selected and combined to create alternative exemplary embodiments including combinations of features that may not be explicitly described above. Features suitable for such combinations and subcombinations will be readily apparent to those skilled in the art upon review of the present application as a whole. The subject matter described in this specification and claims is intended to cover and encompass all appropriate modifications in technology.

Claims

1. 1. A computer-implemented method for validating a certificate associated with a first node, comprising: receiving a transaction template from the first node, where the transaction template references an attestation transaction output and includes a first input signed by an attestation transaction key; obtaining an attestation transaction and determining that the attestation transaction includes the certificate associated with the first node and that the attestation transaction is signed by a certificate authority key, where obtaining includes identifying a last transaction in a series of linked transactions based on the last transaction including the attestation transaction output, and tracing back through the series of linked transactions to identify the attestation transaction; Propagating the transaction template on a blockchain network. where the transaction template being propagated includes a second input that transfers a resource to an output address; whereby the transaction template is validated by a node on the blockchain network if the proof transaction output is included in a set of unspent transaction outputs. method.

2. 2. The method of claim 1, wherein the transaction template includes an input from a first public key associated with the first node, and the certificate includes the first public key.

3. 3. The method of claim 2, wherein propagating includes adding an output to a second public key associated with a second node to the transaction template prior to propagating.

4. 2. The method of claim 1, wherein the transaction template includes an output to a first public key associated with the first node, and the certificate includes the first public key.

5. 5. The method of claim 4, wherein propagating includes adding an input from a second public key associated with a second node to the transaction template prior to propagating.

6. The method of claim 1 , wherein the attestation transaction output comprises a pay-to-public-key output in the attestation transaction.

7. 7. The method of claim 6, wherein the attestation transaction output is one of a plurality of pay-to-public-key outputs in the attestation transaction, each of the pay-to-public-key outputs in the attestation transaction involving a different respective public key.

8. 8. The method of claim 1, wherein obtaining further comprises verifying that the attestation transaction output is a multi-signature output in which an authorized signer includes the certificate authority key.

9. 9. The method of claim 1, wherein the set of unspent transaction outputs comprises all transaction outputs that have not yet been utilized as inputs to further transactions, the set of unspent transaction outputs being maintained by the blockchain network.

10. 10. The method of claim 1, wherein the attestation transaction output is within a transaction having a transaction identifier, a first input in the transaction template references the transaction identifier, and the attestation transaction key is a private key associated with the transaction identifier and an index.

11. 11. The method of claim 1, wherein obtaining comprises sending a request for the attestation transaction to a node in the blockchain network and receiving a response including the attestation transaction.

12. 11. The method of claim 1, wherein obtaining includes receiving a copy of the attestation transaction and a Merkle path associated with the attestation transaction from the first node, the method further including verifying that the attestation transaction is recorded in the blockchain based on the copy of the attestation transaction, the Merkle path, and a set of blockchain block headers.

13. 1. A computing device for validating a certificate associated with a first node, comprising: one or more processors; Memory, computer-executable instructions stored in the memory that, when executed by the one or more processors, cause the processors to perform the method of any one of claims 1 to 12; A computing device comprising:

14. 13. A computer readable medium storing processor executable instructions for validating a certificate associated with a first node, the processor executable instructions including instructions that, when executed by one or more processors, cause the processors to perform the method of any one of claims 1 to 12.

Images