issuer -> signer

draft-irtf-cfrg-bbs-signatures.md

@@ -1647,23 +1647,23 @@ Procedure:
 
 # Privacy Considerations
 
-This section will go through threats to the Prover's privacy. Note that a BBS proof is unlinkable against both the Verifiers and the Issuer, as well as multiple Verifiers colluding with each other and Verifiers colluding with the Issuer. The following sections will describe possible threats, resulting from side chanel information or identifying disclosed messages, that could compromise the unlinkability property of the BBS proof. Such threats, if exploited, could lead to correlation of the Prover's interactions with different Verifiers, resulting to fingerprinting attacks on the Prover's activity.
+This section will go through threats to the Prover's privacy. Note that a BBS proof is unlinkable against both the Verifiers and the Signer, as well as multiple Verifiers colluding with each other and Verifiers colluding with the Signer. The following sections will describe possible threats, resulting from side chanel information or identifying disclosed messages, that could compromise the unlinkability property of the BBS proof. Such threats, if exploited, could lead to correlation of the Prover's interactions with different Verifiers, resulting to fingerprinting attacks on the Prover's activity.
 
 Note that, the following sections describe ways to minimize possible identifying information revealed during a BBS proof presentation. To minimize the privacy threats of an entire system, other protections may also need to be employed, for example, using an IP hiding proxy network like TOR ([@DMS04]).
 
 ## Total Number and Index of Signed Messages
 
-When a Prover presents a BBS proof to a Verifier, other than the messages they decide to disclose, there are two additional pieces of information that will be revealed. First, the total number of signed messages, which can be inferred from the size of the BBS proof and the length of the disclosed messages list. Second, the index the disclosed messages had in the list of signed messages (see (#proof-generation-proofgen)). This information, if unique to each Prover, could be employed to correlate multiple proof presentations together. As a result, the Issuer should not sign lists of messages with unique lengths or unique indexing. For this reason, it is RECOMMENDED that signed lists of messages are padded to a common length (using either random, or an unused by the application message, like 0 or 1). It is also RECOMMENDED that a constant ordering of messages will be preserved when possible. For example, if an application creates signatures for the messages `[<user_name>, <user_affiliation>, <user_country>]`, then those messages should always be signed in the same order, i.e., first message should always be the user's name (`<user_name>`), second message should always be the user's affiliation (`<user_affiliation>`) and the last message should always be the user's country of origins (`<user_country>`). Provers can employ consistency validation mechanisms, like the ones described in [@I-D.ietf-privacypass-key-consistency], to validate that those values are not used to correlate them.
+When a Prover presents a BBS proof to a Verifier, other than the messages they decide to disclose, there are two additional pieces of information that will be revealed. First, the total number of signed messages, which can be inferred from the size of the BBS proof and the length of the disclosed messages list. Second, the index the disclosed messages had in the list of signed messages (see (#proof-generation-proofgen)). This information, if unique to each Prover, could be employed to correlate multiple proof presentations together. As a result, the Signer should not sign lists of messages with unique lengths or unique indexing. For this reason, it is RECOMMENDED that signed lists of messages are padded to a common length (using either random, or an unused by the application message, like 0 or 1). It is also RECOMMENDED that a constant ordering of messages will be preserved when possible. For example, if an application creates signatures for the messages `[<user_name>, <user_affiliation>, <user_country>]`, then those messages should always be signed in the same order, i.e., first message should always be the user's name (`<user_name>`), second message should always be the user's affiliation (`<user_affiliation>`) and the last message should always be the user's country of origins (`<user_country>`). Provers can employ consistency validation mechanisms, like the ones described in [@I-D.ietf-privacypass-key-consistency], to validate that those values are not used to correlate them.
 
-## Issuer's Public Keys
+## Signer Public Keys
 
-As with most systems based on public key cryptography, multiple BBS signatures (and the subsequent BBS proofs) could be correlated with each other, if the Issuer does not use the same key for a large set of produced signatures. For example, the Issuer could use a different key to generate the signatures intended for a specific user, or a small set of users. Every proof generated by that set of users would then be linked to that group (since it will be validated by a different public key). To avoid fragmentation of the user space by different public keys, an application could use the same mechanisms that where proposed to check the consistency of the total number of messages and their indexes (i.e., [@I-D.ietf-privacypass-key-consistency], see (#total-number-and-index-of-signed-messages)).
+As with most systems based on public key cryptography, multiple BBS signatures (and the subsequent BBS proofs) could be correlated with each other, if the Signer does not use the same key for a large set of produced signatures. For example, the Signer could use a different key to generate the signatures intended for a specific user, or a small set of users. Every proof generated by that set of users would then be linked to that group (since it will be validated by a different public key). To avoid fragmentation of the user space by different public keys, an application could use the same mechanisms that where proposed to check the consistency of the total number of messages and their indexes (i.e., [@I-D.ietf-privacypass-key-consistency], see (#total-number-and-index-of-signed-messages)).
 
 ## Disclosed Messages
 
 Although multiple BBS proofs cannot be linked to each other, privacy also depends on the uniqueness of the disclosed messages during proof generation. If a unique message (or unique combination of messages) is revealed multiple times, it could be used to link the corresponding proofs together. Examples of such messages include government IDs, email addresses, phone numbers etc. If not required by the use case, the Prover should avoid disclosing such information when constructing a BBS proof.
 
-For certain types of message values, set membership proofs (for example, [@VB22]) or range proofs (for example, [@BBB17]) could be used to further mitigate the above issue. With a set membership proof, the BBS proof Verifier will be able to validate that one of the Prover's signed (and undisclosed) messages, belongs to a pre-defined set (for example that the Prover's government ID belongs to a set of valid government ID's). The inverse is also possible, where the Prover showcases that one of the undisclosed messages is not part of a set (for example, that a signed unique revocation identifier is not part of the set of revoked identifiers). If a message is represented by a numeric value (see (#mapping-messages-to-scalars)), range proofs can be used to prove that it is within a specific range. As an example, a Prover, instead of revealing their age, they could use a range proof to showcase that they are over 18 years old.
+For certain types of message values, set membership proofs (for example, [@VB22]) or range proofs (for example, [@BBB17]) could be used to further mitigate the above issue. With a set membership proof, the BBS proof Verifier will be able to validate that one of the Prover's signed (and undisclosed) messages, belongs to a pre-defined set (for example that the Prover's government ID belongs to a set of valid government IDs). The inverse is also possible, where the Prover showcases that one of the undisclosed messages is not part of a set (for example, that a signed unique revocation identifier is not part of the set of revoked identifiers). If a message is represented by a numeric value (see (#mapping-messages-to-scalars)), range proofs can be used to prove that it is within a specific range. As an example, a Prover, instead of revealing their age, they could use a range proof to showcase that they are over 18 years old.
 
 # Security Considerations
 
@@ -1717,11 +1717,11 @@ Note that the BBS Interface defined in this document (see (#bbs-signatures-inter
 
 If a BBS Interface accepts both octet strings and scalar values as messages, where depending on the message's type different operations will be used to map it to a scalar (e.g., `hash_to_scalar` for octet strings and the identity operation for scalars), it must still ensure that the properties described in (#define-a-new-map-to-scalar) holds. To that end, the application MUST ensure that it is clear to all participants, which message should be considered an octet string and which a scalar.
 
-As an example, if the type (i.e., octet string or scalar) of the messages inputted to the BBS Interface, is uniquely determined by its index in the messages list (for example, first message is an octet string, second message a scalar etc.,), the map between message index and message type (determined by the Issuer), could be made available as part of the Issuer's public parameters (similar to [@UPROVE]). This map would then be passed to the BBS Interface, which will use it to correctly map each message to a scalar. Another option, is to sign such configurations as part of the `header` parameter of the BBS signature (see (#signature-generation-sign)). In this case, the map does not need to be published by the Issuer.
+As an example, if the type (i.e., octet string or scalar) of the messages inputted to the BBS Interface, is uniquely determined by its index in the messages list (for example, first message is an octet string, second message a scalar etc.,), the map between message index and message type (determined by the Signer), could be made available as part of the Signer's public parameters (similar to [@UPROVE]). This map would then be passed to the BBS Interface, which will use it to correctly map each message to a scalar. Another option, is to sign such configurations as part of the `header` parameter of the BBS signature (see (#signature-generation-sign)). In this case, the map does not need to be published by the Signer.
 
-If the application defines that the first (or last) `n` messages will be scalars and everything else octet strings, it could just publish the `n` value as part of the Issuer's public parameters or again sign it as part of the `header` value.
+If the application defines that the first (or last) `n` messages will be scalars and everything else octet strings, it could just publish the `n` value as part of the Signer's public parameters or again sign it as part of the `header` value.
 
-In any case, the privacy considerations described in (#privacy-considerations) MUST not be violated, for example, by using unique pre-processing rules or maps between message index and type. To validate the consistency of the message processing rules, the Prover could use mechanisms like the ones described in [@I-D.ietf-privacypass-key-consistency].
+In any case, the privacy considerations described in (#privacy-considerations) MUST ΝΟΤ be violated, for example, by using unique pre-processing rules or maps between message index and type. To validate the consistency of the message processing rules, the Prover could use mechanisms like the ones described in [@I-D.ietf-privacypass-key-consistency].
 
 ## Post-quantum Security and Everlasting Privacy