[lamps] Gunter Van de Velde's No Objection on draft-ietf-lamps-rfc5019bis-08: (with COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

Gunter Van de Velde has entered the following ballot position for
draft-ietf-lamps-rfc5019bis-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5019bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Gunter Van de Velde, RTG AD, comments for draft-ietf-lamps-rfc5019bis-08

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points.

I hope that this review helps to improve the document,

117        (For brevity we refer to OCSP as being used to verify certificate
118        status, but only the revocation status of a certificate is checked
119        via this protocol.)

As networking generalist i am unclear what the 'but only' refers towards? it
reads a bit odd. in addition not sure if the word 'we' helps in a formal
document.

What about following rewrite suggestion:
For brevity, the term "OCSP" is used herein to denote the verification of
certificate status; however, it should be noted that this protocol is employed
solely to ascertain the revocation status of a certificate.

121        To date, many OCSP deployments have been used to ensure timely and
122        secure certificate status information for high-value electronic
123        transactions or highly sensitive information, such as in the banking
124        and financial environments.  As such, the requirement for an OCSP

This text processes difficult for me. Would he following text be a potential
rewrite?

To date, numerous OCSP deployments have been implemented to provide timely and
secure certificate status information, crucial for high-value electronic
transactions and the handling of highly sensitive information, particularly
within the banking and financial sectors.

128        is not an issue, and have run on client and server systems where
129        processing power is not constrained.

I assume that there is no additional constraints beyond the capabilities of the
CPU/memory used?

151        This document addresses the scalability issues inherent when using
152        OCSP in PKI environments described above by defining a message
153        profile and clarifying OCSP client and responder behavior that will
154        permit:

Instead of writing 'in PKI environments described above' would it not be more
simpler to say 'in highly scaled PKI environments'?

668     8.  Security Considerations

Is there a special fallback consideration in scenarios where the OCSP
check fails (either due to responder issues or network problems)?
Are there any additional privacy considerations associated with the
lightweight solution beyond those already noted for the traditional OCSP?

G/