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
