Hi Alanna Could you fix this? I am not sure if we need extra process but I approve with condition of the following change.
Old: SingleResponse.SingleExtensions New: SingleResponse.singleExtensions Regards Tadahiko 2026年2月4日(水) 2:56 Sean Turner <[email protected]>: > Yes! I believe it is! > > spt > > On Feb 3, 2026, at 12:45, Tadahiko Ito <[email protected]> > wrote: > > Hi all, and thank you very much for great catches, and sorry to replay > late. > I was almost approved, but let me confirm that. > > > SingleResponse.SingleExtensions > > isn't it "SingleResponse.singleExtensions" (lowercase letter s)? > > Regards Tadahiko Ito > > 2026年2月3日(火) 9:45 Alanna Paloma <[email protected]>: > >> Hi Clint, >> >> Your approval has been noted: >> https://www.rfc-editor.org/auth48/rfc9919 >> >> Once we’ve received Tadahiko’s approval, we will move this document >> forward in the publication process. >> >> Thank you, >> Alanna Paloma >> RFC Production Center >> >> > On Feb 2, 2026, at 12:38 PM, Clint Wilson <[email protected]> wrote: >> > >> > Hi Alanna, >> > >> > I have reviewed and approve this latest version of the document. >> > >> > Thank you! >> > -Clint >> > >> >> On Jan 30, 2026, at 2:39 PM, Alanna Paloma < >> [email protected]> wrote: >> >> >> >> Hi Authors, >> >> >> >> This is a friendly reminder that we await your reviews and approvals >> of the updated files prior to moving this document forward in the >> publication process. See the files below. >> >> >> >> The files have been posted here (please refresh): >> >> https://www.rfc-editor.org/authors/rfc9919.txt >> >> https://www.rfc-editor.org/authors/rfc9919.pdf >> >> https://www.rfc-editor.org/authors/rfc9919.html >> >> https://www.rfc-editor.org/authors/rfc9919.xml >> >> >> >> The relevant diff files are posted here: >> >> https://www.rfc-editor.org/authors/rfc9919-diff.html (comprehensive >> diff) >> >> https://www.rfc-editor.org/authors/rfc9919-auth48diff.html (all >> AUTH48 changes) >> >> https://www.rfc-editor.org/authors/rfc9919-lastdiff.html (htmlwdiff >> diff between last version and this) >> >> https://www.rfc-editor.org/authors/rfc9919-lastrfcdiff.html (rfcdiff >> between last version and this) >> >> >> >> Please review the document carefully as documents do not change once >> published as RFCs. >> >> >> >> We will await any further changes you may have and approvals from each >> author prior to moving forward in the publication process. >> >> >> >> Please see the AUTH48 status page for this document here: >> >> https://www.rfc-editor.org/auth48/rfc9919 >> >> >> >> Thank you, >> >> Alanna Paloma >> >> RFC Production Center >> >> >> >>> On Jan 23, 2026, at 11:34 AM, Alanna Paloma < >> [email protected]> wrote: >> >>> >> >>> Hi Roman, >> >>> >> >>> Thank you for your approval. We’ve noted it on the AUTH48 status page: >> >>> https://www.rfc-editor.org/auth48/rfc9919 >> >>> >> >>> Best regards, >> >>> Alanna Paloma >> >>> RFC Production Center >> >>> >> >>>> On Jan 23, 2026, at 11:25 AM, Roman Danyliw <[email protected]> wrote: >> >>>> >> >>>> Approved. >> >>>> >> >>>> -----Original Message----- >> >>>> From: Alanna Paloma <[email protected]> >> >>>> Sent: Thursday, January 22, 2026 12:45 PM >> >>>> To: Deb Cooley <[email protected]>; Sean Turner <[email protected]>; >> Corey Bonnell <[email protected]>; Clint Wilson < >> [email protected]> >> >>>> Cc: RFC Editor <[email protected]>; >> [email protected]; [email protected]; [email protected]; >> Roman Danyliw <[email protected]>; Russ Housley <[email protected]>; >> auth48archive <[email protected]> >> >>>> Subject: [AD] Re: AUTH48: RFC-to-be 9919 >> <draft-ietf-lamps-rfc5019bis-12> for your review >> >>>> >> >>>> Warning: External Sender - do not click links or open attachments >> unless you recognize the sender and know the content is safe. >> >>>> >> >>>> >> >>>> Authors and Deb*, >> >>>> >> >>>> *Deb - As the AD, please review and approve of the following removed >> text in Section 3.2.3: >> >>>> >> >>>> As such, this profile extends >> >>>> the [RFC6960] definition of "unauthorized" as follows: >> >>>> >> >>>> The response "unauthorized" is returned in cases where the client is >> >>>> not authorized to make this query to this responder or the responder >> >>>> is not capable of responding authoritatively. >> >>>> >> >>>> See this diff file: >> >>>> https://www.rfc-editor.org/authors/rfc9919-auth48diff.html >> >>>> >> >>>> >> >>>> Authors - Thank you for your responses and for confirming those >> updates. We have updated the files accordingly. >> >>>> >> >>>> The files have been posted here (please refresh): >> >>>> https://www.rfc-editor.org/authors/rfc9919.txt >> >>>> https://www.rfc-editor.org/authors/rfc9919.pdf >> >>>> https://www.rfc-editor.org/authors/rfc9919.html >> >>>> https://www.rfc-editor.org/authors/rfc9919.xml >> >>>> >> >>>> The relevant diff files are posted here: >> >>>> https://www.rfc-editor.org/authors/rfc9919-diff.html (comprehensive >> diff) >> >>>> https://www.rfc-editor.org/authors/rfc9919-auth48diff.html (all >> AUTH48 changes) >> >>>> https://www.rfc-editor.org/authors/rfc9919-lastdiff.html (htmlwdiff >> diff between last version and this) >> >>>> https://www.rfc-editor.org/authors/rfc9919-lastrfcdiff.html >> (rfcdiff between last version and this) >> >>>> >> >>>> Please review the document carefully as documents do not change once >> published as RFCs. >> >>>> >> >>>> We will await any further changes you may have and approvals from >> each author and *Deb prior to moving forward in the publication process. >> >>>> >> >>>> Please see the AUTH48 status page for this document here: >> >>>> https://www.rfc-editor.org/auth48/rfc9919 >> >>>> >> >>>> Thank you, >> >>>> Alanna Paloma >> >>>> RFC Production Center >> >>>> >> >>>> >> >>>>> On Jan 22, 2026, at 6:35 AM, Clint Wilson <[email protected]> wrote: >> >>>>> >> >>>>> These changes all look great to me (some really nice catches in >> here too, fwiw). Thank you all for working on this draft! >> >>>>> >> >>>>>> On Jan 21, 2026, at 8:32 AM, Sean Turner <[email protected]> wrote: >> >>>>>> >> >>>>>> Okay on to the detailed review - co-authors please double check: >> >>>>>> >> >>>>>> 1) s3.1.1: There is no “RequestList” it’s “requestList” >> >>>>>> >> >>>>>> OLD: >> >>>>>> OCSPRequest.RequestList >> >>>>>> NEW: >> >>>>>> OCSPRequest.requestList >> >>>>>> 2) s3.2.1: bump dash >> >>>>>> OLD: >> >>>>>> ... the id- >> >>>>>> pkix-ocsp-basic OID. >> >>>>>> NEW: >> >>>>>> ... the >> >>>>>> id-pkix-ocsp-basic OID. >> >>>>>> >> >>>>>> >> >>>>>> 3) s3.2.1: use elements instead of SingleResponses >> >>>>>> OLD: >> >>>>>> two SingleResponses in a BasicOCSPResponse >> >>>>>> NEW: >> >>>>>> two SingleResponse elements in a BasicOCSPResponse >> >>>>>> OLD: >> >>>>>> the CertID of one of the SingleResponses uses >> >>>>>> NEW: >> >>>>>> the CertID of one of the SingleResponse structures uses >> >>>>>> 4) s3.2.1: Refer to correct extension structure >> >>>>>> OLD: >> >>>>>> The responder MAY include the singleResponse.singleResponse >> >>>>>> extensions structure. >> >>>>>> NEW: >> >>>>>> The responder MAY include the SingleResponse.SingleExtensions >> >>>>>> extensions structure. >> >>>>>> 5) s3.2.3: Do we still extend the definition of unauthorized? >> >>>>>> >> >>>>>> In 5019, the definition of unauthorized was extended. RFC 6960 was >> updated to match the definitions in RFC 5019. So can we drop this bit of >> text: >> >>>>>> As such, this profile extends >> >>>>>> the [RFC6960] definition of "unauthorized" as follows: >> >>>>>> >> >>>>>> The response "unauthorized" is returned in cases where the client >> is >> >>>>>> not authorized to make this query to this responder or the >> responder >> >>>>>> is not capable of responding authoritatively. >> >>>>>> 6) s8.2: rename title >> >>>>>> >> >>>>>> OLD: >> >>>>>> >> >>>>>> 8.2. Man-in-the-Middle Attacks >> >>>>>> NEW: >> >>>>>> 8.2. On-Path Attacks >> >>>>>> >> >>>>>> Cheers, >> >>>>>> spt >> >>>>>> >> >>>>>>> On Jan 21, 2026, at 10:48, Alanna Paloma < >> [email protected]> wrote: >> >>>>>>> >> >>>>>>> Hi Sean and Clint, >> >>>>>>> >> >>>>>>> Thank you for confirming those two remaining questions. We have >> updated the document accordingly. >> >>>>>>> >> >>>>>>> The files have been posted here (please refresh): >> >>>>>>> https://www.rfc-editor.org/authors/rfc9919.xml >> >>>>>>> https://www.rfc-editor.org/authors/rfc9919.txt >> >>>>>>> https://www.rfc-editor.org/authors/rfc9919.html >> >>>>>>> https://www.rfc-editor.org/authors/rfc9919.pdf >> >>>>>>> >> >>>>>>> The relevant diff files have been posted here: >> >>>>>>> https://www.rfc-editor.org/authors/rfc9919-diff.html >> (comprehensive >> >>>>>>> diff) https://www.rfc-editor.org/authors/rfc9919-auth48diff.html >> >>>>>>> (AUTH48 changes) >> >>>>>>> https://www.rfc-editor.org/authors/rfc9919-auth48rfcdiff.html >> >>>>>>> (AUTH48 changes side by side) >> >>>>>>> >> >>>>>>> We will await approvals from each author prior to moving this >> document forward in the publication process. >> >>>>>>> >> >>>>>>> See here for the AUTH48 status page of this document: >> >>>>>>> https://www.rfc-editor.org/auth48/rfc9919 >> >>>>>>> >> >>>>>>> Thank you, >> >>>>>>> Alanna Paloma >> >>>>>>> RFC Production Center >> >>>>>>> >> >>>>>>>> On Jan 21, 2026, at 5:40 AM, Sean Turner <[email protected]> wrote: >> >>>>>>>> >> >>>>>>>> Clint, >> >>>>>>>> >> >>>>>>>> Thanks for confirming! >> >>>>>>>> >> >>>>>>>> spt >> >>>>>>>> >> >>>>>>>>> On Jan 20, 2026, at 17:39, Clint Wilson <[email protected]> >> wrote: >> >>>>>>>>> >> >>>>>>>>> The proposed update for #9 seems correct to me. I don’t think >> it’s likely for the direct document link to become outdated in the >> foreseeable future (it appears to have been stable for at least several >> years). >> >>>>>>>>> >> >>>>>>>>> Thank you! >> >>>>>>>>> -Clint >> >>>>>>>>> >> >>>>>>>>>> On Jan 20, 2026, at 1:51 PM, Sean Turner <[email protected]> >> wrote: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>> On Jan 20, 2026, at 14:58, Alanna Paloma < >> [email protected]> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> Hi Sean, >> >>>>>>>>>>> >> >>>>>>>>>>> Thank you for your reply. We have updated as requested. >> >>>>>>>>>>> >> >>>>>>>>>>> Please note that we are awaiting for these two queries to be >> confirmed: >> >>>>>>>>>>> >> >>>>>>>>>>>>> 9) <!-- [rfced] We were unable to find a document directly >> >>>>>>>>>>>>> matching the title provided in the original reference. The >> URL >> >>>>>>>>>>>>> provided goes to the homepage for the Open Mobile Alliance. >> We >> >>>>>>>>>>>>> did find the following URL, which points to the OCSP Mobile >> Profile: >> >>>>>>>>>>>>> >> https://www.openmobilealliance.org/release/OCSP/V1_0-20040127- >> >>>>>>>>>>>>> C/OMA-WAP-OCSP-V1_0-20040127-C.pdf >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> May we update this reference as follows? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> [OCSPMP] Open Mobile Alliance, "OCSP Mobile Profile V1.0", >> >>>>>>>>>>>>> www.openmobilealliance.org . >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Perhaps: >> >>>>>>>>>>>>> [OCSPMP] Open Mobile Alliance, "Online Certificate Status >> >>>>>>>>>>>>> Protocol Mobile Profile", Candidate Version V1.0, 27 >> January >> >>>>>>>>>>>>> 2004, < >> https://www.openmobilealliance.org/release/OCSP/V1_0-20040127-C/OMA-WAP-OCSP-V1_0-20040127-C.pdf >> >. >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> I will defer to my co-authors on this one. >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 10) <!-- [rfced] Please review the "type" attribute of each >> >>>>>>>>>>>>> sourcecode element in the XML file to ensure correctness. >> If >> >>>>>>>>>>>>> the current list of preferred values for "type" >> >>>>>>>>>>>>> ( >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-ty >> >>>>>>>>>>>>> pes) does not contain an applicable type, then feel free to >> >>>>>>>>>>>>> let us know. >> >>>>>>>>>>>>> Also, it is acceptable to leave the "type" attribute not >> set. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> In addition, review each artwork element. Specifically, >> should >> >>>>>>>>>>>>> any artwork element be tagged as sourcecode or another >> >>>>>>>>>>>>> element? >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> I will put this on my to do list ;) >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> I was being sooo slow. I pulled the xml and the three ASN.1 >> code blocks include the correct tag: >> >>>>>>>>>> >> >>>>>>>>>> <sourcecode type="asn.1”> >> >>>>>>>>>> >> >>>>>>>>>> I believe then we are awaiting my co-auhors response on #9! >> >>>>>>>>>> >> >>>>>>>>>> spt >> >>>>>>>>>> >> >>>>>>>>>>> The files have been posted here (please refresh): >> >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919.xml >> >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919.txt >> >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919.html >> >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919.pdf >> >>>>>>>>>>> >> >>>>>>>>>>> The relevant diff files have been posted here: >> >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919-diff.html >> >>>>>>>>>>> (comprehensive diff) >> >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919-auth48diff.html >> >>>>>>>>>>> (AUTH48 changes) >> >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919-auth48rfcdiff.html >> >>>>>>>>>>> (AUTH48 changes side by side) >> >>>>>>>>>>> >> >>>>>>>>>>> Please review the document carefully and contact us with any >> further updates you may have. Note that we do not make changes once a >> document is published as an RFC. >> >>>>>>>>>>> >> >>>>>>>>>>> We will await approvals from each party listed on the AUTH48 >> status page below prior to moving this document forward in the publication >> process. >> >>>>>>>>>>> >> >>>>>>>>>>> For the AUTH48 status of this document, please see: >> >>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9919 >> >>>>>>>>>>> >> >>>>>>>>>>> Thank you, >> >>>>>>>>>>> Alanna Paloma >> >>>>>>>>>>> RFC Production Center >> >>>>>>>>>>> >> >>>>>>>>>>>> On Jan 20, 2026, at 7:39 AM, Sean Turner <[email protected]> >> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> Hi! >> >>>>>>>>>>>> >> >>>>>>>>>>>>> On Jan 16, 2026, at 13:46, [email protected] wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Authors, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> While reviewing this document during AUTH48, please resolve >> (as necessary) the following questions, which are also in the source file. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> 1) <!--[rfced] Please note 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: >> >>>>>>>>>>>>> Updates to Lightweight OCSP Profile for High Volume >> >>>>>>>>>>>>> Environments >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Current: >> >>>>>>>>>>>>> Updates to the Lightweight Online Certificate Status >> Protocol >> >>>>>>>>>>>>> (OCSP) Profile for High Volume Environments >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Because this document will obsolete RFC 5019 (rather than >> >>>>>>>>>>>>> update it), we suggest changing the title and abbreviated >> title as follows. Is this acceptable? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> Updates to Lightweight OCSP Profile for High Volume >> >>>>>>>>>>>>> Environments >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Perhaps (same title as RFC 5019): >> >>>>>>>>>>>>> The Lightweight Online Certificate Status Protocol (OCSP) >> >>>>>>>>>>>>> Profile for High-Volume Environments >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Similarly, may the abbreviated title (which appears in the >> >>>>>>>>>>>>> running header of the PDF) be updated as follows? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> Lightweight OCSP Profile Update >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Perhaps: >> >>>>>>>>>>>>> Lightweight OCSP Profile >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Yes, since we’re obsoleting it there’s no need for the >> “Updates to” / “Update” words. >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those >> that >> >>>>>>>>>>>>> appear in the title) for use on >> >>>>>>>>>>>>> https://www.rfc-editor.org/search. --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Revocation >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 3) <!--[rfced] FYI, we changed "RECOMMENDS" to "is >> RECOMMENDED >> >>>>>>>>>>>>> by" (2 instances), as "RECOMMENDED" is the defined keyword >> >>>>>>>>>>>>> from BCP 14. This update allows using the <bcp14> element >> >>>>>>>>>>>>> without warnings. We realize the original text matches RFC >> 5019. For example: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> Clients SHOULD NOT include the requestExtensions structure. >> If >> >>>>>>>>>>>>> a requestExtensions structure is included, this profile >> >>>>>>>>>>>>> RECOMMENDS that it contain only the nonce extension >> (id-pkix-ocsp-nonce). >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Current: >> >>>>>>>>>>>>> Clients SHOULD NOT include the requestExtensions structure. >> If >> >>>>>>>>>>>>> a requestExtensions structure is included, it is >> RECOMMENDED >> >>>>>>>>>>>>> by this profile that the structure contain only the nonce >> >>>>>>>>>>>>> extension (id-pkix- ocsp-nonce). >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> WFM >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 4) <!--[rfced] Is this line within the sourcecode in >> Section >> >>>>>>>>>>>>> 3.2.1 intended to be a comment within the sourcecode, or >> >>>>>>>>>>>>> should it be taken out of the sourcecode? (Note: This line >> >>>>>>>>>>>>> exceeded the 72-character limit so we included a line break >> >>>>>>>>>>>>> within the sourcecode.) >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> The value for response SHALL be the DER encoding of >> BasicOCSPResponse. >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> This sentence should be taken out of the source code, so I >> guess that means there’s two blocks of source code. >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 5) <!--[rfced] May we update this sentence as follows to >> >>>>>>>>>>>>> clarify that the protocol in [RFC5019] is backward >> compatible, rather than the RFC itself? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> Older responders which provide backward compatibility with >> >>>>>>>>>>>>> [RFC5019] MAY use the byName field to represent the >> >>>>>>>>>>>>> ResponderID, but should transition to using the byKey field >> as soon as practical. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Perhaps: >> >>>>>>>>>>>>> Older responders that provide backward compatibility with >> the >> >>>>>>>>>>>>> protocol defined in [RFC5019] MAY use the byName field to >> >>>>>>>>>>>>> represent the ResponderID but should transition to using >> the byKey field as soon as practical. >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Yes >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 6) <!--[rfced] We are having some trouble understanding how >> >>>>>>>>>>>>> "server name and base64-encoded OCSPRequest structure" fits >> >>>>>>>>>>>>> into the sentence below. Please review and let us know the >> sentence may be updated for clarity. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> When sending requests that are less than or equal to 255 >> bytes >> >>>>>>>>>>>>> in total (after encoding) including the scheme and >> delimiters >> >>>>>>>>>>>>> (http://), server name and base64-encoded OCSPRequest >> >>>>>>>>>>>>> structure, clients MUST use the GET method (to enable OCSP >> >>>>>>>>>>>>> response caching). >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Perhaps: >> >>>>>>>>>>>>> When sending requests that are less than or equal to 255 >> bytes >> >>>>>>>>>>>>> in total (after encoding), including the scheme and >> delimiters >> >>>>>>>>>>>>> (http://), server name, and base64-encoded OCSPRequest >> >>>>>>>>>>>>> structure, clients MUST use the GET method (to enable OCSP >> >>>>>>>>>>>>> response caching). >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> I think that’s right. The 255 bytes needs to include >> everything that is listed there. >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 7) <!--[rfced] Should "productedAt" be "producedAt" (no >> 't')? >> >>>>>>>>>>>>> Even though RFC 5019 contains one instance of >> "productedAt", >> >>>>>>>>>>>>> it contains seven instances of "producedAt". We note that >> >>>>>>>>>>>>> other RFCs also use "producedAt" (e.g., RFCs 9654, 6960, >> 5912). >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> productedAt = March 19, 2023 01:00:00 GMT >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Suggested: >> >>>>>>>>>>>>> producedAt = March 19, 2023 01:00:00 GMT >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> GREAT CATCH! >> >>>>>>>>>>>> >> >>>>>>>>>>>> Definitely needs to be “producedAt”! >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 8) <!--[rfced] May this sentence be updated as follows to >> >>>>>>>>>>>>> avoid citing RFC 9846 twice? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> This functionality has been specified as an extension to >> the >> >>>>>>>>>>>>> TLS [I-D.ietf-tls-rfc8446bis] protocol in Section 4.4.2 of >> >>>>>>>>>>>>> [I-D.ietf-tls-rfc8446bis], but can be applied to any >> >>>>>>>>>>>>> client-server protocol. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Current: >> >>>>>>>>>>>>> This functionality has been specified as an extension to >> the >> >>>>>>>>>>>>> TLS protocol [RFC9846] in Section 4.4.2 of [RFC9846] but >> can >> >>>>>>>>>>>>> be applied to any client-server protocol. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Option A: >> >>>>>>>>>>>>> This functionality has been specified as an extension to >> the >> >>>>>>>>>>>>> TLS protocol in Section 4.4.2 of [RFC9846] but can be >> applied >> >>>>>>>>>>>>> to any client-server protocol. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Option B: >> >>>>>>>>>>>>> In Section 4.4.2 of [RFC9846], this functionality has been >> >>>>>>>>>>>>> specified as an extension to the TLS protocol, but it can >> be >> >>>>>>>>>>>>> applied to any client-server protocol. >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> I prefer option A. >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 9) <!-- [rfced] We were unable to find a document directly >> >>>>>>>>>>>>> matching the title provided in the original reference. The >> URL >> >>>>>>>>>>>>> provided goes to the homepage for the Open Mobile Alliance. >> We >> >>>>>>>>>>>>> did find the following URL, which points to the OCSP Mobile >> Profile: >> >>>>>>>>>>>>> >> https://www.openmobilealliance.org/release/OCSP/V1_0-20040127- >> >>>>>>>>>>>>> C/OMA-WAP-OCSP-V1_0-20040127-C.pdf >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> May we update this reference as follows? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> [OCSPMP] Open Mobile Alliance, "OCSP Mobile Profile V1.0", >> >>>>>>>>>>>>> www.openmobilealliance.org . >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Perhaps: >> >>>>>>>>>>>>> [OCSPMP] Open Mobile Alliance, "Online Certificate Status >> >>>>>>>>>>>>> Protocol Mobile Profile", Candidate Version V1.0, 27 >> January >> >>>>>>>>>>>>> 2004, < >> https://www.openmobilealliance.org/release/OCSP/V1_0-20040127-C/OMA-WAP-OCSP-V1_0-20040127-C.pdf >> >. >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> I will defer to my co-authors on this one. >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 10) <!-- [rfced] Please review the "type" attribute of each >> >>>>>>>>>>>>> sourcecode element in the XML file to ensure correctness. >> If >> >>>>>>>>>>>>> the current list of preferred values for "type" >> >>>>>>>>>>>>> ( >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-ty >> >>>>>>>>>>>>> pes) does not contain an applicable type, then feel free to >> >>>>>>>>>>>>> let us know. >> >>>>>>>>>>>>> Also, it is acceptable to leave the "type" attribute not >> set. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> In addition, review each artwork element. Specifically, >> should >> >>>>>>>>>>>>> any artwork element be tagged as sourcecode or another >> >>>>>>>>>>>>> element? >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> I will put this on my to do list ;) >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 11) <!--[rfced] Should instances of "OCSP protocol" be >> updated >> >>>>>>>>>>>>> to simply "OCSP" to avoid redundancy (if expanded, "OCSP >> >>>>>>>>>>>>> protocol" would read "Online Certificate Status Protocol >> >>>>>>>>>>>>> protocol")? Please review and let us know if any updates >> are needed. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Original: >> >>>>>>>>>>>>> Future versions of the OCSP protocol may provide a way for >> the >> >>>>>>>>>>>>> client to know whether the responder supports nonces or >> does >> >>>>>>>>>>>>> not support nonces. >> >>>>>>>>>>>>> ... >> >>>>>>>>>>>>> The authors of this version of the document wish to thank >> Alex >> >>>>>>>>>>>>> Deacon and Ryan Hurst for their work to produce the >> original >> >>>>>>>>>>>>> version of the lightweight profile for the OCSP protocol. >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Yes please drop the extra “protocol” where appropriate. >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 12) <!--[rfced] Abbreviations >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> a) Both the expansion and the acronym for the following >> term >> >>>>>>>>>>>>> are used throughout the document. Would you like to update >> to >> >>>>>>>>>>>>> using the expansion upon first usage and the acronym for >> the rest of the document? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> certification authority (CA) >> >>>>>>>>>>>> >> >>>>>>>>>>>> I am happy with that. >> >>>>>>>>>>>> >> >>>>>>>>>>>>> b) We note that "AIA" has been expanded two different ways >> in the document. >> >>>>>>>>>>>>> Please review and let us know which version should be used >> for consistency. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> authorityInfoAccess (AIA) vs. authorityInformationAccess >> (AIA) >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> So this is a bit weird maybe: >> >>>>>>>>>>>> >> >>>>>>>>>>>> s3.2.2: >> >>>>>>>>>>>> >> >>>>>>>>>>>> OLD: >> >>>>>>>>>>>> >> >>>>>>>>>>>> authorityInfoAccess >> >>>>>>>>>>>> (AIA) extension nor cRLDistributionPoints (CRLDP) extension >> >>>>>>>>>>>> >> >>>>>>>>>>>> NEW: >> >>>>>>>>>>>> >> >>>>>>>>>>>> Authority Information Access >> >>>>>>>>>>>> (AIA) extension nor CRL Distribution Points (CRLDP) extension >> >>>>>>>>>>>> >> >>>>>>>>>>>> S4.1: >> >>>>>>>>>>>> >> >>>>>>>>>>>> OLD: >> >>>>>>>>>>>> >> >>>>>>>>>>>> authorityInfoAccess extension >> >>>>>>>>>>>> >> >>>>>>>>>>>> NEW: >> >>>>>>>>>>>> >> >>>>>>>>>>>> AIA extension >> >>>>>>>>>>>> >> >>>>>>>>>>>> OLD: >> >>>>>>>>>>>> >> >>>>>>>>>>>> authorityInformationAccess (AIA) extension >> >>>>>>>>>>>> cRLDistributionPoints extension >> >>>>>>>>>>>> >> >>>>>>>>>>>> NEW: >> >>>>>>>>>>>> >> >>>>>>>>>>>> AIA extension >> >>>>>>>>>>>> CRLDP extension >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>>> 13) <!-- [rfced] Please review the "Inclusive Language" >> >>>>>>>>>>>>> portion of the online Style Guide >> >>>>>>>>>>>>> < >> https://www.rfc-editor.org/styleguide/part2/#inclusive_langua >> >>>>>>>>>>>>> ge> and let us know if any changes are needed. Updates of >> >>>>>>>>>>>>> this nature typically result in more precise language, >> which >> >>>>>>>>>>>>> is helpful for readers. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> For example, please consider whether "man-in-the-middle" >> should be updated. >> >>>>>>>>>>>>> --> >> >>>>>>>>>>>> >> >>>>>>>>>>>> I am fine with changing it to on-path if my co-authors are. >> >>>>>>>>>>>> >> >>>>>>>>>>>> spt >> >>>>>>>>>>>> >> >>>>>>>>>>>>> Thank you. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Alanna Paloma and Alice Russo >> >>>>>>>>>>>>> RFC Production Center >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On Jan 16, 2026, at 10:45 AM, [email protected] >> wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> *****IMPORTANT***** >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Updated 2026/01/16 >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> 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 >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> * [email protected] (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). >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> * [email protected], 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-4 >> >>>>>>>>>>>>> Q9l2USxIAe6P8O4Zc >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> * 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, >> >>>>>>>>>>>>> [email protected] 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/rfc9919.xml >> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919.html >> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919.pdf >> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919.txt >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Diff file of the text: >> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919-diff.html >> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919-rfcdiff.html >> (side >> >>>>>>>>>>>>> by side) >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Diff of the XML: >> >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919-xmldiff1.html >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Tracking progress >> >>>>>>>>>>>>> ----------------- >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> The details of the AUTH48 status of your document are here: >> >>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9919 >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Please let us know if you have any questions. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Thank you for your cooperation, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> RFC Editor >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> -------------------------------------- >> >>>>>>>>>>>>> RFC9919 (draft-ietf-lamps-rfc5019bis-12) >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Title : Updates to Lightweight OCSP Profile for >> High Volume Environments >> >>>>>>>>>>>>> Author(s) : T. Ito, C. Wilson, C. Bonnell, S. Turner >> >>>>>>>>>>>>> WG Chair(s) : Russ Housley, Tim Hollebeek >> >>>>>>>>>>>>> Area Director(s) : Deb Cooley, Paul Wouters >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> > >> >> >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
