Hi Corey and Sean, Thank you for your approvals. They have been noted on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9919
Best regards, Alanna Paloma RFC Production Center > On Feb 2, 2026, at 9:26 AM, Sean Turner <[email protected]> wrote: > > Hi Alanna, > > I have reviewed and approve publication! > > Clint and Ito-san it’s down to you two ;) > > Cheers, > spt > >> On Feb 2, 2026, at 08:18, Corey Bonnell <[email protected]> wrote: >> >> Hi Alanna, >> Thank you for providing the latest version of the document. I have reviewed >> and approve publication. >> >> Thanks, >> Corey >> >> -----Original Message----- >> From: Alanna Paloma <[email protected]> >> Sent: Friday, January 30, 2026 5:40 PM >> To: [email protected]; Clint Wilson <[email protected]>; Corey >> Bonnell <[email protected]>; Sean Turner <[email protected]> >> Cc: Roman Danyliw <[email protected]>; Deb Cooley <[email protected]>; RFC >> Editor <[email protected]>; [email protected]; >> [email protected]; Russ Housley <[email protected]>; auth48archive >> <[email protected]> >> Subject: Re: AUTH48: RFC-to-be 9919 <draft-ietf-lamps-rfc5019bis-12> for >> your review >> >> 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-2004012 >>>>>>>>>>>>> 7- 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-2004012 >>>>>>>>>>>>> 7- 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_lang >>>>>>>>>>>>> ua >>>>>>>>>>>>> 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]
