Re: [Privacy-pass] New drafts for IETF107

[Sofía Celi <[e-mail]>]

Hi, Alex!
> The points that you’ve raised above all make sense to me. If you would be interested in submitting an issue/PR for solving them, that would be really useful and I would be happy to review it.

Just sent it ;) I added some grammar corrections as well.
While doing the PR, I also realized that it is not clear when the
'Issuance message' is sent. It seems to not be the output of any of the
API functions... I'm not sure how that one works..

After reading the architecture document, I thought that:

- Maybe it will be nice to give an example for the unique identifier for
the client id
- It will be nice to define what anonymity means in the draft, maybe
taking the definitions of some papers that have defined the different
terms around anonymity.
- This section is a little unclear for me:
"""
In addition, we RECOMMEND that trusted registries indicate at all
times which issuers are deemed to be active.
"""
How will the registries determine which issuers are active?
- It will be nice to also recommend a time for when servers can rotate
their signing keys.
- It also seems to have some variable naming consistency issues that
I'll fix in a PR if it is ok ;)

>> - The architecture draft states the possibility of the existence of
>> malicious servers that can rotate keys in a short time frame. Something
>> that maybe also needs to be think about is the possibility of malicious
>> servers deleting the storage of valid inputs (used to protect against
>> double spending). I don't know how possible this can be, and how to
>> protect.. but I was just wondering if it has been thought.
> 
> I guess this is a possibility. However, a server should only really maintain the double-spend index for their own security (to prevent clients from spending the same token over and over again). If a server decides to delete this storage, then really they have only harmed themselves. So I’m not sure if we need to cover this point specifically, other than mentioning that the server SHOULD maintain a double-spend index as detailed in the document.

Oh, that is right! It makes sense.

Thanks so much!

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places
FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02