This specification describes a signature option that provides the ability to cryptographically prove when a digital signature was created by anchoring the signature to a hash in a publically available merkle tree.
This is an experimental specification and is undergoing regular revisions. It is not fit for production deployment.
This specification describes a signature option that provides the ability to cryptographically prove when a digital signature was created by anchoring the signature to a hash in a publically available merkle tree. This signature option is intended to be used with the signature options data structure used in the Linked Data Signatures [[!LD-SIGNATURES]] specification.
The following terms are used to describe concepts involved in the generation and verification of the Proof of Publication signature option.
A merkle tree-based proof of publication is generated by adding a merkle tree root hash value into a ledger then including a proof in the digital signature. There are several values that MUST be included in order to ensure the proof is valid: a proof of publication algorithm identifier, a ledger identifier, a transaction identifier, the merkle root hash and an array of proofs where each entry in the array is a combination of the parent, the left sibling, and the right sibling.
Another alternative is to include the path from our entry back to the merkle root. We're trying to minimize the data that goes into the signature by making it extremely unlikely that the three hashes just happen to be clustered elsewhere in the same tree. We need to calculate the statistical probability of this happening (hint: it's fantastically unlikely, but we need to think through the threat model).
This algorithm is still too vague for implementers. For example: How do you know what information to include in the merkle leaf nodes when generating the hash? Do you just include all of it? Is it okay to select the same message digest algorithm as what's used in the active signature suite?
The term "proof" is not specific enough. It should either be made more specific or replaced with something like `merklePath` should it be determined that a full path is necessary for security.
To generate the proof of publication, perform the following steps:
PoP2016
.
merklePublicationProof
and included in
signature options before the signature is generated.
A merkle tree-based proof of publication is verified by checking to
see if a value exists in a ledger at the appropriate time.
The input is a signature options document containing a
merklePublicationProof
entry. The output is
true if the proof is valid, or false if it is not.
To verify the proof of publication, perform the following steps:
type
value is PoP2016
.
The following section describes security considerations that developers implementing this specification should be aware of in order to create secure software.
{ "@context": "https://w3id.org/identity/v1", "title": "Hello World!", "signature": { "type": "LinkedDataSignature2015", "creator": "http://example.com/i/pat/keys/5", "created": "2011-09-23T20:21:34Z", "domain": "example.org", "nonce": "2bbgh3dgjg2302d-d2b3gi423d42", "merklePublicationProof": { "type": "PoP2016", "ledger": "bitcoin", "transactionId": "7ea0cef6a31c65590d6c1d61abbfa02d3006da6509a018cdbc709d0a781a7c28", "merkleRoot": "80ab866e989432e023b51e866545c141e00d456e59fa1e253fac3a561e1a6c14", "proof": [{ "merkleParent": "f51cd07057a813f92a33a05ed58a0f26600d2205f9c590f3461f94bd8451b567", "merkleLeftSibling": "247911c653b43a2d13010538c7eae52e500a556448f17384d636857b2b63ae45", "merkleRightSibling": "93ca67aea78e996fb9e10368243110c6f037143dbeec726de0b9172766427399" }, { "merkleParent": "e6a881dd07c479eaf2afdd26ae34b441af2fede85c90b5281346846a5dc81bca", "merkleLeftSibling": "44c66b49e4024bf1ba370c38a3655f2094cd110caf91636f749d9e0385fb9272", "merkleRightSibling": "93ca67aea78e996fb9e10368243110c6f037143dbeec726de0b9172766427399" ] }, "signatureValue": "OGQzNGVkMzVm4NTIyZTkZDY...NmExMgoYzI43Q3ODIyOWM32NjI=" } }