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