From dzacharo at harica.gr Thu Dec 2 13:07:00 2021 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Thu, 2 Dec 2021 15:07:00 +0200 Subject: [cabf_validation] deprecation of v2 Onion addresses in EV Certificates Message-ID: <72d76b40-5478-7cda-1933-267a647be942@harica.gr> Based on https://github.com/cabforum/servercert/issues/191, should we proceed with a ballot to deprecate Onion v2 addresses in EV Certificates? 2021-10-15 was the date when v2 stopped working everywhere. Could we briefly discuss about it during today's meeting? Thanks, Dimitris. From tim.hollebeek at digicert.com Thu Dec 2 20:41:40 2021 From: tim.hollebeek at digicert.com (Tim Hollebeek) Date: Thu, 2 Dec 2021 20:41:40 +0000 Subject: [cabf_validation] Method 7, when the CA is involved Message-ID: As discussed on the November 18th validation subcommittee call, I offered to write some text that would clarify the importance of binding the request to the customer when doing method 7, for CAs that allow DNS delegation to a domain they control. For the purposes of starting the discussion, what about adding the following text to the end of Method 7 (3.2.2.4.7), before the ubiquitous Note: --- CAs MAY operate domains for the purpose of assisting customers with this validation, and MAY instruct customers to add a CNAME redirect from an Authorization Domain Name to such a domain. If the CA does so, the CA SHALL ensure that each domain name is used for a unique Applicant, and not shared across multiple Applicants. --- This at least fixes the urgent problem, which is that some CAs might currently be doing this in insecure ways. -Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4940 bytes Desc: not available URL: From wthayer at gmail.com Mon Dec 13 16:36:15 2021 From: wthayer at gmail.com (Wayne Thayer) Date: Mon, 13 Dec 2021 09:36:15 -0700 Subject: [cabf_validation] Multi-perspective Domain Validation Downgrade Attack Paper Message-ID: The Validation subcommittee has discussed mitigations to DNS hijacking attacks on domain validation a few times in the past without making much progress on a policy solution. Some interesting research was recently published that makes it clear that this problem is not easy to solve: https://dl.acm.org/doi/pdf/10.1145/3460120.3484815 This might be worth some further discussion on an upcoming Validation subcommittee call. Thanks, Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: From anetaw at microsoft.com Tue Dec 14 18:04:05 2021 From: anetaw at microsoft.com (Aneta Wojtczak-Iwanicka) Date: Tue, 14 Dec 2021 18:04:05 +0000 Subject: [cabf_validation] 2021-12-02 Meeting Minutes In-Reply-To: References: Message-ID: These are the Draft Minutes of the Teleconference described in the subject of this message as prepared by Aneta Wojtczak-Iwanicka (Microsoft). Please review the minutes and propose edits if necessary. These minutes will be considered for approval at the next meeting. The recording of the meeting will be deleted once the minutes are approved. Attendees (in alphabetical order) Amanda Mendieta, Andrea Holland, Aneta Wojtczak, Ben Wilson, Bruce Morton, Clint Wilson, Corey Bonnell, Dimitris Zacharopoulos, Doug Beattie, Janet Hines, Joanna Fox, Kati Davids, Martjin Katerbarg, Paul van Brouwershaven, Rebecca Kelley, Ryan Dickson, Thomas Zermeno, Tim Hollebeek, Trevoli Ponds-White, Wayne Thayer Agenda 1. CRL validity period ballot (SC52) 2. Onion V2 address validation 3. CNAME delegation 1. Minutes Preparation * The recording started * Roll call was taken by Tim * The antitrust statement was read by Tim * Minute taker was assigned (Aneta) CRL validity period ballot (SC52): Tim: SC52 did get reposted with the changes related to leap seconds that we got from the comments on the server certificate mailing list. I also added, in response to Dimitris email, some text to the preamble saying that the purpose of specifying thing in seconds is clarity and it is not meant to imply anything about how important the particular time periods are. It is just providing additional clarity. I did just want to call out that the ballot is not intended to say that compliance with various periods like your audit report down to the second is somehow more important that it was before this version. It is neither more or less important. It is just making it absolutely clear what is compliant and what is not compliant. It is up to the Root programs to guide what they care about, how much they care about individual violations and what they do about that. Dimitris: I do not really think it addresses the issue. I think it makes it a little worse because the Root programs can then interpret this statement arbitrarily and the CA wouldn't know if missing a deadline by a few seconds is critical in one Root program and not critical in another root program. So, in my opinion unless we resolve it in a very clear and concise language, we may need to probably remove that part. Tim: I would argue we are in that world today, Dimitri. The Root programs are able to do what I said, and it is up to them how they enforce things. The only difference between where we are today is, where we are today it is unclear exactly what the endpoint is on those periods that are left poorly specified and after the changes to measure them in seconds for better or worse you know exactly down to the seconds what the proper time period is. The ballot does not change anything about how the standards should be enforced. If we want to go further and put some specific language in the BRs about that sort of thing, we could, but this is beyond the scope of the current ballot. Dimitris: I can just add a proposal for 1.6.4 addition that says "a difference of 3600 seconds shall be equal to one hour". If we really want this to be just a guidance, then we should try to remove confusing language like "shall be". The "shall be here" is following the technical language of the the BRs. If we want it to be a guidance, then we should try to remove confusing language like "shall be", "it is expected to be", " it intended to be" to be more descriptive. Tim: That's why I put the "no more no less important" because I wanted to avoid what you are saying - the idea that by making the requirement clear about what is or is not allowed, I do not want to change it to "this is just guidance". It was previously a requirement, it is an absolute requirement it is not the guidance. It is an absolute requirement with an unclear end date. There was some dispute over what end dates are and are not compliant for this various time periods. We see all different bugs filed that this or that is missed by a second, we need a clarity on what the requirement is and that clarity on what the requirement is, in no way changes the enforcement of the requirement. This is what I was trying to say in preamble, this just provides absolute clarity about how to calculate day/time differences. It does not in any way change anything about the importance of being compliant with those requirements. Dimitris: For CRLs and OCSP it is very clear that 1 second accuracy is expected and that's undeniable. I just want to understand if we were to remove the sentence in 1.6.4 would it jeopardized that accuracy for CRL and OCSP? Tim: This is an interesting point to talk about, as this is actually the thing we're disagreeing on. You would prefer something that is scoped to OCSP and CRL. Is that correct? Dimitris: Yes Tim: The reason I would prefer to not to do that is because I do not want to have to come back and do it periodically for every date that is in the BRs. I would prefer consistent rules across the entire BRs about how you are calculating time periods and all the deadlines. Dimitris: Going through the BRs and EV guidelines and finding all dates and duration and having to match whether they meet this definition is a ton of work for no clear benefit. Tim: If the majority of people want to go into other direction, I would be fine with changing it. It is just not my preference. Clint: I tend to agree with you Tim just having this out of the way and clarified seems worthwhile. If there are misunderstandings of certain sections in the future those can be changed but this way, we have a baseline that is consistent, and I doubt that there will be much to change in the future as if we narrowly scope it there will be more ballots in the future on this topic. Dimitris: Unless we have another person on the call to give us their point of view what they would expect from OCSP and how their CA would have to prove that they comply with this requirement for every single date duration. Clint: It seems that it is easy to comply by being lower than the upper bound by some significant margin. Dimitris: The problem is that the tools that are out there whenever you need to schedule something, and that was exactly the reason why I switched from a specific number of days in Network security requirements to months was preciously to avoid that. For example, you calculate that you need to execute a script once a month at the first day of every month, sometimes it will be 31 days sometimes 30 and that is ok, but if you want to be precise to the days it creates difficulties in many different systems. It is not easy to fix that. Clint: I am not clear of what those difficulties would be, so it would be worth listing out or clarifying more where are the challenges with days vs months specificity. Dimitris: I can get some more feedback from my team and share that with the group. Tim: That would be useful. This was the initial concern of mine as well that there are unexpected consequences that we are going end up regretting. We looked into it and our analysis showed what Clint said: if you are already a little bit conservative with your compliance dates just to avoid situations when somebody is out for a day and you miss something (set something for 4 weeks instead of month). Little tweaks like this can help you out. If they are counter examples, please share them. Onion V2 address validation: Dimitris: Onion version 2 addresses are no longer acceptable. Maybe it is worth to work on a ballot to deprecate that and maybe it is an opportunity to fix all the other onion issues that we have open on GitHub. Tim: it is a good idea. There are still a very large companies that are using v2 addresses I am not entirely sure why. We can try to reach out to them and see if we can get some more feedback on why v2 onions are still in use. Dimitris: we can prepare a ballot that phases out version 2 and if there are legitimate use cases out there that would help in the deprecation timeline, we can certainly fix that and take this into account. Tim: Yes, we are going to reach out to them and get some more information and we will provide feedback to the group why these are still out there and if this is just a matter of a transition that has not completed yet or what is going on. We will get some clarity on why they still exist. Dimitris: OK, great. Tim: You mentioned a couple of the other issues. Do you know specifically of top of your head the ones you were thinking of? Dimitris: Yes, I looked at the open issues and there are challenges about CAA requirements. What would be the CAA requirements for the onion addresses? It is more of a clarification on the CAA section. For example Onions are not real DNS addresses, so we need to tweak the language so that they are excluded, or I am not sure how we are going to fix that. Ryan Sleevi, I think recommended some language there. So, it is a good opportunity to catch all these onion issues. I think there are about 7 issues open regarding Onion and we can tackle them all together or separately. Tim: You are right. It may be worth tackling them all at the same time and no have to come back there on a regular basis. Wayne: I want to change a subject and ask about CNAME delegation. Tim: I still owe text on that as well. Dimitris: Just before changing the subject, will anyone else be interested in working with me on a ballot for the onion stuff? Wayne: I would be happy to help with that Dimitris. CNAME delegation: Tim: CNAME delegation - I owe text on this I should give it out to the list today because I am off on vacation starting tomorrow. So, thank you reminding me about that one. Wayne: Ok great, I am looking forward to seeing that so let me know if I can help with that. Tim: Maybe you and Corey can run with that when I am out. Wayne: You mean propose the text or you mean you will propose the text and then we will take it further. Tim: I will propose text and then you guys can take it from there. Wayne: Ok, great. Corey: Dimitris, if you want in addition to Wayne someone else to work with in addition on the tor ballot, I will be happy to do that as well. Dimitris: Fantastic. Tim: Anything else to discuss today? Tim: Next meeting is on December 16th. Meeting adjourned. Thanks, Aneta -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzacharo at harica.gr Wed Dec 15 05:40:12 2021 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Wed, 15 Dec 2021 07:40:12 +0200 Subject: [cabf_validation] 2021-12-02 Meeting Minutes In-Reply-To: <0100017dba1ddaea-3e7d468a-aa1f-4a68-8a7c-9e1d4e08b7ac-000000@email.amazonses.com> References: <0100017dba1ddaea-3e7d468a-aa1f-4a68-8a7c-9e1d4e08b7ac-000000@email.amazonses.com> Message-ID: <8bb4805c-9c25-df01-66bf-a3ce0fee118e@harica.gr> On 14/12/2021 8:04 ?.?., Aneta Wojtczak-Iwanicka via Validation wrote: > Dimitris: The problem is that the tools that are out there whenever > you need to schedule something, and that was exactly the reason why I > switched from a specific number of days in Network security > requirements to months was preciously to avoid that. For example, you > calculate that you need to execute a script once a month at the first > day of every month, sometimes it will be 31 days sometimes 30 and that > is ok, but if you want to be precise to the days it creates > difficulties in many different systems. It is not easy to fix that. I don't believe I could single-handedly change the Network Security Requirements so it might be more accurate to state: "and that was exactly the reason why*the SCWG* switched from a specific number of days in Network security requirements to months was preciously to avoid that" for the final minutes :-) Cheers, Dimitris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corey.Bonnell at digicert.com Wed Dec 15 16:35:29 2021 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Wed, 15 Dec 2021 16:35:29 +0000 Subject: [cabf_validation] Profiles ballot - next steps for open discussion items Message-ID: Hello, I reviewed the meeting minutes [1] of our very productive discussion of the profiles ballot last month and distilled the discussion into the following list of items that have yet to be addressed. Please reply to this message if you know of other items that are still open but aren't listed. Here are the 11 items I identified from the meeting minutes alongside some proposed text for some items. Several of the items are still open-ended and require further discussion before we can develop concrete text proposals: 1. Cross Certificates must have EKUs Move to separate ballot 2. First policy OID must be CABF reserved OID Change to a SHOULD, then consider changing to a MUST in "profiles v2.0" 3. Changes to Name Constraints Drop specification around sRVNames entirely 4. Cross Certificates Current text at https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2 ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1856: "Provided that the Issuing CA has confirmed that the existing CA Certificate was issued in compliance with the then-current version of the Baseline Requirements, the Issuing CA MAY deviate from the requirements in [Section 7.1.4](#714-name-forms) as follows: The encoded `subject` name shall be byte-for-byte identical to the encoded `subject` name of the existing CA Certificate." Does this address the concern surrounding legacy names? 5. AKI/SKI AKIs in roots: do we have follow-up for why this should be a SHOULD? https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2 ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR2797 "Uniqueness": RFC 5280 and RFC 7093 make it clear that AKI and SKI values are not security relevant. Why are we mandating this? 6. certificatePolicies in OCSP responder certificates https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2 ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR2404 Change the MUST NOT to a SHOULD NOT, or MAY? 7. QCStatements as a SHOULD NOT https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2 ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR2260 Change SHOULD NOT to a MAY? 8. Serial number "MUST be a number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG." 9. Non-TLS CAs This is still very much an open-ended question. We likely will need at least one whole meeting on this topic. 10. (Domain Names in Subject Fields requiring DCV, example given was O=SSL.com) Current proposal: https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2 ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR2950 Change to: "Subject commonName attributes MUST NOT..."? 11. Backdating https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2 ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR2128 Change Description to "MUST represent time of signature plus or minus 48 hours"? [1] https://lists.cabforum.org/pipermail/validation/2021-November/001728.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4990 bytes Desc: not available URL: From bwilson at mozilla.com Tue Dec 21 21:25:03 2021 From: bwilson at mozilla.com (Ben Wilson) Date: Tue, 21 Dec 2021 14:25:03 -0700 Subject: [cabf_validation] Draft Meeting Minutes from 16-December-2021 Message-ID: *Validation Subcommittee Meeting of Thursday, December 16, 2021* *Roll Call:* Ben Wilson, Corey Bonnell, Tim Hollebeek, Wayne Thayer, Ryan Dickson, Paul van Brouwershaven, Andrea Holland, Aneta Wojtczak, Brittany Randall, Bruce Morton, Clint Wilson, Dimitris Zacharopoulos, Janet Hines, Joanna Fox, Jose Guzman, Kati Davids, Kidd Freeman (OATI), Michael Slaughter, Martijn Katerbarg, Natalia Kotliarsky, Pekka Lahtiharju, Rebecca Kelley, Tobias Josefowitz, Trev Ponds-White, Tyler Myers, and I?igo Barreira *Antitrust Statement:* Read by Tim. *Agenda* was reviewed. *Next Call:* Call of December 30, 2021, is cancelled. Next call is January 13, 2022. *Vulnerabilities of Distributed Domain Validation* We discussed the recent research paper ( https://dl.acm.org/doi/pdf/10.1145/3460120.3484815) introduced by Wayne Thayer to the mailing list on multi-perspective DNS validation to prevent certificate misissuance due to DNS hijacking. Let?s Encrypt has implemented multi-perspective domain validation. We might want to invite the authors of this recent paper to present to us. Wayne explained that the researchers performed downgrade attacks. A CA queries DNS from multiple points, but the attacker eliminates some to where the system is forced down into only using one. The attacks degrade DNS responses on the other points and then you attack just the one that is remaining with cache poisoning, route hijacking, etc. Wayne asked whether the Validation Subcommittee was the right group to tackle this issue with requirements aimed at closing down some of the vulnerabilities. He noted that the research paper hints at ways that the attacks could be mitigated to some extent. Paul said it might be something for the NetSec group to address because a couple of the recommendations were RPKI and DNSSEC. Many DNS servers automatically select the best performing authoritative DNS server. By attacking by overloading DNS servers with queries, it could result that the attacker?s DNS server becomes the best performing DNS server. One of the strategies is to randomly select DNS servers so that even poorly performing ones are queried. Paul said that NetSec might more appropriate because things like RPKI are a best practice for anyone operating a network. Cloudflare and others have had success in implementing RPKI to prevent these kinds of things from happening. It would help if CAs were required to run their own infrastructure behind a network that is protected by RPKI. For random selection for DNS lookup, that might be a NetSec issue, too. Tim noted that these methods may not be specific to CAs only, and that it could just be considered good practice. Tim said that NetSec is traditionally focused on protecting CA systems from external attacks, but technical details of validation would be better addressed in the Validation Subcommittee, and that is why we previously discussed multi-perspective validation. Paul agreed that it would still be within the Validation Subcommittee?s purview, and we could come forth with technical requirements. Tim noted that when we discussed multi-perspective validation previously, and as he recalled without looking at the discussions, there may have been hesitation due to issues with practice and scale that caused people to not move forward with it as a requirement. Dimitris recalled that we discussed requiring RPKI, which basically accepts only signed route objects, and whether the CA needs to have its own infrastructure for this and must follow this method, or whether upstream service providers could be required by the CA to implement this. A CA that does one or the other has a better chance of mitigating these types of attacks. Paul said it depends, because if you use an upstream ISP, the ISP should use RPKI not just for you as the CA, but because it is an ISP, but some ISPs might say that they don?t have that capability. The other challenge is that you can do it as an authoritative source (someone cannot fake to be you), intercepting and proxying response codes. But it is really about the subscriber target you are checking, if they are not doing RPKI as well, then the attack could still happen on their side. It might be good to make these things long-term requirements. If it were a requirement for ISPs of CAs, then it could help add pressure on the ISPs to implement it because if you are not going to do this, then we need to go somewhere else. Tim stated that it would be good to find out who is doing it and that the CA market might not be big enough to push ISPs in any significant way. Paul ? You can use RIPE Stat (https://stat.ripe.net/) you can enter your IP address to see if it is announcing an RPKI record. So, it?s really easy to see if your network is protected. More and more RPKI is becoming a required practice. Tobias asked how would RPKI mitigate these attacks? Paul responded that the research paper describes how the attacker would capture packets, re-encode them, proxies them, etc. Tobias said but everybody needs to use it. Paul said yes, but the attack was also implemented on the CA side as well. Tobias said that if RPKI were deployed, then we wouldn?t need multi-perspective validation to begin with. Paul said the challenge would be how to get subscribers to implement RPKI, but CAs need to step up and begin implementing it themselves, like Cloudflare has done. Dimitris said it?s partially mitigated unless everybody implements RPKI. Wayne noted that we should not focus just on RPKI because it is only one of the mitigations, and multi-perspective validation is better than validation being done by CAs today. There are things we could do here, such as improving authoritative name server selection. There are things that can be done here or in NetSec to improve from single-point validation to multi-point validation. It is a matter of resources and time as to the progress we can make on addressing these issues. Tim said that looking at this in depth will be more helpful than just having various people saying that CAs should be doing various things. Tim will see if we can speak with the authors. Paul agreed that it would useful and that we should also be looking to see what solutions are easier for CAs to implement in the short term. We should look at the effort needed for CAs to take in order to get us where we want to be (e.g. an analysis of the costs, burdens and benefits). *Ballot SC-52 - Time Intervals for CRLs* See discussion at https://lists.cabforum.org/pipermail/validation/2021-November/001724.html. We discussed whether we should put time frames in terms of seconds in the Baseline Requirements. Dimitris said he wanted a few more days to consult with his team before we started a vote. Tim said that would be fine. Wayne asked when the ballot discussion period would expire and whether we needed to refresh the ballot or start voting now because we don?t want to be voting during the holidays. Tim said he would work on a refresh it and put it out on January 3, 2022, for voting. *CNAME delegation to the CA* Discussions about CNAME delegation have previously occurred. See https://lists.cabforum.org/pipermail/validation/2021-December/001734.html. Discussions have revolved around the purpose of the CA going through the effort of retrieving a token that they put there and whether that tests that the customer still has the delegation in place at the time of issuance. Wayne said he liked Tim?s proposal, but his concern is that it changes the requirement for the applicant to demonstrate control of time at time of issuance to require once at time of initial issuance and to leave it in place until they revoke it. His concerns are about renewals where a CNAME has been delegated to a CA, the CA is going to check it to make sure that the CNAME is there, but the applicant is no longer involved. That differs from the other methods where we require the applicant?s involvement. Tim agreed that it is qualitatively different and that we should discuss whether it is good and if there are concerns. Wayne said that it makes automation of certificate issuance easier, as long as it?s secure. A random value is only value for 30 days, and why can this be different. Tim said, ?If there are problems with the method, the fact that the CA is involved, ? if there is anything going wrong, then there may be problems with some of the CDN providers ... ? Do we need to revisit that, and if so, what security analysis do we need to do? Wayne said that the distinction, from the CA?s perspective, is that if the CDN is requesting the certificate, they are the applicant, legal issues aside. From a CA?s perspective, the applicant is demonstrating control, but when the CA is doing it, that is not the applicant demonstrating control. But what about Google, Apple, etc. getting certificates from themselves? What if the organization is both the CA and the Applicant? Tim that is a known problem with the BRs today, similar to whether a CA can generate the keys if it is also the applicant. Wayne said the problem is the argument that if you are the CA, then you can?t also be the applicant. Tim said we should fix these inconsistencies. Corey noted that the requirement that the CA provide test websites with certificates raises a similar question. Wayne asked, in the case where the CA is not allowed to do something, because it is validation, can the CA claim an exception because it is doing it as the applicant? Tim said the requirements contradict themselves on what to do when the CA is the applicant. Wayne asked whether this is a ?fail-closed? situation? Tim wondered whether CAs would have to revoke the certificates on their test websites, and Wayne said it depends on what validation methods were used. Ben said that if we go too far down with the analysis it gets to the point of absurdum. Tim said we should amend the requirements to address, ?when the CA is the Applicant? and specify that when it is doing CA things, it follows CA requirements and when it is doing applicant tasks, it follows applicant requirements, and when there is a contradiction, resolve it to say that the CA needs to do nothing special from what they were otherwise doing. Wayne said that would solve the problem here, for the most part. Clarification works that any of these validation methods have to be tied to a particular customer account. Tim said it would clarify and one could argue that the ?MAY? language is useful because it indicates that it is allowed behavior by the CA. It clears up the ambiguity of whether the customer is allowed to delegate to the CA or not. Dimitris asked how would this account-focusing part work with ACME? Tim said he thought this would work better with ACME because you already have the account separation. Corey said that the applicant would create a one-time CNAME for the ACME challenge subdomain for the CA. If you?re using a particular ACME client, Certbot, then it can do the DNS, you could set up the DNS challenge on your behalf. You could have the client skip that part and have it delegated to the CA, and it publishes the challenge. There is limited benefit, I guess. Tim ? The ACME protocol could be upgraded to handle this better. Because if the ACME protocol allowed you to specify that the CNAME delegation was already in place, then people could use that instead of the new URL. Certbot would need to be updated to be aware of this method of validation. Wayne suggested that the ballot be circulated for discussion. Tim will propose a ballot. Ben and Clint will look at the draft ballot and let Tim know whether they?ll be able to endorse. *Certificate Profile Suggestions* See Corey?s email - https://lists.cabforum.org/pipermail/validation/2021-December/001738.html. Ryan Dickson said that he had argued previously to keep the requirement for an AKI in self-signed root certificates. As he understands it, Windows, MacOS, and maybe Adobe use AKI and SKI as part of path building. Chrome is looking to move away from platform verifiers, so the concern for Chrome is not particularly long-lived, and others have not voiced interest in keeping the requirement. So I?m fine with going ahead and removing it from the draft ballot as Corey had suggested. Ryan D. said that a second issue is cross-certificates requiring EKUs. What is being changed? Isn?t this more of a dis-ambiguation? BR section 7.1.2.2 says the EKU MAY be present for what we are re-phrasing as affiliated cross certificates. ?EKU may be present? is equivalent to either presence or absence of the EKU. We need to be mindful of affiliated cross certificates and non-affiliated cross certificates. For affiliated cross certificates, the proposed language is a ?SHOULD.? Functionally, I don?t see it as different. Only change is that affiliated CAs we?re going from ?May? to ?Should?. For unaffiliated cross certificates, the current language says, ?For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates: This extension MUST be present?, etc. Functionally, I do not see a difference. How do other people interpret this? Tim said that the European regulators and auditors follow DigiCert?s approach to ?shoulds? and require explanations for departures. Clint said that CAs should justify departures from any ?shoulds?, but it?s still different from a ?must?. Tim acknowledged that the transition from a ?may? to a ?should? is a small change. Ryan D. said we?re trying to jam a lot into these profiles. The more we can simplify, the better. Tim said that on the next call we should be prepared to discuss what items we can just ship because there aren?t any issues, and which are the ones that need more discussion. Dimitris said he I thought that we had previously agreed to post the profiles ballot without any normative changes and then have a version 2. It is much easier to evaluate these kinds of changes in two steps. Some auditors read RFC 2119 a little more strictly. Trev agreed with Dimitris that we had previously discussed the transition from ?mays? to ?shoulds? and that ?shoulds? were considered best practices and could eventually become ?musts? and we should treat ?shoulds? this way. Ryan D asked whether we should remove the ?shoulds?? Tim said that some people in some standards groups take that approach. It would be great if we could modify RFC 2119 to explain in greater detail what ?should? means. Trev suggested that next year we look at the ?shoulds?. Meeting adjourned. -------------- next part -------------- An HTML attachment was scrubbed... URL: