[cabf_validation] Draft Minutes January 26, 2023, Validation Subcommittee Meeting

[Aneta Wojtczak-Iwanicka]

January 26th, 2023, Validation Subcommittee Meeting


Note taker identified. (Aneta Wojtczak-Iwanicka - Microsoft)

Antitrust Statement: Corey Bonnell read the Antitrust Statement

Attendance:

Aaron Poulsen - (Amazon), Andrea Holland -(VikingCloud),  Aneta Wojtczak-Iwanicka - (Microsoft), Bruce Morton – Entrust, Chris Clements - (Google Chrome), Ben Wilson - (Mozilla), Clint Wilson - (Apple), Corey Rasmussen – OAT, Corey Bonnell - (DigiCert), Dimitris Zacharopoulos - (HARICA), Doug Beattie - (GlobalSign), Dustin Hollenback - (Microsoft), Enrico Entschew - (D-TRUST), Martijn Katerbarg - (Sectigo), Michael Slaughter - (Amazon), Michelle Coon - (OATI), Nargis Mannan - (SecureTrust), Paul van Brouwershaven - (Entrust), Pekka Lahtiharju - (Telia Company), Rebecca Kelley - (Apple), Ryan Dickson - (Google), Tobias Josefowitz - (Opera Software AS), Trevoli Ponds-White - (Amazon), Wayne Thayer - (Fastly), Janet Hines - (VikingCloud)



Minutes:
1/12 VSC minutes (Michael Slaughter) were approved.

Meeting Minutes
1. Review of minute-taker roll. Would anyone like to be added or removed to the roll?
Corey: We have about 7 people right now and we would like to get a couple more folks that would be willing to volunteer to be added to the rotation.
Ryan Dickson, Michael Slaughter, Chris Clements, Janet Hines volunteered to be added to the minute-taker rotation.

2. Certificate Profiles - pull requests review:

  1.
Pull request - Add policyQualifiers -> https://github.com/cabforum/servercert/pull/412<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F412&data=05%7C01%7Canetaw%40microsoft.com%7Cbadfd9c224314897cb1408db08a30e27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638113268635795029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V9KokJW6pU8FTEkvJ4byoZj3WIstiUh%2BEmuvrcA27Es%3D&reserved=0>
Corey: This is a footnote to provide some guidance and some rationale for why the inclusion of policy qualifiers is not recommended.
Corey: Does anyone have any comments on this proposed language?
Ben: Okay, I'm there just a second, let me just read it really quick.
Ben: Okay, thanks.
Corey: Any corrections we need to provide? If not, I guess we can consider this approved then we'll go ahead and merge the same. I'll go ahead and do that after       the call.
Corey: All right, thank you Wayne for this, we'll go ahead and get this merged.

  2.
Pull request - Profiles extended effective date -> https://github.com/cabforum/servercert/pull/413<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F413&data=05%7C01%7Canetaw%40microsoft.com%7Cbadfd9c224314897cb1408db08a30e27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638113268635795029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FbguSj8AmetoVXnlso3oAzLkanRyriiHQ5JEmRav9Ls%3D&reserved=0>
Corey: The profiles extended effective date, so we had some good discussion last time. We decided it'd be good to push out the effective date for a couple more        months to give all CAs a chance to comply. A pretty straightforward change is just changing the effective date from April 15th to September 15th. Does anyone have any objection or any proposed changes that you would like to see in this PR? All right, not hearing anything. We'll go ahead and consider this approved as well, and we'll go ahead and merge that into the branch.

  3.
Pull request - This PR fixes issues in section 7.1.2.7.3 and 7.1.2.7.4 -> https://github.com/cabforum/servercert/pull/416<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F416&data=05%7C01%7Canetaw%40microsoft.com%7Cbadfd9c224314897cb1408db08a30e27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638113268635795029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KGDkX9FlIvP2rM%2Bv8HlxqkqN8ocb0LKNtnzA8Znlubo%3D&reserved=0>
Corey: We have Aneta's change, she noticed a couple fixes that need to be done in the subject attributes for each of the validation level certificate types. It is a good change, and it actually removes a lot of the old text, it isn't really relevant anymore, because you can't put OU in subscribers' certs anymore. This also corrects the typo here at the table header. We can see the inclusion of the domain component attribute as well to provide consistency with the other attributes. Does anyone have any questions or comments on this change?
Corey: All right, not hearing anything we can consider this 3rd PR approved so we'll go ahead and get these merged into the profiles branch.

3. Resume discussion of “Applicant” and “Applicant Representative” from BR section 9.6.3

Corey: So, just to provide some context. I do have a to do list for some of the items that we identified throughout a review of the previous sections. I will be converting those to GitHub issues for project tracking. So, we can divvy those out and make any changes to the BRs if necessary. Continuing the tally here and once we complete this exercise for the BRs, I will go ahead and send that out.
Corey: 9.6.3, so we're basically at the section that defines the subscriber agreement. Essentially all the terms that need to be added to the subscriber agreement. We're looking and seeing where the use of the term's applicant/applicant representative were used. If I recall correctly about a month and a half ago, we had some pretty good, robust discussion in the previous sections, especially around the ca warranties. So, I think we'd like to continue that discussion here. So, we see here in the in the 1st paragraph, we do have some introductory text that does use the word applicant : "The CA SHALL require, as part of the Subscriber Agreement or Terms of Use that the Applicant make the commitments and warranties in this section for the benefit of the CA, and the Certificate Beneficiaries" Does anyone have any comments or questions on the use of the term here?
Ben: The applicant isn't bound I guess until they sign, and then they become the subscriber. So, is it better to use applicant/subscriber? They are the same entity. So, I don't know if that matters, I guess.
Trevoli:  Right after that, it says that you're supposed to make the terms of user subscriber agreement legally enforceable against the applicant not the subscriber.
Ben: Right.
Trevoli: What is weird to me.
Ben: I guess, you know, it's the entity, the fact that they're referred to by a different term here, It does present an interesting legal argument that somebody could make.
Corey: I guess is the argument being that a subscriber after the certificate is issued, only then can they agree to these terms?
Ben: No, I think the applicant agrees and then at some point when the certificate is issued then they are the subscriber.
Trevoli: Don't you become a subscriber when you agree to the subscriber agreement?
Ben: Yeah, that is a good question. I don't know if we want to get wrapped around this too much.
Trevoli: So, I guess here's kind of my question Ben. If you're not a subscriber until we issue a certificate then, why is a subscriber agreement legally enforceable against the applicant? Unrelated to certificate issuance.
Ben: Once you sign an agreement, are you then the subscriber and then regardless of whether the certificate has been issued and if you had a dispute about why the CA did not issue you the certificate or why the CA issued a certificate that was defective. How would you make that claim? Are you making a claim as a subscriber or as an applicant or doesn't really matter? I don't think it really matters.
Dimitris: It's just an additional note here, before the certificate is issued the applicant still needs to agree on some terms about processing their personal data from the CA side, so they do have some rights. Even though there's no certificate issued yet.
Clint: I think there's some parts of the Subscriber Agreement or Terms of Use that apply to the applicant, and the others that apply to the subscriber and maybe some of that apply to both. Would it help clarify this if we let's say something like "is legally enforceable against the applicant and once or if the certificate is issued against the subscriber", just making it explicit that it's both if they both, when the certificate gets issued but it's at least the applicant, regardless of whether the certificate gets issued?
Corey: Wondering if the subsequent paragraphs make that clear, it says: "The CA SHALL implement a process to ensure that each Subscriber Agreement or Terms of Use is legally enforceable against the Applicant." So, I guess part of the CAs obligation is to ensure that that is legally binding. But I guess, maybe you were taking a different angle Clint?
Clint: No, that's the sentence where I was thinking of adding the clarification, legally enforceable against the Applicant and the Subscriber or add the Applicant as a Subscriber. I don't know exactly how to phrase that, but just to link those two, because there is kind of a transition of what this single entity is referred to.
Corey: I see.
Ben: That's why I'm thinking putting a slash might be the best way to even though it doesn't look very good. This whole section, the title, your title is subscriber representations and warranties.
Trevoli: Well, we've already discussed, I think prior the titles of these sections here, not necessarily tethered to how we use them.
Corey: Yeah, I think these section titles are coming right out of RFC3647, and then there's some liveries taken in terms of the actual content within those sections. I feel like the idea of, like applicant/subscriber maybe we could have a defined term that encompasses both, the Applicant and the Subscriber.  I don't know what you would call that, but it basically makes it clear that that's the entity that we're talking about regardless of whether or not the certificates have been issued, and that might be a little more concise applicant slash subscriber.
Trevoli: I mean, I think really for me the problem with this section it just goes back to the discussion we've had before where really over indexes on the 1st certificate.
Corey: Yeah.
Trevoli: The certificates don't even live that long anymore, so I would presume that someone wants a certificate for more than a year. So, like, this whole section is probably an extremely tiny percent of the people that CAs actually deal with.
Corey: Yeah, that makes sense. Is there any other comments on the 1st? Kind of skipped over the 2nd paragraph a little, I guess maybe we covered it, but "Prior to the issuance of a Certificate, the CA SHALL obtain, for the express benefit of the CA and the Certificate Beneficiaries either: 1. The Applicant's agreement to the Subscriber Agreement with the CA,  or 2. The Applicant's acknowledgement of the Terms of Use.". I think the differentiation here is the bandwidth to a few months ago was the Terms of Use relevant to the case where the CA is also issuing end entity certificates to itself.
Ben: So, I'm thinking that, if we have applicant on the one hand, and subscriber on the other hand and we wanted to choose 1 or the other. I'm thinking a subscriber might be better here because it just flows better, and the only other thing that that we would get into is the question about representations and warranties are sort of made before the certificate is issued as to who they are and et cetera, and that everything's accurate in there certificate application.
Trevoli: I liked your 1st suggestion better Ben.
Ben: The slash.
Trevoli: Yeah, I mean, that makes it clear that we literally mean it. So, if the purpose of this section is to say, after they already have a certificate, then the CA still needs to make sure that it's legally enforceable against the Subscriber. I'm not sure if legally enforceable against the applicant is specific to solve a problem related to before you issue them a certificate or if it really means applicant, or a subscriber there as an example, but I assume it means both. It makes sense that in the numbers that's just the applicant. Actually, no it doesn't because you're not a subscriber till you get a certificate. So, you could probably apply for like 10 certificates and they could all be rejected, and you still wouldn't be a subscriber even though you've already agreed to the subscriber agreement.
Bruce: I think you're a subscriber if you've signed the agreement. In the enterprise world I have an company sign an agreement and there can be 150 different applicants for certs, but there's only 1 subscription agreement.
Trevoli: Bruce, that makes more logical sense to me but that's not the definition that we have in the doc, but I would agree with you is the rational definition.
Trevoli: I pasted the definition.
Bruce: We even say an applicant like it says an applicant can apply to have a certificate renewed. So, they're already a subscriber, but they're also an applicant but it might not be the case like an applicant can have a certificate renewed, but they're not the subscriber because their company is a subscriber. It is completely different for an individual than for the corporate world, but this has to cover both.
Clint: They tend to transpose these terms as applicant to certificate requester and subscriber to certificate recipients in my mind because like Trev was saying, it's more logical. The subscriber agreement in my mind covers things like account access and access to portals and software and all sorts of things like that. It has nothing to do with the definition of subscriber here so there's really two definitions of subscriber that CAs are trying to meet. One in the BRs and one outside of the BRs and it is pretty times confusing and convoluted to deal with both of those simultaneously.
Trevoli: Yeah, exactly. I would assume that before you issue a certificate, if you charge money for them, you've probably taken information about a payment device. So, you have made an account and you have probably applied for a subscription.
Corey: So, in terms of next steps here, we're looking for the split between the certificate requester and the certificate recipient but really fundamentally it comes down to we don't really have a clean way of representing the case where the entity already has a certificate but they're applying for additional certificates, and I think this is just another manifestation of that.
Trevoli: I would say, I don't even think of it I like where Clint is going. I didn't even think of it as a certificate recipient. It's the certificate holder because it's issued, it's when they have certificates issued. So it's not even the person that you're going to issue it from or to, it's only after they have a certificate, are they subscriber? It's just weird, but that's the words in the BRs.
Corey: All right, so "The CA MAY use an electronic or "click-through" Agreement provided that the CA has determined..." . So, it's basically saying you can have a checkbox on your webpage or a flag in your API. "A separate Agreement MAY be used for each certificate request, or a single Agreement May be used to cover multiple future certificate requests and the resulting Certificates, so long as each Certificate that the CA issues to the Applicant is clearly covered by that Subscriber Agreement or Terms of Use". So, I guess it's interesting to me, it is clearly covered now. I'm not really a lawyer, but I guess that would mean that the certificate requests for subsequent certificates, the previously signed subscriber agreement is also legally enforceable in terms of use for the additional certificates.
Ben:  Yeah, that's how it would work.
Clint: Yeah, I sort of read this as addressing the case that the term brought up where it's like you're an applicant every time you ask for a certificate and how does that work but they're an applicant. They get their first certificate and that's maybe wide over indexes on first certificate because of the specs. Most CAs follow the second half of this clause of using a single agreement to cover all of the certificates they issue after the first one, as long as that agreement encompasses the types of certificates that they're requesting on each subsequent request.
Trevoli: My two suggestions maybe making us more clear as spins for suggestion of just putting the applicant slash subscriber everywhere pretty much where it's like the same thing, or just literally split the section up into two sections. The first time an entity or an applicant gets a certificate from a CA, blah, blah, blah to all of this stuff and then say like thereafter. After whatever do all this stuff with the subscriber, you could just rewrite the section to be clear.  Maybe we specifically would want to say that there's some rules related to how you change the subscriber agreement if someone's already a subscriber. I don't want to do anything extra, but I'm just throwing it out there. Maybe you want to do that, but the easiest thing would probably say applicant versus subscriber.
Corey:  Maybe the splitting of the different sub sections and division of obligations to the first one and the subsequent certs. if we take a look at the required terms that we have to have within a subscriber agreement, maybe we can see if there would be value in splitting those out.
Trevoli: Yeah.
Corey: All right. So, we're seeing that "The Subscriber Agreement or Terms of Use Must contain provisions imposing on the Applicant itself (or made by the applicant on behalf of its principal or agent under a subcontractor or hosting service relationship the following obligations and warranties". There is that hosting service relationship again we've seen that in a couple other places in the BRs. "1st Accuracy of Information: An obligation and warranty provide accurate and complete information at all times to the CA, both in the certificate requests and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA. 2nd Protection of the Private Key: An obligation and warranty by the Applicant to take all reasonable measures to assure control of, keep confidential, and properly protect at all times the Private key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token); The 3rd, The Acceptance of the Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy;"
Ben: Did you notice the switch?
Corey: Yes, and I'm wondering if that's because once they accept the certificate since the certificates been issued, they are now a subscriber as opposed to an applicant Tobias: And there is a definition in 1.6.1 that says exactly that.
Clint: Yes, so kind of goes back to my earlier point a subscriber agreement covers both applicant and subscriber, so to transplant, maybe that's the simplest thing is you just put applicants slash subscriber in a couple of locations where it's clearly intended to apply to both.
Tobias: It's the same entity. It's just different roles but they fill in the interaction. I mean the definition in 1.6.1. says : "The natural person or legal entity that applies for (or sees renewal of) a Certificate. Once the Certificate is issued, the Applicant is referred to as the Subscriber". So, it's the same entity and you can be an applicant while you're a subscriber in relation to another certificate.
Corey: All right, so it looks like for this particular sub item for number 3 it looks like we might want to consider and the other items as well, the applicants slash subscriber just to cover the case where certificates have previously been issued. It's clear that these obligations are relevant to them. Is there any comment on Accuracy of Information and Protection of private key? All right, moving on to use the cert, "Use of Certificate: An obligation and warranty to install the certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate, solely in compliance with all applicable laws and solely in accordance with the Subscriber agreement or Terms of Use". Rather interesting requirement, I think. I suppose that's some type of mitigation against fishing, but if you have a server misconfiguration and add a new host name for your server or you delete a host name from your server. You reconfigure your servers such that your certificate installed where it's not with one of the subjectAltNames, this is no longer relevant technically violating subscriber agreement, which is rather interesting.
Clint: Even just the word installed a certificate, it's just a file sitting there. Did I transfer the file on the server? Is that installed? Is it configuration? This one seems a little bit wonky.
Trevoli: Yeah, I was wondering too that things like that do not work. Just like, I do not know, maybe it used to work in the olden days whenever this was written.
Ben:  Do we want to put a flag on this and come back to it another day? This is something we should really look into.
Clint: The second part seems fine. It's just the first part, right?
Trevoli: The second part seems totally logical.
Ben: Well, the first part probably came from somewhere that had some other language and then we replaced server with servers and subjecAltNames. This idea came from somewhere and was modified for this purpose.
Tobias: I would be fine with removing the 1st part.
Trevoli: Yeah, let's make it a to do. Let's just remove the first sentence.
Corey: Yeah, I'm adding it right now.
Trevoli:  You can easily just put that in your subscriber agreement as well.
Tobias: And also, why would you?
Trevoli: I totally agree. I'm just saying if it's super important to you. You could put it in there.
Corey: The CA specific term you mean?
Trevoli: Yes. You know, if you're like paranoid people are going to install a certificate on a server where they won't work on you care about that.
Corey:  All right, for the fifth item, we have:  "Reporting and Revocation: An obligation and warranty to: a. promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and b. promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate; ".On the first read, I think it sounds pretty reasonable. Did anyone have any comments on that one?
Tobias:  We discussed this right and it's rather obvious that we can't actually expect any subscriber to do this. No, at least not a high percentage of them. I think it's more than that gives us a legal reason to act in case something like this happens.
Trevoli: Isn't that the entire purpose of this? On the off-chance CA decides to sue someone.
Tobias: Yeah, exactly. No, besides it is just basically so then the CA can revoke.
Trevoli: Yes, this exists just so we can say like tough. We're rocking it. You agreed to it.
Corey: All right, "Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise."
Trevoli: Yes, I would say, totally, I want to talk about things that probably will never happen. It is 6.
Corey: Yeah, especially since it hard to say every use of the private key. So, even if you have like a cert issued off a private PKI. It just so happens to certify the public key for that compromised private key technically according to this, you have to stop using that cert too. I'm not sure if we want to do anything about that but I guess those are the rules.
Trevoli: I only care about doing something about it if someone is going get mad, if a CA decides not to ever go after this or enforce it.
Corey: All right, given the lack of any strong desire to modify these things, moving on to "Responsiveness: An obligation to respond to the CA’s instructions concerning Key Compromise or Certificate misuse within a specified time period".
Trevoli: It seems like the same as 5 except that I doubt anyone could reasonably put in there and you need to respond if we tell you on a day that your company is closed for key compromise you need to respond to us.
Corey: 24 hours, for certain subscribers, I imagine that is probably next to impossible in certain circumstances.
Tobias:  It's the same thing I didn't really like it, but a certificate is revoked if there is no response.
Corey: All right, "Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if revocation is required by the CA’s CP, CPS, or these Baseline Requirements.". So, I think this is kind of just the cover all for all the things that we just discussed.
Clint: It seems like one of the more important ones to have.
Corey: Yes, I think this was actually added at some point, I think it was SC-30 or SC-31. It was like clean up some clarifications ballot about a couple of years ago, I think it was added. All right, any further discussion on 9.6.3? if not, I think we are getting close to the end. We'll go to jump in at 9.8, really quick to see if there's anything relevant here. "If the CA has not issued or managed the Certificate in compliance with these Requirements and its Certificate Policy and/or Certification Practice Statement, the CA MAY seek to limit its liability to the Subscriber and to Relying Parties, regardless of the cause of action or legal theory involved, for any and all claims, losses or damages suffered as a result of the use or reliance on such Certificate by any appropriate means that the CA desires." Any other comments on that particular passage?
Trevoli: If the lawyers don't care about it, I don't care about it.
Corey: Yeah, clearly an engineer wrote this passage. Indemnities: "Notwithstanding any limitations on its liability to Subscribers and Relying Parties, the CA understands and acknowledges that the Application Software Suppliers who have a Root Certificate distribution agreement in place with the Root CA do not assume any obligation or potential liability of the CA under these Requirements or that otherwise might exist because of the issuance or maintenance of Certificates or reliance thereon by Relying Parties or others." I don't think this is directly relevant to what we were looking at, or what we are scanning for. Any discussion on this?
Ben: Just like a flag for everyone to put in their hat and that is that at some point, I'm going to want to revise this because Mozilla doesn't have Roots certificate distribution agreements in place. We agree to distribute, but we don't have an agreement in place. It's not really an agreement. We can take it, so we would like to be identified despite this provision, or we would like to revise this, so that it says something other than having a root certificate distribution agreement in place.
Tobias: You talk to your legal department they will probably, but I don't know, but time they might say something like, it doesn't look like an agreement, but it is an agreement.
Ben: Well, we don't have one so that is just an FYI, make a flag thanks.
Corey:  Thanks, Ben. Yeah, I think some root programs they do have. I think Microsoft, they stated publicly they do have such agreements in place.
Ben: This was really written for Microsoft's benefit.
Corey: I see. Okay, well, that makes sense then.
Dimitris: Especially if you look at the second part. It has actually allowed subscribers/relying parties to file claims against the application software suppliers. They directly cause a certificate to be displayed as not trustworthy. It looks like it probably came from the eighties or something.
Ben: I don't think we talk about subscriber indemnities. Most CAs probably in their sections of their cps's would say subscribers or applicants are supposed to indemnify CAs for misrepresentations. if you're the victim of an imposter you don't have to get to indemnify because you're not really the party that made the allegations or made the representations to obtain the certificate, but if you were able to get that person that applicant who wasn't really the lawful person then you could go after them for some kind of misrepresentation unless they are judgement proof, or you can find them.
Dimitris: I think other than Microsoft, other root programs don't have a specific agreement signed, so you're holding the same boat.
Ben: What happens is a lot of CAs will just copy this language into their CP and CPS and I will make a comment that we don't like that language because we wanted to cover us too, so I'll have them replace the contract language with something more vague.
Trevoli: Well, let's definitely update it then it's going make everyone change it in their CP if it's in their CP. Action item that's what I got out of this.
Corey: So, it looks like Ben, you'll be driving this change.
Ben: Yes, when I find time. Okay, it's not a high priority. It's a back burner.
Corey: All right, I think we are at the end. I think we made it all the way through the BRs and we have quite a to do list here that probably has at least a dozen items in it. So, I will clean up that list and circulate it before the next call and then we can start identifying the high priority items that we'd like to address through this work. So, I think this is a good exercise, at least in my case, I wanted a couple of things from this close reading of the BRs I hope, you know, everyone else did as well. So, I think this is a good exercise. We just have to take the next steps.
Doug: Quick question on that, how does this ballot going to relate to the profiles ballot? Is it going to be an add on to the profile's ballot? How are we going to roll this out?
Corey: This is an entirely different effort. There is not a lot of clarity right now in the BRs in terms of the difference between an applicant and a subscriber and some of the obligations relating to the CAs. So, this is an entirely different effort from profiles ballot. This is kind of like another major piece of work that we would like to tackle.
Trevoli: I would hope that we don't do it as one ballot unless we identify places where that makes sense, but it seems like a lot of the action items were kind of disparate to a section, some of them. So, like case by case.
Doug: So, when you do a ballot, it'll be based on the baseline of the proposed ballot. You see what I mean, there might be conflicting changes.
Trevoli: Yeah, so not optimistic. I am optimistic that we will pass the certificate profiles ballot, and that will be the official BRs before we even get to writing up a ballot for one of these changes, I believe in us.
Doug: Okay, that answers my question. Yeah, yeah, I know the motivation for the profiles pilot.
Corey: I think in this case, though what was nice about this work is that it largely doesn't touch section 7. I think we all want the profiles ballot to pass, and it sounds like there's good agreement and good consensus on the content. I see this work is largely independent of that, just given that we're touching different parts of the BRs for this work. I think section 7, I don't think had really anything a substance in terms of this analysis. All right, so I will take an action item prior to the next call to circulate the to do list and we'll go ahead and discuss and identify the higher priority items that we want to address first for this. Thank you everybody.  I think we have about just one minute left, so we'll just wrap up now. The next meeting will be February 9th.
Dimitris: Cory, just for the next agenda, we should start discussing items for the F2F.
Corey: You're right, that's only a month away. Yes, we'll definitely do that. Thank you everybody.

Meeting adjourned.

Thanks,
Aneta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230207/2a53a9df/attachment-0001.html>