(Re: my paper at http://eprint.iacr.org/2002/151/ ) Stefan Brands wrote:

- The system is subject to a simple attack. The problem lies with the multiplication of the hashes. Let's take the Chaum blinding as an [...]

(For our readers at home, that was the vulnerability I mentioned in my response to Adam). [...]

- My work certainly does provide for "revocable anonymity" and "pooling" prevention. For pooling protection, see paragraph 2 on page 193, section 5.11 page 210 paragraph 2, and section 5.5.2 on page 211. For [...]

When I speak of pooling credentials, I'm talking about Alice presenting her student ID along with the senior-citizen ID Bob loaned her (or for which Bob is answering clandestine-ly), as if they both belonged to her, in order to get both discounts on her movie tickets. In my system, you get your credentials issued in a set associated with a single identity, and it's hard for Alice to get Bob's credentials included in one of her own sets. It works even if the CAs don't trust each other. Page 211 of your book talks about discouraging lending, which doesn't help in the case when Bob answers in Alice's behalf when she shows his credentials. In any case, section 5.5.2 only adds liability to pooling - it doesn't prevent it mathematically. (As to lending in general, I think you're right that discouragement may be the best we can do). Page 193 and 210 do talk about having an identifying value encoded in the credentials which the holder can prove is or isn't the same as in other credentials. However, the discussion on page 193 is with respect to building digital pseudonyms, and the discussion on page 210 seems to be about showing that values are *not* the same, following a scenario in which a pseudonym holder has been identified as a misbehaver. I can think of ways in which this feature might be leveraged to create otherwise-unlinkable sets of credentials from different (distrusting) CAs, but it's never addressed directly that I can see, and would need some specifics filled in. Nonetheless, I'll point out in my paper that it's a possibility in your system.

- The proposed hashing technique for selective disclosure was introduced by myself in 1999. Quoting from page 27 of my MIT Press book titled [...]

Pages 27 and 184 of your book are now both referenced in my section on selective disclosure.

- More seriously, the simple hash technique has numerous drawbacks, as I explain on page page 27 of my MIT Press book, in the very same paragraph: "Although certificate holders now have some control over which attributes they reveal to verifiers, they are forced to leave behind digital signatures. ... [...]

What do you mean by "forced to leave behind digital signatures"?

... Worse, nothing prevents the CA and others from tracing and linking all the communications and transactions of each certificate holder." ... [...]

This is of course overcome in my system with blinding and cut-and-choose.

[ Snipped discussion of features which Brands' system has and my system doesn't: boolean formulae, lending prevention, limited show, wallet-with-observer, discarding protection, anonymous recertification / updating, multi-application certificates, etc. ]

From my response to Adam Back: I'm glad that was clear in my text. This isn't a do-everything system like Brands' - rather, it has 2 aims. 1: show how to do simple selective disclosure in a Chaum/Fiat/Naor-like system using X.509v3 credentials as a base, and 2: show how to link credentials from multiple issuers to the same identity without compromising anonymity. And actually, I forgot to mention the original goal of my paper, which was to create a system not encumbered by your patents or Chaum's. I'll expand my related work section to point out that your system and others have lots of features which my system doesn't attempt to provide. My apologies if my terse treatment mischaracterized your work. -J