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

["Stanislav V. Smyshlyaev" <[e-mail]>]

Dear Lynne,

Thank you for your message and for your efforts with this draft.

I've reviewed the latest updates to Section 5 and Section 7.3 (based on
https://www.rfc-editor.org/authors/rfc9474-auth48diff.html).

I agree that the updates could be considered "beyond editorial" and that it
would be better to make such changes at the earlier stages. On the other
hand, I am fine with these updates and confirm that they do not change
anything that needs an additional reviewing stage. So I approve.

Best regards,
Stanislav

On Wed, Sep 27, 2023 at 3:58 AM Lynne Bartholomew <[e-mail]>
wrote:

> Hi, *Stanislav.
>
> Please review the latest updates to Section 5 and the new "In contrast,
> the named variants ..." sentence in Section 7.3.  We ask for your review
> because these updates could be considered "beyond editorial".  Please let
> us know if you approve.
>
> 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
>
> Thank you!
>
> RFC Editor/lb
>
> > On Sep 26, 2023, at 3:00 PM, Lynne Bartholomew <[e-mail]>
> wrote:
> >
> > 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
> >
> >
>
>