[cabf_validation] 2022-04-21 Meeting Minutes

[Aneta Wojtczak-Iwanicka]

2022-04-21 validation-sc minutes



Attendees:

Aneta Wojtczak-Iwanicka

Andrea Holland

Ben Wilson

Bruce Morton

Clint Wilson

Corey Bonnell

Dimitris Zacharopoulos

Doug Beattie

Daryn Wright

Hubert Chao

Iñigo Barreira

Janet Hines

Joanna Fox

Joe Ramm

Johnny Reading

Michael Slaughter

Michelle Coon

Paul van Brouwershaven

Pekka Lahtiharju

Rebecca Kelley

Ryan Sleevi

Tyler Myers

Tobias Josefowitz

Wayne Thayer



Minute-taker: Aneta



Corey checked who is up for the next round of minutes. Ben was on the list for the next meeting, and Ben acknowledged that he should be able to take notes next time.



Corey read the antitrust statement.


Minutes from the last meeting were approved.



Agenda:



  1.  Brief overview of the Validation-sc GitHub project for tracking: https://github.com/cabforum/servercert/projects/2<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fprojects%2F2&data=05%7C01%7Canetaw%40microsoft.com%7Ce76d8e2e9bcd4237ce5e08da2d836390%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637872339588819845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=j6xUYQTgmCqKYYtAR2%2FehEq6OF8X5KGW%2BMOVCtsEhds%3D&reserved=0>



Corey provided and update about a migration from Trello (https://trello.com/b/NuqJuIcZ/validation-working-group<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrello.com%2Fb%2FNuqJuIcZ%2Fvalidation-working-group&data=05%7C01%7Canetaw%40microsoft.com%7Ce76d8e2e9bcd4237ce5e08da2d836390%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637872339588819845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=U66CmHiVJOrjBFXj8cHfNT32YgxlzqBPo4RCvvyR16Q%3D&reserved=0>) to the GitHub project in  the server     cert repo (https://github.com/cabforum/servercert/projects/2<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fprojects%2F2&data=05%7C01%7Canetaw%40microsoft.com%7Ce76d8e2e9bcd4237ce5e08da2d836390%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637872339588819845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=j6xUYQTgmCqKYYtAR2%2FehEq6OF8X5KGW%2BMOVCtsEhds%3D&reserved=0>)



Corey: We have a GitHub project if you go to servercert-> projects, you would see those 3 different projects under servercert. We have "Validation" here. The different swim lanes are basically what we had previously in Trello. So, the approach that we took was that we created a GitHub issue in the servercert repo for every item that was in Trello that we knew that was not completed, and we use the validation-sc label. When we have that label there, we can then "add cards" that is basically each of these items is now a card. You can add the issues here and you can keep track of the status of each one by dragging them through these different states. The idea was to take what was initially in Trello and put it in GitHub and then we can use it for our project tracking. It basically mirrors what we did in Trello. I think moving forward after we get past the initial profiles ballot, we can start using it as an effective means for tracking the various work that we are doing.  Any questions or comments on this?



Ben: This looks good.



  1.  Email raised by Doug on the mailing list about the approach that we would take for the transition from the profiles we have currently in the BRs to the new profiles ballot.



Corey: There was some discussion back in November when we discussed the approach and it sounded like Doug wanted to revisit some of that discussion to make sure that we are all on the same page and if there is anything we are missing.



Doug: I couldn't really glean from the minutes what the final approach was. I know we are anxious to get this ballot in a formal discussion phase and voting. I was not clear to me how that would happen based on those meeting minutes, whether you can pick and choose what version. if you are not required to be audited against the most recent version if you reference that other version. It sounded like some of those were less than optimal, the suggestion I had that is not probably even a good suggestion. I think we need to get a ballot in a version of Baseline Requirements that accurately describes the intent of the spec., that can be balloted against going forward if we do have other updates for key protection or weak keys. So, we have one stream of specs that continually get updated. If we are not going to go through and highlight and put effective dates for every little change throughout the whole ballot like every little field that may have changed than somehow, we need to figure out how we convey the new requirements with a new effective date but permit customers to continue doing what is available in the current version of the spec. I thought it would be good to before we submit a formal ballot that we kind of collectively know what the plan is for getting this out for voting and then enforcement.



Ryan: The intent has always been from the moment we put together that current draft of the branches is to ballot what is in that branch and bring that forward. So, they were the elements from the last call that were discussed after this to figure out the incorporation change. The intent has always been to have a single replacement activity that goes on where sections 7.1/7.2 are replaced with this new profile work. There has been a lot of discussion on this, I know Tim in the past has raised concerns about that approach and he suggested that he was going to submit some pull requests with some alternatives, and it never came through and I think that's where are some of the discussions on the list that you are seeing what are the alternatives to do that. The intent here has always been for this is that the majority of this is a restatement of either existing 5280 requirements or existing Baseline requirements or things that are not of normative effect.  I know we spent a lot of time two weeks ago discussing "SHOULD" and "MAY" but with a focus on things that are requirements and then as well for those that are seeing changes and there are changes like one of the things that has been discussed in the past "What about changes to the Root certificate profile?". Well, how often are you issuing Root certificates and how much lead time do you need for any policy change, a root certificate change like that given that we have been discussing it for a year and a half the intend. A change to a subscriber certificate that make sense to have a phase in there, so one of the of the things from the last call that we talked about was certificate policies within OCSP and making sure that in the OCSP responder certificate does not assert compliance with a DV profile or with the OV profile because that does not really fit with the OCSP responder, because the OCSP responder is not a subscriber certificate. So, in that example what is currently in a tree has a phase in period, so the intent had been that we are doing a full-scale replacement for things that folks have legitimate concern about that it does have to have a phase in date we have the ability to have phase in date. So, I think what's useful from what you just described and what you said in the email and something that we have been asking for over a year now is: "are there changes in there that do need phase in periods?". If there are individual fields that need to phase in let's bring them to the table, let's discuss that, let's understand the impact of that. We already moved a lot of stuff to V2 and hopeful that has reduced any of that tension but if there are elements there that folks want to bring next week let's discuss those and understand: are these changes or are these just maybe existing requirements to figure out if they need a phase in date and then of course there is a discussion period. I do not think that there has ever been a time where things have been perfect going into discussion period, that's the whole reason we have 3 plus weeks discussion period. The intent here, when the ballot comes out it does come with immediate effect, that immediate effect should not be anything of functional or substantive concern because it is either an existing requirement or requirements from things that you already have a substantial lead time in plan to going into.



Doug: CAs in general understands what's coming it is just maybe some of the little nuggets buried in here that when we go back from a compliance point of view with the "MUST" or even the "SHOULDNT's" that perhaps we are not quite there yet. I guess, the intent is during the discussion period or before identifying some things with the proposed effective date that may align with the wider audience and otherwise the whole ballot becomes effective immediately after the IPR review. Is the intent that after the IPR review this new ballot is 100% enforced and applicable and any little deviation are called out like the OCSP?



Ryan: Yes, that's exactly. There has been a receptiveness of just having one align effective date. The current draft, like the OCSP date, the intent was to push it back 6 months, since it sounded like that's what people like. I am just trying to make sure that we do not end in the Thanksgiving period, so with where we at in April, maybe it is closer to 5 months just because if we have a month of discussion and review then we are looking at end of May becoming effective. The idea being is that October 31st or October 1st but trying to get it, so that sometime before end of this year that any of those changes that are hopefully minor that there are achievable and substantive and those that will present challenges are moved to v2, and I hope we are at that stage. So, yes there will be sort of a second effective date. There is the immediate "here is the text that replaces the existing text and has all the same normative force" and there are those areas that are called out of saying "these are things that are coming to effect in October". It clarifies any before and after stage, immediately the before becomes the effective thing and then in October whatever a new requirement says again using the OCSP responder certificate. Does the OCSP responder certificate need 6 months? I hope not, but some CAs issue their OCSP responder certificates for a year in January, so there may be ceremonies to plan, get folks in the DC. The OCSP responder was an example of a potential need for a new ceremony. Hopefully that addresses things.



Doug: It is clear to me, thanks Ryan. So, if we have any specific item, that we think should have a later effective date we will raise those.



Ryan: Yes, exactly. Again, with these profiles, I know Corey looked for censys and I have been using crt.sh and our internal resources trying to make sure that these changes are going to align with sort what Cas are doing. Hopefully with respect of profiles, there shouldn't big concerns but if there are, yes to clarify with effective dates where some of these may present challenges that's what the goal has been for the past year to understand are there elements like this. I understand that for some CAs it is not until the discussion period. This is where we talked about 3 plus week of discussion period to allow CAs to work through their compliance team. I would hope when it comes to profiles it is a bit easier to review. I understand that CAs for validation practices can have 12 of product lines and polices in place. Hopefully profiles is a bit more centrally visible, because you are going to run it through linting so you have a chance to look at certificates being issued to see that and have time to surfacing issues. This is the hope of what has been going on for the last year, but I realized that some CAs may not have internalized that opportunity.



Corey: So, the discussion that we had back in November took some of a different approach that we would specify that for a certain period of time the previous version of BRs, the profile specified in that one will be applicable and t the later point there will be a hard transition date when that allowance will be removed and it seems like there was raw consensus on that November call. I just want to ensure that everyone who previously voice support for that sees that as the best path forward or the proposal being discussed today is the best path forward.



Ryan: That proposal has been floated multiple times and each time we have shared our concerns with that being viable. I know Tim was very invested in the proposal, but the request had been lets look at some concrete changes. It causes lots of issues, I do not think we will be able to bring that ballot forward in that form. I do not know to necessarily be able to endorse because, it creates a lot more confusion than profiles sole. The conversation in November was not a new conversation, we have been talking about this for years and I do not think we are quite comfortable with endorsing that approach and voting for that. That becomes more a hard blocker so trying to figure out a way forward. Again, I do want to stress that said if there are elements of profiles that folks feel are not capture by existing requirements by 5280 and do needs some time to change, we want to make sure those go in. If there are concerns, we want to make sure that we address them and make sure that they are incorporated and at the same time to make sure that we are able to make ballots in some effect. I want to acknowledge that, because the ideas from that November call were not new and happy to dig up some minutes in the past, where the concerns were raised and the request was made to show how this is going to work, because there are lots of issues like Doug raised on the list.


Corey: Any other feedback? I just want to make sure that everyone is supportive of this new approach.



Clint: I am supportive of it.



Corey: So, the consensus raised on this call is that we will not be referencing the previous version of the BRs instead these profiles ballot will become a single source of truth for what is valid or invalid in the certificate profiles. Am I understanding this correctly?



Doug: That is accurate and there will be specific effective dates for certain things that CAs need more time doing, so there will be a few requirements changes that says this "SHOULD" requirement is “OK” and on a certain date it will turn into a "MUST" or whatever the case is.



Corey: So, it sounds like we will take the approach of just integrating this profile work ballot directly in the section 7. I guess, if there is nothing else to discuss on that point, I can start digging into some of the things we discussed recently and we did not have time on the last call. Maybe we want to look into some MUST and MUST not that have been proposed. I think last time we discussed the future prohibition on including the certificate policies extension in OCSP responder certificates. I did not know if we want to cover that again today or if forward prohibition date will be appropriate. The discussion was not quite concluded on the last call but hopefully we want to pick it back up. Does anyone have any preference?



Ryan: Since, we spent a lot of time discussing your PR39, just want to capture “what are the plans?”, “what are the next steps?”, “when can we stop taking about this ballot on the call?”, as I am sure everyone is ready.  Our plan is to try to bring this to ballot before the next call, however that means incorporating a number of changes like fixing some of the buggy srv name table, upper bound for serial numbers (Corey has got text for that), going forward with limiting domain control validation requirement to the CN attribute for issuer certificates. It sounds like that is a path forward, even though it is an existing requirement but some folks have questions about that so that is going to be incorporated. It would be interesting to understand if folks feel there is a need for an effective date for backdating for subscriber certificates. The current proposal is to allow some backdating, but it was not clear from our previous discussion if it was needed for a subscriber certificate. Because it fits within an existing Root store prohibition an in particular in the existing BR when it talks about accurate time of issuance, that the “notBefore” time cannot be before the validation time. So, there was already understanding of prohibition backdating and this is just clarifying it. I think it is useful to ask folks if this is something that is going to cause issues in their systems. It should not be though just from what we are seeing in CT. The certificate policies in the OCSP responder will stay with a forward dating requirement that will be updated to October. The alternative is that we could push the effective date out, even functionally for CA it still means if you want to avoid any Holiday freezes, you still need to do it sooner than later. Allowing SKI in a subscriber certificate, we will go with that, it is still should not though. There may be a reason for a not browser related technologies stack, either way those still stay permitted. Scoping the SKI uniqueness and making sure it is not scoped to the issuing CA certificate but to the logical CA operator.  The intent is to incorporate all of those changes that I just mentioned. One of the big change we may want to discuss is "what does the intermediate that is issued from an in scope TLS CA looks like to bring it out of scope of the BRs? The intent here is to keep non TLS intermediate defined, so the CAs can make sure that they are very clearly bringing that CA in their hierarchy out of scope of the BRs. It is still a subject to RFC5280 and it is still subject to the signature requirements. I think within that non-TLS discussion it sounded like there was some concern about existing work from ballot sc31 which already says a set of must not requirements for a certificate that is issued from a in scope CA. There was a concern about whether or not it can be done or set. It is something in the BRs today, so maybe that is something to discuss because it is within a scope of the charter.

There was a giant run down on this and I know Corey was jumping around those changes, so we have these commits. That was the plan for breaking those commits integrating them and then looking to bring to a ballot with accompanying explanation for every one of these changes. I have been playing with a couple different formats (textual form -> bulleted list/parallel table). The idea is that, you can put them side by side as you are reading each section you can read through the table or through its textual requirement and here is the explanation how this text came to be. I will try to prepare one of those.



Corey: did you say you have the textual format? You are working on that now, is that something you can show?



Ryan:  Showed supplemental documentation that is intended to explain the reasoning behind changes in a new version of certificate profiles (Comparison of changes to v1.8.1).



Corey: This essentially becomes that supplementary documentation that we have been talking about.



Ryan: Yes, that's exactly. This is one approach, the other approach was to use that supplementary documentation but structured it in a table way. So, that you can look table to table. For Authority Key Identifier working through each filed, taking about some of the other requirements, recommends should why is it should. Things like new requirements, we talked about authority cert issuer. It says that this is a new requirement from Mozilla policy. Authority Cert Serial number goes hand in hand. For things that are just straight transposition, we see EKU. So, yes this is one of the end draft textual forms.



Corey: This is truly great. Are you planning checking this into your repo?



Ryan: Yes, exactly. Do folks have a preference when it comes to reviewing with your compliance teams? Is it a bulleted list workable or you would prefer tables if I can make tables working or do you really not care and you would rather see it and go from there?



Corey: At least for me I do like the textual format you have here. Maybe I am just biased towards text over tables, but I think this is a nice way of comprehensively mining out all the changes.



Inigo: I do not have any preferences as well, so this is ok for me.



Ryan: The textual makes it easier to provide some of these longer explanation like talking about CRLs distributions points. It is trying to call out where they are new requirements and talking about what the impact would be, so we can discuss how some of those phase in. The intent here is to incorporate this and to go with the ballot into the discussion period, so we can figure out which of those would need effective dates. We are talking one effective date, hopefully 6 months out in the future and we can make it effective at the end of October, maybe end of November or end of December but functionally end of October.



Aneta: So, the plan is that this will be finalized and then shared with CAs, so CAs can go through this document and decide which change would need an effective date. Is that the plan?



Ryan: So, plan for this document is that this accompanies the ballot for discussion period and it is meant to help folks who have not been on two and a half years of validation calls to understand each of the requirements where did they come from and they can go through and review during the discussion period and if there are any concerns with anything either, it is possible that folks may disagree and say "this thing that you say is an existing requirement, this is a change and we would need an effective date" or  maybe that this thing that is a change on paper but it is not a functional change for any operational practices, so we do not need an effective date. Yes, this is to help CAs to review existing practice against this.



Aneta: So, it will go out at the same time as the ballot will go out.



Ryan: Yes, this needs to accompany the ballot so folks can make an effective review of that. The important thing from our previous call is that we concluded this is not part of the ballot itself. This text does not become part of the BR. This is not something we will have to maintain continually. Right now, this is listed as a comparison of changes to v1.8.1, however if we want to make it as a living document, we could look into bringing this as a separate document and removing the explanation like "this is a new requirement" or maybe rephrase it to say this is not a requirement of 5280 but still have the explanation text that goes with that.



Aneta: Is there a plan to add dates to this document for the sections that already have dates?



Ryan: This text is meant to be read in the context with the ballot, it is not meant to standalone. The current approach of this text is that you read it with the ballot, and you can go through each line of that ballot and match that to the explanation to understand how this came to be.



Aneta: I understand that this should go together with the ballot, but I think it would be easier to analysis if you have it in both places.



Ryan: That is useful feedback. The intent here had been to explain where the requirements come from as opposed to explain the ballot but there is somewhere to meet in the middle for that. It is important to make sure that the CAs do not just relay on this document, because this not a normative document, the ballot is the ballot. This is trying to explain all of the context for two and half years of discussion for where each of those requirements came from or how they were arrived at, but it can make sense to call out for folks who are not looking at the ballot text with it. I do not think that for this first version it will be as critical, because we do not have a lot of date effective things other than like the OCSP but if CAs do have legitimate concerns on some of these changes that it makes sense to continue to have this as a living explanation



Aneta:  Will the subscriber certificate profile will be added to this document?



Ryan: Yes, it is not fully completed. Every section of the ballot will be added here. So, we will have all the way through for every single change for that explanation to go through. There are things I was playing with that's why we see "TODO: sleevi" here because the subject field is crossed reference in a number of sections. My intend had been rather that cross referencing provide fully explanation to make it a bit easier in a textual form. So, yes there will have a section heading for every single section of that ballot change that explains for each field what those requirements are, so It means that sometimes it repeats these sections.



Aneta: Would it be worth going through this document in two weeks when it is complete and decide which section should have an effective date because there are some concerns since there are some dependencies?



Ryan: So, the proposal is doing it during the discussion period for the ballot.



Aneta: So, we do not want to go through this document to review and add dates to items that may still be a concern.

Ryan: That is the approach that could be done, our attempt though with this having gone on for so long it benefits from having broader feedback and broader discussion. We certainly could take another round within the validation group and go through those, but really I think at this stage we are looking for the concrete feedback and the best way to get that is though overall discussion period. Again, we know it can be at most 3 weeks for the first phase but that doesn't mean that it cannot be more than 3 weeks, and this is fully expected that there will be at least one revision of this ballot as it goes to the broader group. When I am talking bringing it to the ballot, I am talking about bringing it to the larger group and making sure that we are actually engaging everyone and getting the right feedback. Bringing it broader that just the validation subcommittee, because we have been lingering around in this sort of final stages and going on those some minor points. The intend was to bring it to the broader group and identify those and to have CAs be able to provide some of the technical details for these changes and why they might be a concern. Something like a cross-certificated subordinate CA is generally not something that CAs are issuing every day and they have a script to follow and the script that gets reviewed and so there is hopefully ample time for CAs to make an in-course correction such that a new requirement to say a Root CA or Cross-Certified CA should not really require a phase in period because you have so much lead time to make those changes. A change to subscriber certificates on the other hand absolutely you need a lead time to make those changes because you are issuing every day and you need to make sure that those systems are all work through and those are not manual issuances. You are using your CA system actively issuing them. So that was the intent here. So, for some of these even during the discussion period the hope is that with this textual explanation for how those things are done CAs can update their existing profiles well before the effective date if they do even need to such there is no need for an effective date. But if a CA is issuing a new Root every week maybe we do need an effective date but that's what the discussion period can sort out.



Aneta: Why I am asking all of these is because we talked about having one date for whole section 7 and today, we decided to have a date for each item that is a concern that’s why I think it is a good idea maybe to go through it again in two weeks and then base on that discussion create a ballot with dates for each section that really needs it.



Ryan: It is tricky. We are at the stage where we want to make sure that CAs have lead time for this and I do not want to suggest that we are stepping on the gas pedal here but his has gone for so long. What would be the benefit of doing that on the next call versus doing it during the discussion period. There is still a 100% opportunity to review everything which we were been asking for the past year independent of the conversation November we have been asking for a year "do things need effective dates?", “are there concerns with changes?”. It would still have the same amount of review time either if we review it during the next validation call or we will review it during the discussion period so that's why I am having a bit of a trouble.



Corey: Since, we are out of time. Can I suggest that we do pick up this topic at the beginning next time just to make sure we have an alignment withing this group before we suggest this to the larger Server Cert working group? Does it sound like a good approach, or do we want to hammer this out offline before the next?



Aneta: I like this approach that we will pick it up during the next call.



Corey: Any objections to that approach?



Clint: I do not have an objective to picking it up, but I think we should start the discussion period. I do not think it needs to preclude starting the discussion period in other words. So, if we want to talk about whether or not we continue working through this document or something like that online I see that there could be some value, but I also definitively agree this should go to the wider group sooner than later.



Ryan: Does that work as a solution to bring it to the discussion period so it is on a radar for a wider group and then indicate that the next validation call will have bandwidth for a real time discussion after folks have had a week. Realistically, it will take another week to take all of those last bits in. That will give the wider group a chance to dial in as well.



Doug: It will be great to finalize all outstanding pull requests too and just make sure we have a baseline that reflects as close as possible what is going to be in a ballot.



Ryan: Absolutely.



Corey: I suppose there is a value in circulating it to the larger group but if there are outstanding concerns within this group. I think it would be viable to have some time on the next call to further flesh out. Maybe that is a good approach. We can initially fill this to the wider group within the next two weeks but then if there is any feedback or we still have concerns internally within this group we can spend some time on the next call. Sounds like a good approach for everybody?



Corey: I see the thumbs up from Ryan. All right sounds like that's a good course of action. Thank you everybody that was a very good discussion. Talk again in two weeks.





Thanks,

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