Define standard CAA semantics for limiting cert issuance

[CBonnell]

No description provided.

[CBonnell]

This item was discussed at the 2022-07-28 meeting.

There were several types of restrictions identified that would be valuable to standardize (ordered in order of importance by the group):

1. DCV method
2. account identifier
3. certificate type (DV/IV/OV/EV)

[CBonnell]

We discussed this item on the 2023-10-19 call. We determined two steps for this effort:

1. Determine which type of restrictions would be valuable (there was discussion on whether account ID restrictions would potentially cause outages)
2. Determine how the restrictions will be expressed (refer to RFC 8657 as source of inspiration)

[wthayer]

@CBonnell I noticed that RFC 8657 includes provisions for use without ACME. I think this could be a relatively simple change to require RFC 8657 support for ACME requests and to define the semantics for non-ACME requests. A straw-dog ballot proposal is:

Effective day-month-2025, add the following to TLS BR section 3.2.2.8 CAA Records::

• CAs MUST process the RFC 8657 accounturi and validationmethods parameters when performing CAA checks on certificate requests that have been made using the ACME protocol.

• For requests not made using the ACME protocol, CAs MUST process the accounturl parameter and document its proper use in this section of their CPS.

• For requests not made using the ACME protocol, CAs MUST process the following validationmethods semantics: non-ACME labels are formed by concatenating the string ‘ca-dv-’ with the BR 3.2.2.4 subsection number, e.g. ‘ca-dv-7’ represents the DNS method described in TLS BR 3.2.2.4.7

Perhaps we could put this on the agenda for an upcoming VSC meeting and gauge interest?

[romanf]

I'm not sure I understand the use-case for the accountURI extension (the validationmethods is clear). Can somebody help me out with a short description of where that would be usefull?

[jospurvis]

As I understand it, accounturi is used to govern which account at the provider may be used to obtain a certificate. This prevents someone with a different account at the same CA from obtaining certificates for that domain.

[orangepizza]

@wthayer would ca-db-7 not authorize dns-01 acme challenge because it isn't triggered because CA used ACME for this request?
and I wish there is more human readable name for each method; we can add human readable name at each method's document, isn't it?

[wthayer]

@wthayer would ca-db-7 not authorize dns-01 acme challenge because it isn't triggered because CA used ACME for this request?
@orangepizza that's a good question. From the CA's point of view, they are using one method or the other but that is probably not obvious to the Subscriber. We will need to explicitly define the behavior here (for both DNS and HTTP methods).

and I wish there is more human readable name for each method; we can add human readable name at each method's document, isn't it?
I agree with your point about making this mechanism more user friendly, but it's not obvious to me that defining human readable names for each method really achieves that goal.

[orangepizza]

@wthayer would ca-db-7 not authorize dns-01 acme challenge because it isn't triggered because CA used ACME for this request?
@orangepizza that's a good question. From the CA's point of view, they are using one method or the other but that is probably not obvious to the Subscriber. We will need to explicitly define the behavior here (for both DNS and HTTP methods).

and I wish there is more human readable name for each method; we can add human readable name at each method's document, isn't it?
I agree with your point about making this mechanism more user friendly, but it's not obvious to me that defining human readable names for each method really achieves that goal.

I guess 3.2.2.4.19 Agreed-Upon Change to Website - ACME would be better example: this is clearly for acme http-01 challenge, but your wording doesn't allow ca-db-19 because when using ACME that's not a namespace it looks for