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]
