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

[Ballot discuss]
This is a minor item, but when looking at:

IssuerAndSerialNumber ::= SEQUENCE {
        issuer      Name,
        serialNumber CertificateSerialNumber }

This does not uniquely identify a CA. When embedding an entire CA chain as proof, I can just make up my own matching LetsEncrypt named CA and EE cert with the same serial as my victim, and see if I can get a Cert B without actually having the private key of the real Cert A.

Perhaps something can be said in the Security Considerations that when trusting a CA, its public key should also be checked along its name to match the expected pubkey of the CA that CA B is about to trust.

Additionally, perhaps a note should be made in the Security Considerations section that this method can only be trusted before known PQ attacks are available. If Cert A (and thus CA A) uses quantum breakable algorithms, this scheme no longer guarantees that Cert B is requested by the owner of Cert A and not some lucky owner of a shiny new expensive quantum computer.

[Ballot comment]
# 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.

[Ballot comment]
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.

[Ballot comment]
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".

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lamps-cert-binding-for-multi-auth-05. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the SMI Security for PKIX Certificate Extension registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

a single registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-pe-relatedCert
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

Second, in the SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2) registry also in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

a single registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-aa-relatedCertRequest
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

Third, in the SMI Security for PKIX Module Identifier registry also in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

a single registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-mod-related-cert-2023
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-05-16):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-cert-binding-for-multi-auth@ietf.org, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org, tim.hollebeek@digicert.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Related Certificates for Use in Multiple Authentications within a Protocol) to Proposed Standard


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: - 'Related
Certificates for Use in Multiple Authentications within a
  Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-05-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a new CSR attribute, relatedCertRequest, and a
  new X.509 certificate extension, RelatedCertificate.  The use of the
  relatedCertRequest attribute in a CSR and the inclusion of the
  RelatedCertificate extension in the resulting certificate together
  provide additional assurance that two certificates each belong to the
  same end entity.  This mechanism is particularly useful in the
  context of non-composite hybrid authentication, which enables users
  to employ the same certificates in hybrid authentication as in
  authentication done with only traditional or post-quantum algorithms.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-cert-binding-for-multi-auth/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5734/
  https://datatracker.ietf.org/ipr/5735/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document was broadly agreed to and uncontroversial.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document is intended to be used in US government PKIs and is written and
supported by a relevant agency.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not relevant.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The chairs assisted the authors in getting the ASN.1 modules to compile correctly,
they now do.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, the document was carefully written and has been carefully reviewed.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The Security checklist has been reviewed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard.  This is appropriate for a technology intended to be used at
scale in production.  Datatracker is correct.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors have each stated they are not aware of any IPR related to this draft.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are some non-ascii characters left and the copyright year is now wrong
since it passed WGLC in 2023.  In the shepherd's opinion, these can be bundled
up and addressed along with AD comments.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Only RFCs are referenced.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Two OIDs and a module ID are requested.  The assignments look fine, though
the name of the module references "2023".  It perhaps should be updated to
"2024" or have the reference to the year of publication removed.  The shepherd
is unaware of a reason the year should be included and the document does not
justify its inclusion.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document was broadly agreed to and uncontroversial.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document is intended to be used in US government PKIs and is written and
supported by a relevant agency.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not relevant.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The chairs assisted the authors in getting the ASN.1 modules to compile correctly,
they now do.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, the document was carefully written and has been carefully reviewed.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The Security checklist has been reviewed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard.  This is appropriate for a technology intended to be used at
scale in production.  Datatracker is correct.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors have each stated they are not aware of any IPR related to this draft.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are some non-ascii characters left and the copyright year is now wrong
since it passed WGLC in 2023.  In the shepherd's opinion, these can be bundled
up and addressed along with AD comments.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

Only RFCs are referenced.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Two OIDs and a module ID are requested.  The assignments look fine, though
the name of the module references "2023".  It perhaps should be updated to
"2024" or have the reference to the year of publication removed.  The shepherd
is unaware of a reason the year should be included and the document does not
justify its inclusion.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/