Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-cfrg-rsa-blind-signatures-14> for your review
Christopher Wood <caw@heapingbits.net> Tue, 19 September 2023 14:03 UTC
Return-Path: <caw@heapingbits.net>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4161C15198F; Tue, 19 Sep 2023 07:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_PDS_SHORTFWD_URISHRT_QP=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b="rpnM8cKt"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="Oz2Q3Xs9"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJfZlF2N8fKg; Tue, 19 Sep 2023 07:03:34 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFACEC151709; Tue, 19 Sep 2023 07:03:33 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id AA5F9320095A; Tue, 19 Sep 2023 10:03:32 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 19 Sep 2023 10:03:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm2; t=1695132212; x=1695218612; bh=Qwtk3iRf6nZBVJJ6d1I/zE2KC wFlEwP3p7GYXhrQGuA=; b=rpnM8cKt6jhONuYtQW9vpvv/p+sxtr7GZRM+rHn0X LWMKZjsuO7McoocwPAwvPW9hUxsu11mZH9c/BYvM1EMq5GQXSzEWg7bMKRW1hsEj 7u8BJD6C3YBG54V7071zlZ3Uivfs6BaElqqS3GS71GG/6C88StjwwOdFIV288iQ/ /CQIfjrSt6vINt9tvx7GpnYYWCumTL4j1pwG0mNbz/rG/r91fJ3hPSeFY2kPVzBm 997jq8kods7rgQEYlYHOGgyL6HP70o4IT9xzXrnoY8GhTH7xTafO6j1WOx5SBG5h m/mU4kG6h4p88Kdf0SbRUBKSOzw/Pjivg4WOe4VXQJ91w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695132212; x=1695218612; bh=Qwtk3iRf6nZBVJJ6d1I/zE2KCwFlEwP3p7G YXhrQGuA=; b=Oz2Q3Xs92Q1o4c3sBAMzkH3EmdxPyQjIrN0ecUZoNymfb6fd+cA IgEFVzqJ/ve14qrekvFlrALeo4w31WEEYrfSyvBbVgltjFWI0T+1zEyCKfwve0fd TRok+ob0811q93bea52F8RELnbTgG21a7RN+IXsQh/IXzqGT8crF228TB9tZwBm6 3soTL/HOZDP2uc3HyJI69xyHEDyR9wWhHbYaK3adi61ITDtWYvi0yjgqy6wVGm/s rSwOQXfoWamX8fqZ5q3v1wGIEg4J+ZyBgm7xh3SePfLB/IL5E1rDtygf4my4wKKm JzH8jIZBOtVGzAheXtWe91OjoM9HdlKXZFw==
X-ME-Sender: <xms:M6oJZckfJeh0bdJ1QKpp52TTQQzlI2BCFgvLSNAxmFx10gxLgNmjww> <xme:M6oJZb06nxX7KYrNmTVlTpHOlIuFZKlnPgiVBHFeyCMZVV5MC4FEpXxKhFiVvgPsT uKf--Hz8esllnlseRc>
X-ME-Received: <xmr:M6oJZaooLketgDR6OvgbMZ3CFkoKal-JB3yLqFJz76_yK1SL_EtU1Qz-6Ky-AK3VYJYvsP0KusA3iRDkwE_5t-ZsMtaaKhHLiGaKkqRaQSqYg4UOrHAVVQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekuddggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdlqdegmdenucfjughrpegtggfuhfgjffevgffkfhfvofesthhqmhdt hhdtjeenucfhrhhomhepvehhrhhishhtohhphhgvrhcuhghoohguuceotggrfieshhgvrg hpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepfeehleejffeggeefveef ffefffeludffuddvgeejheehuedvhfetuddvkefgkeeinecuffhomhgrihhnpehrfhgtqd gvughithhorhdrohhrghdpuhgtshgurdgvughupdgrtghmrdhorhhgpdhsthgrnhhfohhr ugdrvgguuhdpuhhsvghnihigrdhorhhgpdguohhirdhorhhgpdhnihhsthdrghhovhdpih gvthhfrdhorhhgpdhirggtrhdrohhrghdpmhhitghrohhsohhfthdrtghomhenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrph hinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:M6oJZYl4y_Rrwnbauen54VQfGDW8hClLU-zt8E4hX--fnAHPpqD13Q> <xmx:M6oJZa0sfTFAbpC9slIWbbtuIKlx5keCQhyP768bbH3_-sLt4a0zow> <xmx:M6oJZfsP0j6h5Fl8jT6KWPYnC5p3F9VvR6EtJjg9HAsQrpq1NhGrAQ> <xmx:NKoJZdRXEg63R7lz5wSi_2UqmG_Vyb6aLjSCDEPh5hZ6fUKTqODsqg>
Feedback-ID: i2f494406:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Sep 2023 10:03:31 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Christopher Wood <caw@heapingbits.net>
In-Reply-To: <20230919011956.11BE6D844F@rfcpa.amsl.com>
Date: Tue, 19 Sep 2023 10:03:19 -0400
Cc: Frank Denis <fd@00f.net>, Frederic Jacobs <frederic.jacobs@apple.com>, IRSG <irsg@irtf.org>, "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <032013F4-F4C6-4FFB-8D74-AA30884BD9FB@heapingbits.net>
References: <20230919011956.11BE6D844F@rfcpa.amsl.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/EooTYzXidRgz8qeAQR4KAmq2mXQ>
Subject: Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-cfrg-rsa-blind-signatures-14> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Sep 2023 14:03:38 -0000
Before digging into this, is there a reason we can’t do this AUTH48 via GitHub? I find it quite cumbersome (and error prone) to carry this out over email. GitHub gives us the added benefit of letting others follow along in the process. Best, Chris > On Sep 18, 2023, at 9:19 PM, rfc-editor@rfc-editor.org 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>. --> > > > 2) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 > of RFC 5743 have been adhered to in this document. --> > > > 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). > > 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 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. --> > > > 5) <!-- [rfced] Sections 4.1 through 4.4: We changed the artwork to > sourcecode with type="pseudocode" in these sections. > > 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 --> > > > 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). --> > > > 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]. > --> > > > 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. --> > > > 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. --> > > > 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]. --> > > > 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]. > > b) We don't see any mention of "PrepareIdentity" in Section 7.3. > Will this text and citation be clear to readers? > > 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]. --> > > > 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. > > 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." > > 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]. > > d) We do not see any mention of "FDH" or the word "full" in [RSA-FDH]. > Will this citation be clear to readers? > > 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>. --> > > > 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>. --> > > > 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/>. --> > > > 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. --> > > > 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. --> > > > 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 > > 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) > > c) Should "random prefix" in Section 4.5 be "message randomizer > prefix" or perhaps "msg_prefix"? --> > > > Thank you. > > RFC Editor/lb/ap > > > On Sep 18, 2023, at 6:18 PM, rfc-editor@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2023/09/18 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info/). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-editor@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9474.xml > https://www.rfc-editor.org/authors/rfc9474.html > https://www.rfc-editor.org/authors/rfc9474.pdf > https://www.rfc-editor.org/authors/rfc9474.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9474-diff.html > https://www.rfc-editor.org/authors/rfc9474-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9474-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9474 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9474 (draft-irtf-cfrg-rsa-blind-signatures-14) > > Title : RSA Blind Signatures > Author(s) : F. Denis, F. Jacobs, C. A. Wood > WG Chair(s) : > Area Director(s) : > >
- [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-cfrg-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Christopher Wood
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Christopher Wood
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Christopher Wood
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Lynne Bartholomew
- [auth48] *[Document Shepherd] Re: AUTH48: RFC-to-… Lynne Bartholomew
- Re: [auth48] *[Document Shepherd] Re: AUTH48: RFC… Stanislav V. Smyshlyaev
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Christopher Wood
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Christopher Wood
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Christopher Wood
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Frederic Jacobs
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Christopher Wood
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Frank Denis
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Christopher Wood
- Re: [auth48] AUTH48: RFC-to-be 9474 <draft-irtf-c… Lynne Bartholomew