Consider using distinct base proof and disclosure proof head bytes for optional features

[Wind4Greg]

Currently we use the following "header bytes" (really CBOR tags) for ECDSA-SD and BBS:

• ECDSA-SD base proof header bytes 0xd9, 0x5d, and 0x00.
• ECDSA-SD disclosure proof header bytes 0xd9, 0x5d, and 0x01.
• BBS base proof header bytes 0xd9, 0x5d, and 0x02.
• BBS disclosure proof header bytes 0xd9, 0x5d, and 0x03.

To enable easier error and consistency checking I would propose using the following (or something similar) for each of the optional features:

• BBS Anonymous Holder Binding base proof header bytes 0xd9, 0x5d, and 0x04.
• BBS Anonymous Holder Binding disclosure proof header bytes 0xd9, 0x5d, and 0x05.
• BBS Pseudonyms with Issuer-known PID base proof header bytes 0xd9, 0x5d, and 0x06.
• BBS Pseudonyms with Issuer-known PID disclosure proof header bytes 0xd9, 0x5d, and 0x07.
• BBS Pseudonyms with Hidden PID base proof header bytes 0xd9, 0x5d, and 0x10.
• BBS Pseudonyms with Hidden PID disclosure proof header bytes 0xd9, 0x5d, and 0x11.

As an example, with the anonymous holder binding feature, when a holder receives a base proof, it would be able to tell from the header values that to generate a disclosure proof it must use its secret value. Or in the case of a pseudonym with hidden PID, by seeing the header value it knows to use its pid and generate a pseudonym prior to preparing the disclosure proof. Similarly on the verifier side of things then can know whether to use a pseudonym when performing disclosure proof verification. Note that we do have other mechanisms to tell these cases a part, but this seems like a helpful check.

[dlongley]

I think this is a good idea.

However, we should avoid adding this until we're sure there isn't more consolidation of the base primitives from the IETF spec so as to avoid churn (and possible confusion in implementations if things move around). So the first step, I think, is seeing if / how the IETF primitives change and then adding this to improve checks in implementations. I'm also not sure if the verifier needs to know whether the PID is known to the issuer or not, so those header values might need to be combined for the disclosure proof, which might impact the order we want to use for these headers.

Also, why the jump from 0x07 => 0x10?

[TallTed]

It's hard to grok these bullets. Might I suggest tabular presentation?

optional feature	base proof header bytes	disclosure proof header bytes
ECDSA-SD	0xd9, 0x5d, and 0x00	0xd9, 0x5d, and 0x01
BBS	0xd9, 0x5d, and 0x02	0xd9, 0x5d, and 0x03
BBS Anonymous Holder Binding	0xd9, 0x5d, and 0x04	0xd9, 0x5d, and 0x05
BBS Pseudonyms with Issuer-known PID	0xd9, 0x5d, and 0x06	0xd9, 0x5d, and 0x07
BBS Pseudonyms with Hidden PID	0xd9, 0x5d, and 0x10	0xd9, 0x5d, and 0x11

2024-04-10 — Edited to improve table

[Wind4Greg]

Hi @dlongley why the jump 0x07 => 0x10? A brain fart must have been thinking in octal (base 8 ==> real old timey computer stuff). @TallTed once we know if the pseudonym flavors can be consolidated and folks agree, I like the idea of tables not just for this information but to make the optional features and their parameters easy to understand.

[Wind4Greg]

Hi @TallTed and @dlongley, walking through test vector generation for the optional features and put down some notes below on inputs, parameters, and serialization requirements. The goal will be to clean up the descriptions of the procedures (issues have already been raised on missing steps and such). Whether we make the info tabular, where to put informative versus normative information can discuss.

Anonymous Holder Binding

Key security value: holders secret value. Which is never revealed outside the holder. Only a commitment with proof is conveyed to the issuer for "blind signing".

• Add base proof extra inputs: commitment with proof of holders secret value (from the holder)
• Add base proof extra parameter(s) for serialization: optional signer_blind
• Add derived proof extra inputs: holders secret value, secret_prover_blind, optional signer_blind; Note first two are known to holder, the last is included with base proof from issuer.
• Add derived proof extra parameter(s) for serialization: none

Additional notes: The verification of the derived proof uses the Blind BBS variation per https://www.ietf.org/archive/id/draft-kalos-bbs-blind-signatures-00.html#section-4.2.4, i.e., requires a different BBS api_id than the regular BBS case and hence this MUST be communicated to the verifier.

Pseudonym with Issuer Known Pid

Key security value: pid. This is generated by the issuer, must be unique per holder and random. Must be securely conveyed to holder; It is not revealed to verifiers. Used to generate pseudonym along with the verifier id value.

• Add base proof extra inputs: pid (generated by the issuer, must be unique per holder and random)
• Add base proof extra parameter(s) for serialization: pid
• Add derived proof extra inputs: pid, verifier id; The first is included with base proof from issuer. The second is communicated from the verifier (exact mechanism is out of scope)
• Add derived proof extra parameter(s) for serialization: pseudonym (generated by holder)
• Verify derived proof extra inputs: verifier id, pseudonym; This first is known to verifier, second is included with derived proof.

Additional notes: The verification of the derived proof uses the procedure from https://www.ietf.org/archive/id/draft-vasilis-bbs-per-verifier-linkability-00.html#section-4.3. A verifier knows to use a procedure of this type due to presence of the pseudonym value. However, we may need to differentiate the two pseudonym cases (ongoing work at IETF/DIF).

Pseudonym with Hidden PID

Key security value: holders pid value. Which is never revealed outside the holder. Used to generate pseudonym along with verifier id.

• Add base proof extra inputs: commitment with proof of holders pid (from the holder); Implicit input: needs to know whether intent is for pseudonym versus anonymous holder binding.
• Add base proof extra parameter(s) for serialization: optional signer_blind
• Add derived proof extra inputs: verifier id, pid, secret_prover_blind, optional signer_blind; The first is communicated by the verifier; The next two are known to the. The last is from issuer and included with base proof.
• Add derived proof extra parameter(s) for serialization: pseudonym (generated by holder)
• Verify derived proof extra inputs: verifier id, pseudonym; This first is known to verifier, second is included with derived proof.

Additional notes: Due to the use of BBS api_id during BBS signature generation we need an "implicit input" and need to differentiate the base proof generated here from the anonymous holder binding case. Currently working with IETF/DIF BBS team to see if we can use same pseudonym verification procedure, currently these are slightly different.

[Wind4Greg]

Hi all, @dlongley, and @TallTed, after walking through the test vector generation for the optional features again. I'd really like those extra tags to help: (a) letting me know what I'm receiving (no dummy placeholders if we can help it), (b) the BBS algorithm/api_id to apply, and (3) what additional information will be needed for preparing the "proof". As inspired by @TallTed below is the info in tabular form. The two different pseudonym disclosure proof code points may not be needed if we can reconcile the interfaces in the IETF/DIF BBS pseudonym draft. Otherwise it would nice to have these code points. Other opinions?

Optional Feature Tags, Parameters, and inputs

Name	proof type	header bytes	serialized values	api_id	extra inputs
ECDSA-SD	base	0xd9, 0x5d, and 0x00	baseSignature, publicKey, hmacKey, signatures, and mandatoryPointers	N/A	N/A
ECDSA-SD	disclosure	0xd9, 0x5d, and 0x01	baseSignature, publicKey, signatures, compressedLabelMap, and mandatoryIndexes	N/A	N/A
BBS	base	0xd9, 0x5d, and 0x02	bbsSignature, bbsHeader, publicKey, hmacKey, and mandatoryPointers	BBS-SHA	N/A
BBS	disclosure	0xd9, 0x5d, and 0x03	bbsProof, compressedLabelMap, mandatoryIndexes, selectiveIndexes, and presentationHeader	BBS-SHA	N/A
BBS Anonymous Holder Binding	base	0xd9, 0x5d, and 0x04	bbsSignature, bbsHeader, publicKey, hmacKey, mandatoryPointers, and signerBlind	BLIND_BBS	commitment with proof for holder secret
BBS Anonymous Holder Binding	disclosure	0xd9, 0x5d, and 0x05	bbsProof, compressedLabelMap, mandatoryIndexes, selectiveIndexes, and presentationHeader	BLIND_BBS	holder secret, proverBlind
BBS Pseudonyms with Issuer-known PID	base	0xd9, 0x5d, and 0x06	bbsSignature, bbsHeader, publicKey, hmacKey, and mandatoryPointers, pid	PSEUDO_BBS	issuer generates pid
BBS Pseudonyms with Issuer-known PID	disclosure	0xd9, 0x5d, and 0x07	bbsProof, compressedLabelMap, mandatoryIndexes, selectiveIndexes, presentationHeader, and pseudonym	PSEUDO_BBS	verifier id
BBS Pseudonyms with Hidden PID	base	0xd9, 0x5d, and 0x08	bbsSignature, bbsHeader, publicKey, hmacKey, mandatoryPointers, and signerBlind	PSEUDO_BBS	commitment with proof for pid
BBS Pseudonyms with Hidden PID	disclosure	0xd9, 0x5d, and 0x09	bbsProof, compressedLabelMap, mandatoryIndexes, selectiveIndexes, presentationHeader, and pseudonym	PSEUDO_BBS	pid, proverBlind, verifier id

[msporny]

PR #158 has been merged to address this issue; closing.