Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-cfrg-rsa-blind-signatures-14> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Chris.

Thank you for your replies to our questions!  We have updated this document per your notes below.

A few follow-up items for you:

Regarding this item and your reply:

>> 7) <!-- [rfced] Section 5:  We do not see "RSASSA-PSS" mentioned in
>> Section 9.1.1 of RFC 8017.  Is EMSA-PSS-ENCODE considered an
>> RSASSA-PSS parameter?  If yes, will this be clear to readers?
>> Please let us know if any changes are needed.
>> 
>> Original:
>> Each
>> variant specifies RSASSA-PSS parameters as defined in Section 9.1.1
>> of [RFC8017] and the type of message preparation function applied (as
>> described in Section 4.1). -->
> 
> Please rewrite this to be:
> 
>    “Each variant specifies EMSA-PSS options Hash, MGF, and saltLen as defined in Section 9.1.1 of [RFC8017], as well as the type of message preparation function applied (as described in Section 4.1).”

We could not find "saltLen" in RFC 8017, but we found "sLen" in its Section 9.1.1 and "saltLength" in its Appendices A.2 and C.  We used "sLen" accordingly.  Please let us know any objections.

= = = = =

Regarding our question 9) and your reply:

> I suggest something slightly different (I’m only providing the RSABSSA-SHA384-PSS-Randomized version — the rest can be produced similarly):
> 
>    "RSABSSA-SHA384-PSS-Randomized:  This named variant uses SHA-384 as EMSA-PSS Hash option, MGF1 with SHA-384 as the EMSA-PSS MGF option, and 48 as the sLen option (salt length); it also uses the randomized preparation function (PrepareRandomize)."

= = = = =

>> 12) <!-- [rfced] Section 7:
>> 
>> a) We don't see any mention of "PrepareRandomize" or "preparation"
>> (as in "randomized preparation function (PrepareRandomize)" from
>> Section 5) in [Lys22].  Will this text and citation be clear to
>> readers?
>> 
>> Original:
>> Lysyanskaya also proved that the RSABSSA variants which use the
>> PrepareRandomize function achieve blindness in [Lys22].
> 
> Please update this to the following: 
> 
>    "Lysyanskaya also proved that the RSABSSA variants which use the PrepareRandomize function achieve blindness in (see version B of the protocol and related proofs in [Lys22])."

We reverted to "which" in this sentence but added appropriate punctuation.  Please confirm that RSABSSA variants always use the PrepareRandomize function.  (If not, we should use "that" instead of "which".)

= = = = =

Please review our updates carefully, and let us know if anything (parameter names in particular) is incorrect.

The latest files are posted here (please refresh your browser):

   https://www.rfc-editor.org/authors/rfc9474.txt
   https://www.rfc-editor.org/authors/rfc9474.pdf
   https://www.rfc-editor.org/authors/rfc9474.html
   https://www.rfc-editor.org/authors/rfc9474.xml
   https://www.rfc-editor.org/authors/rfc9474-diff.html
   https://www.rfc-editor.org/authors/rfc9474-rfcdiff.html
   https://www.rfc-editor.org/authors/rfc9474-auth48diff.html

   https://www.rfc-editor.org/authors/rfc9474-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9474-xmldiff2.html

Thanks again!

RFC Editor/lb


> On Sep 25, 2023, at 6:49 AM, Christopher Wood <[e-mail]> wrote:
> 
> Hi Sandy, all,
> 
> Please see inline below for answers to the AUTH48 questions.
> 
>> On Sep 18, 2023, at 9:19 PM, [e-mail] wrote:
>> 
>> Authors,
>> 
>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>> 
>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>> title) for use on <https://www.rfc-editor.org/search>. -->
> 
> Please also include "RSABSSA” alongside “RSA” and “blind signature”.
> 
>> 
>> 2) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1
>> of RFC 5743 have been adhered to in this document. -->
> 
> Confirmed.
> 
>> 
>> 3) <!-- [rfced] Section 1:
>> 
>> a) We updated this sentence to clarify that the family of variants is
>> specified by this document and not computed.  Please let us know any
>> objections.
>> 
>> Original:
>> This document specifies a protocol for computing RSA blind signatures
>> using RSA-PSS encoding, and a family of variants for this protocol,
>> denoted RSABSSA (RSA Blind Signature with Appendix).
>> 
>> Currently:
>> This document specifies (1) a protocol for computing RSA blind
>> signatures using RSA-PSS encoding and (2) a family of variants
>> (Section 5) for this protocol, denoted RSABSSA (RSA Blind Signature
>> with Appendix).
> 
> This updated text is fine.
> 
>> 
>> b) We see in other documents and in online searches that "RSABSSA" is
>> often listed as "RSA-BSSA" and defined as "RSA Blind Signature Scheme
>> with Appendix".  We also see that "RSA-BSSA" and (lowercased) "RSA
>> Blind Signature Scheme with Appendix" were used in version -01 of
>> this document but then changed, and we realize that any changes would
>> affect such listings as "RSABSSA-SHA384-PSS-Randomized" and
>> "RSABSSA-SHA384-PSS-Deterministic".
> 
> Please continue using RSABSSA. It’s a term this document introduced — it was not defined elsewhere.
> 
>> Please let us know if you would like to make any updates as related
>> to this term.  (We are fine either way but thought that this item was
>> worth pointing out.) -->
>> 
>> 
>> 4) <!-- [rfced] Section 4:  Should any of the artwork in this section
>> be sourcecode?  Please see
>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>, and let
>> us know if any changes are needed.  If the sourcecode-types page
>> does not contain an applicable type, please let us know.
>> Also, if you use sourcecode, it is acceptable to leave the "type"
>> attribute unset. -->
> 
> Please pick whatever is the correct formatting for this material. The editors have no preference.
> 
>> 5) <!-- [rfced] Sections 4.1 through 4.4:  We changed the artwork to
>> sourcecode with type="pseudocode" in these sections.
> 
> Sounds good.
> 
>> See <https://www.rfc-editor.org/materials/sourcecode-types.txt> for a
>> list of sourcecode types.
>> 
>> Please review, and let us know any objections. -->
>> 
>> 
>> 6) <!-- [rfced] Section 4.2:  "If EMSA-PSS-ENCODE raises an error, raise
>> the error" reads oddly here.  Do two entities raise the same error,
>> or does one entity forward the error thrown by EMSA-PSS-ENCODE?
>> If you would like to rephrase, please provide alternative text.
>> 
>> Original:
>> 2. If EMSA-PSS-ENCODE raises an error, raise the error and stop
>> 
>> Perhaps:
>> 2. If EMSA-PSS-ENCODE raises an error, stop
>> 
>> Or possibly:
>> 2. If EMSA-PSS-ENCODE throws an error, raise the error and stop -->
> 
> This text means that if EMSA-PSS-ENCODE raises an error, then the implementation of RSABSSA should raise that same error. To that end, I think the original text is fine, but perhaps you can change it to the following to make it more clear?
> 
>    "If EMSA-PSS-ENCODE raises an error, re-raise the error and stop” (note use of 're-raise’ instead of ‘raise’)
> 
>> 
>> 7) <!-- [rfced] Section 5:  We do not see "RSASSA-PSS" mentioned in
>> Section 9.1.1 of RFC 8017.  Is EMSA-PSS-ENCODE considered an
>> RSASSA-PSS parameter?  If yes, will this be clear to readers?
>> Please let us know if any changes are needed.
>> 
>> Original:
>> Each
>> variant specifies RSASSA-PSS parameters as defined in Section 9.1.1
>> of [RFC8017] and the type of message preparation function applied (as
>> described in Section 4.1). -->
> 
> Please rewrite this to be:
> 
>    “Each variant specifies EMSA-PSS options Hash, MGF, and saltLen as defined in Section 9.1.1 of [RFC8017], as well as the type of message preparation function applied (as described in Section 4.1).”
> 
>> 
>> 8) <!--[rfced]  Would it be correct to expand the first mention of “MGF1” as “mask generation function 1 (MGF1)" (per use in RFC 9151, which references RFC 8017), or do you prefer to leave the text as is (to match use in RFC 8017)?
>> 
>> Current:
>>  Each variant uses the MGF1 mask generation function 
>>  defined in Appendix B.2.1. of [RFC8017].
>> 
>> Perhaps:
>>  Each variant uses the mask generation function 1 (MGF1) 
>>  defined in Appendix B.2.1. of [RFC8017].
>> -->
> 
> This is fine.
> 
>> 9) <!-- [rfced] Section 5:  We had trouble parsing these sentences.
>> If the suggested text is not correct, please provide clarifying text.
>> 
>> Original:
>> 1.  RSABSSA-SHA384-PSS-Randomized: This named variant uses SHA-384 as
>>     the hash function, MGF1 with SHA-384 as the PSS mask generation
>>     function, a 48-byte salt length, and uses the randomized
>>     preparation function (PrepareRandomize).
>> 
>> 2.  RSABSSA-SHA384-PSSZERO-Randomized: This named variant uses
>>     SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask
>>     generation function, an empty PSS salt, and uses the randomized
>>     preparation function (PrepareRandomize).
>> 
>> 3.  RSABSSA-SHA384-PSS-Deterministic: This named variant uses SHA-384
>>     as the hash function, MGF1 with SHA-384 as the PSS mask
>>     generation function, 48-byte salt length, and uses the identity
>>     preparation function (PrepareIdentity).
>> 
>> 4.  RSABSSA-SHA384-PSSZERO-Deterministic: This named variant uses
>>     SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask
>>     generation function, an empty PSS salt, and uses the identity
>>     preparation function (PrepareIdentity).  This is the only variant
>>     that produces deterministic signatures over the client's input
>>     message msg.
>> 
>> Suggested:
>> RSABSSA-SHA384-PSS-Randomized:  This named variant uses SHA-384 as
>>    the hash function, MGF1 with SHA-384 as the PSS mask generation
>>    function, and a 48-byte salt length; it also uses the randomized
>>    preparation function (PrepareRandomize).
>> 
>> RSABSSA-SHA384-PSSZERO-Randomized:  This named variant uses SHA-384
>>    as the hash function, MGF1 with SHA-384 as the PSS mask generation
>>    function, and an empty PSS salt; it also uses the randomized
>>    preparation function (PrepareRandomize).
>> 
>> RSABSSA-SHA384-PSS-Deterministic:  This named variant uses SHA-384 as
>>    the hash function, MGF1 with SHA-384 as the PSS mask generation
>>    function, and a 48-byte salt length; it also uses the identity
>>    preparation function (PrepareIdentity).
>> 
>> RSABSSA-SHA384-PSSZERO-Deterministic:  This named variant uses
>>    SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask
>>    generation function, and an empty PSS salt; it also uses the
>>    identity preparation function (PrepareIdentity).  This is the
>>    only variant that produces deterministic signatures over the
>>    client's input message msg. -->
> 
> I suggest something slightly different (I’m only providing the RSABSSA-SHA384-PSS-Randomized version — the rest can be produced similarly):
> 
>    "RSABSSA-SHA384-PSS-Randomized:  This named variant uses SHA-384 as EMSA-PSS Hash option, MGF1 with SHA-384 as the EMSA-PSS MGF option, and 48 as the sLen option (salt length); it also uses the randomized preparation function (PrepareRandomize)."
> 
>> 
>> 
>> 10) <!-- [rfced] Section 6.1:  "errors generated throughout this
>> specification" reads oddly.  If the suggested text is not
>> acceptable, please provide alternative text.
>> 
>> Original:
>> The explicit errors generated throughout this specification, along
>> with the conditions that lead to each error, are listed in the
>> definitions for Blind, BlindSign, and Finalize.
>> 
>> Suggested:
>> The generation of explicit errors as discussed throughout this
>> specification, along with the conditions that lead to each error,
>> are listed in the definitions for Blind, BlindSign, and Finalize. -->
> 
> Please keep the original text.
> 
>> 11) <!-- [rfced] Section 6.2:  Should "RSASSA-PSS OID" be "id-RSASSA-PSS
>> OID" per RFC 5756?
>> 
>> Original:
>> If the server public key is carried in an X.509 certificate, it MUST
>> use the RSASSA-PSS OID [RFC5756]. -->
> 
> Yes, thank you, it should be "id-RSASSA-PSS OID"
> 
>> 12) <!-- [rfced] Section 7:
>> 
>> a) We don't see any mention of "PrepareRandomize" or "preparation"
>> (as in "randomized preparation function (PrepareRandomize)" from
>> Section 5) in [Lys22].  Will this text and citation be clear to
>> readers?
>> 
>> Original:
>> Lysyanskaya also proved that the RSABSSA variants which use the
>> PrepareRandomize function achieve blindness in [Lys22].
> 
> Please update this to the following: 
> 
>    "Lysyanskaya also proved that the RSABSSA variants which use the PrepareRandomize function achieve blindness in (see version B of the protocol and related proofs in [Lys22])."
> 
>> 
>> b) We don't see any mention of "PrepareIdentity" in Section 7.3.
>> Will this text and citation be clear to readers?
> 
> Please modify Section 7.3 in the following way:
> 
> OLD:
> The named variants that use the PrepareRandomize function -- RSABSSA-SHA384-PSS-Randomized and RSABSSA-SHA384-PSSZERO-Randomized -- explicitly inject fresh entropy alongside each message to satisfy condition (2). As such, these variants are safe for all application use cases
> NEW:
> The named variants that use the PrepareRandomize function -- RSABSSA-SHA384-PSS-Randomized and RSABSSA-SHA384-PSSZERO-Randomized -- explicitly inject fresh entropy alongside each message to satisfy condition (2). As such, these variants are safe for all application use cases. In contrast, the named variants that use the PrepareIdentity function do not inject fresh entropy and therefore could be a problem with low entropy inputs.
>> 
>> 
>> 
>> Original:
>> However, additional
>> assumptions on the message inputs are required for blindness to hold
>> for RSABSSA variants that use the PrepareIdentity function; see
>> Section 7.3 for more discussion on those results. -->
>> 
>> 
>> 13) <!-- [rfced] Section 7.4:  Because this is the first mention of
>> "message randomizer prefix", we updated this sentence for ease of the
>> reader.  Please let us know any objections.
>> 
>> Original:
>> All random values in the protocol, including the salt, message
>> randomizer prefix, and random blind value in Blind, MUST be generated
>> from a cryptographically secure random number generator [RFC4086].
>> 
>> Currently:
>> All random values in the protocol, including the salt, message
>> randomizer prefix (msg_prefix; see Appendix A), and random blind
>> value in Blind, MUST be generated from a cryptographically secure
>> random number generator [RFC4086]. -->
> 
> This is fine — thanks.
> 
>> 
>> 14) <!-- [rfced] Section 7.6:
>> 
>> a) We do not see any mention of "v3" or "version 3" as related to
>> X.509 in RFC 4055.  Will this citation be clear to readers?
>> 
>> Original:
>> First, it is recommended in recent
>> standards, including TLS 1.3 [RFC8446], X.509v3 [RFC4055], and even
>> PKCS#1 itself.
> 
> Please update this to be:
> 
>    "First, it is recommended in recent standards, including TLS 1.3 [RFC8446], X.509 [RFC4055], and even PKCS#1 itself."
> 
>> 
>> b) Because this text is quoted, we updated it to match the text in
>> RFC 8017.  Please let us know any concerns; for example, if you wish
>> to keep "recommended for eventual adoption", the quotes will need to
>> be removed.
>> 
>> Original:
>> According to [RFC8017], "Although no attacks are
>> known against RSASSA-PKCS#1 v1.5, in the interest of increased
>> robustness, RSA-PSS [RFC8017] is recommended for eventual adoption in
>> new applications."
>> 
>> Currently:
>> According to [RFC8017], "Although no attacks are known
>> against RSASSA-PKCS1-v1_5, in the interest of increased robustness,
>> RSASSA-PSS is REQUIRED in new applications."
> 
> This is fine.
> 
>> 
>> c) We could not find "RSASSA-PKCS#1 v1.5" in any published RFC.
>> We changed "RSASSA-PKCS#1 v1.5" to "RSASSA-PKCS1-v1_5" per
>> RFC 8017 and other published RFCs accordingly.  Please let us know
>> any concerns.
>> 
>> Original:
>> While RSA-PSS is more complex than RSASSA-PKCS#1
>> v1.5 encoding, ubiquity of RSA-PSS support influenced the design
>> decision in this draft, despite PKCS#1 v1.5 having equivalent
>> security properties for digital signatures [JKM18].
>> 
>> Currently:
>> While RSA-PSS is more
>> complex than RSASSA-PKCS1-v1_5 encoding, ubiquity of RSA-PSS support
>> influenced the design decision in this document, despite PKCS #1 v1.5
>> having equivalent security properties for digital signatures [JKM18].
> 
> No concerns.
> 
>> 
>> d) We do not see any mention of "FDH" or the word "full" in [RSA-FDH].
>> Will this citation be clear to readers?
> 
> 
> Yes, this will be clear. RSA-FDH is the canonical reference for the full domain hash.
> 
>> Original:
>> Full Domain Hash (FDH) [RSA-FDH] encoding is also possible, and this
>> variant has equivalent security to PSS [KK18]. -->
>> 
>> 
>> 15) <!-- [rfced] Informative References:  As we have found that some
>> ".edu" pages are not always stable*, may we update the listings
>> below as follows?
>> 
>> * (although we could not find an alternative to the page provided for
>> [Chaum83])
>> 
>> Original:
>> [RSA-FDH]  Bellare, M. and P. Rogaway, "Random Oracles are Practical:
>>            A Paradigm for Designing Efficient Protocols", October
>>            1995, <https://cseweb.ucsd.edu/~mihir/papers/ro.pdf>.
>> 
>> Suggsted:
>> [RSA-FDH]  Bellare, M. and P. Rogaway, "Random Oracles are Practical:
>>            A Paradigm for Designing Efficient Protocols", CCS '93:
>>            Proceedings of the 1st ACM conference on Computer and
>>            communications security, pp. 62-73, DOI 10.1145/
>>            168588.168596, December 1993, <https://dl.acm.org/doi/
>>            abs/10.1145/168588.168596>.
>> ...
>> Original:
>> [RemoteTimingAttacks]
>>            Boneh, D. and D. Brumley, "Remote Timing Attacks are
>>            Practical", 12th Usenix Security Symposium, May 2003,
>>            <https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf>.
>> 
>> Suggested:
>> [RemoteTimingAttacks]
>>            Brumley, D. and D. Boneh, "Remote Timing Attacks are
>>            Practical", Proceedings of the 12th USENIX Security
>>            Symposium, August 2003,
>>            <https://www.usenix.org/legacy/events/sec03/tech/brumley/
>>            brumley.pdf>. -->
>> 
> 
> We have no preference. Whatever you think is best.
> 
>> 
>> 16) <!-- [rfced] Informative References:  Per
>> <https://doi.org/10.6028/nist.fips.186-4>, which steers to
>> <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>, FIPS
>> 186-4 has been superseded by FIPS 186-5.  May we update as suggested?
>> 
>> Original:
>> The RECOMMENDED method for generating the server signing key pair is
>> as specified in FIPS 186-4 [DSS].
>> ...
>> [DSS]      "Digital Signature Standard (DSS)", National Institute of
>>            Standards and Technology report,
>>            DOI 10.6028/nist.fips.186-4, July 2013,
>>            <https://doi.org/10.6028/nist.fips.186-4>.
>> 
>> Suggested:
>> The RECOMMENDED method for generating the server signing key pair is
>> as specified in FIPS 186-5 [DSS].
>> ...
>> [DSS]      "Digital Signature Standard (DSS)", National Institute of
>>            Standards and Technology report,
>>            DOI 10.6028/nist.fips.186-5, February 2023,
>>            <https://doi.org/10.6028/NIST.FIPS.186-5>. -->
> 
> 
> Yes, this is fine.
> 
>> 
>> 
>> 17) <!-- [rfced] Informative References:  The following references are
>> not cited anywhere in this document.  Please let us know where they
>> should be cited; otherwise, the listings will be removed.
>> 
>> Side note regarding [UProve]:  If this listing is to be kept, please
>> advise regarding the currently listed date.  We could not find a
>> February 2012 version.  Is this date correct?
>> 
>> Original:
>> [BLS-Proposal]
>>            Ladd, W., "[Privacy-pass] External verifiability: a
>>            concrete proposal", July 2020,
>>            <https://mailarchive.ietf.org/arch/msg/privacy-pass/
>>            BDOOhSLwB3uUJcfBiss6nUF5sUA/>.
>> ...
>> [KLRX20]   Kastner, J., Loss, J., Rosenberg, M., and J. Xu, "On
>>            Pairing-Free Blind Signature Schemes in the Algebraic
>>            Group Model", September 2020,
>>            <https://eprint.iacr.org/2020/1071>.
>> ...
>> [PolytimeROS]
>>            Benhamouda, F., Lepoint, T., Loss, J., Orru, M., and M.
>>            Raykova, "On the (in)security of ROS", July 2020,
>>            <https://eprint.iacr.org/2020/945>.
>> ...
>> [TZ22]     Tessaro, S. and C. Zhu, "Short Pairing-Free Blind
>>            Signatures with Exponential Security", January 2022,
>>            <https://eprint.iacr.org/2022/047>.
>> ...
>> [UProve]   Microsoft, "U-Prove", February 2012,
>>            <https://www.microsoft.com/en-us/research/project/
>>            u-prove/>. -->
> 
> Thanks — please remove these references if they are not used.
> 
>> 18) <!-- [rfced] Appendices A.1 through A.4:  We changed the artwork to
>> sourcecode with type="test-vectors".
>> 
>> See <https://www.rfc-editor.org/materials/sourcecode-types.txt> for a
>> list of sourcecode types.
>> 
>> Please review, and let us know any objections. -->
> 
> This is fine.
> 
>> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the
>> online Style Guide at
>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
>> and let us know if any changes are needed.
>> 
>> Note that our script did not flag any words in particular, but this
>> should still be reviewed as a best practice. -->
> 
> We have reviewed and confirm the current language is appropriate.
> 
>> 20) <!-- [rfced] Please let us know if any changes are needed for the
>> following:
>> 
>> a) The following terms were used inconsistently in this document.
>> We chose to use the latter forms.  Please let us know any objections.
>> 
>> Random Oracle Model / random oracle model (per RFC 8017)
>> 
>> zero knowledge proofs / zero-knowledge proofs
> 
> Both of these are fine changes.
> 
>> 
>> b) The following term appears to be used inconsistently in this
>> document.  Please let us know which form is preferred.
>> 
>> signature-message pair (1 instance) /
>>   (message, signature) pair (3 instances in Section 7.5)
> 
> Please use the latter form.
> 
>> 
>> c) Should "random prefix" in Section 4.5 be "message randomizer
>> prefix" or perhaps "msg_prefix"? -->
> 
> Please use “message randomizer prefix,” as that seems to be the most accurate description.
> 
> Thanks again, and please let us know when these updates are in place so we can review and approve the final version.
> 
> Best,
> Chris, for the editors