Hi Daniel, Thank you for responding to our questions. We updated the document accordingly (see files below).
We have a followup question. We replaced the [X9.62] reference with [SEC1] and also updated "[X9.62] Annex A” to "Section 2.3.3 of [SEC1]” as you suggest. Are any updates needed for “X9.62” in the following sentence? Section 3.2 of RFC 8292 does mention "X9.62 encoding”. Current: Additionally, as noted in Section 3.2 of [RFC8292], the X9.62 encoding simplifies key comparisons and is more compact than alternative formats. — FILES (please refresh) — Updated XML file: https://www.rfc-editor.org/authors/rfc9749.xml Updated output files: https://www.rfc-editor.org/authors/rfc9749.txt https://www.rfc-editor.org/authors/rfc9749.pdf https://www.rfc-editor.org/authors/rfc9749.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9749-auth48diff.html https://www.rfc-editor.org/authors/rfc9749-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9749-diff.html https://www.rfc-editor.org/authors/rfc9749-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9749 Thank you, RFC Editor/rv > On Mar 7, 2025, at 3:49 AM, Daniel Gultsch <dan...@gultsch.de> wrote: > > On Thu, Mar 6, 2025 at 2:22 AM <rfc-edi...@rfc-editor.org> wrote: > >> 1) <!-- [rfced] Please note that the title of the document has been updated >> as >> follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC >> Style Guide"). Please review. >> >> Original: >> Use of VAPID in JMAP WebPush >> >> Current: >> Use of Voluntary Application Server Identification (VAPID) in JSON Meta >> Application Protocol (JMAP) WebPush >> --> > > ACK > >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. --> > > add > > <keyword>WebPush</keyword> > > >> 3) <!-- [rfced] Will readers understand what "it" refers to here? >> >> Original: >> To facilitate that, the >> client (or user agent in WebPush terminology) needs the VAPID public >> key of the application server to pass it along to the push service >> when retrieving a new endpoint. >> >> Perhaps (remove "it"): >> To facilitate that, the >> client (or user agent in WebPush terminology) needs the VAPID public >> key of the application server to pass along to the push service >> when retrieving a new endpoint. > > Please go with that variant > >> 4) <!-- [rfced] FYI - We updated these sentences as follows (pointed to >> Section >> 4.2 of [RFC8292] in both and updated phrasing relating to the status code >> to be consistent). Let us know any concerns. >> >> Original: >> Consequently, the push >> service will reject the PushVerification with a 403 (Forbidden) >> status code, as specified in [RFC8292]. >> ... >> This mismatch leads to the push service rejecting the >> PushVerification request with HTTP status code 403, as specified in >> [RFC8292], Section 4.2. >> >> Updated: >> Consequently, the push >> service will reject the PushVerification with a 403 (Forbidden) >> status code, as specified in Section 4.2 of [RFC8292]. >> ... >> This mismatch leads to the push service rejecting the >> PushVerification request with a 403 (Forbidden) status code, as specified >> in >> Section 4.2 of [RFC8292]. >> --> > > ACK > >> 5) <!-- [rfced] Would you like the references to be alphabetized or left in >> their >> current order? >> --> > > The current order is fine. > >> 6) <!-- [rfced] The following reference has been withdrawn. See >> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf. Would you >> like to cite the latest version (i.e., FIPS 186-5)? >> >> Original: >> [FIPS186] National Institute of Standards and Technology (NIST), >> "Digital Signature Standard (DSS)", FIPS 186-4, July 2013, >> <https://doi.org/10.6028/NIST.FIPS.186-4>. >> >> Perhaps: >> [FIPS186] NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5, >> February 2023, <https://doi.org/10.6028/NIST.FIPS.186-5>. >> --> > > Yes. > >> 7) <!-- [rfced] The following reference has been replaced by ANSI X9.142 >> (and X9.62 >> seems to no longer be available on the ANSI webstore). >> >> See: >> https://x9.org/asc-x9-issues-new-standard-for-public-key-cryptography-ecdsa/ >> https://webstore.ansi.org/standards/ascx9/ansix91422020 >> >> Would you like to cite X9.142-2020 in this document? >> >> Original: >> [X9.62] American National Standards Institute, "Public Key >> Cryptography for the Financial Services Industry: The >> Elliptic Curve Digital Signature Algorithm (ECDSA)", >> ANSI X9.62-2005, November 2005. >> >> Perhaps: >> [X9.142] American National Standards Institute, "Financial services - >> Public >> Key Cryptography for the Financial Services Industry - The >> Elliptic >> Curve Digital Signature Algorithm - ECDSA", ANSI X9.142-2020, >> September 2020. >> >> >> If this change is made, please confirm that Annex A appears in X9.142-2020 >> with the information in the following sentence. We are unable to access the >> full document to verify (it is behind a paywall). >> >> Original: >> The ECDSA public key that the push service will use to >> authenticate the application server, in its uncompressed form (as >> described in [X9.62] Annex A) and encoded using base64url encoding >> [RFC7515]. >> --> > > Please change the reference to > > [SEC1] Standards for Efficient Cryptography Group, "SEC 1: > Elliptic Curve Cryptography", Version 2.0, May 2009, > <http://www.secg.org/sec1-v2.pdf>. > > Specifically Section 2.3.3 of that document. > > This describes the same format and is not behind a paywall. > >> 8) <!-- [rfced] Should the following be tagged as <dl> rather than >> <ul> with a single bullet? To see what <dl> looks like, please see Section 3 >> in these test files: >> >> https://www.rfc-editor.org/authors/rfc9749-TEST.txt >> https://www.rfc-editor.org/authors/rfc9749-TEST.html >> >> Original: >> * applicationServerKey: "String" >> >> The ECDSA public key that the push service will use to >> authenticate the application server, in its uncompressed form (as >> described in [X9.62] Annex A) and encoded using base64url encoding >> [RFC7515]. Current systems use the P-256 curve [FIPS186]. >> --> > > Yes, please use <dl> > >> 9) <!-- [rfced] Should the Informative Note in Section 3 be in the <aside> >> element? The aside element is defined as "a container for content that is >> semantically less important or tangential to the content that surrounds >> it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >> --> > > Yes. please use <aside> > >> 10) <!-- [rfced] We see inconsistent use of <tt> in this document. Please >> review >> the notes below and let us know how to update for consistency. In the >> html and pdf outputs, the text enclosed in <tt> is output in fixed-width >> font; in the txt output, there are no changes to the font. >> >> a) This term appears with twice with <tt> and once with quotation marks: >> >> <tt>urn:ietf:params:jmap:webpush-vapid</tt> >> "urn:ietf:params:jmap:webpush-vapid" >> >> >> b) This term appears once with <tt> and six times without <tt>: >> >> <tt>PushSubscription</tt> >> PushSubscription >> >> Also, consider if the following should be handled in the same way as >> PushSubscription; currently, these do not have <tt>. >> >> PushVerification >> StateChange >> sessionState >> applicationServerKey >> >> >> c) These terms have a similar structure, but one appears with <tt> and one >> without (one instance of each). We recommend consistent handling. >> >> <tt>PushSubscription/changes</tt> >> >> PushSubscription/set >> --> > > Please use <tt> in all of the mentioned cases. > >> 11) <!-- [rfced] This document consistently uses "WebPush" (single word with >> no >> space). We see use of both "WebPush" (single word) and "Web Push" (two >> words) in past RFCs. See the notes below and let us know if you would >> like to leave the single-word form in this document or make a change. >> >> RFC 8030 - uses two-word form in title of "Web Push Identifiers" registry, >> but >> also uses one-word form in a couple of instances (i.e., "WebPush scenarios" >> and "WebPush Architecture"). >> >> RFC 8291 - uses both forms (seems the two-word form is used in prose and the >> one-word form is used in code). >> >> RFC 8292 - uses the two-word form in document title and in the context of >> "Web >> Push protocol". >> >> The only RFCs with this term in the document title are RFCs 8291 and 8292, >> and >> both use "Web Push" (two words). See >> https://www.rfc-editor.org/rfc-index.txt. >> --> > > Please use the two word "Web Push" then. I’ve added a keyword > "WebPush" (see above) so it shows up in searches. > >> 12) <!-- [rfced] FYI - We have added expansions for the following >> abbreviations >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> expansion in the document carefully to ensure correctness. >> >> Voluntary Application Server Identification (VAPID) >> JSON Meta Application Protocol (JMAP) >> JSON Web Token (JWT) >> Elliptic Curve Digital Signature Algorithm (ECDSA) >> --> > > I have reviewed these and they are correct. > >> 13) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online Style Guide >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let >> us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> > > ACK > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
