I-D list for Secure Telephone Identity Revisited RSS Feed

OCSP Usage for Secure Telephone Identity Certificates

2026-02-19T15:09:27.162628+00:00

IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation

OCSP Usage for Secure Telephone Identity Certificates

2026-02-18T17:04:04.994212+00:00

[Ballot discuss]
I also have what I think is a minor issue to address.

Normally with OCSP, there is a concept of "hard fail" vs "soft fail", as the action for what to do when one fails to reach the OCSP server (or fails to update a staple entry). It is unclear to me what the expected behaviour is in this ecosystem, when the OCSP has been unavailable for such a time that pregenerated staples have expired. Does one just omit the OCSP staple and let the requester judge the lack of staple? Does one refuse the call? Mark it has "potential spam" ? How is one client expected to respond when it sees no OCSP staple? Would it attempt to connect to the OCSP server's Distribution Point itself? What if that fails? Would a client treat a response differently if it used to get OCSP information from a server, but suddenly doesn't, versus a server that has never sent OCSP staples.

Perhaps a short paragraph in the Security Considerations Section could clarify this.

OCSP Usage for Secure Telephone Identity Certificates

2026-02-18T17:04:04.994130+00:00

[Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters

OCSP Usage for Secure Telephone Identity Certificates

2026-02-18T02:03:43.992905+00:00

[Ballot comment]
Thank you to Vijay Gurbani for the GENART review.

OCSP Usage for Secure Telephone Identity Certificates

2026-02-18T02:03:43.992821+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw

OCSP Usage for Secure Telephone Identity Certificates

2026-02-17T15:43:08.137344+00:00

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

I have a few comments to share and hope it improves the document.

1) Abstract: s/Certififcate Revocation Lists/Certificate Revocation Lists

2) section 1: Perhaps s/implementation of credentials which identify the parties/implementation of credentials that identify the parties

3) section 3.5: s/OCSP may provide an important optimizations/OCSP may provide important optimizations

4) Appendix C: s/decorated URI could could then verify/decorated URI could then verify

5) Appendix C: the reference to RFC6961 seems not required since it was obsoleted by RFC8446 which is being obsoleted by RFC8446bis that is being referenced right next to RFC6961 ?

OCSP Usage for Secure Telephone Identity Certificates

2026-02-17T15:43:08.137240+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Ketan Talaulikar

OCSP Usage for Secure Telephone Identity Certificates

2026-02-17T09:26:44.650281+00:00

[Ballot comment]

# Éric Vyncke INT AD comments for draft-ietf-stir-certificates-ocsp-12
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### Spell checker

Please use a spell checker, e.g., `Certififcate` in the abstract ;-)

### Section 4.1

Why not a MUST in `Servers SHOULD return responses that would otherwise have been "unknown" as "not good" (i.e., return only "good" and "not good" responses).` especially as the "i.e.," part seems to be mandatory.

OCSP Usage for Secure Telephone Identity Certificates

2026-02-17T09:26:44.650194+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke

OCSP Usage for Secure Telephone Identity Certificates

2026-02-17T07:57:04.700854+00:00

[Ballot comment]
It would be good to fix the spelling of "Certififcate" in the abstract!

OCSP Usage for Secure Telephone Identity Certificates

2026-02-17T07:57:04.700749+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Gorry Fairhurst

OCSP Usage for Secure Telephone Identity Certificates

2026-02-14T13:00:53.713575+00:00

[Ballot discuss]

I don't believe this is hard to fix....

General: I see no discussion in the main body of the specification about the use of a nonce to guarantee freshness (there are, however, nonces in the Appendix B examples). Is this intentional? Do you expect that an OCSP responder would generate OCSP proofs in advance (making the nonce option impossible)? In my opinion only, the removal of the nonce option makes it easier to pre generate OCSP proofs that allow quicker distribution in fewer round trips (this eases the ability to staple OCSP). I would recommend making a statement of expectation with regard to the use/non-use of a nonce to guarantee freshness.

OCSP Usage for Secure Telephone Identity Certificates

2026-02-14T13:00:53.713555+00:00

[Ballot comment]
Thanks to PHB for their secdir reviews.

Section 3, para 3: CRL partitions are mentioned without definition. The previous sentences discuss scoping mechanisms, perhaps add that these scoping mechanisms result in multiple sections of CRLs that are called partitions.

Section 8, para 2: Request/Distribution of an OCSP staple is also subject to DNS attacks. An effective mitigation for the denial of service issue is to have OCSP proofs generated in advance, and load balanced, or stored in multiple locations.

OCSP Usage for Secure Telephone Identity Certificates

2026-02-14T13:00:53.713485+00:00

[Ballot Position Update] New position, Discuss, has been recorded for Deb Cooley

OCSP Usage for Secure Telephone Identity Certificates

2026-02-14T04:21:18+00:00

IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed