Updated the ACME Client Keys security consideration #22

ounsworth · 2024-06-24T15:56:40Z

Closes #18

This change might be a bit contentious, and gets at a number of points raised by TimH.
This should be reviewed by the author group + Tim.

vanbroup

I think the changes look good, a few minor suggestions.

vanbroup · 2024-06-25T07:25:20Z

draft-vanbrouwershaven-acme-auto-discovery.md

+  EVBRs:
+    title: "Minimum Security Requirements for Issuance of Mark Certificates, v2.0.1"
+    target: "https://cabforum.org/working-groups/server/extended-validation/documents/CA-Browser-Forum-EV-Guidelines-2.0.1.pdf"
+    author:
+      - org: CA/Browser Forum
+    date: 6 May, 2024
+  QWAC-ENISA:
+    title: "Qualified Website Authentication Certificates"
+    target: "https://www.enisa.europa.eu/publications/qualified-website-authentication-certificates"
+    author:
+      - org: European Union Aguncy for Cybersecurity (ENISA)
+    date: May 16, 2016
+  VMCRequirements:
+    title: "Guidelines for the Issuance and Management of Extended Validation Certificates"
+    target: "https://bimigroup.org/resources/VMC_Requirements_latest.pdf"
+    author:
+      - org: BIMI Group
+    date: March 7, 2024


Do we really need to link to this information and do we want to include links to versions that will be out of date even before publication of the draft itself?

If we want to keep this information, I have correct the information and links to the current latest version.

Suggested change

EVBRs:

title: "Minimum Security Requirements for Issuance of Mark Certificates, v2.0.1"

target: "https://cabforum.org/working-groups/server/extended-validation/documents/CA-Browser-Forum-EV-Guidelines-2.0.1.pdf"

author:

- org: CA/Browser Forum

date: 6 May, 2024

QWAC-ENISA:

title: "Qualified Website Authentication Certificates"

target: "https://www.enisa.europa.eu/publications/qualified-website-authentication-certificates"

author:

- org: European Union Aguncy for Cybersecurity (ENISA)

date: May 16, 2016

VMCRequirements:

title: "Guidelines for the Issuance and Management of Extended Validation Certificates"

target: "https://bimigroup.org/resources/VMC_Requirements_latest.pdf"

author:

- org: BIMI Group

date: March 7, 2024

BR:

title: "Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates"

target: "https://cabforum.org/working-groups/server/baseline-requirements/requirements/"

author:

- org: CA/Browser Forum

EVG:

title: "Guidelines for the Issuance and Management of Extended Validation Certificates"

target: "https://cabforum.org/working-groups/server/extended-validation/guidelines/"

author:

- org: CA/Browser Forum

QWAC:

title: "Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified certificates"

target: "https://www.etsi.org/deliver/etsi_en/319400_319499/31941102/"

author:

- org: ETSI

VMC:

title: "Guidelines for the Issuance and Management of Extended Validation Certificates"

target: "https://bimigroup.org/resources/VMC_Requirements_latest.pdf"

author:

- org: BIMI Group

vanbroup · 2024-06-25T07:27:08Z

draft-vanbrouwershaven-acme-auto-discovery.md


-To ensure a secure account binding per customer, it is essential that each customer possesses their own unique ACME key. The utilization of individual ACME keys allows for a distinct association between the customer's account and the established account binding.
+To ensure a secure account binding, it is essential that each customer be able to control and pre-approve the ACME account keys that are authorized to request certificates against their account, particularly for certificate types that have billing implications, or that have additional verification requirements beyond what can be done inline within the ACME protocol, such as OV, EV [[EVBRs]], Qualified Website [[QWAC-ENISA]], or Verified Mark Certificates [[VMCRequirements]].


Inline with the suggestion above:

Suggested change

To ensure a secure account binding, it is essential that each customer be able to control and pre-approve the ACME account keys that are authorized to request certificates against their account, particularly for certificate types that have billing implications, or that have additional verification requirements beyond what can be done inline within the ACME protocol, such as OV, EV [[EVBRs]], Qualified Website [[QWAC-ENISA]], or Verified Mark Certificates [[VMCRequirements]].

To ensure a secure account binding, it is essential that each customer is able to control and pre-approve the ACME account keys that are authorized to request certificates against their account, particularly for certificate types that have billing implications, or that have additional verification requirements beyond what can be done inline within the ACME protocol, such as OV [[BR]], EV [[EVG]], Qualified Website [[QWAC]], or Verified Mark Certificates [[VMC]].

I´d remove the "particularly for certificate types that have billing implications" because IMO that´s dependant on the CA if the´d like to charge for it but it´s not part of a technical implementation.

vanbroup · 2024-06-25T07:29:51Z

draft-vanbrouwershaven-acme-auto-discovery.md


-If an account binding were to be established based on a shared ACME key, it could potentially lead to unauthorized users obtaining certificates using the same Certificate Authority (CA) based on the established account binding. This scenario poses a significant security risk and could result in the compromise of sensitive information or unauthorized certificate issuance.
+In traditional ACME deployments, this binding is accomplished via External Account Binding (EAB) keys or via unique ACME account keys per CA account. In the deployments for which ACME auto-discovery is envisioned to be useful, these authorization mechanisms may not be appropriate because the ACME client may be under the control of a cloud service provider (CSP) who may use the same ACME client key for all requests across customer accounts and who does not know the customer's EAB key (and if it did, then it would not require an auto-discovery mechanism in the first place).


Suggested change

In traditional ACME deployments, this binding is accomplished via External Account Binding (EAB) keys or via unique ACME account keys per CA account. In the deployments for which ACME auto-discovery is envisioned to be useful, these authorization mechanisms may not be appropriate because the ACME client may be under the control of a cloud service provider (CSP) who may use the same ACME client key for all requests across customer accounts and who does not know the customer's EAB key (and if it did, then it would not require an auto-discovery mechanism in the first place).

In traditional ACME deployments, this binding is accomplished via External Account Binding (EAB) keys or via unique ACME account keys per CA account. In the deployments for which ACME auto-discovery is envisioned to be useful, these authorization mechanisms may not be appropriate because the ACME client may be under the control of a Cloud Service Provider (CSP) who may use the same ACME client key for all requests across customer accounts and who does not know the customer's EAB key (and if it did, then it would not require an auto-discovery mechanism in the first place).

Another potentail editorial comment. I´d remove the "In traditional" because it means that could be ACME deployments not based on the standard which is not our case as per the next sentence.

vanbroup · 2024-06-25T07:31:28Z

draft-vanbrouwershaven-acme-auto-discovery.md


-To mitigate this risk, it is crucial to enforce the use of individual ACME keys for each customer. This ensures that the account binding is securely linked to the respective customer's account, preventing unauthorized access or misuse by other users. By maintaining separate ACME keys per customer, the integrity and confidentiality of the account binding process are upheld, enhancing the overall security posture of the system.
+The mechanism by which a CA obtains authorization to accept requests from a given ACME client key against a given CA account is outside the scope of this document and MAY be proprietary. Such a mechanism should be designed carefully to not lower the overall security of the system, and to not prevent CSPs from being able to rotate client keys.


Should we make a reference here to the acme-client-discovery draft?

I see a potential sync problem if we refer another draft that may have a different progress or not be even published.

vanbroup · 2024-06-25T07:32:49Z

draft-vanbrouwershaven-acme-auto-discovery.md


-To mitigate this risk, it is crucial to enforce the use of individual ACME keys for each customer. This ensures that the account binding is securely linked to the respective customer's account, preventing unauthorized access or misuse by other users. By maintaining separate ACME keys per customer, the integrity and confidentiality of the account binding process are upheld, enhancing the overall security posture of the system.
+The mechanism by which a CA obtains authorization to accept requests from a given ACME client key against a given CA account is outside the scope of this document and MAY be proprietary. Such a mechanism should be designed carefully to not lower the overall security of the system, and to not prevent CSPs from being able to rotate client keys.


Is this relevant or normative?

Suggested change

The mechanism by which a CA obtains authorization to accept requests from a given ACME client key against a given CA account is outside the scope of this document and MAY be proprietary. Such a mechanism should be designed carefully to not lower the overall security of the system, and to not prevent CSPs from being able to rotate client keys.

The mechanism by which a CA obtains authorization to accept requests from a given ACME client key against a given CA account is outside the scope of this document. Such a mechanism should be designed carefully to not lower the overall security of the system, and to not prevent CSPs from being able to rotate client keys.

Updated the ACME Client Keys security consideration

714dfb5

vanbroup reviewed Jun 25, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updated the ACME Client Keys security consideration #22

Updated the ACME Client Keys security consideration #22

ounsworth commented Jun 24, 2024 •

edited

Loading

vanbroup left a comment

vanbroup Jun 25, 2024

barrini Jun 25, 2024

vanbroup Jun 25, 2024

barrini Jun 25, 2024

vanbroup Jun 25, 2024

barrini Jun 25, 2024

vanbroup Jun 25, 2024

barrini Jun 25, 2024

vanbroup Jun 25, 2024


		To ensure a secure account binding per customer, it is essential that each customer possesses their own unique ACME key. The utilization of individual ACME keys allows for a distinct association between the customer's account and the established account binding.
		To ensure a secure account binding, it is essential that each customer be able to control and pre-approve the ACME account keys that are authorized to request certificates against their account, particularly for certificate types that have billing implications, or that have additional verification requirements beyond what can be done inline within the ACME protocol, such as OV, EV [[EVBRs]], Qualified Website [[QWAC-ENISA]], or Verified Mark Certificates [[VMCRequirements]].


		If an account binding were to be established based on a shared ACME key, it could potentially lead to unauthorized users obtaining certificates using the same Certificate Authority (CA) based on the established account binding. This scenario poses a significant security risk and could result in the compromise of sensitive information or unauthorized certificate issuance.
		In traditional ACME deployments, this binding is accomplished via External Account Binding (EAB) keys or via unique ACME account keys per CA account. In the deployments for which ACME auto-discovery is envisioned to be useful, these authorization mechanisms may not be appropriate because the ACME client may be under the control of a cloud service provider (CSP) who may use the same ACME client key for all requests across customer accounts and who does not know the customer's EAB key (and if it did, then it would not require an auto-discovery mechanism in the first place).


		To mitigate this risk, it is crucial to enforce the use of individual ACME keys for each customer. This ensures that the account binding is securely linked to the respective customer's account, preventing unauthorized access or misuse by other users. By maintaining separate ACME keys per customer, the integrity and confidentiality of the account binding process are upheld, enhancing the overall security posture of the system.
		The mechanism by which a CA obtains authorization to accept requests from a given ACME client key against a given CA account is outside the scope of this document and MAY be proprietary. Such a mechanism should be designed carefully to not lower the overall security of the system, and to not prevent CSPs from being able to rotate client keys.

Updated the ACME Client Keys security consideration #22

Are you sure you want to change the base?

Updated the ACME Client Keys security consideration #22

Conversation

ounsworth commented Jun 24, 2024 • edited Loading

vanbroup left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ounsworth commented Jun 24, 2024 •

edited

Loading