[lamps] Orie Steele's No Objection on draft-ietf-lamps-rfc5019bis-08: (with COMMENT)

[Orie Steele via Datatracker <[e-mail]>]

Orie Steele 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:
----------------------------------------------------------------------

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