[cabf_validation] 2023-01-12 VSC Meeting DRAFT Minutes
Slaughter, Michael
slghtr at amazon.com
Tue Jan 24 00:54:33 UTC 2023
January 12, 2023 Validation Subcommittee Meeting
Note taker identified. (Michael Slaughter - Amazon)
Antitrust Statement: Corey Bonnell read the Antitrust Statement
Attendance:
Aaron Poulsen - (Amazon), Aneta Wojtczak-Iwanicka - (Microsoft), Ben Wilson - (Mozilla), Clint Wilson - (Apple), Corey Bonnell - (DigiCert), Dimitris Zacharopoulos - (HARICA), Doug Beattie - (GlobalSign), Dustin Hollenback - (Microsoft), Enrico Entschew - (D-TRUST), Inigo Barreira - (Sectigo), Martijn Katerbarg - (Sectigo), Michelle Coon - (OATI), Nargis Mannan - (SecureTrust), Pekka Lahtiharju - (Telia Company), Rebecca Kelley - (Apple), Rollin Yu - (TrustAsia Technologies, Inc.), Ryan Dickson - (Google), Tobias Josefowitz - (Opera Software AS), Trevoli Ponds-White - (Amazon), Wayne Thayer - (Fastly) - Wendy Brown - (FPKI), Paul van Brouwershaven - (Entrust), Chris Clements - (Google Chrome), Michael Slaughter - (Amazon), Janet Hines – (VikingCloud)
Minutes:
12/15 VSC minutes (Doug) were approved.
F2F 57 (Day 3) VSC minutes (Chris) were approved.
Meeting Minutes
1. Certificate Profiles
* Pull Request - Integration of SC-56 and SC-56 (https://github.com/cabforum/servercert/pull/409)
* Corey proposed taking the language from the two newest profiles and adding it to the cabforum:profiles branch. No objections were raised and the pull request is considered approved. Corey merged the PR after the call.
* Pull Request - Update policyQualifiers for CA profiles from NOT_RECOMMENDED to a MAY for CA certificates. (https://github.com/cabforum/servercert/pull/411)
* Paul - Last call we agreed that we did not want this change for end-entity certificates but were fine with for CA certificates.
* Corey - I recall that there were some concerns raised that specifying in this matter doesn’t achieve the goal of minimizing chain size which generated some push back.
* Ryan - IIRC both of the proposed changes would add additional overhead for many handshakes and we therefore should leave the language AS-IS i.e (NOT_RECOMMEND)
* Ben - I agree with Ryan’s recollection.
* Wayne - What I said in the last meeting was that for a TLS connection you are delivering the chain as part of the handshake so there is no reduction of bytes on the wire. IIRC the objection to NOT RECOMMEND is that CAs may interpret that as on the deprecated path but we have other language that specifically designates something as on the deprecation path so there may not be a conflict.
* Trev - That was my recollection as well. “Will be deprecated” is separate from “Not recommended”
* Dimitris - I verified the prior minutes and see that the stances are consistent.
* Ben - I believe there will be some value for the ICA
* Dimitris - I would prefer the MAY but acknowledge the additional bytes on the wire.
* Ryan - I still recommend NOT RECOMMENDED on both places. We have data that indicates that not many people actually look at data on certificates and will probably not use it. Imagine the value that a family member may have by following the policy and then trying to interpret it.
* Trev - I doubt anyone is demanding more things in my chain.
* Ben - Well I am.
* Wayne - It’s always a good idea to provide some bread crumbs that explain why a requirement is phrased a certain way since it will always come up.
* Corey - for the context of this PR, it will maintain the current language. Paul does it make sense to add the additional pointer?
* Paul - That doesn’t align with my intent so I do not wish to change the PR. I will retract the PR based on the consensus.
* Corey - Would anyone like to own the action to add an explanatory note about the wire size.
* Wayne - I will take that action.
* Ryan - Are we taking this approach (adding explanatory guidance) in any other areas? I want
* Corey - Yes in some areas there is similar guidance.
* Dimitris - I would just recommend that if there is a controversial topic that doesn’t have unanimous agreement then we should add explanatory context in the actual doc.
* Coery - I agree that having the design rationale in the doc is a good idea.
* Ben - We can add it in the far right column.
1. Topic 2: Ordering of the subject DN fields
* Doug - We have ordered fields and unordered fields and the expectations between the two groups is unclear.
* Corey - My understanding is that the ordering is only with regard to the specific attributes that are designated as “Ordered”. For example, if you have an EV cert with business code (which is not ordered) it can be interleaved with the ordered field. That was my intent.
* Doug - If we are trying to follow an x500 ordering scheme then inserting random fields in the middle of the ordered list might cause problems. Does it make sense to have ordering in that case? If everyone agrees that this a good way to do then I will disagree and commit.
* Corey - Your understanding of 5280 aligns with mine that it doesn’t define any ordering constraints. Some attributes follow hierarchical (Country → State). In certain regions the postal code might cover multiple localities. In my mind it makes sense for certain attributes to follow certain other attributes.
* Aneta - Does this mean that the Subject will start with Country Name for all OV certs or can it start with commonName and go the other direction?
* Corey - Based on the table, they must go in the top-down specified order (country name → commonName).
* Aneta - Ok.- Subject must start with country name. If you go to 7.1.2.7.4 . The name of the table is incorrect and it doesn’t say that the order must be kept. It should be consistent with the other section. domainComponent is in different places in 7.1.2.7.4 vs 7.1.4.
* Clint - What we have now makes sense but it’s worth calling out that some certificate parsers will reverse the ordering.
* Corey - That’s right the LDAP string representation will reverse the ordering recorded in the certificate. If there are no more comments then it sounds like we are good with the status quo. Would anyone like to create a PR to have the issues addressed?
* Aneta - I can work on that PR.
* Ryan - I am hopeful that at this point the immediate group can get pens down and balloted. It’s been in discussion for multiple years now. Are there any objections to getting to pens down? Would anyone be open to endorsing the ballot once we get it more firm.
* Clint - I second I am happy to endorse.
* Dimitris - I am happy to endorse.
* Ryan - Next steps; Wayne and Aneta will work on the remaining PRs, those will be discussed at the next Validation Sub Committee which can then be added to a ballot proposal.
* Would everyone feel comfortable pushing the effective date back to July 15th which was one of the dates that Tim called out for policy changes. I would own submitting the PR. Is that enough time?
* Dimitris - I would prefer to push the effective date away from summer due to many folks being away on vacation.
* Ryan - Would love to see it be April but it may not be reasonable so I will make a PR to make September 15th the effective date.
* Ben - I support the September date.
* Wayne - I will also support the September date.
* Clint - I also support September.
* Corey - Sounds like the consensus is for September.
* Ryan - Next steps - We have 3 PRs to discuss at the next meeting and have 2 endorsers so we’re ready to take flight.
* Corey - Agreed with the next steps
1. Status check on Global Sign the LEI ballot
* Doug - Eva is busy this week so she is not on the call and no status update.
* Dimitris - There has not been any progress made on that.
1. Resuming the analysis on the terms Applicant and Applicant representatives
* Not covered
Thanks,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230124/649b6b52/attachment-0001.html>
More information about the Validation
mailing list