Re: Single Use Key Pairs: Disposable Private Keys?

To illustrate Sam's and Bob's points, it may be interesting to contrast our
asymmetric signature assumptions with the way the KSI blockchain works.
(Disclosure: I knew nothing about KSI until I joined my current company. We
use KSI for some other things and I've had to learn about it as a result.)

The KSI blockchain is permissioned, and consists of a hierarchy of nodes
that accept documents to be signed. When a document is accepted at a leaf
node, its SHA-256 hash is computed. Along with all other documents at that
leaf note, these hashes are aggregated. Higher levels of the blockchain
compute hashes over increasing number of docs, until the root hash of the
blockchain is updated to reflect the newly ingested data. In such a world,
the "signature" on a document is just the path from the document content to
the root of the blockchain's merkle tree. You know who "signed" the
ingested document as a leaf node, and who "endorsed" that signature by
incorporating its hash into progressively higher levels of the merkle tree.
But you know that by the position of the nodes in the hierarchy, not by the
use of a private key belonging to a particular node. Forging the signature
can't be done by stealing private keys -- only by stealing a node's place
in the hashing hierarchy. There is little risk of disruption from quantum
computing. The system is radically efficient/scalable, and it provides
global timestamping with 1-second resolution. I believe this system more or
less matches Bob's description of how we could store checksums in a VDR. It
provides global verification of document authenticity.

Given that such a system has been in production for almost as long as
Bitcoin, and has these desirable qualities, it is instructive to ask why we
haven't glommed onto it more. Opinions will vary, but I think the essence
of the answer is implicit in Sam's proviso, "If the signature is merely
representing that a signer saw the data." As an SSI community, we want
systems, I think, where the signature is more laden with intention (or is
more granular in intention) than that. And we want systems where issuers
don't have to be pre-approved and share a single governance. And we want
the ability to require that an authorized holder, rather than a random
person, be the presenter of the data (Sam's nonce/replay issue). And we
want the ability to selectively disclose or generate ZKPs rather, than
sharing the signed data directly.

To the extent that none of these extra considerations apply, or to the
extent that they can be worked around or minimized, I think the checksum
approach may be worthy of consideration. But if we really want all of them,
I don't think checksums are the optimal approach.



On Mon, Dec 13, 2021 at 12:40 PM Bob Wyman <bob@wyman.us> wrote:

> ...are you assuming a classic checksum could be stored in the same way on
>> a VDR?
>
> In the abstract, a signature doesn't tell you anything other than that the
> checksum was encrypted using the private key paired with the public key.
> Thus, in the absence of the private key, or some way to cause it to be used
> in a verification process, the signature doesn't really add any useful
> information that isn't provided by the unsigned checksum. Given this, it
> would seem reasonable to store checksums in a Verifiable Data Registry
> (VDR) rather than going through the hassle of processing signatures.
> Storing the checksum in the VDR would shift the burden of proof to whatever
> methods the VDR used to assert the correctness of its content.
>
> But, if you had a public key that was accompanied by claims, such as those
> in a certificate issued by a key pair provider, which stated that it had
> issued a key pair containing the public key, then you could verify the
> virtual presence of the private key by interacting with the provider of the
> certificate. In this case, it would be irrelevant if the private key was
> still accessible. Of course, the most you could know was that the relevant
> key pair had been issued by the provider, but, you wouldn't be able to
> know, or discover, who had used the private key.
>
> bob wyman
>
>
> On Mon, Dec 13, 2021 at 12:15 PM Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
>> A checksum doesn't amount to a signature/proof.
>>
>> With a checksum approach, anybody is free to change the VC's claims,
>> metadata (aka packing list), and/or the inner/outer id's and simply
>> recompute the checksum.
>>
>> If you want to call what I'm proposing single-use key-pair based
>> "checksums" that might be an interesting but confusing term.
>>
>> What I'm proposing are not checksums in the classic sense. There is a
>> stated assumption that the public key of the SUKP is stored on a VDR for
>> verification purposes.
>>
>> ...are you assuming a classic checksum could be stored in the same way on
>> a VDR?
>>
>> Get Outlook for Android <https://aka.ms/AAb9ysg>
>> ------------------------------
>> *From:* Mike Prorock <mprorock@mesur.io>
>> *Sent:* Monday, December 13, 2021 10:03:05 AM
>> *To:* Bob Wyman <bob@wyman.us>
>> *Cc:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>;
>> sam@prosapien.com <sam@prosapien.com>; public-credentials (
>> public-credentials@w3.org) <public-credentials@w3.org>
>> *Subject:* Re: Single Use Key Pairs: Disposable Private Keys?
>>
>> +1 Bob
>>
>> Mike Prorock
>> mesur.io
>>
>> On Mon, Dec 13, 2021, 11:45 Bob Wyman <bob@wyman.us> wrote:
>>
>> I think I'm missing something in the scenario you describe. If the
>> private key has been discarded, how can a signature generated with that
>> private key serve as anything more than a checksum? If a checksum is all
>> you need, why not just provide a checksum? Why bother with the signature?
>>
>> bob wyman
>>
>>
>> On Sat, Dec 11, 2021 at 11:50 PM Michael Herman (Trusted Digital Web) <
>> mwherman@parallelspace.net> wrote:
>>
>> If an NFT (for a photo, a calf, or a kiss, etc.) or a unique
>> one-of-a-kind business document (a specific purchase order, invoice,
>> waybill, delivery confirmation, etc.) is represented as a (signed)
>> verifiable credential, once the proof is generated for the VC, is it
>> necessary to persist the private key used to sign the VC?
>> ...can't the private key be thrown away if it is no longer needed to sign
>> anything further?
>> ...that is, only the public key needs to be persisted and keyed to the
>> VC's outer id and stored in the corresponding DID document?
>> ... inspired by the early part of Sam's KERI ssimeetup talk.
>>
>> Michael Herman
>> Founder
>> Trusted Digital Web
>> Get Outlook for Android <https://aka.ms/AAb9ysg>
>>
>>