Related Certificates for Use in Multiple Authentications within a Protocol
draft-ietf-lamps-cert-binding-for-multi-auth-05

This document uses the RFC2119 keywords "SHOULD NOT", "MUST", "MAY", and
"SHOULD", but does not contain the recommended RFC8174 boilerplate. (It
contains a variant of the RFC2119 boilerplate.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"
 * Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
   "intrinsic", "original"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 2
> ontaining the extension is able to be used in combination with the other spec
>                                    ^^^^^^^
Avoid the passive voice after "to be able to".

Section 2, paragraph 1
> at the end-entity owns and wants identified in the new certificate requested
>                                  ^^^^^^^^^^
The double modal "wants identified" is nonstandard (only accepted in certain
dialects). Consider "to be identified".

Section 4, paragraph 1
> d certificate } The extension is comprised of an octet string, which is the
>                               ^^^^^^^^^^^^^^^
Did you mean "comprises" or "consists of" or "is composed of"?

Section 5, paragraph 5
> reements on certificate policy with regards to certificate application, issua
>                                ^^^^^^^^^^^^^^^
Use "in regard to", "with regard to", or more simply "regarding".

# Orie Steele, ART AD, comments for draft-ietf-lamps-cert-binding-for-multi-auth-05 
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-cert-binding-for-multi-auth-05.txt&submitcheck=True

Thanks to Robert Sparks for the ARTART review.

## Comments

### Confusing ED Note

I agree with Robert's comment:

```
I also found the "ED Note" calling out (I assume) the discussion of _not using_
SCVPCertID instead of this extension, but quoting the structure anyway, pretty
confusing. Please consider if it will stimulate implementor error.
```

### non-composite hybrid authentication

```
19	   same end entity.  This mechanism is particularly useful in the
20	   context of non-composite hybrid authentication, which enables users
21	   to employ the same certificates in hybrid authentication as in
22	   authentication done with only traditional or post-quantum algorithms.
```

This document appears to define the term / concept of "non-composite hybrid authentication".

Later in security considerations, the general concept of hybrid is discussed.

Consider a reference to https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/.

I found the term "non-composite hybrid" clear, however other readers might not.

### Media types for URLs?

```
202	   *  - If the request for (new) Cert B is to the same CA organization
203	      as issued (existing) Cert A, then the UniformResourceIdentifier
204	      value SHOULD be a URL that points to a file containing a
205	      certificate or certificate chain that the requesting entity owns,
206	      as detailed in [RFC5280]; the URL is made available via HTTP or
207	      HTTPS.  The file must permit access to a CMS 'certs-only' message
208	      containing the end entity X.509 certificate, or the entire
209	      certificate chain.  In this case, preference for a URL keeps the
210	      data limit smaller than using a dataURI.  All certificates
211	      contained must be DER encoded.
```

Are there specific media types, which MUST / SHOULD be supported?

Is there a benefit to specifying Accept / Content-Type headers here?

## Nits

### extant -> still existing

```
100	   - one in an extant certificate, and one in a current request) belong
101	   to the same entity.  To facilitate this, a CSR attribute is defined,
```

Might improve readability for folks who's first language is not english.

It's also possible more clarity regarding validity would help here... "currently valid, non revoked" ?

### PQC

```
111	   traditional cryptography to PQC.
```

Expand on first use. 

You might also consider relating PQC to Quantum Resistant (QR).

### dataURI reference location

```
199	   HTTPS, or a dataURI.  This field can contain one of two acceptable
200	   values:
```

Consider adding the reference to RFC2397 here, instead of a few sentences later.


### to be to the

```
466	   authentication have to be to the satisfaction of the verifier.  A
```

Have to satisfy the verifier?

### promiscuous online protocols

```
471	   implicit.  In an online protocol like IPsec where the peers are
472	   generally known, any mechanism selected from a pre-established set
473	   may be sufficient.  For more promiscuous online protocols, like TLS,
474	   the ability for the verifier to express what is possible and what is
475	   preferred – and to assess that it got what it needed – is important.
```

Is there a better word? 
I dared to search and the results varied in ways that lead me to believe there might be a better term here.

Thank you for this document -- it is quite far outside my skillset, and so I have nothing to add....

Thanks for working on this specification. I have no issues here from transport protocol point of view.

Thanks for the work done in this document.

Below some non-blocking comments.

# Abstract

Please expand `CSR` at first use.

# Other non-expanded acronyms

E.g., PQP, PQ

# Wrong BCP 14 template

As noted by Mahesh.

# Section 3.1

Should this be a normative MUST in `All certificates contained must be DER encoded` ?

# X.509 or X.509v3

I noticed a single use of X.509v3 while other places are X.509. Is it on purpose ? If so, then some explanations will be welcome.