<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>2022-04-07 validation-sc minutes<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Attendees:<o:p></o:p></p><p class=MsoNormal>Andrea Holland<o:p></o:p></p><p class=MsoNormal>Ben Wilson<o:p></o:p></p><p class=MsoNormal>Bruce Morton<o:p></o:p></p><p class=MsoNormal>Clint Wilson<o:p></o:p></p><p class=MsoNormal>Corey Bonnell<o:p></o:p></p><p class=MsoNormal>Daryn Wright<o:p></o:p></p><p class=MsoNormal>Dustin Hollenbeck<o:p></o:p></p><p class=MsoNormal>Enrico Entschew<o:p></o:p></p><p class=MsoNormal>Joanna Fox<o:p></o:p></p><p class=MsoNormal>Joe Ramm<o:p></o:p></p><p class=MsoNormal>Paul van Brouwershaven<o:p></o:p></p><p class=MsoNormal>Rebecca Kelley<o:p></o:p></p><p class=MsoNormal>Ryan Dickson<o:p></o:p></p><p class=MsoNormal>Ryan Sleevi<o:p></o:p></p><p class=MsoNormal>Stephen Davidson<o:p></o:p></p><p class=MsoNormal>Trevoli Ponds-White<o:p></o:p></p><p class=MsoNormal>Wayne Thayer<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Minute-taker: Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey read the antitrust statement.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Primary topic of discussion were the changes proposed to the certificate profiles ballot to reflect recent discussions: https://github.com/sleevi/cabforum-docs/pull/39<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Including AKI in Root Certificates<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: I think the takeaway for the previous call was that we should make this a SHOULD and provide supplementary text explaining the rationale.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: My recollection was that we would specify a "MAY" and document in the supplementary text various quirks of client implementations. This normative change would not be made in this ballot, as was agreed back in November. We can specify this as a normative requirement in a future ballot.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: I don't think I agree that this is a normative change. RFC 2119 is specific in how to interpret a "SHOULD"; it's something that you should have a good reason not to do but you can. The intent of the inclusion of a SHOULD-level requirement is to lead CAs to the "happy path" where there is maximum interoperability with clients. Is there strong objection to making this a SHOULD and we should make this a MAY or else CAs will vote "no", or how else can we address these concerns?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: I suppose my concern isn't with gauging whether or not the ballot will pass, but rather ensuring that we agree on approach. I do see changing a "MAY" to a "SHOULD" as a normative change, as they are meaningfully different RFC 2119 terms. The agreement previously reached was that we would minimize normative changes in the initial ballot to ensure that the ballot is easy to understand for CAs. Down the road, we can add further improvements. For example, in a few months we can have a ballot that moves this to a SHOULD or MUST. Or for the prohibition on including certificatePolicies in the OCSP responder profile: there is no requirement today that prohibit its inclusion but it is something we can mandate in a future ballot. The intent is not to pass this profiles ballot and not improve upon it for several years, but instead to get this initial version integrated into the BRs and then we can iterate on improvements in future ballots. Pushing off normative requirements changes would also reduce complexity by not having to have extensive discussion on effective dates.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: Do you think the change from MAY to SHOULD should have an effective date?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: I think it would be preferable to push off normative requirements changes unless we know of a compelling reason to include it.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: I suppose this is where the disconnect may be. My recollection was that for the initial profiles ballot, we would document existing requirements and add guidance so that CAs know of the "happy path". Some of the changes presented in this PR appear to be "change for change's sake", which is perhaps one of the sources of disconnect.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Prohibiting certificatePolicies in OCSP responder certs<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: The original proposal was to implement a ban roughly 6 months after the effective date. OCSP responders are not issued daily, so it seems like ample notice to mandate this effective date. Again, my understanding wasn't this ballot couldn't contain requirements changes, but rather that it can, provided the changes are clear, well justified, and have ample lead times.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Clint: I agree with Ryan. Given the large amount of time dedicated to this ballot, I would prefer shorter lead times for these changes barring specific feedback on why these changes are not feasible. I share some of Corey's concern that if we push too fast then it will slow down future work, but I also don't see any strong justification for delaying these changes. Especially for things such as the change from a MAY to a SHOULD for AKI in root certificates; it's a no-op operationally for CAs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: There definitely are competing concerns. If we can add things that don't have an impact now, we can. But we should be wary of introducing things that may have an impact. For the MAY to SHOULD change, I do think there may be an impact as auditors may require evidence for the rationale of violating the SHOULD. But if there's consensus it's a no-op, then we can change it.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Bruce: I agree with Corey that it is a normative change.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: I want to clarify: is the concern that with a SHOULD there is a requirement than analysis must be performed and auditors may expect evidence of such analysis, or is it that auditors may interpret a SHOULD as a MUST?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: If your auditor does treat a SHOULD as a MUST without documentation for the analysis, then a CA may receive an audit observation if they are unable to produce such documentation.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: The explanation that we would provide in the supplementary documentation would be that evidence.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: Yes, but that may be up to auditor interpretation. Again, we can keep the SHOULD, but based on previous discussions we were going to relax to a MAY. I don't see this particular item as important, but I think the differences in opinion on this issue highlight some high-level differences across the entire ballot.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: Agreed. To fully understand: is the extent of concerns surrounding the change from a MAY to a SHOULD be around auditor interpretation, or are there additional concerns?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: There may not be additional concerns beyond auditor interpretation, but I'd be in favor of minimizing these sorts of changes.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan D: I tend to agree with Ryan (S) and Clint; this is a no-op change. As for pushing off changes, we should have justification for doing so. The discussion on "auditor interpretation" doesn't help me to see the concrete challenges that this language would create.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Trev: One of the things that we wanted to differentiate when we previously discussed this is that we should separate requirements changes from formatting changes. When CAs diff from one version of the BRs to another and both formatting and requirements changes are included in the set of changes, then it becomes more difficult to determine whether the change is the result of a requirements change or a mere change in presentation format. For that reason, we previously determined it would be best to introduce requirements changes separately to ensure they don't get lost in the document churn.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan D: I can appreciate this perspective, but I think we're adding unnecessary work by separating out these items. There will be separate ballots, each with their own voting and review periods. If we have to chase this ballot with others immediately thereafter, it seems like we're delaying the inevitable.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Trev: Right, but I think you can make the opposite argument that if we would have taken out these requirements changes and put them in their own ballot, we would have been done with all this work some time ago. I see the BRs as a living document that we can change in the future, so I see minimizing the number of changes as reducing the burden for each ballot individually.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Clint: We have also heard from CAs that the sheer number of ballots is a burden, such as more IPR reviews. It certainly is a tricky balance.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Trev: Yes, which is why we previously proposed introducing the formatting change ballot. Then shortly thereafter, we would, for example, introduce another ballot with five requirements changes. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: CAs will need to closely review this ballot regardless of whether or not there are intentional requirements changes introduced to ensure that their practices are in alignment.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Non-TLS Sub CA profile<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: From the previous discussion, I believe the common understanding is that we would define solely what is technically necessary for a non-TLS sub CA. I believe the discussion in September and at the F2F is that you cannot issue non-TLS ICAs with malformed extensions. Removing the non-TLS profile entirely from the profile is modifying the BRs to essentially say that issuing certificates with malformed extensions is permissible. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: My recollection of the F2F meeting was that there are certain circumstances where you do need to issue certificates with malformed extensions. For example, critical nameConstraints are may not be supported by certain client implementations. It is a RFC 5280 violation to make the nameConstraints extension non-critical. Browsers may support the critical nameConstraints extension, but in other trust frameworks, such as S/MIME, there may be email clients that do not. The challenge is that we still have mixed use PKI heirarchies today, but the proposed non-TLS ICA profile may cause issues for non-TLS use cases. So the F2F consensus was that, in the short term, we would not normatively specify the non-TLS ICA profile.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: We have today in the BRs section 7.1.2.4 that states all certificates must conform with RFC 5280, but we also have the explicit permission to violate RFC 5280's requirement for critical nameConstraints. If we are saying that 7.1.2.4 doesn't apply to non-TLS certificates, then we are saying that it doesn't encompass all issuance under a BR CA.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: We reached a different conclusion at the F2F, where there was agreement that the issuance of non-TLS certificates is not in scope of the TLS BRs today. In particular, the exclusion of the serverAuth EKU means that the issuance of that certificate is out of scope of the BRs. That's not to say this won't change in the future, but that is the current state of the requirements today.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: We have in section 7.1.2.2 (g) requirements for non-TLS ICAs. Was the view that this language is not applicable?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: Yes, there was agreement that the EKU specification for non-TLS ICAs was not appropriate for inclusion in the BRs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: This language is present in the TLS BRs today. It sounded from the minutes that this language doesn't apply today.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: Yes, the conclusion reached was that this language is essentially unenforceable, as it is opining on issuance that is not in scope of the BRs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: One of the main motivations for this profiles work was to explicitly specify the profile of all certificates signed by a BR CA. So the position that certain issuances are "out of scope" seems to run counter to that goal. Is the argument that the BRs only apply when a "certificate-shaped thing" looks like a TLS certificate?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: Yes, that was the conclusion at the F2F.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ryan S: The logical extension of that is that the issuance any malformed certificate might not actually be a mis-issuance, but rather a signing operation that is simply out of scope of the BRs. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: One of the challenges is that specific Root Programs may have expectations in this area, but the BRs today do not. Essentially, this is another take on the long discussions of the "scope of the BRs".<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: We only have 1 minute left, but we can resume on the list and at the next meeting.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Clint: This discussion has been very helpful. Perhaps we can have a special validation meeting to more quickly hash out these issues.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: I agree, Clint. We can devote the majority of the time on the next call to these issues and if we determine that additional time beyond that is needed, we can have a special meeting to more quickly reach conclusions.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Meeting adjourned.<o:p></o:p></p></div></body></html>