Updates to Lightweight OCSP Profile for High Volume Environments
draft-ietf-lamps-rfc5019bis-12

I have only one comment:

Section 3.2.2, Appendix A:  The two terms 'byName' and 'byKey' are used without being defined (note: this is true in RFC 5019 too).  There are numerous 'Name' fields in the ASN.1, but no 'Key' fields.  My suggestion is to define these terms by pointing to the appropriate ASN.1 field.

[note:  finally, I get to ballot on a document I understand.  LOL]

# É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.`

# Internet AD comments for draft-ietf-lamps-rfc5019bis-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### Appendix B.5

* Out of curiosity, what causes the different formats for the time strings:

  - "GeneralizedTime 10/04/2024 12:37:47 GMT", and
  - "UTCTime 02/04/2024 12:37:47 GMT"?

  Clearly they're both GMT, and therefore compliant with S3.2.4.  I'm just
  curious...

# 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/

# Orie Steele, ART AD, comments for draft-ietf-lamps-rfc5019bis-08 
CC @OR13

This review is in the ["IETF Comments" Markdown format][ICMF].
You can use the [`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues, or using this [online validator](https://mnot.github.io/ietf-comments/).

Line numbers are generated with this:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-rfc5019bis-08.txt&submitcheck=True

## Comments

### Section 1 profile discovery

```
169	   OCSP does not have the means to signal responder capabilities within
170	   the protocol.  Thus, clients will need to use out-of-band mechanisms
171	   to determine whether a responder conforms to the profile defined in
172	   this document.  Regardless of the availability of such out-of-band
173	   mechanisms, this profile ensures that interoperability will still
174	   occur between an OCSP client that fully conforms with [RFC6960] and a
175	   responder that is operating in a mode as described in this
176	   specification.
```

Consider documenting at least 1 out of band mechanism in an appendix?

### Section 3.1.1 missing Signature

```
194	   Provided for convenience here, but unchanged from [RFC6960], the
195	   ASN.1 structure corresponding to the OCSPRequest with the relevant
196	   CertID is:
```

https://datatracker.ietf.org/doc/html/rfc6960#section-4.1.1 contains:

```
   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT SEQUENCE OF Certificate
   OPTIONAL}
```

But this section does not. 

I am not sure if this impacts "copy paste / validation", but it is a "change" that I noticed.

Later sections note that unsigned requests are acceptable, perhaps this is the reason for the ommision?

### Section 3.1.1 which AlgorithmIdentifier is used for SHA-256? 

```
221	   The CertID.issuerNameHash and CertID.issuerKeyHash fields contain
222	   hashes of the issuer's DN and public key, respectively.  OCSP clients
223	   that conform with this profile MUST use SHA-256 as defined in
224	   [RFC6234] as the hashing algorithm for the CertID.issuerNameHash and
225	   the CertID.issuerKeyHash values.
```

I wondered if there is a better reference for the AlgorithmIdentifier that is SHA-256.
Something more ASN.1 specific?

### sha-1 still ok?

In Section 3.1.1:

```
230	   However, these OCSP clients should transition from SHA-1 to SHA-256
231	   as soon as practical.
```

Capitalize SHOULD? Why not MUST? (given the as soon as practical comment)

Later in security considerations:

```
749	8.7.  Use of SHA-1 for the calculation of CertID field values

751	   Although the use of SHA-1 for the calculation of CertID field values
752	   is not of concern from a cryptographic security standpoint, the
753	   continued use of SHA-1 in an ecosystem requires that software that
754	   interoperates with the ecosystem maintain support for SHA-1.  This
755	   increases implementation complexity and potential attack surface for
756	   the software in question.  Thus, the continued use of SHA-1 in an
757	   ecosystem to maintain interoperability with legacy software must be
758	   weighed against the increased implementation complexity and potential
759	   attack surface.
```

8.7 framing reads as "no rush", which does not seem like a security consideration.


### Section 3.1.2 ignore requestorName?

```
246	   If the OCSPRequest is signed, the client SHALL specify its name in
247	   the OCSPRequest.requestorName field; otherwise, clients SHOULD NOT
248	   include the requestorName field in the OCSPRequest.  OCSP servers
249	   MUST be prepared to receive unsigned OCSP requests that contain the
250	   requestorName field, but MUST handle such requests as if the
251	   requestorName field were absent.
```

Why not "clients MUST NOT include the requestorName field in the OCSPRequest" ?

Wording of the second part could also be clearer, something like:

```
248	   include the requestorName field in the OCSPRequest.  OCSP servers
249	   MUST handle unsigned OCSP requests that contain the
250	   requestorName field, as if the requestorName field were absent.
```

### Section 3.2.3 resource exhaustion?

```
382	   Also, in order to ensure the database of revocation information does
383	   not grow unbounded over time, the responder MAY remove the status
384	   records of expired certificates.  Requests from clients for
```

Why not SHOULD? Under what circumstances SHOULD the status records for expired certificates be retained indefinitely?

### Section 3.2.4 redundant MUST?

```
400	      available about the status of the certificate.  Responders MUST
401	      always include this value to aid in response caching.  See
402	      Section 7 for additional information on caching.
```

The MUST here seems redundant? Are these fields always present, or optional except for this one?

The text in later sections implies these are all mandatory.

### Section 4.2 expiration checks

```
439	   Similarly, an application MUST validate the signature on certificates
440	   in a chain, before asking an OCSP client to check the status of the
441	   certificate.  If the certificate signature is invalid or the
442	   application is not able to verify it, an OCSP check MUST NOT be
443	   requested.  Clients SHOULD NOT make a request to check the status of
444	   expired certificates.
```

Why not MUST NOT? Consider:

```
441	   certificate.  If the certificate signature is invalid or the
442	   application is not able to verify it, or the certificate is expired, 
443	   an OCSP check MUST NOT be requested.
```

### Section 6 HTTP vs HTTPs

```
492	6.  Transport Profile

494	   OCSP clients can send HTTP-based OCSP requests using either the GET
495	   or POST method.  The OCSP responder MUST support requests and
496	   responses over HTTP.  When sending requests that are less than or
497	   equal to 255 bytes in total (after encoding) including the scheme and
498	   delimiters (http://), server name and base64-encoded OCSPRequest
```

I assume the use of `http` instead of `https` is intentional, 
I wouldn't mind a brief comment on why not HTTPs here.


# 8.5.  Modification of HTTP Headers is ok?

```
734	   manipulated by an attacker.  Clients SHOULD use these values for
735	   caching guidance only and ultimately SHOULD rely only on the values
736	   present in the signed OCSPResponse.  Clients SHOULD NOT rely on
```

Why not MUST?


## Nits

### Section 8.3 capitalize must

```
715	   As detailed in [RFC6960], clients must properly validate the
716	   signature of the OCSP response and the signature on the OCSP response
717	   signer certificate to ensure an authorized responder created it.
```

### 8.4.  Denial-of-Service Attacks

Consider alternative language to "should", such as "ought to", or capitalize it, and make it more actionable.


### Section 3.1.1 DN expand on first use

```
221	   The CertID.issuerNameHash and CertID.issuerKeyHash fields contain
222	   hashes of the issuer's DN and public key, respectively.  OCSP clients
```

Where you say "header", I believe you mean "header field", especially below Section 7.

Thanks for working on this update. 

One thing the I noticed that the profile transport uses HTTP only ( and not HTTPs). There might be good reasons for using it that way in certain scenarios. I would strongly suggest to explain the rational(s) behind the choice.