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]
