[cabfpub] Final Minutes of CA/Browser Forum F2F#60
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Sun Nov 19 06:44:37 UTC 2023
Here are the final minutes of F2F#60.
Dimitris Zacharopoulos
CA/B Forum Chair
------- BEGIN FINAL F2F #60 CA/B Forum Plenary Meeting minutes -------
Meeting 60 minutes
CABF Face-to-Face Meeting 60: Day 1 October 3, 2023
THESE ARE DRAFT MINUTES
CA/Browser Forum level Meeting
Attendance
Aaron Gable - (Let's Encrypt), Aaron Poulsen - (Amazon), Abhishek Bhat -
(eMudhra), Adam Jones - (Microsoft), Adrian Mueller - (SwissSign),
Adriano Santoni - (Actalis S.p.A.), Aleksandra Kurosz (Asseco Data
Systems S.A.), Andrea Holland - (VikingCloud), Andreas Henschel
(D-Trust), Aneta Wojtczak-Iwanicka - (Microsoft), Anna-Marie Christian
(WebTrust / CPA Canada), Antti Backman - (Telia Company), Arno Fiedler -
(ETSI), Arnold Essing (Telekom Security), Arvid Vermote - (GlobalSign),
Ben Wilson - (Mozilla), Brianca Martin - (Amazon), Brittany Randall -
(GoDaddy), Bruce Morton - (Entrust), Chris Clements - (Google),
Christophe Bonjean - (GlobalSign), Clemens Wanko - (ACAB'c / TUV
Austria), Clint Wilson - (Apple), Corey Bonnell - (DigiCert), Corey
Bonnell (DigiCert), Corey Rasmussen - (OATI), Daryn Wright - (GoDaddy),
Dave Chin - (CPA Canada/WebTrust), Dean Coclin (DigiCert), Dimitris
Zacharopoulos - (HARICA), Don Sheehy (WebTrust), Doug Beattie -
(GlobalSign), Ellie Lu - (TrustAsia Technologies Inc.), Enrico Entschew
(D-Trust), Eva Vansteenberge - (GlobalSign), Hannah Sokol - (Microsoft),
Hogeun Yoo - (NAVER Cloud), Ian McMillan - (Microsoft), Inaba Atsushi -
(GlobalSign), Inigo Barreira - (Sectigo), Janet Hines - (VikingCloud),
Jeremy Rowley - (DigiCert), Joanna Fox - (TrustCor Systems), Jochem van
den Berge - (Logius PKIoverheid), John Mason (Microsoft), John Sarapata
(Google Trust Services), Joseph Ramm - (OATI), Jozef Nigut - (Disig),
Kateryna Aleksieieva - (Asseco Data Systems SA (Certum)), Keshava
Nagaraju - (eMudhra), Kiran Tummala - (Microsoft), Leo Grove (SSL.com),
Li-Chun Chen (ChungHwa Telecom), Lynn Jeun - (Visa), Mads Henriksveen -
(Buypass AS), Marcelo Silva - (Visa), Marco Schambach - (IdenTrust),
Martijn Katerbarg - (Sectigo), Michael Guenther - (SwissSign), Michael
Slaughter - (Amazon), Michelle Coon - (OATI), Mohit Kumar (GlobalSign),
Nargis Mannan - (VikingCloud), Nate Smith - (GoDaddy), Naveen Kumar -
(eMudhra), Nicol So - (CommScope), Nikolaos Soumelidis (QMSCERT), Nitesh
Bakliwal (Microsoft), Paul van Brouwershaven - (Entrust), Pedro Fuentes
- (OISTE Foundation), Pekka Lahtiharju - (Telia Company), Raffaela
Achermann - (SwissSign), Rebecca Kelley - (Apple), Rich Kapushinski -
(CommScope), Rob Brand (Ministry of Economic Affairs and climate Policy
(NL)), Rob Stradling - (Sectigo), Rollin Yu - (TrustAsia Technologies
Inc.), Roman Fischer (SwissSign AG), Ryan Dickson - (Google), Scott Rea
- (eMudhra), Sissel Hoel - (Buypass AS), Stephen Davidson - (DigiCert),
Steven Deitte - (GoDaddy), Sven Rajala - (Keyfactor), Tadahiko Ito -
(SECOM Trust Systems), Tim Callan (Sectigo), Tim Crawford - (CPA
Canada/WebTrust), Tim Hollebeek (DigiCert), Tobias Josefowitz - (Opera
Software AS), Tom Zermeno (SSL.com), Trevoli Ponds-White - (Amazon),
Tsung-Min Kuo - (Chunghwa Telecom), Vijayakumar (Vijay) Manjunatha -
(eMudhra), Wayne Thayer - (Fastly), Wen-Chun Yang (ChungHwa Telecom),
Wendy Brown - (US Federal PKI Management Authority), Xiu Lei - (GDCA).
Approval of CABF Minutes from last teleconference
*Leader:* Dimitris Zacharopoulos (HARICA)
Minutes were approved.
Future face to face meeting schedule
*Leader:* Dimitris Zacharopoulos (HARICA)
*Presentation link:
*https://cabforum.org/wp-content/uploads/1-CABF_Future-meetings.pdf
* Spring 2024 meeting will be hosted by eMudhra in New Delhi, India
* Summer 2024 meeting will be hosted by Actalis in Bergamo, Italy
* Fall 2024 meeting will be hosted by Amazon in Seattle, WA
*Discussion outside the presentation:* No further discussion.
Forum Infrastructure Subcommittee
*Leader:* Jos Purvis (Fastly), Ben Wilson (Mozilla)
*Minutes:* Tim Callan (Sectigo)
*Presentation link:* No presentation
*Discussion minutes:
*
Jos Purvis (Fastly):
Jos thanks the guest speaker for being flexible in schedule.
Jos raises the question for how the Wiki is going for everyone.
Paul van Brouwershaven (Entrust):
When we first previewed the wiki, it was very well organized. But now in
production I'm having trouble finding things.
We also tend to find earlier drafts and I don't know if this is real
work or something that is being accidentally drafted.
Jos:
I have gotten that impression as well. It has been bumpier than we
thought. Some aspects got better but other things got harder.
Dimitris Zacharopoulos (Harica):
I'm also having some difficulty finding things. I'm also having trouble
understanding the terminology and structure of the new wiki. Perhaps
some instructions for working group chairs, etc. might be helpful.
For today I wanted to add a page for the minutes, and I didn't know if I
should create a page or put it under another page or what.
Jos:
Each particular wiki is opinionated about how it thinks your info should
be laid out. In the initial evalatation, the sructure seemed to make
sense, but the more we have rearranged, we are running into friction
with how it thinks it should be laid out. If it's creating more work
than it's solving, then it's not a helpful tool.
I would rather back up a step and consider a different tool than trying
to adjust everyone's thinking to a different way of laying out
information. I think maybe this hasn't been the right tool.
Dimitris:
Maybe it's not the tool. Maybe people don't know how to organize and
use it.
Clint Wilson (Apple):
Overall it's a lot easier to actually work in the editor. The main
issue I have is finding stuff that was in the old wiki. But maybe it's
more about documentation of the wiki and how to use it and structure it.
Not as far as a style guide, but something to help.
Paul:
Looking at meetings, there are 142 pages in Records. When I go to face
to face meetings, it sends me to face to face meetings calendar. It
seems like we have a tree structure in theleft, but it seems like w're
missing some information there. and we have a tree structure at the top
that doesn't make sense.
Perhaps the template could really be a template.
Maybe the tool is fine but we put some effort into organization.
Jos:
In the course of moving things over, maybe stuff got garbled. It's very
difficult for the old archival information not to come up in a search.
If we would find it useful, Iw ould be happy to write up a quick summary
of how we think about information. I think that's a good idea. We
tried to dump everytihng to the wiki. That didn' work well. so maybe
we start with a clean wiki with no info in it and turn it over to the
committee chairs to organization as they see fit. Migrate content, and
create new content as they see fit.
Aaron Poulsen (Amazon):
I would love to see some consistency in the wiki. I have found
navigation convoluted with the new wiki to the ponit where I no longer
come to the wiki for information.
Jos:
That's what we want to avoid.
Trevoli Ponds-White (Amazon):
Something I always want on the wiki is a landing page for the groups.
When I left, I wanted to send messages to chairs of the groups, and we
didn't have basic stuff for most of the working groups on the wiki with
the relevant informaiton for that WG.
Jos:
I will commit next meeting to talking about how the wiki tihnks about
information. Let's use that as a starting poing.
Trev:
I wouldn't purge all the content just because it's hard to navigate.
Jos:
I will pull somethign together about what it can do and how it thinks
about information so we can make better decisions.
Aaron Gable:
Two additional comments.
I think we're in a situation where for any given item of information
there's a lack of clarity for if it's true home is the wiki or the
website. Server Certificiate Working group has pages for every ballot.
Is the page on the wiki or the website the authoritiative source for
that ballot? Why do we have both? We should clarify things like that.
We have a habit of not cross linking very much. Cross linking (and our
emails) don't do that very much. Like there was a recent email saying
the agenda has been updated, but there was no link to the meeting 60
agenda page in the wiki. There is a culture change we can make about
using links, which would make navigation much easier.
Jos:
I very much agree with the information heirarchy problem between the
wiki, the website, and GitHub. Where do I create things? We could use a
step back to think about what we want our information flow to be. It's
okay to say we're going to do this function at only one place and not
anywhere else.
Paul:
We heard a few sources about where ballots can be located and also
recording votes etc. It would be valuable if we more formally used the
pull request to actually hold the ballot language and could have
approvals of code owners assigned to that.
Aaron P:
Jos, this isn't easy so we really appreciate you and the team working on
this.
Jos:
We may also come back with a suggestion for what we think the
information flow and heirarchy should be, to consider. This is exactly
the kind of feedback I was hoping to get today. Please contact me or
the infrastructure subcommittee if you have any more input.
Other pieces on the project list include:
* Wayne was working on some of the issues with email bouncing. We
need some adjustments to our setup.
Ben:
We don't have anything structural on web site changes.
Jos:
Onboarding instructions were a significant project that we want some
movement around. It's a documenting-how-things-work project that is on
our slate for this next term.
Is there any other new business to discuss?
(No new business is raised.)
Dimitris:
Thanks to the infrastructure subcommittee for doing such great work and
keeping things running.
Open Mic
*Discussion leader:* Dimitris Zacharopoulos (HARICA)
*Minutes:*Dimitris Zacharopoulos (HARICA) & Kiran Tummala (Microsoft)
(Paul): The CABF is usually re-active. We are missing the pro-active
work. We usually do not engage in controversial topics where we should
be discussing what is making a topic controversial. Try to set goals and
what needs to be accomplished. Make documents more readable.
Clint asked for a specific example
Paul mentioned that it would be more efficient to if the forum would
evaluate for example the objective for proposing somthing such as the
Google's 90-dayscert validity proposalas a collaborative effort, instead
something that is driven outside the forum. By collaboratively looking
at the issue (instead of the solution) we create a better perspective,
look at different mitigations, and create broader support from the members.
Another example given by Paul is Post-Quantum. How is the forum going to
prepare for PQC, are we going to endorse hybrid/composite certificates?
What quantum-resistant algorithms do we select for TLS, SMIME, or
CodeSigning, certificates, these might not be the same because of the
different use case and algorithm characteristics. What about the size of
the certificates and Root Storesnow we also move to single purpose
hierarchies, root stores are going to become significantly larger. The
impact of SCT signatures, etc. While for TLS the harvest now, decrypt
later attack can be mostly addressed in the TLS session key-exchange
(i.e., PFS), this does not protect the client/server authentication.
Paul also mentioned about the compliance risks and audit costs when
there are standards with similar requirements, similar language with
different titles.
Trev: Sometimes we can present problems and solutions and data to
support that.
Paul said we should present issues with concrete data, even without a
solution, and let the Forum propose solutions. We should always talk
about the problem we're trying to resolve.
Tim Callan: What you get out of it is what you put in it. Members need
to bring in more issues and drive them. If it's a reasonable issue, it
will be discussed and proposals will be presented.
Trev: We need a higher-bar for the presentations. Dig into the data
behind it and then make policy changes. We see many bugs on a certain
issue that can drive policy changes.
Nitesh: Driving with focus on objectives with data backing is critical,
v/s jumping to solutions directly. Another aspect that forum should
consider is to publish each year ahead goals/objectives for each
sub-workstream, to drive future looking aspects more predictably
Dimitris: If a Member has an issue that wants to be discussed but
doesn't have time to drive it, the issue should be shared with the
larger group because there might be others that face the same issue, and
perhaps another person can drive it.
Share lessons learned from CAs and continuous improvement. Presentation
from ATS with important lessons learned. Share these initiatives more
broadly. Codifying these implementations in the BRs later.
Paul: Should we make the recordings available because of the different
geographical locationsof our members?
Perhaps share on the Management List, don't share, don't store it.
Start with a slide with the Notewell, you are not suppored to make this
public.
Archival bit, after some specific times.
Clint: Add the recording and transcript to the member's tool for a
certain amount of time.
Agree to stop the recording when there is a confidential issue to
discuss. That topic will not be added in the minutes.
Put on the Agenda at the next F2F Teleconferences for action items.
Guest Speaker
*Presenter:* Rob Brand - Ministry of Economic Affairs and climate Policy
(NL)
*Title: *Building Trust, Empowering the Digital Economy - eIDAS Trust
Services
*Presentation link:*
https://cabforum.org/wp-content/uploads/2-Guest-Speaker-231003CABForum-Presentation-NL-v1.0.pdf
*Minutes:*Kiran Tummala (Microsoft)
Presentation Notes:
*Management Audit and Certification Process in the Netherlands:*
* Rob discussed a management audit that was conducted in the
Netherlands regarding the certification process for trust services.
* It was noted that the supervisory body in the Netherlands did not
have the authority to provide a second opinion on the certification
process.
* The process seemed less robust, leading to concerns about the
quality of trust services certification in the past.
*Telecommunications and Digital Hack in 2011:*
* Rob highlighted that the supervisory body's limited knowledge in the
telecommunications sector contributed to a significant digital hack
in 2011.
* A man-in-the-middle attack with fake certificates exposed weak
security practices.
* The impact was significant, affecting qualified certificates and
leading to the shutdown of government services.
* A certification authority even went bankrupt.
*Security Awareness and Regulatory Adjustments:*
* After the 2011 incident, the Netherlands took steps to increase
security awareness.
* Efforts were made to adjust regulations within Europe regarding
certificates.
* Three key areas of improvement were identified: increased security
awareness, legal improvements, and organizational measures.
*Role of the Inspector for Digital Infrastructure:*
* A new supervisory body, known as the Inspector for Digital
Infrastructure, was established in the Netherlands.
* This body took on supervisory tasks and aimed to become a knowledge
center for trust services.
* This development was considered a positive step in improving oversight.
*Yearly Crisis Exercises and Multi-Vendor Strategy:*
* The Netherlands initiated yearly crisis exercises and developed a
crisis manual for digital affairs.
* A multi-vendor strategy was implemented to avoid dependency on a
single organization in case of a disaster.
* This strategy aimed to ensure continued government operation in the
event of a similar crisis.
*Impact of eIDAS Regulation:*
* The eIDAS regulation was hailed as a dramatic improvement over the
previous signature directive.
* It harmonized requirements and introduced product certification
based on standard 1765.
* Auditors could now assess systems directly, not just the management
system.
*Supervisory Body Independence:*
* The eIDAS regulation gave supervisory bodies the autonomous
responsibility to accept or decline applications for qualification.
* Even if a service provider met the assessment requirements, the
supervisory body could still refuse qualification based on their
assessment of the data center, enhancing oversight.
* Government Use of Qualified Trust Services:
* Government organizations in the Netherlands were required to use
qualified trust services to ensure their identity and legitimacy.
* This requirement was seen as crucial for secure communication within
NATO and to build trust.
*Transition Away from Green Bar:*
* The transition away from the green bar indicator for trustworthiness
in websites had posed some challenges.
* It was noted that the shift occurred around 2018 and continued.
* Discussions around new indicators were ongoing to maintain user
confidence.
*eIDAS Regulation Updates and Future Considerations:*
* The eIDAS regulation was undergoing updates, with a target effective
date around 2024.
* Specific articles and requirements were still under negotiation.
* Discussions around uniformity, user-friendly indications, and
potential changes in root stores were being considered.
*Cooperation and Global Trust:*
* Cooperation between stakeholders, including browser vendors and
certificate authorities, was seen as essential.
* Efforts were made to ensure that unilateral decisions did not
jeopardize trust.
* Trust services and their regulation were expected to play a crucial
role in the digital economy's autonomy and sovereignty.
*EU Participation in the CA/Browser Forum:*
* The possibility of the EU participating more formally in the
CA/Browser Forum was discussed.
* Concerns about the requirement to sign an Intellectual Property
Rights (IPR) agreement were raised.
* The need for further discussion and potential adjustments to
participation requirements was acknowledged.
*Future Trends:*
* Trust regulation was expected to become more prevalent in various
sectors.
* The geopolitical situation and the emphasis on digital autonomy and
sovereignty were influencing trust services.
* Trust services were being viewed from a perspective of autonomy and
sovereignty
Browser Updates
Mozilla Root Program Update
*Leader:* Ben Wilson (Mozilla)
*Minutes:* Doug Beattie (Globalsign)
*Presentation link:*
_https://cabforum.org/wp-content/uploads/2023-October-Mozilla-Browser-News.pdf_
<https://cabforum.org/wp-content/uploads/2023-October-Mozilla-Browser-News.pdf>*
*
*Discussion outside the presentation: *
There were no material discussion beyond what was presented.
Google Root Program Update
*Leader:* Chris Clements & Ryan Dickson (Google Chrome)
*Minutes:* Stephen Davidson (DigiCert)
*Presentation link:
*https://cabforum.org/wp-content/uploads/5-CABF-F2F-60-Chrome-Browser-Update.pdf
*Discussion outside the presentation:*
1) Chrome Root Program Updates:
*
Modern Infrastructures Survey Background and Motivation
o
Chrome believes that encryption makes the web more secure and
protects users. In order for encryption to provide this security
benefit, it must be consistently and reliably deployed.
o
Promoting modern infrastructures enhances that consistency and
reliability - through simplicity and agility.
+
when systems are simple they are easier to understand, use,
and manage, leading to fewer errors and more consistent results.
+
when systems are agile they can adapt to change and promote
continuous improvement and reliability - while delivering
their service.
o
Promoting Modern Infrastructures aligns with higher-level Chrome
Root Program goals of promoting simplicity and agility.
o
Shared background on “Moving Forward, Together" initiative
+
Long-term grouping of initiatives, first introduced at F2F 55.
+
Non-normative, and therefore not policy.
+
Shared publicly and in advance of any corresponding
implementation timelines to identify existing and create new
opportunities to help.
o
Described a tentative, phased approach for achieving the goals
of “Moving Forward, Together.”
+
Since MFT was first introduced, the Chrome team has had a
lot of conversations about milestone sequencing, and coupled
with the results from this most recent survey - heard and
saw a desire for general sequencing.
#
Naturally, by conveying an ordering or phasing,
stakeholders can better prepare.
#
The plan presented is tentative. The order may change as
the Chrome team collects more data, studies community
feedback, and as new threats emerge.
#
If during exploration, it’s determined a goal cannot be
achieved at the stated time without significant negative
impact to the ecosystem, plans will be adjusted.
+
Immediate focus is support for automation and term limit for
roots included in the Chrome Root Store
#
Both of these initiatives represent a commitment to
simplicity and agility - and are fundamental for
achieving many of the other goals described in MFT.
o
Chrome’s approach is influenced by data collected from a number
of sources to include public tools like crt.sh <http://crt.sh>
and Censys, results from Chrome’s own experimentation,
evaluating peer-reviewed research, and through using CA owner
surveys. These tools help improve perspective and predict impact
of areas of exploration.
*
Survey, Findings, and Themes
o
Survey background:
+
Goal: understand CA owner perspective related to impacts of
“modern infrastructures" initiatives like term limit,
reduced certificate lifetime, reduced domain validation
reuse, etc.
+
100% of CA owners responded.
#
47% of CA owners provided comments to an open-ended
question at the end of the survey.
#
Chrome interpreted these results to indicate what was
top of mind for most CA owners.
*
47% cited a negative impact or otherwise expressed
concern associated with the proposed root term limit
*
26% expressed appreciation for the opportunity to
offer feedback, and
*
22% asked for sufficient migration time before any
future requirements should become effective.
#
Chrome appreciates the candid responses provided by CA
owners and will continue this approach in future surveys.
o
Survey results:
+
Automation
#
Chrome believes adoption of modern practices like
automated certificate issuance and management help
realize the full security value of TLS.
#
Goals for and motivation related to automation were
shared at F2F 59. If interested in learning more, refer
back to that presentation.
#
76% of CA owners included in the Chrome Root Store
stated support for automated solutions
#
~99.99 of the certificates issued in the Web PKI today
are issued by these CA owners, estimated by combining
survey responses and publicly available data.
*
Noted that this data analysis was a point-in-time
analysis, performed the week of September 21st.
#
~82 of the certificates issued by the Web PKI today are
issued using some form of automation.
*
This was extrapolated by considering CA owner survey
responses against data from tools like crt.sh.
#
The described data points, along with other feedback in
response to the survey was interpreted by the Chrome
team to indicate:
*
broader support for automation by CA owners and
corresponding service providers will continue to
create better opportunities for website owners to
improve the consistency and reliability of TLS
implementations.
*
support and innovation related to automation can
help reduce the trade offs related to the time and
effort required to adopt these practices.
*
there are opportunities to improve the state of
automation across the ecosystem to include increased
availability of services, development of new
features and product enhancements that will make
adopting automation a better fit for certain types
of subscribers, and opportunities to educate the
user community on the opportunity automation presents.
o
Chrome is planning a blog post about automation,
to be published in the next week or so.
+
Term Limits
#
The Chrome Root Program feels a term limit for roots
included in the Chrome Root Store will:
*
Help promote and realize the gains of continuous
improvement.
*
Promote agility while discouraging potentially
dangerous practices and eliminating single points of
failure. It also allows adoption of new standards
and security features not available when earlier
roots were established.
*
Reduce risk by re-establishing “known good" security
baselines that may have been unknowingly lost over a
period of time that is now sometimes up to 35 years.
By reducing the period a root is relied upon, we
reduce the maximum window of potential abuse.
#
Refresher, MFT describes a proposal for a 7-year term
limit. Survey questions were focused at understanding
how that proposal impacts the ecosystem.
#
Results:
*
On average, CAs reported the “Active Signing
Lifetime" which was described as “how long root CAs
are used to sign new ICA certificates responsible
for leaf certificate issuance — before transitioning
to a new root?” - was about 15 years.
*
Most respondents indicated “Active Signing Lifetime"
was between 10 and 20 years.
*
Though about 15% of CA owners aligned with the
7-year proposal, most do not.
o
The most common theme shared by CA owners
indicated that the proposed term limit would
exacerbate the challenges of achieving root
ubiquity - a critical user and device support story.
#
Conclusions:
*
Chrome identified concern, and some degree of risk
communicated in response to the proposed 7 year term
limit. Because of that feedback, Chrome will change
its proposed approach. Specifics will be shared
later in the presentation.
*
A more agile approach is still preferred, and might
be explored again in the future. It’s possible that
over time, barriers to reduced functional life of
roots will be removed - without additional active
effort.
*
Opportunities for innovation may also improve
opportunities for agility.
*
Chrome encourages CA owners to explore how they can
adopt more frequent root rotation.
*
Future Areas of Exploration
o
Described upcoming Chrome areas of exploration to include
linting, phasing-out multi-purpose roots, and phasing out client
authentication use cases.
o
Brief motivation for exploring these areas:
+
Broader adoption of linting has the opportunity to reduce
common mis-issuance events, resulting in fewer Web PKI
incidents that typically do not materially affect the
underlying security of TLS connections.
+
Today, Chrome transitively trusts over 2,300 CA certificates
#
About half of these CAs support use cases other than
server Authentication — the only use case applicable for
Chrome – and presumably other web-browser certificate
consumers.
#
Given that each CA trusted represents added attack
surface, and given that the comingling of use cases
minimally increases complexity, Chrome intends to phase
out roots not dedicated to server authentication in the
future.
+
Chrome wants to understand the applicability of
clientAuthentication use cases for web browsers and
corresponding root store’s, like Chrome’s - whose use case
for TLS is website authentication — not server-to-server or
device authentication.
o
For these areas, CA owners can expect opportunities to share use
cases and impact related to Chrome’s proposals. CA owner
feedback is considered and valued.
o
If requirements are drafted, Chrome will do so in a way that
attempts to minimize unintended impact and allows stakeholders
time to prepare for and respond to changes.
o
Finally, these proposals will take time. As an example, Chrome
began studying automation requirements almost a year ago, but
the Chrome Root Program Policy does not yet have requirements
related to automation.
+
This point was again emphasized as it relates to leaf validity.
o
Described that exploring a reduction in maximum certificate
validity is still and will remain a priority for the Chrome Root
Program.
+
Chrome is often motivated by thinking about the impact of
“worst case" scenarios.
#
For example, if we imagined an event like Heartbleed
happening again…. are we adequately prepared to respond
as an ecosystem? Are our collective users and customers
in a position to respond quickly and completely to a
vulnerability or incident that puts the foundation of
web security at risk?
+
As a community, and as leaders in this space, it is our
combined responsibility to continue improving such that when
we need to respond, we can - and without delay.
+
Chrome believes the combination of automation and reduced
certificate validity best positions us to manage risk and
promote agility moving forward — and remains committed to
exploring this further.
*
Policy Updates
o
Chrome will be introducing a new “pre-flight" process,
introduced at the last Face-to-Face, where CA owners can offer
comments or request clarifications prior to a new policy version
becoming final and effective.
o
Described the pre-flight process, and what CAs should expect
related to timelines and next steps.
o
A summary of the updates included in the policy update were
described. A point of emphasis was removing language from the
Chrome Root Program policy and instead relying on reference to
the CCADB policy, especially as it relates to incident reporting.
o
New subsections related to Root CA Key Material Freshness,
Automation Support, and the Root CA Term-Limit
+
Key Freshness: Updates are intended to be clarifying to more
clearly describe expectations related to how CA owners can
illustrate that pre-existing key freshness requirements are
satisfied.
+
Automation: New requirements such that applicants applying
to the Chrome Root Program after January 15, 2024 must
support some form of automation. ACME is preferred, however
other solutions can also be acceptable. This outcome was
influenced by CA owner feedback, as originally, Chrome
intended to require use of ACME. There is no expectation or
requirement that subscribers must use automation, just that
CAs must make it an option for their use.
+
Term-limit: New requirements that will limit a root’s
inclusion in the Chrome Root Store to 15 years. This
timeline was influenced by CA owner feedback provided during
the recent CA owner survey. A specific phase-out plan is
described in the policy update to reduce negative impact to
the ecosystem as this change is implemented.
*
Feature Launch Roadmap: The Chrome Certificate Verifier and Root
Store have been deployed on all platforms, where possible. A FAQ
link in the presentation materials describes more information about
when specific platforms transitioned to the new Chrome tools.
2) Certificate Transparency Updates
*
Chrome Security team members sent notice on 9/15 and 9/29 that
several logs have been approved for inclusion in Chrome and are
marked as Qualified.
*
Chrome is always looking for new CAs to responsibly operate CT logs,
and that these types of community contribution are evaluated when
reviewing root store applications.
*
Reach out to the Chrome team if interested in running a CT log.
3) General Browser News
*
Beginning in Chrome 116, Chrome began offering support for Kyber.
o
This is not post quantum x.509 support, this is from the
perspective of establishing symmetric secrets during the TLS
handshake.
*
Interested parties can learn more about this change in a blog post
that’s linked from the slides.
**
Apple Root Program Update
*Leader:* Clint Wilson (Apple)
*Minutes:* Corey Bonnel (Digicert)
*Presentation link:*
https://cabforum.org/wp-content/uploads/6-2023-October-Apple.pdf
*Discussion outside the presentation:*
Clint asked CT log operators to prepare sharded logs for 2026.
Additionally, he would like to drive discussion on the state of CT log
operators.
Clint provided a review of 2023:
Earlier this year, a new version of Apple root policy was published. The
primary intention was to document previously undocumented requirements.
Additionally, a feedback cycle was introduced. This feedback cycle was
very beneficial in terms of improving the root policy.
Several CAs opted to remove their S/MIME-issuing CAs from the Apple
program instead of complying with the S/MIME Baseline Requirements,
which came into effect on September 1st. Overall, the S/MIME BR
implementation in preparation of the effective date was relatively smooth.
Clint provided a reminder of upcoming effective dates:
Apple will no longer accept multi-purpose root inclusion requests after
April 15, 2024.
Apple will require CAs to support at least domain validation method for
the issuance of serverauth TLS certificates that can be automated as of
August 15, 2024.
Apple will require that S/MIME-issuing CAs provide a S/MIME BR audit
report uploaded to CCADB by December 1st, 2024.
Clint reminded CAs that they need to share incident reports with Apple.
If the report is available in Bugzilla, then a link to the incident is
sufficient.
Clint said that several inclusion requests have been received where not
all the requisite information has been provided. To move the request
along, all required information must be provided.
Clint provided a preview of 2024 changes:
Addressing backlog items:
1. Website improvements to provide an archive of previous versions of
the policy as well as a changelog
2. Clarify how updated versions of external documents that are
referenced in the policy affect the policy
3. Improve language on key generation and protection requirements
4. High-level discussion on:
a. certificate validity periods and validation data re-use periods
b. use of subject DN attributes
c. requirements for the annual self-assessment
d. PQC: TLS certificates are not high priority, but other certificate
use cases are
Clint would like input and suggestions for next steps, as it may be
helpful to pilot initiatives in root policy before introduction of a
requirement in the BRs. The IETF strongly recommends running code that
implements a draft standard to ensure its feasibility. Clint also
alluded to a hesitation by implementers to not implement something that
is not yet required. It's desired to understand the potential impact of
a proposed requirement before it actually comes into effect and becomes
a compliance issue.
Trev agreed that it is an involved process to add something to the BRs.
She asked Clint if he's implying that root policy is easier to implement
as opposed to the BRs, as it is a compliance incident regardless of the
source of the requirement.
Clint said that it's not necessarily easier to modify root policy as
opposed to the BRs, but rather that beneficial items have been
originally introduced in root policies and later incorporated into the
BRs. If there's value in piloting a requirement before it becomes a
compliance-impacting requirements, then the requirements better account
for edge cases without CAs experiencing non-compliance incidents.
Jeremy asked if the scope of investigation on data re-use includes
organization validation data, or is domain validation and mailbox
validation reuse being considered. Clint clarified that the domain names
expressed in the nameConstraints of technically constrained CA
certificates was one facet. A wider view of all aspects of validation
data re-use is being considered, but few concrete items yet.
Clint said that in Q1 or Q2 2024, a preview of an upcoming policy update
in Q3 or Q4 next year will be circulated.
Microsoft Root Program Update
*Leader:* Hannah Sokol and Nitesh Bakliwal (Microsoft)
*Minutes:* Dean Coclin (Digicert)
*Presentation link:*
https://cabforum.org/wp-content/uploads/7-Microsoft_F2F60_Presentation.pdf
*Discussion outside the presentation:*
* Question about the change in code signing certs accepting only RSA,
what is the rationale for that?
* Answer: Not a change, that is what they currently support.
They looked at ECDSA but the ROI to implement that isn't there at this
time.Microsoft believes that exploring the approaches to support PQC as
future, is better investment.
* Question: What's the plan for MSFT to support PQC? Answer: Will be
investing time to look at that now.It is the future approach and
reason why we are not investing in ECDSA support exploration.
* Question: Which CT logs will be trusted. Answer: Not published yet.
*
Question: Regarding upcoming SCT policy, is this a technical
restriction or a root policy? Answer: Starting with a technical
implementation but moving toward a root policy.
*
Question: With audits, will you notify CAs if they have issues? With
so many different root policies, we have to harmonize or else it's
not feasible. Answer: Yes, we intend to notify CAs. Also, Good
pointaround harmonization, will likely piggyback on another root
policies.However, all Mozilla, Apple, Google and Apple should meet
and syncronize their CT policy.
*
Comment: It would be preferable instead of having root policies,
that these things go thru the CA/B Forum.
*
Comment: Sometimes there are things that are out of scope of the forum.
*
Comment: We should try to put as much in the forum as possible. CT
is not part of BRs. Couldn't that be part of the BRs? Would be good
to discuss in forum.
*
Comment: CT Log operators are an entity not envisioned in BRs and
may not be CAs or Browsers. But you can make a conditional
requirement, ( if you are a CA or brownser and operate a log then
you must....).
CCADB Update
*Leader:* Ben Wilson (Mozilla, on behalf of the CCADB Steering Committee)
*Minutes:* Hannah Sokol (Microsoft)
*Presentation link:
*https://cabforum.org/wp-content/uploads/8-CAB-F2F-60-CCADB-Update.pdf
*Discussion outside the presentation:*
Updates to the CCADB.org
August this past year, added policy on CCADB usage as well as tooling
Usage
- Ran into problem with license with Salesforce due to overuse. Had to
add guidance around usage. < 5 log on per month (~ once per week)
- halved the use and we appreciate all the compliance around this
Tooling
- trouble maintaining the tools and se we moved to the GitHub. PEM Tool
which is built into CCADB. Processes PEM file and processes CCADB with
read only information (fixed bugs related to this parser)
- EVReadiness tool - paste in a PEM and run EV OID and the name of the
server you are testing and test the cert against EV guidelines. URL will
say what the testing does as well as a URL to the tool itself
Feature Updates: CA reports and Communications
Working on Audit Team Qualifications that is to come out this month
Click on "My CA" -> CA Reports
Report on all your certs and show your root / intermediate root ect.
Helps with your audits and self-assessment
Generate this report, export to CSV, remove columns you dont need, and
you then can use it for one of those two use cases
CA Communications
Shows all your comms that you have been partied to and things that have
been sent out from your Root CA
Working on audit teams qualifications - upload button instead of
referencing a URL. You would upload Auditing qualifications. This is for
when something is separate (WebTrust) other roots stores are wanting it
and so we added functionality to upload audit team qualifications
Under audit team there would be an upload button, what do you want to
upload, upload file, and it will show the place where that is saved
within CCADB
Is this for ETSI? This is mainly for WebTrust or any other auditor where
auditing qualifications need to be used
Check box where we look at auditor team qualifications and if it
satisfies the qualifications
What else is going on?
If you want to see request enhancements or bugs there is a link to the
dashboard
We prioritize and triage the bugs
Can see the status and you are welcome to submit those as well
Add S/MIME fields to upload or populating data about SBRs
3.1 Announce incident reporting format
Taken current criteria and reorganized it into 7 different categories
and will publish it at the end of the week. Ask that CAs start giving
incident reports in this formal language and paste this into a Bug and
it will break it into these categories
Put attached files in the appendix (ex. crt.sh hashes)
Don: When do you feel you will be ready for SMIME reports? To receive them?
Ben: We are ready now, it is just not stored in the CCADB. We will
communicate among the root operators that here is the audit report. The
person on call would review the SMIME audit reports along with other
reports. It is not recorded in CCADB until we get this functionality.
This should be delivered near the end of Q4
Don: Delayed parsing out Network Security report until you are ready to
receive it in a separate template. We have the report and are drafting
new reports to req the separation of Network Security. What is the
timeline around that?
Ben: We have talked about this. Yes, it looks like we can do it at the
same time as SMIME. There are time budgeting restrictions with our
outsourced software dev. However, that was the planned approach to add
the network security with (might be wrong, other members call me out)
Chris: Confirming that the desire is to align with those two new audit
types. Work through CCADB steering committee requirements
Clint: More conversation around timing around separation of the root
reports. That the criteria is separate. Will have emails back and forth
to make sure
Q&A Root program discussions
*Minutes:* Arvid Vermote (GlobalSign)
Question: Are root programs open for CT harmonization?
Mozilla: Yes, as we drafted our policy we were under the assumption
there would be consistency between root programs. Agreement it would be
better to come to a common language.
Feedback: Suggestion to have the CT policy under CABF. Having multiple
policies does not mean they are the same, the continue to require
monitoring. Should have one document, one policy, one list of CT logs.
Apple: there are some outstanding quesitons: are the current policies
causing conflicts / complexitieis or is it more a risk we see for the
future? Other thought: if we shift it to CABF it would inherently end up
being a different set of entities the policy applies to (right now,
voluntary CA but might change if we move it to CABF)
Feedback: multiple examples were given about the potential complexitiies
of the current "multiple policies" approach
Apple: open to consolidating but hoping everyone understands the
implications
Microsoft is also open to jontly review and explore opportunity for
consolidation and is already looking at Chrome and Apple policies as
baseline
Chrome: CT policy is seperate from root program policy. There is an
opportunity to align were the beliefs are common but there will always
be independent root program requirements. Just because common
requirements are aligned it does not mean the programs still might have
seperate requirements.
Feedback: complying to all the different policies is diffirent, question
to the root programs to make sure requirements are aigned. There is no
reason why the root programs should come together, compare and make sure
things aligned.
Aligned: alignment excercises are done during CT days.
Feedback: it makes sense for the browsers to have unique products, as
long as the browsers continue to discuss stuff and work together to make
sure a shared product does not break in a single browser because of
their CT policy, that is what the CAs want to avoid
Question for Chrome: you said you wanted to phase out client auth. What
would be the driver for that?
Chrome answer: we noticed that only 10% of certificates in scope within
the Chrome root program contained client auth, not clear on the use case
and no insights on what it would be. Awaiting feedback from further
surveys what the consumer impact on removing client auth would be.
Feedback: the trust anchor for client auth is configured server side so
having it chained to public trust anchors seems not needed, but maybe
there are cases were there needs to be interoperability / consumers need
multiple issuers for their client auth certificates.
Chrome: no intent to prohibit it from private PKI / other uses cases,
only to remove it from TLS certificates
Audit Updates
ETSI Update
*Leader:* Nick Pope and Arno Fiedler (Chairs ETSI ESI)
*Minutes:* Clemens Wanko (TUV AUSTRIA)
*Presentation link:
*https://cabforum.org/wp-content/uploads/10-ETSI-ESI-Activities-CABFORUM2023-10.pdf
*ETSI summary of most important news (see slides for details):*
Arno reported latest developments and updates from the ETSI/ESI
normative developments. The overall map of available standards shows not
only full coverage now but several updates supporting ongoing
developments in all the different areas like:
* legal devs. at EU-level, like NIS2 and eIDAS2 as well as
* supporting CA/B Forum specifics, like S/MIME BR with the ETSI TS 119
411-6.
See slides for further details.
*Discussion outside the presentation:* No additional discussion.
ACAB'C Update
*Leader:* Clemens Wanko (TÜV AUSTRIA)
*Minutes:* Arno Fiedler (Vice Chair ETSI ESI)
*Presentation link:
*https://cabforum.org/wp-content/uploads/11-20231003_CAB-Forum_60_ACABc_presentation_V1.4.pdf
*ACAB'C summary of most important news (see slides for details):*
*Updates*
* *NIS2/Cybersecurity requirements for EU-based CA/TSP*
* Clemens reminded CA/TSP based on EU grounds on upcoming
caybersecurity requirements derived from th eEU directive on NIS2
(DIRECTIVE (EU) 2022/2555. Requrements following the directive will
be defined, released by EU MS and adhered to by CA/TSP from 18th
Oct. 2024 (Art. 41). Requirements for CA/TSP (mainly!) are addressed
in updated ETSI EN 319 401. National MS specifics to be added to
show full compliance.
* *S/MIME BR audit integration*
* ETSI TS 119 411-6 is interfacing between ETSI EN 319 411-1/2
requirements for CA/TSP issuing PTC
* and S/MIME BR. CA/TSP shall ensure that their CAB base audits on the
...411-6 plus S/MIME BR and mention those in their reports
including the AAL.
* *Policy based AAL templates *
* AAL concept change to improve CCADB AALV.
* New concept: a _set of different attestations letters_is required
_to form one complete audit attestation_
* There is 1 standardletter template and 4 specific ones.
* Standard Audit Attestation Letter
* Lists all Roots and all corresponding SubCA (Intermediate & Issuing
CA) that have been in the scope of the conformity assessment
* SMIME-BR Audit Attestation Letter
* List only the Roots and only the corresponding SubCA to the Roots
(Intermediate & Issuing CA) that have been assessed against the
SMIME BR (=> ETSI TS 119 411-6)
* TLS-BR Audit Attestation Letter
* List only the Roots and only the corresponding SubCA to the Roots
(Intermediate & Issuing CA) that have been assessed against the
TLS BR (ETSI policies DVCP, IVCP, OVCP, QNCP-w)
* TLS-EV Audit Attestation Letter
* List only the Roots and only the corresponding SubCA to the Roots
(Intermediate & Issuing CA) that have been assessed against the
TLS EV Guidelines (=> ETSI policies EVCP, QEVCP-w)
* Code Signing-BR Audit Attestation Letter
* List only the Roots and only the corresponding SubCA to the Roots
(Intermediate & Issuing CA) that have been assessed against the
Code Signing BR (=> ETSI policies NCP, NCP)
See slides for further details.
*Discussion outside the presentation:*No additional discussion.
WebTrust Update
*Leader:* Tim Crawford, Don Sheehy, Dave Chin, (CPA Canada)
*Minutes:* Bruce Morton (Entrust)
*Presentation link:
*https://cabforum.org/wp-content/uploads/12-Webtrust-CABF-update-Oct-2023-New-Format-v4.pdf
*Some notes from the presentation:*
* WebTrust for S/MIME v1.0.1 has been issued.
* WebTrust for CA 2.2.2 in progress.
* Reporting templates being updated.
* Practioner guidance updated.
* Details controls reporting updated which is not a public report. The
report is made up of 6 major sections.
* Impact of assessment of ISO 27099 on WebTrust. There were many
changes. The rough draft showed too many issues. So now ISO 21188 is
under review which will be updated and may contain items from ISO
27099. So WebTrust for CA should not be impacted until effort is done.
* WebTrust for Network Security report will be effective 1 April 2024.
* Still working on WebTrust for CA supporting X9 and IoT programs.
* Added two new members to the WebTrust task force.
* For a WebTrust audit a Signing Practioner is needed who must be WTCA
licensed and PKI trained. Quality
* New seal pricing and bundles.
* Seal updates for RAs, S/MIME and Qualified Seal.
*Discussion outside the presentation:* none
Q&A Audits and Standards
*Minutes:*Kiran Tummala (Microsoft)
*ADJURNED Forum Plenary Meeting for Day 1*
CABF Face-to-Face Meeting 60: Day 2 October 4, 2023
CA/Browser Forum Meeting
Attendance
Aaron Gable - (Let's Encrypt), Aaron Poulsen - (Amazon), Abhishek Bhat -
(eMudhra), Adam Jones - (Microsoft), Adrian Mueller - (SwissSign),
Adriano Santoni - (Actalis S.p.A.), Aleksandra Kurosz (Asseco Data
Systems S.A.), Andrea Holland - (VikingCloud), Andreas Henschel
(D-Trust), Aneta Wojtczak-Iwanicka - (Microsoft), Anna-Marie Christian
(WebTrust / CPA Canada), Antti Backman - (Telia Company), Arno Fiedler -
(ETSI), Arnold Essing (Telekom Security), Arvid Vermote - (GlobalSign),
Ben Wilson - (Mozilla), Brianca Martin - (Amazon), Brittany Randall -
(GoDaddy), Bruce Morton - (Entrust), Chris Clements - (Google),
Christophe Bonjean - (GlobalSign), Clemens Wanko - (ACAB'c / TUV
Austria), Clint Wilson - (Apple), Corey Bonnell - (DigiCert), Corey
Bonnell (DigiCert), Corey Rasmussen - (OATI), Daryn Wright - (GoDaddy),
Dave Chin - (CPA Canada/WebTrust), Dean Coclin (DigiCert), Dimitris
Zacharopoulos - (HARICA), Don Sheehy (WebTrust), Doug Beattie -
(GlobalSign), Ellie Lu - (TrustAsia Technologies Inc.), Enrico Entschew
(D-Trust), Eva Vansteenberge - (GlobalSign), Hannah Sokol - (Microsoft),
Hogeun Yoo - (NAVER Cloud), Ian McMillan - (Microsoft), Inaba Atsushi -
(GlobalSign), Inigo Barreira - (Sectigo), Janet Hines - (VikingCloud),
Jeremy Rowley - (DigiCert), Joanna Fox - (TrustCor Systems), Jochem van
den Berge - (Logius PKIoverheid), John Mason (Microsoft), John Sarapata
(Google Trust Services), Joseph Ramm - (OATI), Jozef Nigut - (Disig),
Kateryna Aleksieieva - (Asseco Data Systems SA (Certum)), Keshava
Nagaraju - (eMudhra), Kiran Tummala - (Microsoft), Leo Grove (SSL.com),
Li-Chun Chen (ChungHwa Telecom), Lynn Jeun - (Visa), Mads Henriksveen -
(Buypass AS), Marcelo Silva - (Visa), Marco Schambach - (IdenTrust),
Martijn Katerbarg - (Sectigo), Michael Guenther - (SwissSign), Michael
Slaughter - (Amazon), Michelle Coon - (OATI), Mohit Kumar (GlobalSign),
Nargis Mannan - (VikingCloud), Nate Smith - (GoDaddy), Naveen Kumar -
(eMudhra), Nicol So - (CommScope), Nikolaos Soumelidis (QMSCERT), Nitesh
Bakliwal (Microsoft), Paul van Brouwershaven - (Entrust), Pedro Fuentes
- (OISTE Foundation), Pekka Lahtiharju - (Telia Company), Raffaela
Achermann - (SwissSign), Rebecca Kelley - (Apple), Rich Kapushinski -
(CommScope), Rob Brand (Ministry of Economic Affairs and climate Policy
(NL)), Rob Stradling - (Sectigo), Rollin Yu - (TrustAsia Technologies
Inc.), Roman Fischer (SwissSign AG), Ryan Dickson - (Google), Scott Rea
- (eMudhra), Sissel Hoel - (Buypass AS), Stephen Davidson - (DigiCert),
Steven Deitte - (GoDaddy), Sven Rajala - (Keyfactor), Tadahiko Ito -
(SECOM Trust Systems), Tim Callan (Sectigo), Tim Crawford - (CPA
Canada/WebTrust), Tim Hollebeek (DigiCert), Tobias Josefowitz - (Opera
Software AS), Tom Zermeno (SSL.com), Trevoli Ponds-White - (Amazon),
Tsung-Min Kuo - (Chunghwa Telecom), Vijayakumar (Vijay) Manjunatha -
(eMudhra), Wayne Thayer - (Fastly), Wen-Chun Yang (ChungHwa Telecom),
Wendy Brown - (US Federal PKI Management Authority), Xiu Lei - (GDCA).
Definitions and Glossary WG
*Leader:* Tim Hollebeek (DigiCert)
*Minutes:* Stephen Davidson (DigiCert)
*Presentation link:* No presentation
*Discussion outside the presentation:*
There was discussion to clarify the Charter language, including on end
date currently included in the Charter, questioning if this creates
unnecessary administration or accidental landmine to step on. Clint
Wilson thought that end date would set impetus to deliver, and give the
opportunity to revisit the charter after the initial deliverable. Dean
Coclin questioned what happens if the WG initial task is not completed.
Trevoli Ponds White supported the idea of setting milestones, but did
not want to create Charter busy work. Scott Rea supported this. It was
agreed to change the language to set a milestone rather than end the
Charter. Paul van Brouwershaven suggested adding language for the WG to
periodically reevaluate its goals.
There was discussion regarding changing name to Document Reform, with
initial scope being definitions and glossary. Initial chair to get the
group started is Tim Hollebeek, and vice is Brianca Martin from Amazon.
Tim Callan also offering assistance.
There was discussion of the Charter language for goals and objectives.
Stephen Davidson asked that procedures be clearly defined for
interactions with other WG. Tim suggested that GitHub issues would be a
good way to transparently track that work.
Tim described that the WG will not create normative requirements into
definitions. It is only normative by its incorporation into other BR.
This may include some restating of existing definitions.
Tim and Clint described how the consensus and ballot process matched the
CABF bylaws.
Next steps are to get the charter letter finalized and out for vote.
The goal would be start meetings in November. ??? commented that
changes made by this WG can impact the requirements by other WG; this
may require other WG to substantively update their own standards.
Proof-of-Concept for BR of BRs with requirements Matrix
*Leader:* Paul van Brouwershaven (Entrust)
*Minutes: *Tim Callan (Sectigo)
*Presentation link:
*https://cabforum.org/wp-content/uploads/15-20231004-Proof-of-concept-for-BR-of-BRs.pdfPaul
van Brouwershaven (Entrust)
*Discussion outside the presentation:*
Paul van Brouwershaven (Entrust):I have included links in the chat for
this code if you want to see for yourself
Let's look at how we manage documents, avoid duplication of content, and
become more effective. This is my proposal and I wanted to demonstrate
how it might work. This isn't an attempt to get us to decide to do it
this way. It is a demonstration.
Why I'm doing this. Objective is reducing duplication and enhancing
clarity.
Benefits include, when we centralize baseline requirements into one
document, it becomes much easier to manage and update. Think about org
val information in code signing, S/MIME, and TLS. It's mostly
duplicated data.
This will promote consisstency. We don't have to worry about
inconconsistiences between documeemtns. Easier to adhere to because you
only have to understand that section.
Efficiency.
Clarity.
This might require some challenges with IPR clearance. If we are
separating or combining source documents, where do you review IPR.
Definitions WG has a similar problem. Probably it means IPR clearance
has to happen at a forum level rather than at a WG level. Perhaps
everyone will be required to particiapate in that WG.
I'm sure we can deal with this, but we might need to rethink some things.
Layered approach. These things extend each other. DV is the minimum
level. Then OV sits on that. And then EV on top of that. Certificate
profile requirements are up at the top. You can simply exclude layers
to drop to a lower authentication level.
Transforming the RFC 3647 formatted documents. Each chapter has a
subdirectory. That means we have small documents, each containing a
single section. The small documents are easier to manage.
With full BRs, migration takes a long time. Large docs are hard to
navigate. Identifiying changes is difficult. It's easy to mess up a
large document. Merging layers of documents can be very difficult.
These layers are created based on the weight of what they are saying.
There is an explanation of this in the slide deck, p. 10.
Right now we write paragraphs, which can require interpretation for what
the distinct requirements are. In this format, the actual requirements
are spelled out. We can filter documents based on target profiles.
Allows control statements. Allows CAs to incorporate in a GRC system.
Helps with self-assessments.
This is a lot like what they're doing in ETSI.
Advanced instructions are a possibility. I built instructions for
appendices to include only in the BRs and ignore everywhere else.
The generated BR doc is equal to the source doc.
Code signing and S/MIME include some TLS specific requirements. This is
easily solved.
There is also an option to specify a level of assurance.
Let's look at how this actually works. (Paul gives a demo of the data
structure.)
Dimitris Zacharopoulos (HARICA):
I understand we should align the different sections of the different
documents. It's an easy concept but I imagine there is some work to get
to this.
Paul:
The nice thing is we can migrate paragraph by paragraph over time.
Tim Hollebeek (DigiCert):
Agreed. The hard part is building it out and figuring out how things
work and whatnot. Talking in abstract is easier then getting the
details right. I'm keen to give this a run and see how it works. If we
don't run into too many problems, we can continue to maintain this and
let it evolve as we move over.
Paul:
Right now we don't use the same headers across documents. This would
solve that.
[Paul demonstrates how to use an existing section from the BRs and
extend with an additional text. Paul shows how to add an additional
layer in the middle of a section.]
Trevoli Ponds-White (Amazon):
I love the idea of having a BR of BRs. I thought the intent was to
capture requirements that are similar. I can see how this is an IPR
challenge. It looks like the proposal is the group would maintain the
section that goes in all the BRs. I would think it would be for the
individual working groups to pull in the sections they want.
Paul:
If you look at what we're doing, maybe 80% to 90% of content is the
same. If we have a WG that works on the BRs, that would be baseline
rquirements that everyone is based on. The WGs shouldn't question
them. Then these groups would add requirements specific to their
certificate types.
Trev:
Your first statement was it's 80% the same. There should be one
requirement. I'm trying to connect the dots between the text is the
same and so I made individual files to make them different.
Tim:
Paul, the sections you wrote about underscore CS, for example, would be
the responsibility of the code signing working group.
Paul:
I've demonstrated that here in the code owners. EVGs is server cert WG.
Code signing is code signing WG. Nobody else can change that. The
different files help us to do this on a slow pace where we think it's
needed. If we stay within one document, this will be a multiyear
project that may never finish.
Aaron Gable (LE):
I love this. I love the ability of individual CAs to automatically
generate their CP/CPS.
Paul:
You could add your own files and instead of writing requirements, put
control statements in those files. You could automatically generate a
self-assessment. We could support that from the forum to help the
members maintain it.
Aaron:
Minor concerns. One, it seems like what you're talking about here is
three separate initiatives. Changing the way the maintian these
documents. Take advantage of that tooling to unify and harmonize these
documents. Let's make it possible to automatically extract
reqiurements. I love all three of these, but it seems like we should
focus on the restucturing and do it with no diff to the documents,
knowing it is groundwork. Let's discuss and decide on these as three
separate things.
When a WG decides the text in the BRs isn't sufficient for us and we
need to modify it to change the verbiage, Git is bad at displaying small
diffs in modified files. Eventually we may have to band aid the fact
that Git is bad at that.
Paul:
I included a script that when we transform documents, it will compare
each section to the BR and remove if it's exactly the same. The next
step is to identify documents that were the same for 90% or 99%. This
is the low hanging fruit for modification.
Trev:
The infrastructure WG set up all these docs in GitHub. It feels to me
like this just the structure of what was set up. I figure most people
don't care. I don't know if we need to BRs group to even care how these
documents are created.
Aaron:
In my opinion, step one is tighten up the scripts so the output is
virtually identical to the existing documents. And then let's just
start working. That first step doesn't need a working group.
Trev:
It has a working group.
Paul:
If we want to, this can be done by infrastructure WG.
Clemens Wanko (ACAB'c):
Do I understand the idea is to support the WGs but not to use that as a
final version to use? Remember, we need a stable version to work on.
Paul:
All these documents will be merged into the same documents we have
today. The BR of BRs is exactly the same except space and no
stipulation. Code signing is almost the same except renaming files.
Similar for S/MIME.
Dimitris:
I think the bylines and WGs already cover this. Are there any
objections to proceeding? This is just a transformation of GitHub that
will product the exact same documents. We will need some poeple to
support Paul in this.
Clint Wilson (Apple):
I like the way this is shaping up. Careful how we move forward. There
are a lot of people where this is foreign space for them. Anything we
can do to help anybody's ability to engage with the BRs might make it
easier. They only have to do one tiny document. Keeping the changes we
initially make as additive, so there's familiarity while we transition.
I'd love to have conversation about how you work with this written up,
so folks can reference it as they start working with this.
Dimitris:
To propose changes, you don't need to use GitHub if you're not fluid in
it. Use Word with track changes and work with someone who knows the
GitHub process.
Paul:
I think this will make contributions easier because the files are
smaller and the risk is lower. I hope this encourages more collaboration.
Clint:
If we have a list of ballot shepherds, that will help.
Paul:
We need to take this on in the infrastructure WG and take this to the
next step.
*ADJURNED Forum Plenary Meeting for Day 2*
------- END FINAL F2F #60 CA/B Forum Plenary Meeting minutes -------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20231119/ddf04744/attachment-0001.html>
More information about the Public
mailing list