An Attribute for Statement of Possession of a Private Key
draft-ietf-lamps-private-key-stmt-attr-09

# Éric Vyncke, INT AD, comments for draft-ietf-lamps-private-key-stmt-attr-08
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Tim Hollebeek for the shepherd's 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

### ACME

Does this document impact ACME ?

### Not-valid-after relationship

Should there be a relationship on the expiration dates of the 2 certs ? E.g., the expiration date of the cert #2 <= expiration date of the cert #1

### Section 2

Can 2 different CA be used ? Should the text be clear on whether it is allowed or not ?

Can the signature key pair be used to sign multiple CSR for multiple key negotiation keys ?

### Section 6

Why not a MUST in `If the CA revokes a compromised signature certificate, then the CA SHOULD also revoke all key establishment certificates` ?

I note some cases where lowercase non-2119 words are used that surprised me. For example, [in Section 6](https://www.ietf.org/archive/id/draft-ietf-lamps-private-key-stmt-attr-08.html#section-6-5), if you "Likewise... MUST", I would expect the first clause to also be a MUST.

Similarly, [in Section 3](https://www.ietf.org/archive/id/draft-ietf-lamps-private-key-stmt-attr-08.html#section-3-7), I was surprised that the diagnostic responses are not SHOULDs (though I can see a plausible rationale there, that such an action occurs after the protocol exchange has failed and therefore has no bearing on interoperability of the protocol).

Hi Russ, 

Thank you for the effort put into this document.

Thanks to Adrian Farrel for the OPSDIR review and Russ for promptly addressing the review: 

* I like the new text added, but would prefer if that text was put in a separate section (grouped with other ops matters) in a specific section.

* Thanks also for expanding the terms as suggested by Adrian. However, please use a consistent approach for expanding these as we have currently two forms:

CURRENT:
   Certification Authority (CA) ….
   ..

   For example, ..
   a ML-DSA (Module-Lattice-Based Digital Signature Algorithm) .. a ML-KEM
   (Module-Lattice-Based Key-Encapsulation Mechanism) public key.  For
   … ECDSA (Elliptic Curve Digital Signature Algorithm) … ECDH
   (Elliptic Curve Diffie-Hellman) public key.
   ..
   2.  … Certificate Signing Request (CSR)
  
Please find below some comments:

# Meta comment

I trust the responsible AD/WG validated the examples and the ASN module.

Are there readily available online tools that one can use for these checks?

# Introduction:

## Missing Reference

CURRENT:
   A statement of possession may be used in lieu of the usual proof of
   possession mechanisms.  

Do we have a reference for these “usual” mechanisms?

## Redundant normative behavior

CURRENT:
   possession of the same certificate subject.  If the Certificate
   Policy [RFC3647] allows, the CA MAY accept this statement in lieu of
   proof that the requestor has possession of the private key.

* I guess a word is missing for “policy..allows”. Allows what?

* I guess this should be s/MAY/may as we do have the normative behavior in the body of the draft.
 
## nits

OLD:
   3.  The subject sends the CSR to the CA, and it gets back a signature
       certificate.  The signature certificate includes a key usage of
       digitalSignature, nonRepudiation, or both Section 4.2.1.3 of
       [RFC5280].

   6.  The subject sends the CSR to the CA, and it gets back a key
       establishment certificate.  The key establishment certificate
       includes a key usage of keyEncipherment or keyAgreement
       Section 4.2.1.3 of [RFC5280].


NEW:
   3.  The subject sends the CSR to the CA, and it gets back a signature
       certificate.  The signature certificate includes a key usage of
       digitalSignature, nonRepudiation, or both (Section 4.2.1.3 of
       [RFC5280]).

   6.  The subject sends the CSR to the CA, and it gets back a key
       establishment certificate.  The key establishment certificate
       includes a key usage of keyEncipherment or keyAgreement
       (Section 4.2.1.3 of [RFC5280]).

# Section 2

## Quote source of the citation

CURRENT:
      "The subject of the signature certificate that is used to validate
      the signature on this certificate request states, without
      providing proof, that it has possession of the private key that
      corresponds to the public key in the certificate request."

## Redundant behavior with 5280

CURRENT:
   The CA MUST perform certification path validation for the signature
   certificate as specified in Section 6 of [RFC5280].  If the
   certification path is not valid, then the CA MUST reject the
   certificate request.

Doe we need the second MUST? Isn’t that covered by the validation in rfc5280#section-6.1.6?

Please update accordingly. Thanks.

## Internal redundant behaviors

This section says: 

CURRENT:
   If they are different, the
   certificate policy MUST describe how the CA can determine that the
   two subject names identify the same entity. 

Section 5 has also:

CURRENT:
   If a CA allows subject in the key establishment certificate to be
   different than the subject name in the signature certificate, then
   certificate policy MUST describe how to determine that the two
   subject names identify the same entity.   

Please keep one MUST as these are covering the same aspect. I guess the first one should be kept but s/MUST/must in the sec cons section.

## Subject alternative names

Any reason why a different approach is followed for certificate policy when discussing subject alternative names vs subject names. 

CURRENT:

   The subject in the signature certificate SHOULD be the same as the
   subject name in the certificate request.  If they are different, the
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ 
   certificate policy MUST describe how the CA can determine that the
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   two subject names identify the same entity.  If the CA is unable to
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   determine that the two subject names identify the same entity, then
   the CA MUST reject the certificate request.

   If subject alternative names are present in the certificate request,
   they SHOULD match subject alternative names in the signature
   certificate.  If the CA is unable to determine that each of subject
   alternative names identifies the same entity as is named in the
   signature certificate, then the CA MUST reject the certificate
   request.

and Section 5:

   If a CA allows subject in the key establishment certificate to be
   different than the subject name in the signature certificate, then
   certificate policy MUST describe how to determine that the two
   subject names identify the same entity.  Likewise, if a CA allows
   subject alternative names in the key establishment certificate that
   are not present in the signature certificate, then certificate policy
                                                 ^^^^^^^^^^^^^^^^^^^^^^
   MUST describe how to determine that the subject alternative names
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   identify the same entity as is named in the signature certificate.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

## When is this possible?

CURRENT:
   If the CA is unable to
   determine that the two subject names identify the same entity, then
   the CA MUST reject the certificate request.

Given the MUST in the previous sentence, when this case occurs? It seems to me that a clarification is needed here.

# Section 4

## (nit) s/establisment/establishment
## (nit) s/signture/signature

# Fix IANA action

I guess the following change should be made to be consistent with the ASN module:

CURRENT:
   For the ASN.1 Module in the Appendix A of this document, IANA is
   requested to assign an object identifier (OID) for the module
   identifier (TBD0) with a Description of "d-mod-private-key-
                                            ^^^^^^^^^^^^^^^^
   possession-stmt-2025".  The OID for the module should be allocated in
   the "SMI Security for PKIX Module Identifier" registry
   (1.3.6.1.5.5.7.0).

NEW:
   For the ASN.1 Module in the Appendix A of this document, IANA is
   requested to assign an object identifier (OID) for the module
   identifier (TBD0) with a Description of "id-mod-private-key-   
   possession-stmt-2025".  The OID for the module should be allocated in
   the "SMI Security for PKIX Module Identifier" registry
   (1.3.6.1.5.5.7.0).

Cheers,
Med

Thank you to Roni Even for the GENART review.