[lamps] Éric Vyncke's No Objection on draft-ietf-lamps-rfc5019bis-08: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke 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:
----------------------------------------------------------------------


# Éric Vyncke, INT 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 (including a nearly DISCUSS
for section 3.1.1) but replies would be appreciated even if only for my own
education).

Special thanks to Russ Housley for the shepherd's detailed write-up including
the WG consensus *but it lacks* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 3.1.1

Even if 3.1.1 is included in 3.1 (profile-related), `OCSPRequests that conform
to this profile` the "this" is a little unclear. Suggest to be more specific
rather than using "this".

About `these OCSP clients should transition`, should this be a normative
"SHOULD" ? Also, the paragraph above has a "MUST" for SHA-256 and this text
appears to allow for SHA-1. To be honest, I was really close to ballot a
DISCUSS on this point.

## Section 3.1.2

I am confused after reading this section. Should the responders simply ignore
invalid request signature ? How can a server "MUST be prepared" while still
responders "MAY ignore the signature".

## Section 3.2.2

Isn't `on the returned OCSPResponse` a pleonasm ? I.e., the response is always
'returned'.

## Section 3.2.4

`producedAt MUST be expressed Greenwich Mean Time (Zulu)` or should be UTC ?

## Section 6

Even if the payload is signed and contains public information, is a non-https
scheme suitable in `including the scheme and delimiters (http://)` ?

## Section 7.1

Should there be any recommendation on the Max-Age value in `responders MAY
indicate when the client should fetch an updated OCSP response by using the
cache- control:max-age directive`?

## Section 7.2

Are CDN implicitly covered by "HTTP proxies" ?

In `max-age = < n > -where n is a time value later than thisUpdate but earlier
than nextUpdate.` is max-age really an absolute time rather than a relative
time in seconds ?

## Section 7.3

Probably due to my lack of knowledge about OCSP, but is there a difference in
"OCSP responder" and "server" in this section ? Especially about `First, it
allows for the caching of OCSP responses on the server, thus lowering the
number of hits to the OCSP responder.`