Re: Demonstration of Support for NIST-Compliant Selective Disclosure for Data Integrity Cryptosuites in VCWG

@Manu: I was thinking a bit more about the spec and had the following
questions. I’d appreciate if you could take the time to answer these to me.

1) If I understood correctly, the ephemeral public key has to be revealed
in every transaction (derived proof), correct? If this is the case,
wouldn’t it be better (required) to generate a new key pair per statement
instead, to avoid correlation based on that key. The key is specific to a
credential and therefore a potential unique identifier. I know that other
approaches have similar issues, eg the MSO of an mDL can be seen as an
identifier which is why vendors issue those regularly using different
strategies. I assume this could also be done in the case of ecdsa-sd but it
would be a bit more expensive since each statement is signed.

2) If I understood correctly, the algorithm uses a master issuer key to
sign an ephemeral public key where each statement is signed by the
corresponding ephemeral secret key. Where do you see the advantage of this
approach in general compared to issuing individual credentials for each of
these statements? To me it sounds similar.

3) Can you elaborate why, where and how the hmac comes into play? I
understood it’s more or less to have pseudo random node identifiers but I’m
not sure why it is needed to have deterministic random values for that in
the first place instead of for example fully random values that don’t
require an hmac.

I also wanted to clarify that ISO mDL uses one salt per individual
statement and therefore uses more than one salt. Mentioning this because it
was stated ISO mDL uses only one salt per credential.

Thanks,
Oliver

On Sun 13. Aug 2023 at 07:06, Oliver Terbu <oliver.terbu@spruceid.com>
wrote:

> I guess if one can throw away the esk then HSM could be viable.
>
> On Sun 13. Aug 2023 at 06:36, Oliver Terbu <oliver.terbu@spruceid.com>
> wrote:
>
>> Re ephemeral keys on ecdsa-sd. this means an issuer cannot use a boring
>> old HSM to protect the signatures, correct? It wouldn’t be viable imo. To
>> many keys (at least a new keypair for each VC) and also the ephemeral
>> nature doesn’t seem to fit if one uses an HSM.
>>
>> On Sat 29. Jul 2023 at 17:13, Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>>> Hey Christopher and Sam, apologies for the delay in response, last
>>> week was hectic.
>>>
>>> On Fri, Jul 21, 2023 at 10:31 PM Christopher Allen
>>> <ChristopherA@lifewithalacrity.com> wrote:
>>> > Is this fundamentally selective disclosure using hash-based ‘elision’?
>>>
>>> You'd have to define "hash-based elision" for me to give you a
>>> definitive answer, but I'll try anyway. :)
>>>
>>> From what I understand of Gordian Envelope and ACDC, no it's not
>>> hash-based elision. I say that with a huge caveat that my
>>> understanding of both is almost certainly not tracking the latest
>>> developments, and they differ in important ways. I believe ecdsa-sd is
>>> a different approach. The approach is outlined in this slide deck:
>>>
>>>
>>> https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit#slide=id.g2174b6c9183_0_1364
>>>
>>> There are detailed examples of how it works on slides 18-25. Perhaps
>>> you could take a look and let me know if you agree that it's not an
>>> elision-based approach?
>>>
>>> Sam smith wrote:
>>> > The ACDC spec for some time has included  similar mechanisms 1) nested
>>> partial disclosure and/or 2) arrays of blinded hashes for selective
>>> disclosure.
>>>
>>> To be clear, ecdsa-sd does neither due to information leakage
>>> concerns. We use a flat list of statements that only reveals structure
>>> when a selective disclosure is made and not before, and only then with
>>> the information revealed (which is not true for other mechanisms like
>>> SD-JWT). So, with ecdsa-sd, you don't accidentally discover the
>>> structure of information that is not disclosed. From what I remember,
>>> ACDC can do this for some structures (but not for sets/lists). I don't
>>> know where Gordian is on this particular item.
>>>
>>> We don't encode arrays of blinded hashes because that can leak
>>> information (which is further elaborated upon, below).
>>>
>>> > So apparently, there is some convergence to using collections of
>>> blinded hashes as standard cypto enabled selective disclosure mechanisms.
>>>
>>> I wouldn't say that, there are drawbacks to using collections of
>>> blinded hashes, which I touch upon above and elaborate upon below.
>>>
>>> > I wasn’t aware of anything possible other than that which is NIST
>>> compliant as BBS+ & CL sigs both requires pairing cryptography.
>>>
>>> Yes, the ecdsa-sd approach does not require pairing-based
>>> cryptography... it uses boring old NIST-compliant cryptography. The
>>> steps are roughly:
>>>
>>> 1. Convert the input document into canonical statements (RDF
>>> canonicalized quads).
>>> 2. Split the quads into one "mandatory disclosure set" and multiple
>>> "selective disclosure statements".
>>> 3. Generate an ephemeral NIST-compliant keypair.
>>> 4. Sign the "mandatory disclosure set" and the public component of the
>>> ephemeral key using your public DID (or whatever public NIST key you
>>> want to use).
>>> 5. Individually sign each "selective disclosure statement" with the
>>> ephemeral private key, and then throw the private key away.
>>> 6. Bundle all the signatures together; that's your initial proof.
>>> Attach the signature to the document using the generalized Data
>>> Integrity "add proof" algorithm, and hand it over to the holder.
>>>
>>> The holder can then take that document, with the attached initial
>>> ecdsa-sd proof, and generate derived proofs (selectively disclosed
>>> VCs) to give to verifiers.
>>>
>>> > The link to the PR wasn’t that helpful, no details or docs in it.
>>>
>>> The PR contains links to the slide deck, the specification text, and
>>> one complete implementation, which has a lot of documentation related
>>> to the usage of the library. I'll re-produce those links below:
>>>
>>> Presentation on Selective Disclosure for W3C Data Integrity
>>>
>>> https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit#
>>>
>>> ecdsa-sd specification text:
>>>
>>> https://pr-preview.s3.amazonaws.com/w3c/vc-di-ecdsa/pull/20.html#ecdsa-sd-2023
>>>
>>> ecdsa-sd-2023-cryptosuite library usage:
>>>
>>> https://github.com/digitalbazaar/ecdsa-sd-2023-cryptosuite/blob/main/README.md
>>>
>>> > Is this proposal a hash of an LD quad list (aka a “quin”) or some
>>> other technique?
>>>
>>> The "mandatory disclosure set" is a single hash and signature of a set
>>> of quads. Each "selective disclosure statement" is individually hashed
>>> and signed. There is also an HMAC that is used as a randomization
>>> function to prevent leaking information via bnode identifiers. This
>>> information leakage prevention mechanism is a feature that is missing
>>> from other selective disclosure techniques when dealing with arrays of
>>> data (such as the number of employees in a company, or children in a
>>> family, or items in a shipping manifest, or other types of information
>>> leakage that you don't want when doing a selective disclosure).
>>>
>>> > Does it use a single salt ( i.e. like mDL) or can individual items be
>>> salted or unsalted depending on correlation requirements?
>>>
>>> There is no single salt value, as described above. The signatures
>>> themselves are correlatable because we're not using pairing-based
>>> cryptography. That said, it's possible to have multiple  per-signature
>>> hashes and salts. We're looking for feedback on the current
>>> specification to see if we should add that functionality or not. It
>>> would provide some level of correlability protection as long as we can
>>> find the right NIST-approved primitives to do it. The challenge with
>>> this cryptography suite has been using only NIST-approved primitives,
>>> which limits the options we have wrt. anti-correlation primitives.
>>>
>>> -- manu
>>>
>>> --
>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>> Founder/CEO - Digital Bazaar, Inc.
>>> https://www.digitalbazaar.com/
>>>
>>> --
>> *Oliver Terbu*
>> Director Identity Standards, Spruce ID <https://spruceid.com/credible>
>>
> --
> *Oliver Terbu*
> Director Identity Standards, Spruce ID <https://spruceid.com/credible>
>
-- 
*Oliver Terbu*
Director Identity Standards, Spruce ID <https://spruceid.com/credible>