[cabf_validation] 2021-12-02 Meeting Minutes

Tue Dec 14 18:04:05 UTC 2021

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: <http://lists.cabforum.org/pipermail/validation/attachments/20211214/9cabade7/attachment-0001.html>