[cabf_validation] 2023-03-23 Minutes of the Validation Subcommittee

Fri Apr 7 21:13:49 UTC 2023

Validation Subcommittee — 23 March 2023

Attendance: Aaron Poulsen - (Amazon), Aneta Wojtczak-Iwanicka - (Microsoft), Ben Wilson - (Mozilla), Bruce Morton - (Entrust), Chris Clements - (Google), Clint Wilson - (Apple), Daryn Wright - (GoDaddy), Dimitris Zacharopoulos - (HARICA), Dustin Hollenback - (Microsoft), Inigo Barreira - (Sectigo), Joseph Ramm - (OATI), Martijn Katerbarg - (Sectigo), Michael Slaughter - (Amazon), Michelle Coon - (OATI), Nargis Mannan - (VikingCloud), Nate Smith - (GoDaddy), Paul van Brouwershaven - (Entrust), Rebecca Kelley - (Apple), Rollin Yu - (TrustAsia Technologies, Inc.), Thomas Zermeno - (SSL.com), Tim Hollebeek - (DigiCert), Tobias Josefowitz - (Opera Software AS), Trevoli Ponds-White - (Amazon), Wayne Thayer - (Fastly), Wendy Brown - (US Federal PKI Management Authority)

Wayne Thayer leading the meeting while Corey is out.

Anti-Trust Statement was read by Wayne Thayer.

Review and approval of minutes from March 9, 2023 completed. Minutes approved.

Agenda
Updates on Multi-Perspective / Multi-Vantage Point Domain (MPDV) validation
Review of CDN Issuance Flow

MPDV
Work items were allocated for MPDV, with follow-up meeting in April.
There is discussion ongoing around details of this work, and while not taking place directly in the CA/B Forum, it’s not too late to join the conversation.

CDN Issuance Workflow
The Workflow is broken down into two flows for Initial Certificate Request and Renewal/Subsequent Certificate Request
The flows reviewed are described on the (new) CA/BForum Wiki under: Server Certificate WG -> Validation -> Validation Subcommittee -> CDN issuance flow

Initial Certificate Request
Wayne: The assumption here is that the DNS for the site is not yet pointed at the CDN; it may or not be accessible elsewhere, but it’s not routed through the CDN so validation can’t be automate by the CDN.
Step 1 discussion: The Subscriber Agreement
Wayne: The CDN or the website operator can act as the applicant/subscriber, but it’s not clear whether one shouldbe preferred over the other. It’s unknown which is more common, but in my opinion it’s better for the website operator to be the subscriber, though it’s easier in some cases for the CDN to be the subscriber. That’s an area the group should make some improvements in.
Dimitris: We’ve said in the past it can be either, with pros and cons for each, but from the perspective of the CDN it doesn’t really matter. They just need somebody to be attached to the subscriber agreement and bear all the obligations and responsibilities for that.
Trev: Why would it be better for the website operator to be the subscriber.
Ben: How do you know who the subscriber is with certificates containing multiple SAN values?
Dimitris: Whoever signs the subscriber agreement. Some want 1 certificate and 50 or 200 domain names inside that.
Ben: It’s easier if to concentrate on the single entity that’s common among all of them, which is the CDN operator.
Trev: Some people do want a cert with 1000 domains in it, which would have a large blast radius. But considering that we want an ecosystem where there’s automation and fast response to incidents, like key compromise. With such a cert, is the website operator who we would contact? The 1000 domain owners? If the subscriber is the CDN, they can certainly let those impacted know, but they can directly take the appropriate security action. So what are the pros of the website operator as subscriber?
Wayne: Conceptually, the reason for the subscriber agreement is to bind the operator to the terms of the agreement. There’s an argument to be made that the CDN is operating the website, but they’re not really, as they’re doing it on behalf of their customer. 
Trev: It’s interesting that it’s not sufficient for the CDN customer to be bound to the terms of service for the CDN, which would typically include the set of subscriber obligations the CDN wants.
Tim: Since we have not requirements for CDNs, it might or might not. The subscriber agreement covers about 3 different types of things that the subscriber should do, and we’ve split the subscriber up in the modern Web PKI into 3 or 4 different companies. Untangling every CA’s subscriber agreement and figuring out what needs to go where and needs to apply to which individuals, especially based on different use cases, will be fun.
Tobi: In the CDN use case, if you have a subscriber whose agreed to a subscriber agreement with the CA, but they have no control over anything (the subscriber can’t lose the key since they don’t have access to it). So the subscriber would need a contract with the CDN to make the subscriber agreement enforceable, right? That’s impractical and no something anyone wants.
Dimitris: In practice, a customer signing up to a CDN accepts the terms of service.
Tobi: If I’m the subscriber as a person, and go to a CDN to sign up (accepting the terms of service), all these things happen in the background (such as keys being generated, which I never have access to). All these obligations from the subscriber agreement, I can’t act on them because the CDN, in practice, has all the control. If I want to fulfill my legal obligations as the subscriber, I would need to have legal provisions with the CDN.
Dimitris: There’s one model where the CDN can ask for a certificate from their customer (produced outside the CDN workflow, the customer provides the key and chain). It could also be an identity cert, like an EV cert, which the CDN couldn’t get with the customer’s data.
Tobi: Let’s assume this CDN use case under discussion is not that because what you just described is no different from the customer hosting the site themselves.
Wayne: This CDN use case does address some of that, down a few steps.
Trev: To Dimitris’ point, why couldn’t a CDN request an identity cert on behalf of their customer? All you have to do is give all the correct information.
Wayne: But then would the CDN be the subscriber, or the CDN’s customer? In that case, I think it would have to be the CDN’s subscriber.
Ben: Agreed.
Trev: Like what Tim was saying, the subscriber is sort of 3 different jobs, and like what Tobi was saying, what is the key thing that we consider the subscriber to have control over in order to make them the important entity? If you’re in a closed ecosystem, where the CDN generated the keys and sent them to the CA, the website operator doesn’t have control over the keys and didn’t make the request to the CA.
Ben: So is the subscriber the entity that controls the key or the identity in the certificate?
Tim: I lean towards moving past the concept of subscriber, and replace it with roles like “operation key holder” and admit these are different roles with different responsibilities. Then we can talk about key protection in the context of the entity that holds the keys and identity in the context of what’s in the subject. Then we can create requirements about what the applicant does to prove they’re the subject, or applying on behalf of the subject. The problem is the term “subscriber”. The subscriber is no longer a single person or organization, and we should fix it to match reality.
Wayne: That’s a pretty good summary of what needs to happen here and the work we need to do.
Tim: I also posted in chat something similar to what Tobi was saying, which is that the key problem with the legal agreements is that a CDN customer may agree to the terms of service, but those CDN terms of service may or may not match the requirements of the BRs for key protection. If the subscriber is giving their keys to someone else, they’d need some legal/contractual requirement to show an auditor, in theory.
Step 5 Discussion:
Dimitris: Is there any particular reason you only propose using DNS validation?
Trev: It’s usually DNS, not required to be.
Wayne: In my mind, DNS is the most common and I was thinking in terms of what the most easily automated methods, being either DNS or HTTP validation. We could go through all the methods to discuss if valuable.

Renewal Certificate Request:
Wayne: The distinction made on the renewal side is that the website is already being served through the CDN and therefore has the ability to inject data for HTTP validation, and therefore, while DNS validation is probably still very often used for renewals, it wouldn’t necessarily have to be.
Clint: Is this limited to renewals, or could it simply be a 2nd certificate request from the same subscriber?
Trev: For the same domain?
Clint: Yes, maybe a different subdomain?
Wayne: The distinction I’m making is whether you’re getting a cert for a website that is already served by the CDN or a cert for a website that’s not.
Tim: That’s not a binary choice. I could have 2 domains in my cert currently and apply for a new cert with those same 2 domains as well as a 3rd new one, not served by the CDN.
Trev: Clint, before he describes it, is your questions about reusing validation that was previously done or something else?
Clint: It could be; it’s really more about what Wayne was describing. What is the separation between these request types? Renewal, as a term, is a very narrowly defined thing that’s happening whereas certificate issuance in general is going to cover a lot of things, like a 2nd certificate for the same domain, but different subdomain; or the same FQDN as in the 1st cert; or totally different domain, but same customer. So I was just trying to understand the boundaries of what this 2nd flow is intended to describe.
Dimitris: We have a bit the same issue as with Corey’s description. Wayne has obviously made some assumptions on these workflows that we probably need to isolate and highlight somewhere.
Clint: I think he’s done a good job of explaining the assumptions, but I agree and that’s sort of what I was getting at is what are the boundaries of what we’re trying to discuss.
Dimitris: A renewal is renewing the exact same certificate, you don’t add any domain names, you don’t remove anything, you have the same identity, and you just extend the notAfter date.
Tim: That describes the traditional NIST/historical definition of renewal, which we should keep. Renewal is used much more loosely in the Web PKI, so we should be clear that we’re following the NIST definition of renewal for this workflow where you’re not allowed to change anything other than the notAfter date.
Wayne: When you start documenting these flows, there’s so many permutations that it’s difficult to describe something that makes sense without making some assumptions. And yes, I definitely assumed that this was the NIST definition of renewal.
Ben: What if we replaced renewal with “subsequent certificate requests” or something like that?
Trev: Subsequent sounds like a request from the same customer of the CDN, but potentially for a different website or domain. I assumed the same as Wayne did, that we’re talking about a certificate that is being requested for the purpose of being used on the resource that it was being used on to maintain availability of that resource. That’s what renewal refers to, it doesn’t refer to the same person requesting a different certificate even with the same set of domains, but for a different piece of infrastructure.
Tim: I actually think the fact we moved away from the traditional definitions of renewal and rekey is a mistake in the BRs and the traditional concept of renewal and rekey is something we should reintroduce and start using them to talk about some of these flows that are different for the renewal case.
Trev: If we split up “subscriber” it would also help clarify what we care about and mean by renewal.
Michael: Tim, can you clarify what you mean by the traditional definition of rekey and renew?
Tim: Yeah if you look at NIST documents from 1990 or so, you’ll see that renewal is defined as issuing a new certificate based on an existing certificate where the new certificate matches the existing certificate completely except for the notAfter date. And rekey is similar where you’re issuing a new certificate and all the details are absolutely identical except the key is different. You’re rotating a key because of key compromise or similar. Those are both very small modifications that happen with issuance rules that are very different from the Web PKI rules, but basically they have the same effect. They say you’re allowed to rely on the validation of those other fields from the previous certificate to avoid doing revalidation of that information for the new certificate because you’re only doing a renewal; there’s no change of information in the certificate and it was previously trusted so it can still be trusted.
Michael: So by the NIST definition, what is the process that Wayne has written up? Would it be a rekey or a renew? Because I assume that after it’s changing the notAfter date and there’s a new key being generated, which kind of fits both definitions.
Tim: In the language of the current BRs neither of these things actually exist. There’s no such thing as a renewal or a rekey. People colloquially use these expressions to mean a much broader thing, but from the perspective of the BRs it’s just a new certificate that happens to share some information with the previous certificate. And instead of relying on the previous certificate, we have validation reuse requirements which allow reuse of the validation information instead of reuse of the certificate information. Same problem solved in a different way.
Michael: So these are two independent issuance events from the perspective of the BRs.
Dimitris: The BRs don’t say anything about rekeying, but the EV Guidelines do, so there’s some language which describes the rekey (changing the key with the same notAfter date and some exceptions to the validation of the entity).
Wayne: To summarize, we have a second takeaway. My initial idea of splitting out the Initial Request from a Renewal Request was to talk about the possibility of using different validation methods in a CDN workflow. It sounds like there’s a broader discussion that needs to be had around describing the differences between initial issuance, rekeys, renewals, adding/removing SANs (whatever the term may be for that).
Tim: Let me talk through that case a little bit. I mentioned it because a lot of people talk about that as a renewal, but I think the right way of doing that is if you want to take a 2 domain cert and add a 3rd domain, I think the right way of handling that is saying that’s not a renewal, just renew your 2 domain cert continually until you’re ready, and in parallel go through the new issuance process for the 3 domain cert. Go through the normal initial issuance process and go forward that way; if you add a SAN, it’s not a renewal and we say you just go through new issuance.
Wayne: Is there value in distinguishing that case?
Tim: This is an operation that’s common. Having to go through new issuance every time for that might cause people to do weird things. If they’re under the same parent domain, you have an obvious way out, but if it’s unrelated... I’m not sure we’d need to call it out separately in the requirements, but we do need to at least analyze the case of what happens if you’re making a small change to your large infrastructure, like just adding 1 more domain? Can we shortcut things for you or not?
Michael: That’s interesting because it kind of blurs the line between the value that a CDN is adding vs what the CA is, and what the interaction with the CA is. I imagine the CDN would have some type of identifier that would represent this series of certificates that are related associated with certain resources. That can be true, while at the same time the interaction between the CDN and the CA are still initial issuances for each additional SAN that’s being added to the certificate. I don’t know where the BRs should be in that story; whether it should be simply, whether we define what a renewal is in the commonly used sense that we just described, and then everything else is some flavor of initial issuance. Let the CDN manage that connectivity between the different issuances for their customers.
Tobi: Michael just spoke my mind. I would pose it more as a question: Do you think a CDN needs to perform actual renewals as opposed to simply API requests and then tying them together?
Michael: The entire concept of renewal could be managed by the CDN, and to the CA it’s just a series of related issuances that have some commonality between them. The CDN can associate them together.
Tim: There’s also a Step 2; We have the ACME ARI stuff and it’s entirely possible that the renewal is actually initiated by the CA. 
Step 1 discussion:
Michael: On the Renewal Request flow, in 1.a, when you say that there may be a confirmation that the website operator would like to renew, can you provide the rationale behind that comment? Is that related to the previous discussion about the subscriber agreement?
Wayne: It’s more related to A) the potential cost involved, that the website operator would be involved in and B), if it’s an OV/EV cert, the need to engage with the website operator to perform the org validation.
Michael: So it’s more about expressing renewal intent to the CDN, rather than the ability of the CDN to renew the certificate?
Wayne: Yes
Trev: Some of what’s captured in the examples is double-checking with the person that’s paying the bills and some of it is you actually need information from them (like with OV you would need information from them). For the other pieces, unless all the other services that make use of the certificate are free, I’m not sure why we would need to insert a special step to make sure they want to pay for a certificate. There’s an assumption that you’re paying the CDN to host the website, so if you no longer want to pay them to host the website, there’s other non-certificate related things. I think most website operators just want their website to stay up, not most website operators want to confirm every 300 days that they want their website to stay up. We should err on the side of expecting people to opt out, rather than opting in.
Wayne: That’s a good point. I wonder if I should just take this sub-step out; it doesn’t add much to the overall flow.
Trev: I think if you add to it “there may be confirmation with the website operator for cases where additional information is needed to complete the renewal” or something. Or take it out, either way.
Meeting Adjourned
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230407/9110f788/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3621 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230407/9110f788/attachment-0001.p7s>