Re: Vulnurability Disclosure - How does it happen?

['Ben Wilson' via dev-security-policy@mozilla.org]

Amir,
To answer the last question first, Chunghwa Telecom did not disclose this
recent attack, but I don't think we have sufficient information from the
article to determine the effects of the breach on the CA operations. So
without more information, it might be premature to answer the question, "Is
a security incident like the one I posted above considered an instance of a
CA "failing to comply"?"
The process envisioned by the policy and guidance does contemplate that
these disclosures would be in a secure bug (to which Mozilla would grant
other root programs access). It also contemplates that another, public bug
would need to be created, using the incident-reporting template (including
a description of the CA's incident response). Finally, because this is a
new process, we do not yet have any experiences to share or to use in
evaluating the success or shortcomings of the requirement.
Ben

On Thu, May 23, 2024 at 9:54 AM 'Amir Omidi (aaomidi)' via
dev-security-policy@mozilla.org  wrote:

> Hey folks,
>
> I am bringing this up because of:
> https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web
>
> (I've marked my questions in bold)
>
> I'm mainly basing this discussion around:
> https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to
> understand what the intent of some of the wording in this is, and how it
> applies to CAs.
>
> In that wiki, we see:
>
> > Vulnerabilities/incidents that may “significantly impact the
> confidentiality, integrity, or availability” of a CA's internal systems,
> regardless of direct impact on certificate issuance, must be reported if
> they pose ongoing risk to the overall integrity and security of CA
> operations. This includes significant impact not just to issuing systems,
> but also to network and server security, internal software, and the
> availability and reliability of certificate status services, such as CRLs
> and OCSP.
>
> What is Mozilla's intent by the phrase "must be reported if they pose
> ongoing risk to the overall integrity and security of CA operations."
>
> More specifically:
>
>1. *"Disclosed" to whom? Public? Just Mozilla?*
>2. *What does "if they pose an ongoing risk" mean? If its a one-off
>attack, does that mean it does not need to be disclosed?*
>
> I'm also unsure about trusting CAs to determine the significance of such
> an attack. We've seen recently that a few CAs have really jumped to making
> claims such as "this incident has no security impact" before doing any
> proper RCA or even understanding the extent of the incident. *Has Mozilla
> found any issues with leaving the determination up to CAs in the past?*
>
> More broadly, how does this wiki work when read in conjunction with the 
> Mozilla
> Root Store Policy
> 
>
> Specifically, section 2.4:
>
> > When a CA operator fails to comply with any requirement of this policy -
> whether it be a misissuance, a procedural or operational issue, or any
> other variety of non-compliance - the event is classified as an incident
> and MUST be reported to Mozilla as soon as the CA operator is made aware.
>
> *Is a security incident like the one I posted above considered an instance
> of a CA "failing to comply"?*
>
> In 2.4.1 we see:
>
> > Additionally, and not in lieu of the requirement to publicly report
> incidents as outlined above, a CA Operator MUST disclose a serious
> vulnerability or security incident in Bugzilla
>  as a secure bug
> 
> in accordance with guidance found on the Vulnerability Disclosure wiki
> page .
>
> From my reading here, this means that all security vulnerabilities are
> being disclosed privately to Mozilla. I guess this *kind of* makes sense
> here.
>
> *Would Mozilla be open to having a limited cooling-off period where these
> secure bugs stay private, but after that period the information becomes
> public*?
>
> My justification for asking this is:
>
>- Other CAs can and should learn from how a CA responded to a security
>incident.
>- There may be commonalities in attack patterns that these incidents
>being public can help surface.
>- It reassures the community that these incidents are being taken
>seriously by allowing third parties to also verify and validate the
>incident response and mitigation items.
>
>
> Beyond this, *I'd also be interested in hearing if Chunghwa Telecom has
> disclosed the impact of this recent attack on their systems (if any) to
> Mozilla and the other root programs.*
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> 

Re: Proposed whiteboard tag for non-incident "bugs"

['Ben Wilson' via CCADB Public]

Hi Clint and Rob,
This is relatively easy to implement, and we can start immediately by just
adding [ca-infosharing] in the whiteboard. I've added it to the Mozilla CA
Program wiki - https://wiki.mozilla.org/CA/Bug_Triage#Whiteboard_Tags ("For
non-incident "lessons learned" and other descriptions of comprehensive
steps a CA might take when addressing compliance, or cascading incidents,
or to share its compliance-related experiences for the benefit of the
ecosystem"), and I'll get this added somewhere on the CCADB website.
Thanks,
Ben

On Wed, May 22, 2024 at 4:18 PM 'Clint Wilson' via CCADB Public <
public@ccadb.org> wrote:

> Hi Rob,
>
> This incident is a valuable example for the ecosystem of the steps that
> may be necessary for a CA to take when approaching compliance and incidents
> comprehensively, especially when incidents spiral or cascade into the
> discovery of more underlying or systemic issues than at first appearance. I
> would absolutely encourage other CAs to share (and continue sharing)
> similar information, as we see SSL.com working on with their reseller
> interactions or when Amazon provided a presentation at a recent CA/B Forum
> F2F. Even if the events from which CAs learned a great deal or which
> heavily impacted their ability to successfully comply with industry
> expectations and requirements are in the distant past, such retrospective
> analyses can be incredibly valuable no matter their timing.
>
> I similarly support disclosing such "lessons learned" in Bugzilla and
> having a tag dedicated thereto seems appropriate -- especially if this
> becomes more common for CAs to do. Alternatively, if Mozilla would prefer
> organizing these in some other way, I'm not opposed; the goal here is
> discoverability and there are likely any number of ways to succeed in that
> goal.
>
> Cheers!
> -Clint
>
> On Wednesday, May 22, 2024 at 12:25:12 PM UTC-7 Rob Stradling wrote:
>
>> A few years ago, Sectigo created
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1724476 in order to share
>> information about our "Guard Rails" project.  Quoting that bug:
>> *“Guard Rails” is a convenient name for a series of programmatic checks
>> we are putting in place to confirm certificate orders for compliance with
>> specific requirements before issuance can occur. Guard Rails are like
>> Certificate Lints, except that they may be stricter than what CA/B Forum
>> and root program policies require. By defining and adding these checks, we
>> can eliminate potential sources of misissuance and achieve higher overall
>> issuance quality. This initiative is borne in part from the understanding
>> that human-based processes are fundamentally error prone, and to the degree
>> we can implement defined machine processes, our error rate will go down.*
>>
>>
>> We took steps  
>> (comment
>> #1) to avoid this bug being seen as an "incident" bug:
>> *Since this bug is intended to be a repository for information and
>> discussion rather than a response to any particular CA Compliance incident,
>> I'm immediately marking it as RESOLVED INCOMPLETE and deliberately not
>> putting [ca-compliance] in the Whiteboard field. We chose to deviate from
>> the ": " bug title format for the same reason.*
>>
>> However, at some point since then somebody decided to add the
>> "[ca-compliance]" whiteboard tag, which seems problematic to us.
>>
>> In order to clearly identify this type of information sharing "bug", and
>> even to encourage other CAs to consider doing likewise, we would like to
>> propose a new whiteboard tag:
>>
>> [ca-infosharing]
>>
>> --
>> Rob Stradling
>> Distinguished Engineer
>> Sectigo Limited
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "CCADB Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to public+unsubscr...@ccadb.org.
> To view this discussion on the web visit
> https://groups.google.com/a/ccadb.org/d/msgid/public/2642e3b1-cbc0-4964-9743-b27851ff17b8n%40ccadb.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to public+unsubscr...@ccadb.org.
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaaQiU_MJE_vhBPtwTeHtDO%2BgzydOfukHd%2B1pfAhF7J5Gg%40mail.gmail.com.

Re: [cabfpub] Voting Period Begins: Ballot FORUM-022: Establish Forum IPR Subcommittee

[Ben Wilson via Public]

Mozilla votes "Yes" on Forum-022, and I'll assume that is what was meant by
Antti.

On Thu, May 16, 2024 at 2:55 AM Backman, Antti <
antti.back...@teliacompany.com> wrote:

> Telia votes ’Yes’ on Ballot FORUM-002
>
>
>
> //Antti
>
>
>
> *From: *Public  on behalf of Ben Wilson via
> Public 
> *Date: *Wednesday, 15. May 2024 at 18.02
> *To: *CA/Browser Forum Public Discussion List 
> *Subject: *[cabfpub] Voting Period Begins: Ballot FORUM-022: Establish
> Forum IPR Subcommittee
>
> *Ballot FORUM-022:  Establish Forum IPR Subcommittee*
>
>
>
> Proposed by Ben Wilson of Mozilla and endorsed by Roman Fischer of
> SwissSign and Clint Wilson of Apple.
>
>
>
> *Purpose of Ballot*
>
>
>
> The CA/Browser Forum’s Intellectual Property Rights (IPR) Policy and
> associated documentation were last revised in 2018. Since then, there have
> been requests for clarification about application of the IPR Policy to
> contributions of non-Forum Members, and sections of the IPR Policy and
> documentation have been identified as needing amendment, including the form
> for filing and handling of Essential Claim Exclusion Notices. It is
> proposed that a Charter be adopted establishing a Forum IPR Subcommittee
> (FIPR) and that the proposed scope of the FIPR be to update and improve the
> IPR Policy and associated documentation and to discuss the following:
>
>
>
> (a) How to address contributions provided by non-Forum Members (e.g.,
> invited experts, guest speakers, researchers, etc.);
>
> (b) If any clarifications and/or changes are necessary to the IPR Policy
> in view of recent events; and
>
> (c) A potential contributor license agreement for the Forum’s GitHub
> repository and policy for contributing to the Forum’s GitHub repository.
>
>
>
> *Following the passage of this ballot:*
>
>- A new Forum IPR Subcommittee will be formed under the CA/Browser
>Forum, as outlined in section 5.6 of the Bylaws (Forum Subcommittees);
>- Mailing list(s), GitHub repository(ies), Wiki resource(s), and other
>collaboration tools will be established as needed to enable the Forum
>Subcommittee to fulfill its charter; and
>- The Forum Subcommittee will publish a set of recommended revisions
>to the IPR Policy and associated documentation for the Forum to adopt.
>
>
>
> *MOTION BEGINS*
>
>
>
> *Establish Forum IPR Subcommittee*
>
>
>
> Upon approval from the CA/Browser Forum by ballot in accordance with
> sections 2.3 and 5.6 of the Forum Bylaws, the Forum IPR Subcommittee
> (“FIPR”) is created to perform the activities as specified in the Charter,
> which is found here:
>
>
>
>
> https://github.com/cabforum/forum/compare/30de00ae9672088cf618706b9e7c464fa8c34c51...b50bc495ced317c437ed6b397bb4fb574484b56b
>
>
>
> *MOTION ENDS*
>
>
>
> *The procedure for approval of this ballot is as follows:*
>
>
>
> *Discussion* (7+ days)
>
>
>
> *Start Time*: 2024-May-06 22:00 UTC
>
> *End Time*: After 2024-May-13 22:00 UTC
>
>
>
> *Vote for approval* (7 days)
>
>
>
> *Start Time:*  2024-May-15 15:00 UTC
>
> *End Time: * 2024-May-22 15:00 UTC
>
>
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[cabfpub] Voting Period Begins: Ballot FORUM-022: Establish Forum IPR Subcommittee

[Ben Wilson via Public]

*Ballot FORUM-022:  Establish Forum IPR Subcommittee*



Proposed by Ben Wilson of Mozilla and endorsed by Roman Fischer of
SwissSign and Clint Wilson of Apple.



*Purpose of Ballot*



The CA/Browser Forum’s Intellectual Property Rights (IPR) Policy and
associated documentation were last revised in 2018. Since then, there have
been requests for clarification about application of the IPR Policy to
contributions of non-Forum Members, and sections of the IPR Policy and
documentation have been identified as needing amendment, including the form
for filing and handling of Essential Claim Exclusion Notices. It is
proposed that a Charter be adopted establishing a Forum IPR Subcommittee
(FIPR) and that the proposed scope of the FIPR be to update and improve the
IPR Policy and associated documentation and to discuss the following:



(a) How to address contributions provided by non-Forum Members (e.g.,
invited experts, guest speakers, researchers, etc.);

(b) If any clarifications and/or changes are necessary to the IPR Policy in
view of recent events; and

(c) A potential contributor license agreement for the Forum’s GitHub
repository and policy for contributing to the Forum’s GitHub repository.



*Following the passage of this ballot:*

   - A new Forum IPR Subcommittee will be formed under the CA/Browser
   Forum, as outlined in section 5.6 of the Bylaws (Forum Subcommittees);
   - Mailing list(s), GitHub repository(ies), Wiki resource(s), and other
   collaboration tools will be established as needed to enable the Forum
   Subcommittee to fulfill its charter; and
   - The Forum Subcommittee will publish a set of recommended revisions to
   the IPR Policy and associated documentation for the Forum to adopt.



*MOTION BEGINS*



*Establish Forum IPR Subcommittee*



Upon approval from the CA/Browser Forum by ballot in accordance with
sections 2.3 and 5.6 of the Forum Bylaws, the Forum IPR Subcommittee
(“FIPR”) is created to perform the activities as specified in the Charter,
which is found here:



https://github.com/cabforum/forum/compare/30de00ae9672088cf618706b9e7c464fa8c34c51...b50bc495ced317c437ed6b397bb4fb574484b56b



*MOTION ENDS*



*The procedure for approval of this ballot is as follows:*



*Discussion* (7+ days)



*Start Time*: 2024-May-06 22:00 UTC

*End Time*: After 2024-May-13 22:00 UTC



*Vote for approval* (7 days)



*Start Time:*  2024-May-15 15:00 UTC

*End Time: * 2024-May-22 15:00 UTC
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[cabfpub] Bergamo F2F Agenda Item

[Ben Wilson via Public]

Hi Dimitris,
There appears to be an open slot on the F2F agenda - Wed. May 29th at 9:05
a.m.  I was thinking we could use that time to discuss revocation timelines
and balancing the security provided by revocation with the
security/stability needed to support critical infrastructure. In other
words, we could discuss BR section 4.9.1 and  concerns about disruption of
global/national operations in banking/finance, transportation, government,
telecommunications, healthcare, and other key areas where certificate
revocation might cause key systems to fail.
Should I put this topic in that open slot on the wiki?
Thanks,
Ben
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

Added " Although not expressed in the bug, it appears that certificate
revocation was delayed as well."

On Fri, May 10, 2024 at 10:54 AM George  wrote:

> Although it was not mentioned in the original bug, it may be worth adding
> that the certificates in bug 1867130
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1867130> were also not
> revoked within 5 days of discovery. Entrust might've based the start of the
> 5 day deadline at the time the "Director of compliance confirmed
> investigation conclusions to support team" at 2023-11-21 15:00 UTC with all
> certificates being revoked by 2023-11-26 14:50 UTC, but I don't think
> that's correct if that was the case.
>
> On Friday, May 10th, 2024 at 5:27 PM, 'Ben Wilson' via
> dev-security-policy@mozilla.org  wrote:
>
> Here are draft summaries of the additional historic incidents. I'll be
> adding these to the Entrust Issues page:
> https://wiki.mozilla.org/CA/Entrust_Issues
>
> *Invalid data in State/Province Field -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658792
>
> It was initially discovered that Entrust had issued 395 OV SSL
> certificates to a large international organization with “NA” for the
> state/province information. Entrust worked on a drop-down list to prevent
> the error. Certificate revocation would not occur within established
> timeframes, so Bug #1658794 for delayed revocation was opened.
>
> *Late Revocation for Invalid State/Province Issue - *
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658794
>
> This is the delayed revocation bug related to Bug #1658792, above. Entrust
> said that when educating large institutions about rapid revocation, factors
> include who owns a certificate, where it is deployed, and the type of
> system or application that requires the certificate. It also said that it
> was advocating automation with such institutions to help speed up
> certificate replacement and to minimize human error.
>
> *EV TLS Certificate incorrect jurisdiction -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1802916
>
> Entrust mis-issued 322 EV certificates with the wrong state and locality
> jurisdiction fields due to complex data entry processes. Entrust
> implemented a different automated dropdown system for jurisdiction
> selection. Certificate revocation would not occur within established
> timeframes, so Bug #1804753 for delayed revocation was opened.
>
> *Delayed Revocation for EV TLS Certificate incorrect jurisdiction - *
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753
>
> This is the delayed revocation bug related to Bug #1802916, above. Entrust
> listed 8 Subscribers who were pushing back on immediate certificate
> revocation and the reasons given (e.g. extensions granted due to
> end-of-year freezes). Entrust committed to “continue to develop and extend
> methods for automatic certificate renewal.”
>
> *Jurisdiction Locality Wrong in EV Certificate -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1867130
>
> Two EV TLS Certificates were mis-issued due to human error in the
> Jurisdiction Locality field. (The incident revealed 340 additional accounts
> needing similar updates.) Entrust said it would enhance its linting
> processes to include possibly using an external service to validate
> locality data against verified country data.
>
> *SHA-256 hash algorithm used with ECC P-384 key - *
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1648472
>
> A Mozilla policy was adopted to require hashing with SHA-384 for an ECC
> P-384 key. Existing CAs using SHA-256 were not re-configured when Mozilla
> adopted this policy. This incident revealed a serious gap in taking new
> requirements and implementing them. Ryan Sleevi noted that linting was just
> a safety net and not a systemic solution. Entrust was also criticized for
> the lack of detail in its incident report and its decision to not revoke
> the certificates.
>
> Entrust committed to improving its monitoring and implementation of policy
> changes to prevent similar incidents. Ryan set forth a number of proactive
> systemic corrections that Entrust needed to take, rather than taking a
> reactive stance on matters of non-compliance.
>
> Entrust committed to rigorous review of certificate profiles, browser
> policy revisions, and industry developments. As a final comment, Ryan said,
> “My big concern is, going forward, we see incident reports from Entrust
> take a more systemic, holistic response, like Comment #16, to try and cover
> the scenarios, and to provide sufficient detail about the situation and its
> failures to understand how those relate. The goal isn't to make CAs wear
> proverbial sackcloth, it's to try and make sure we're understanding how
>

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

 PM Watson Ladd  wrote:

> Could we add a section for geographical incidents? This is slightly
> outside your time window, but I think reading the series here has some
> uncanny echos in the ones in your window.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658792
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658794
> https://bugzilla.mozilla.org/show_bug.cgi?id=1802916
> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753
> https://bugzilla.mozilla.org/show_bug.cgi?id=1867130
>
> On Tue, May 7, 2024 at 7:59 AM 'Ben Wilson' via
> dev-security-policy@mozilla.org 
> wrote:
> >
> > Dear Mozilla Community,
> >
> > Over the past couple of months, a substantial number of compliance
> incidents have arisen in relation to Entrust. We have summarized these
> recent incidents in a dedicated wiki page:
> https://wiki.mozilla.org/CA/Entrust_Issues. In brief, these incidents
> arose out of certificate mis-issuance due to a misunderstanding of the EV
> Guidelines, followed by numerous mistakes in incident handling (including a
> deliberate decision to continue mis-issuance), which have been compounded
> by a failure to remediate the issues in a timely fashion in line with
> well-established norms and root store requirements.
> >
> > Our preliminary assessment of these incidents is that while they were
> relatively minor initially, the poor incident response has substantially
> aggravated them and the progress towards full remediation remains
> unacceptably slow. This is particularly disappointing in light of previous
> incidents in 2020 (#1651481 and #1648472), which arose out of similar
> misunderstandings of the requirements, similar poor decision-making in the
> initial response, and lengthy remediation periods that fell well below
> expectations. Entrust gave commitments in those bugs to address the root
> problems through process improvements, and it is concerning to see so
> little improvement 4 years later.
> >
> > In light of these recent incidents, we are requesting that Entrust
> produce a detailed report of them. This report should cover in detail:
> >
> > The factors and root causes that lead to the initial incidents,
> highlighting commonalities among the incidents and any systemic failures;
> >
> > Entrust’s initial incident handling and decision-making in response to
> these incidents, including any internal policies or protocols used by
> Entrust to guide their response and an evaluation of whether their
> decisions and overall response complied with Entrust’s policies, their
> practice statement, and the requirements of the Mozilla Root Program;
> >
> > A detailed timeline of the remediation process and an apportionment of
> delays to root causes; and
> >
> > An evaluation of how these recent issues compare to the historical
> issues referenced above and Entrust’s compliance with its previously stated
> commitments.
> >
> > Finally, Entrust’s report should include a detailed proposal on how it
> plans to address the root causes of these issues. In light of previous
> guarantees given by Entrust in 2020 to ensure speedy remediation in future
> incidents, this proposal should include:
> >
> > Clear and concrete steps that Entrust proposes to take to address the
> root causes of these incidents and delayed remediation;
> >
> > Measurable and objective criteria for Mozilla and the community to
> evaluate Entrust’s progress in deploying these solutions; and
> >
> > A timeline for which Entrust will commit to meeting these criteria.
> >
> > We strongly recommend that Entrust go beyond their existing commitment
> to offer systematic, automated solutions for effective remediation, like
> ACME ARI and that it also include clear and measurable targets for the
> adoption of these tools by new and existing subscribers.
> >
> > This report should be submitted to Mozilla dev-security-policy mailing
> list for evaluation by the community and Mozilla, who will weigh whether
> Entrust’s report presents a credible and effective path towards
> re-establishing trust in Entrust’s operation. Submission should be no later
> than June 7, 2024.
> >
> > We thank community members for their engagement on these issues and look
> forward to their feedback on Entrust’s report and proposed commitments.
> >
> >  Thanks,
> >
> > Ben Wilson
> >
> > Mozilla Root Program
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "dev-security-policy@mozilla.org" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to dev-security-policy+unsubscr...@moz

Re: [Smcwg-public] Background for discussion of Legacy Profiles

[Ben Wilson via Smcwg-public]

Hi all,

I am currently aligned with Wendy’s and Judith’s concerns expressed on the
recent call about sunsetting the Legacy profile, but I look forward to
discussing this further in Bergamo. The Legacy profile provides greater
flexibility, and migrating to only the Multipurpose and Strict profiles may
have unforeseen consequences. While no one else has explicitly stated they
are not ready for this move, the Mozilla Root Program has integrated the
S/MIME BRs into our root store policy, necessitating support for diverse
use cases while ensuring broad compliance. We need to ensure that everyone
not involved in the S/MIME WG is prepared for such a significant move, and
we might find out about problems when it is too late to address them. For
instance, we could see compliance issues in Bugzilla from CA operators who
are currently enabled with the email trust bit, or we might receive a root
inclusion request from a CA operator unwilling or unable to restrict
issuance to only strict or multipurpose certificates.

In summary, I'd just like to understand the issues better and minimize
disruption and compliance issues down the road.

I look forward to your thoughts and suggestions.

Thanks,

Ben


On Thu, Apr 11, 2024 at 8:40 AM Stephen Davidson via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> Hello all:
>
>
>
> I attach the summary that we reviewed in the SMCWG call yesterday.
>
>
>
> It highlights the differences between the Legacy generation profiles and
> the Multipurpose/Strict profiles, including links to the relevant text
> sections in the S/MIME BR.
>
>
>
>
> https://cabforum.org/posts/2024/2024-04-10-legacy-deprecation/SMCWG_20240410_Final.pdf
>
>
>
> This should facilitate review and feedback to help the SMCWG determine
> appropriate steps and timelines to migrate to the Multipurpose/Strict
> profiles.
>
>
>
> Regards, Stephen
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Ben Wilson via Servercert-wg]

Mozilla changes its vote to "no" on Ballot SC-74 with the understanding
that additional edits are needed.

On Sun, May 5, 2024 at 1:05 PM Ben Wilson  wrote:

> Mozilla votes "yes" on Ballot SC-74.
>
> On Sun, May 5, 2024 at 3:06 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg  wrote:
>
>> HARICA votes "yes" to ballot SC-74.
>>
>> On 5/5/2024 11:24 π.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg
>> wrote:
>>
>> Voting begins for ballot SC-74.
>> SC-74 - Clarify CP/CPS structure according to RFC 3647 Summary
>>
>> The TLS Baseline Requirements require in section 2.2 that:
>>
>> *"The Certificate Policy and/or Certification Practice Statement MUST be
>> structured in accordance with RFC 3647 and MUST include all material
>> required by RFC 3647."*
>>
>> The intent of this language was to ensure that all CAs' CP and/or CPS
>> documents contain a similar structure, making it easier to review and
>> compare against the BRs. However, there was some ambiguity as to the actual
>> structure that CAs should follow. After several discussions in the SCWG
>> Public Mailing List
>> <https://lists.cabforum.org/pipermail/servercert-wg/2023-November/004070.html>
>> and F2F meetings, it was agreed that more clarity should be added to the
>> existing requirement, pointing to the outline described in section 6 of RFC
>> 3647.
>>
>> The following motion has been proposed by Dimitris Zacharopoulos (HARICA)
>> and endorsed by Aaron Poulsen (Amazon) and Tim Hollebeek (Digicert).
>>
>> You can view the github pull request representing this ballot here
>> <https://github.com/cabforum/servercert/pull/503>.
>> Motion Begins
>>
>> MODIFY the "Baseline Requirements for the Issuance and Management of
>> Publicly-Trusted TLS Server Certificates" based on Version 2.0.4 as
>> specified in the following redline:
>>
>>-
>>
>> https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae
>>
>> Motion Ends
>>
>> This ballot proposes a Final Maintenance Guideline. The procedure for
>> approval of this ballot is as follows:
>> Discussion (at least 7 days)
>>
>>- Start time: 2024-04-25 16:30:00 UTC
>>- End time: on or after 2024-05-02 16:30:00 UTC
>>
>> Vote for approval (7 days)
>>
>>- Start time: 2024-05-05 8:30:00 UTC
>>- End time: 2024-05-12 8:30:00 UTC
>>
>>
>>
>> ___
>> Servercert-wg mailing 
>> listServercert-wg@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>>
>> ___
>> Servercert-wg mailing list
>> Servercert-wg@cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

Dear Mozilla Community,

Over the past couple of months, a substantial number of compliance
incidents have arisen in relation to Entrust. We have summarized these
recent incidents in a dedicated wiki page:
https://wiki.mozilla.org/CA/Entrust_Issues. In brief, these incidents arose
out of certificate mis-issuance due to a misunderstanding of the EV
Guidelines, followed by numerous mistakes in incident handling (including a
deliberate decision to continue mis-issuance), which have been compounded
by a failure to remediate the issues in a timely fashion in line with
well-established norms and root store requirements.

Our preliminary assessment of these incidents is that while they were
relatively minor initially, the poor incident response has substantially
aggravated them and the progress towards full remediation remains
unacceptably slow. This is particularly disappointing in light of previous
incidents in 2020 (#1651481
<https://bugzilla.mozilla.org/show_bug.cgi?id=1651481> and #1648472
<https://bugzilla.mozilla.org/show_bug.cgi?id=1648472>), which arose out of
similar misunderstandings of the requirements, similar poor decision-making
in the initial response, and lengthy remediation periods that fell well
below expectations. Entrust gave commitments
<https://bugzilla.mozilla.org/show_bug.cgi?id=1651481#c17> in those bugs to
address the root problems through process improvements, and it is
concerning to see so little improvement 4 years later.

In light of these recent incidents, we are requesting that Entrust produce
a detailed report of them. This report should cover in detail:

   -

   The factors and root causes that lead to the initial incidents,
   highlighting commonalities among the incidents and any systemic failures;
   -

   Entrust’s initial incident handling and decision-making in response to
   these incidents, including any internal policies or protocols used by
   Entrust to guide their response and an evaluation of whether their
   decisions and overall response complied with Entrust’s policies, their
   practice statement, and the requirements of the Mozilla Root Program;
   -

   A detailed timeline of the remediation process and an apportionment of
   delays to root causes; and
   -

   An evaluation of how these recent issues compare to the historical
   issues referenced above and Entrust’s compliance with its previously stated
   commitments.

Finally, Entrust’s report should include a detailed proposal on how it
plans to address the root causes of these issues. In light of previous
guarantees <https://bugzilla.mozilla.org/show_bug.cgi?id=1651481#c17> given
by Entrust in 2020 to ensure speedy remediation in future incidents, this
proposal should include:

   -

   Clear and concrete steps that Entrust proposes to take to address the
   root causes of these incidents and delayed remediation;
   -

   Measurable and objective criteria for Mozilla and the community to
   evaluate Entrust’s progress in deploying these solutions; and
   -

   A timeline for which Entrust will commit to meeting these criteria.

We strongly recommend that Entrust go beyond their existing commitment
<https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c0> to offer
systematic, automated solutions for effective remediation, like ACME ARI
and that it also include clear and measurable targets for the adoption of
these tools by new and existing subscribers.

This report should be submitted to Mozilla dev-security-policy mailing list
for evaluation by the community and Mozilla, who will weigh whether
Entrust’s report presents a credible and effective path towards
re-establishing trust in Entrust’s operation. Submission should be no later
than June 7, 2024.

We thank community members for their engagement on these issues and look
forward to their feedback on Entrust’s report and proposed commitments.

 Thanks,

Ben Wilson

Mozilla Root Program

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm%2BRG0YHCA%40mail.gmail.com.

Re: comment on Entrust_Issues wiki page

['Ben Wilson' via dev-security-policy@mozilla.org]

All,
I hadn't announced this page yet, hoping to reference it in an email
currently undergoing internal review. But thanks for your comment.
I'll see about posting the email as soon as I can.
Thanks,
Ben

On Mon, May 6, 2024 at 3:58 PM Mike Shaver  wrote:

> The page lists the following issue:
>
> “
> 5. EV Certificate missing Issuer’s EV Policy OID -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1888714
>
> Entrust issued 1,963 EV TLS certificates September 11-22, 2023, without
> including an EV TLS CP OID. Root Causes were the misinterpretation of the
> EV Guidelines and the TLS BRs and a failure to recognize the overriding
> requirements of the EV Guidelines. (A misinterpretation of standards led to
> non-compliant certificates, and linting failed to detect the issue.) As
> remediation, since April 11, 2024, Entrust has used pkilint as a
> post-issuance linter to detect similar issues. (Mis-issued certificates are
> a subset of the certificates disclosed and being revoked under bug
> #1883843 . Status
> of revocation is listed in bug #1886532
> .)
>
> *Issues:* Misinterpretation of Requirements; Policy/Procedure Failure;
> Certificate Mis-issuance”
>
> In my opinion it should also list that Entrust promised to provide a full
> list of affected certs and an incident report by April 5th, and continued
> to comment in the bug, but did not post that list or the IR until April
> 10th. No comment was made about a delay, or the reason that it was
> necessary.
>
> Mike
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-policy+unsubscr...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqsbubH8_7-NNxC7E7FbV%2BCqBPF%3DaYR2GseNCjy1mqEXHA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabKSQhyHSPeh6iEki4mkH9Kkky0Wpes8YyB2-xsEnNu1w%40mail.gmail.com.

[cabfpub] Discussion Period Begins: Ballot FORUM-022: Establish Forum IPR Subcommittee

[Ben Wilson via Public]

*Ballot FORUM-022:  Establish Forum IPR Subcommittee*



Proposed by Ben Wilson of Mozilla and endorsed by Roman Fischer of
SwissSign and Clint Wilson of Apple.



*Purpose of Ballot*



The CA/Browser Forum’s Intellectual Property Rights (IPR) Policy and
associated documentation were last revised in 2018. Since then, there have
been requests for clarification about application of the IPR Policy to
contributions of non-Forum Members, and sections of the IPR Policy and
documentation have been identified as needing amendment, including the form
for filing and handling of Essential Claim Exclusion Notices. It is
proposed that a Charter be adopted establishing a Forum IPR Subcommittee
(FIPR) and that the proposed scope of the FIPR be to update and improve the
IPR Policy and associated documentation and to discuss the following:



(a) How to address contributions provided by non-Forum Members (e.g.,
invited experts, guest speakers, researchers, etc.);

(b) If any clarifications and/or changes are necessary to the IPR Policy in
view of recent events; and

(c) A potential contributor license agreement for the Forum’s GitHub
repository and policy for contributing to the Forum’s GitHub repository.



*Following the passage of this ballot:*

   - A new Forum IPR Subcommittee will be formed under the CA/Browser
   Forum, as outlined in section 5.6 of the Bylaws (Forum Subcommittees);
   - Mailing list(s), GitHub repository(ies), Wiki resource(s), and other
   collaboration tools will be established as needed to enable the Forum
   Subcommittee to fulfill its charter; and
   - The Forum Subcommittee will publish a set of recommended revisions to
   the IPR Policy and associated documentation for the Forum to adopt.



*MOTION BEGINS*



*Establish Forum IPR Subcommittee*



Upon approval from the CA/Browser Forum by ballot in accordance with
sections 2.3 and 5.6 of the Forum Bylaws, the Forum IPR Subcommittee
(“FIPR”) is created to perform the activities as specified in the Charter,
which is found here:



https://github.com/cabforum/forum/compare/30de00ae9672088cf618706b9e7c464fa8c34c51...b50bc495ced317c437ed6b397bb4fb574484b56b



*MOTION ENDS*



*The procedure for approval of this ballot is as follows:*



*Discussion* (7+ days)



*Start Time*: 2024-May-06 22:00 UTC

*End Time*: After 2024-May-13 22:00 UTC



*Vote for approval* (7 days)



Start Time: TBD

End Time: TBD
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Ben Wilson via Servercert-wg]

Mozilla votes "yes" on Ballot SC-74.

On Sun, May 5, 2024 at 3:06 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

> HARICA votes "yes" to ballot SC-74.
>
> On 5/5/2024 11:24 π.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg
> wrote:
>
> Voting begins for ballot SC-74.
> SC-74 - Clarify CP/CPS structure according to RFC 3647 Summary
>
> The TLS Baseline Requirements require in section 2.2 that:
>
> *"The Certificate Policy and/or Certification Practice Statement MUST be
> structured in accordance with RFC 3647 and MUST include all material
> required by RFC 3647."*
>
> The intent of this language was to ensure that all CAs' CP and/or CPS
> documents contain a similar structure, making it easier to review and
> compare against the BRs. However, there was some ambiguity as to the actual
> structure that CAs should follow. After several discussions in the SCWG
> Public Mailing List
> 
> and F2F meetings, it was agreed that more clarity should be added to the
> existing requirement, pointing to the outline described in section 6 of RFC
> 3647.
>
> The following motion has been proposed by Dimitris Zacharopoulos (HARICA)
> and endorsed by Aaron Poulsen (Amazon) and Tim Hollebeek (Digicert).
>
> You can view the github pull request representing this ballot here
> .
> Motion Begins
>
> MODIFY the "Baseline Requirements for the Issuance and Management of
> Publicly-Trusted TLS Server Certificates" based on Version 2.0.4 as
> specified in the following redline:
>
>-
>
> https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae
>
> Motion Ends
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
> Discussion (at least 7 days)
>
>- Start time: 2024-04-25 16:30:00 UTC
>- End time: on or after 2024-05-02 16:30:00 UTC
>
> Vote for approval (7 days)
>
>- Start time: 2024-05-05 8:30:00 UTC
>- End time: 2024-05-12 8:30:00 UTC
>
>
>
> ___
> Servercert-wg mailing 
> listServercert-wg@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/servercert-wg
>
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Infrastructure] Google doc for the CABF Handbook

[Ben Wilson via Infrastructure]

I've updated this some more:
https://docs.google.com/document/d/1GfisFGuFKFeY4kHr08zsQks1GwpRVyn2Gl6-eGSDmOw/edit

On Thu, Mar 21, 2024 at 4:12 AM Inigo Barreira via Infrastructure <
infrastructure@cabforum.org> wrote:

> Hi all,
>
>
>
> See this link:
> https://docs.google.com/document/d/1GfisFGuFKFeY4kHr08zsQks1GwpRVyn2Gl6-eGSDmOw/edit?usp=sharing
>
>
>
> It´s a Google doc with what was shared initially in the email. It´s just a
> very first draft of a framework with the basics to handle to all
> new/old/potential responsible people in order to have it all in on document
> and organized.
>
> Some of these sections are already covered and some maybe need
> adjustments/updates/clarifications. Feel free to add anything that is
> correct and move the document where you think suits better.
>
>
>
> Regards
> ___
> Infrastructure mailing list
> Infrastructure@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
>
___
Infrastructure mailing list
Infrastructure@cabforum.org
https://lists.cabforum.org/mailman/listinfo/infrastructure

Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation

[Ben Wilson via Servercert-wg]

All,

I am currently looking at this version in Gitub:
https://github.com/cabforum/servercert/blob/SC-71/docs/BR.md. But I'm a
little confused on whether some of the recently suggested changes have been
merged into that version.

I'll defer to Dustin on whether Bruce's first suggestion for "Subscriber
Agreement" in BR section 9.6.1 should replace the second, less preferable,
option.

Finally, re: the wording for the effective date, which I didn't like*, what
if it said something like this instead?

Prior to 2025-03-15, CAs may continue to refer to and utilize the phrase
"Terms of Use" as defined in the previous version of these Requirements
within their CP and CPS documents. Effective 2025-03-15, CAs shall replace
references to "Terms of Use" with "Subscriber Agreement" in their CP and
CPS documents. This change does not preclude the inclusion of "terms of
use" and other necessary terms and conditions within broader CA operational
documents, provided they are consistent with these Requirements

Feel free to edit as you see fit.

* My concern with the previously proposed language was that the first
sentence was too broad in that it didn't specify the context in which
"Terms of Use" might already be used, and similarly, my concern with the
second sentence was that it was overly broad in prohibiting all uses of
"Terms of Use" whatsoever.

Ben

On Tue, Apr 30, 2024 at 2:13 PM Bruce Morton 
wrote:

> Hi Ben,
>
>
>
> We have some feedback from our legal team.
>
>
>
> First suggestion is to simplify the change to only address the objectives
> of the ballot:
>
> 5. Subscriber Agreement: That, if the CA and Subscriber are not
> Affiliated, the Subscriber and CA are parties to a legally valid and
> enforceable Subscriber Agreement that satisfies these Requirements, or, if
> the CA and Subscriber are the same entity or are Affiliated, the Applicant
> Representative has accepted the Subscriber Agreement;
>
>
>
> Alternative (less preferable) option, accepts additional warranties that
> are superfluous to the objectives of the ballot, but fixes the legal
> impossibility of the last item (iii):
>
> 5. Subscriber Agreement: That,
>
> i. the Subscriber has access to the most current version of the Subscriber
> Agreement, which is posted to the CA’s policy document repository or has
> been provided through other means;
>
> ii. the applicable Subscriber Agreement is the Subscriber Agreement that
> was in force when the Certificate was issued; and
>
> iii. if the CA and Subscriber are not Affiliated, the Subscriber and CA
>  are parties to a legally valid and enforceable Subscriber Agreement that
> satisfies these Requirements, or, if the CA and Subscriber are the same
> entity or are Affiliated, the Applicant Representative has accepted the
> Subscriber Agreement;
>
>
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Servercert-wg  *On Behalf Of *Ben
> Wilson via Servercert-wg
> *Sent:* Wednesday, April 24, 2024 3:06 AM
> *To:* Wayne Thayer 
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins -
> Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
>
>
>
> I removed it because I didn't like the phrasing. I can propose other
> wording for an effective date, unless anyone else wants to take a crack at
> it. On Wed, Apr 24, 2024, 1: 59 AM Wayne Thayer 
> wrote: Thanks Ben!The
>
> I removed it because I didn't like the phrasing. I can propose other
> wording for an effective date, unless anyone else wants to take a crack at
> it.
>
>
>
> On Wed, Apr 24, 2024, 1:59 AM Wayne Thayer  wrote:
>
> Thanks Ben!
>
>
>
> The second commit you linked removes the effective date for CP/CPS updates
> from section 9.6.3. While I'm not convinced that this is necessary, it
> seems to add some clarity. Was that paragraph meant to remain in place? If
> not, what is the reasoning?
>
>
>
> Otherwise I am also happy with these changes.
>
>
>
> - Wayne
>
>
>
> On Tue, Apr 23, 2024 at 4:21 PM Aaron Gable via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
> Hi Ben,
>
>
>
> Thank you! I believe those combine with the previous commits to produce
> this redline, which looks good to me:
>
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...682488a832db5b6b4fcdd4cd7cbd86ae9541453e
> <https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...682488a832db5b6b4fcdd4cd7cbd86ae9541453e__;!!FJ-Y8qCqXTj2!c-eKDU27xX1FU55g2nJgccUKbM9SvUI7wCrdCc8dTazyEHAuWyMH8

Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

['Ben Wilson' via dev-security-policy@mozilla.org]

Hi Amir,

Here is a quick update on this issue, while I continue working on a summary
of the discussion concerning the acquisition of e-commerce monitoring by
AUSTRIA CARD.

Since June 1, 2022, section 3.2 of the Mozilla Root Store Policy (MRSP) has
required that ETSI auditors be members of the Accredited Conformity
Assessment Bodies' Council (ACAB'c). One of the underlying reasons for
adopting this requirement was to ensure consistency in auditor
qualifications, guidance, and attestation letters. The ACAB’c membership
requirement continues to help improve the quality of ETSI audits. However,
the MRSP also allows Mozilla to temporarily waive the ACAB’c membership
requirement under certain circumstances.

e-commerce monitoring’s ETSI audit is currently performed by A-SIT (Secure
Information Technology Center – Austria). According to Herbert Leithold,
Executive Director of A-SIT, “A-SIT is a government-funded information
security organisation with formal duties that require strict neutrality and
independency.” For this reason, A-SIT asserts that it is precluded from
joining the ACAB’c. While A-SIT is currently not a member of ACAB'c, it has
otherwise met auditor qualification requirements and its audits have
conformed to templates provided by the ACAB’c.

We are considering whether to grant a temporary approval of A-SIT as an
exception to the ACAB’c membership requirement. Such temporary approval
would be subject to periodic re-evaluation, and likely it would eventually
be withdrawn. We sincerely appreciate everyone's contributions as they
facilitate our ability to make well-informed decisions. We kindly request
your insightful perspectives and opinions.

Thanks,

Ben


On Fri, Apr 26, 2024 at 12:09 PM Amir Omidi (aaomidi) 
wrote:

> Did you ever hear from them?
>
> On Tuesday, March 5, 2024 at 11:18:13 AM UTC-5 Ben Wilson wrote:
>
>> All,
>> March 1 was the scheduled end of public discussion on this matter.
>> However, I have one unresolved question that I have presented to the CA
>> operator and its audit firm regarding ACAB'c membership (see MRSP section
>> 3.2). As soon as I hear back on that question, I'll provide a summary of
>> the entire discussion here.
>> Thanks,
>> Ben
>>
>> On Friday, February 23, 2024 at 7:36:13 AM UTC-7
>> regist...@e-monitoring.at wrote:
>>
>>> *Preface*
>>>
>>> The only thing that changed is the ownership, and the ownership is
>>> represented by the new management. This only formal change has already been
>>> notified to the authorities and approved and registered. The rest remains
>>> unchanged.
>>>
>>> e-commerce monitoring GmbH fulfills different trust service requirements
>>> from ISO/IEC, eIDAS / ETSI, CA/Browser Forum to Root Program requirements,
>>> remains a member of the European Trust List (EUTL) as before and is
>>> permanently monitored by the Austrian Supervisory Body (RTR/TKK) and
>>> regularly assessed by a Conformity Assessment Body.
>>>
>>> The management has changed from Hans G. Zeger to Emmanouil Kontos and
>>> Markus Kirchmayr. The takeover of the company includes the taking over of
>>> the existing, trained and trusted staff which results in no changes except
>>> top management. e-commerce monitoring GmbH continues to provide
>>> certification and trust services according to the respective policies.
>>>
>>> It is in the interest of AUSTRIA CARD-Plastikkarten und Ausweissysteme
>>> Gesellschaft m.b.H. that e-commerce monitoring GmbH continues to fully
>>> comply with the Browser/OS Root Store Policies.
>>>
>>>
>>> *Ownership and Governance*
>>>
>>> The ultimate beneficial owner is Nikolaos Lykos. The new shareholder of
>>> e-commerce monitoring GmbH is AUSTRIA CARD-Plastikkarten und Ausweissysteme
>>> Gesellschaft m.b.H., Nikolaos Lykos owns 77.57 % of shares in AUSTRIACARD
>>> HOLDINGS AG, which is the parent company of AUSTRIA CARD-Plastikkarten und
>>> Ausweissysteme Gesellschaft m.b.H. (it is owned 100% by AUSTRIACARD
>>> HOLDINGS AG).
>>>
>>> AUSTRIACARD HOLDINGS AG is a publically listed company with subsidiaries
>>> in Europe and the USA (please find more details in the prospectus on
>>> AUSTRIACARD´s website (
>>> https://www.austriacard.com/wp-content/uploads/2023/01/AustriaCard_Prospectus_24.01.2023_FINAL.PUBLICATIONpdf.pdf
>>> )
>>>
>>> Emmanouil Kontos is the Managing Director of the company and authorized
>>> to represent the company solely. Markus Kirchmayr is authorized to
>>> represent the company jointly with Emmanouil Kontos. Both will not take any
>>> trusted roles

Re: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and Weak Keys

[Ben Wilson via Servercert-wg]

Mozilla votes "yes".

On Fri, Apr 26, 2024 at 2:00 AM Wayne Thayer via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Purpose of Ballot SC-073
>
> This ballot proposes updates to the Baseline Requirements for the Issuance
> and Management of Publicly-Trusted TLS Server Certificates related to weak
> and compromised private keys. These changes lie primarily in Section
> 6.1.1.3:
>
>-
>
>6.1.1.3(4) clarifies that, for the purpose of this requirement, CAs
>shall be made aware of compromised keys using their existing notification
>mechanism(s).
>-
>
>6.1.1.3(5) improves guidance for CAs around the detection of weak
>keys. Should this ballot pass, these changes become effective on November
>15, 2024.
>
> Notes:
>
>-
>
>This ballot builds on the extensive work done by SSL.com in creating
>ballot SC-59v2 Weak Key Guidance. SSL.com’s contributions are appreciated.
>-
>
>Thanks to Rob Stradling of Sectigo for the generation and publication
>of the set of Debian weak keys referenced in this ballot.
>-
>
>The Debian weak keys requirements have been discussed extensively,
>including in the following threads:
>https://lists.cabforum.org/pipermail/servercert-wg/2024-March/004291.html
>and
>https://lists.cabforum.org/pipermail/servercert-wg/2024-April/004422.html
>
>-
>
>This ballot does not appear to conflict with any other ballots that
>are currently under discussion.
>
>
> The following motion has been proposed by Wayne Thayer of Fastly, and
> endorsed by Brittany Randall of GoDaddy and Bruce Morton of Entrust.
>
> — Motion Begins —
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
> based on Version 2.0.3.
>
> MODIFY the Baseline Requirements for the Issuance and Management of
> Publicly-Trusted TLS Server Certificates as specified in the following
> Redline:
>
> Here is a link to the immutable GitHub redline:
> https://github.com/cabforum/servercert/compare/a65402cff89affe1fc0a1f0e49807c7e42e1608a...bee10c8e4a56815bffd59fab12cbd4044baa7cc0
>
>
> — Motion Ends —
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
> Discussion (7+ days)
>
>-
>
>Start time: 2024-04-18 00:00:00 UTC
>-
>
>End time: 2024-04-26 00:00:00 UTC
>
> Vote for approval (7 days)
>
>-
>
>Start time: 2024-04-26 00:00:00 UTC
>- End time: 2024-05-03 00:00:00 UTC
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation

[Ben Wilson via Servercert-wg]

I removed it because I didn't like the phrasing. I can propose other
wording for an effective date, unless anyone else wants to take a crack at
it.

On Wed, Apr 24, 2024, 1:59 AM Wayne Thayer  wrote:

> Thanks Ben!
>
> The second commit you linked removes the effective date for CP/CPS updates
> from section 9.6.3. While I'm not convinced that this is necessary, it
> seems to add some clarity. Was that paragraph meant to remain in place? If
> not, what is the reasoning?
>
> Otherwise I am also happy with these changes.
>
> - Wayne
>
> On Tue, Apr 23, 2024 at 4:21 PM Aaron Gable via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
>> Hi Ben,
>>
>> Thank you! I believe those combine with the previous commits to produce
>> this redline, which looks good to me:
>>
>> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...682488a832db5b6b4fcdd4cd7cbd86ae9541453e
>>
>> Aaron
>>
>>
>> On Tue, Apr 23, 2024 at 4:25 AM Ben Wilson  wrote:
>>
>>> Dimitris, Aaron, Wayne, and Others,
>>> We are working on improving the language of the ballot.
>>> Here are a couple of versions for you to review and provide feedback on.
>>> https://github.com/cabforum/servercert/commit/d0d962e04bd81a71ebf71a7c45a015cbc75ac979
>>>
>>>
>>> https://github.com/cabforum/servercert/commit/682488a832db5b6b4fcdd4cd7cbd86ae9541453e
>>> Thanks,
>>> Ben
>>>
>>>
>>> On Sun, Apr 21, 2024 at 8:29 PM Dustin Hollenback via Servercert-wg <
>>> servercert-wg@cabforum.org> wrote:
>>>
>>>> Thank you all for the great feedback! We’ll take this offline and
>>>> re-work it based on the input.
>>>>
>>>>
>>>>
>>>> *From:* Servercert-wg  *On Behalf
>>>> Of *Dimitris Zacharopoulos (HARICA) via Servercert-wg
>>>> *Sent:* Sunday, April 21, 2024 1:24 AM
>>>> *To:* Aaron Gable ; CA/B Forum Server
>>>> Certificate WG Public Discussion List 
>>>> *Subject:* [EXTERNAL] Re: [Servercert-wg] Discussion Period Begins -
>>>> Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 19/4/2024 9:54 μ.μ., Aaron Gable wrote:
>>>>
>>>> On Fri, Apr 19, 2024 at 11:07 AM Dimitris Zacharopoulos (HARICA) via
>>>> Servercert-wg  wrote:
>>>>
>>>> What happens if the SA/ToS document changes? I had the impression that
>>>> the ACME client would be able to see the new version and ask that the
>>>> updated version is accepted. How does this process work in practice?
>>>>
>>>>
>>>>
>>>> The ACME protocol itself only has one mechanism for updating the Terms
>>>> of Service: respond to all requests with HTTP 403 Forbidden, error type
>>>> "urn:ietf:params:acme:error:userActionRequired", and a link to a URL where
>>>> a human can take action to agree to the new terms. Breaking every single
>>>> ACME client until their operator takes manual action on a webpage is
>>>> unacceptable and unrealistic, so ACME server operators do not actually do
>>>> this.
>>>>
>>>>
>>>> The ACME protocol was designed to support popular use cases promoting
>>>> automation. The level of automation can be decided by the Applicant. For
>>>> example, if an Applicant chooses the dns-01 challenge and wants to manually
>>>> update their DNS server to include the challenge, so be it. That doesn't
>>>> mean that this breaks every single ACME client. It's supposed to be a
>>>> feature, not a bug :-)
>>>>
>>>> My point is that if an Applicant wants to automate the response to a
>>>> new Terms of Service, they can program the ACME client to connect to the
>>>> return URL with the new document, accept it and continue with the request.
>>>>
>>>>
>>>>
>>>>
>>>> However, this is preceded by one caveat: RFC 8555 Section 7.3.3 says
>>>> "If the server has changed its terms of service since a client
>>>> initially accepted, *and the server is unwilling to process a request
>>>> without explicit agreement to the new terms*, ...".
>>>>
>>>>
>>>>
>>>> So there's an easy path forward: include language in the Subscriber
>>>> Agreement to the effect of "this agreement may be updated&q

Re: [cabf_netsec] Voting Period Begins | Ballot NS-003: Restructure the NCSSRs

[Ben Wilson via Netsec]

Mozilla votes "yes" on this ballot.

On Tue, Apr 23, 2024, 5:59 PM Clint Wilson via Netsec 
wrote:

> Ballot NS-003 is proposed by Clint Wilson of Apple and endorsed by Trevoli
> Ponds-White of Amazon and David Kluge of Google Trust Services.
>
> *Purpose of Ballot*
>
> This ballot proposes a comprehensive restructuring of the Network and
> Certificate System Security Requirements (NCSSRs), excepting Section 4. The
> current structure of the document has proven to be challenging for creating
> ballots, contains duplicated requirements, and separates similar
> requirements across the document. These issues have led to inefficiencies
> in managing and implementing security standards. Therefore, this proposal
> aims to streamline the document's structure, eliminate redundancies,
> improve comprehensibility, and enhance clarity and coherence.
>
> *Reasons for Proposal:*
>
>
>- *Complexity in Ballot Creation*: The current document structure can
>make it difficult to create and manage ballots efficiently, leading to
>somewhat awkward updating processes, abandoned ballots, and a lack of
>confidence that ballots effect the intended changes.
>- *Redundancy*: Over time, some parts of the NCSSRs have touched on
>the same topic, leading to some duplication across the document and further
>to confusion and inconsistency in implementation.
>- *Fragmentation*: Similar requirements for different parts of a CA’s
>NCSSR-relevant infrastructure are scattered throughout the document, making
>it somewhat more difficult for to locate and comprehend a complete picture
>of these requirements effectively.
>- *Minor Issues*: The document contains other, more minor issues that
>also impede its usability and effectiveness, such as missing definitions,
>unclear list structures, and requirements that are more optional than they
>may currently appear.
>
>
> *Benefits of the Updated Document Structure:*
>
>
>- *Enhanced Clarity*: The revised structure should improve the clarity
>and coherence of the document, making the requirements it represents easier
>to understand, as well as result in greater consistency when implementing
>or assessing its security requirements.
>- *Future Updates*: A more granular document structure should improve
>the process of creating and managing ballots in the future. Similarly, the
>improved proximity of related requirements should hopefully aid in
>identifying the areas the NCSSRs can most benefit from further attention.
>- *Grouping and De-duplication of Similar Requirements*: By
>consolidating duplicated requirements, the updated document should make it
>much easier to find, comprehend, assess, and implement related 
> requirements.
>- *Clearer Recommendations*: The updated document includes a number of
>additional “SHOULD”-type stipulations, clarifying some of the language in
>the current NCSSRs such that it’s easier to identify where the NCSSRs
>impose a strict requirement as opposed to a strong recommendation.
>
>
> Overall, this ballot proposal seeks to address existing challenges in
> updating the current version of the NCSSRs and pave the way for future
> improvements to the NCSSRs.
>
> *MOTION BEGINS*
>
> This ballot modifies the “Network and Certificate System Security
> Requirements” as follows, based on version 1.7:
>
>
> https://github.com/cabforum/netsec/compare/c62a2f88e252de5c79b101fa3c9e9c536388639a...8bd66d27c07e30d1f4d9e6dd57b075bca499bf2e
>
> *MOTION ENDS*
>
> The procedure for approval of this ballot is as follows:
>
> *Discussion Period* (14+ days)
>
> Start Time: 2024-April-09 16:00 UTC
> End Time: 2024-April-23 15:59 UTC
>
> *Voting Period* (7 days)
>
> Start Time: 2024-April-23 16:00 UTC
> End Time: 2024-April-30 16:00 UTC
> ___
> Netsec mailing list
> Netsec@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/netsec
>
___
Netsec mailing list
Netsec@cabforum.org
https://lists.cabforum.org/mailman/listinfo/netsec

Re: [Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation

[Ben Wilson via Servercert-wg]

Dimitris, Aaron, Wayne, and Others,
We are working on improving the language of the ballot.
Here are a couple of versions for you to review and provide feedback on.
https://github.com/cabforum/servercert/commit/d0d962e04bd81a71ebf71a7c45a015cbc75ac979

https://github.com/cabforum/servercert/commit/682488a832db5b6b4fcdd4cd7cbd86ae9541453e
Thanks,
Ben


On Sun, Apr 21, 2024 at 8:29 PM Dustin Hollenback via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Thank you all for the great feedback! We’ll take this offline and re-work
> it based on the input.
>
>
>
> *From:* Servercert-wg  *On Behalf Of 
> *Dimitris
> Zacharopoulos (HARICA) via Servercert-wg
> *Sent:* Sunday, April 21, 2024 1:24 AM
> *To:* Aaron Gable ; CA/B Forum Server Certificate
> WG Public Discussion List 
> *Subject:* [EXTERNAL] Re: [Servercert-wg] Discussion Period Begins -
> Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation
>
>
>
>
>
> On 19/4/2024 9:54 μ.μ., Aaron Gable wrote:
>
> On Fri, Apr 19, 2024 at 11:07 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg  wrote:
>
> What happens if the SA/ToS document changes? I had the impression that the
> ACME client would be able to see the new version and ask that the updated
> version is accepted. How does this process work in practice?
>
>
>
> The ACME protocol itself only has one mechanism for updating the Terms of
> Service: respond to all requests with HTTP 403 Forbidden, error type
> "urn:ietf:params:acme:error:userActionRequired", and a link to a URL where
> a human can take action to agree to the new terms. Breaking every single
> ACME client until their operator takes manual action on a webpage is
> unacceptable and unrealistic, so ACME server operators do not actually do
> this.
>
>
> The ACME protocol was designed to support popular use cases promoting
> automation. The level of automation can be decided by the Applicant. For
> example, if an Applicant chooses the dns-01 challenge and wants to manually
> update their DNS server to include the challenge, so be it. That doesn't
> mean that this breaks every single ACME client. It's supposed to be a
> feature, not a bug :-)
>
> My point is that if an Applicant wants to automate the response to a new
> Terms of Service, they can program the ACME client to connect to the return
> URL with the new document, accept it and continue with the request.
>
>
>
>
> However, this is preceded by one caveat: RFC 8555 Section 7.3.3 says "If
> the server has changed its terms of service since a client
> initially accepted, *and the server is unwilling to process a request
> without explicit agreement to the new terms*, ...".
>
>
>
> So there's an easy path forward: include language in the Subscriber
> Agreement to the effect of "this agreement may be updated", and always be
> willing to process requests without explicit agreement to the new terms. At
> a glance, Let's Encrypt, Google Trust Services, GoDaddy, and HARICA all
> take this approach in their Subscriber Agreement documents.
>
>
>
> So I think there are two potential issues with the proposed language:
>
> 1) "The Certificate Warranties specifically include [that]... the
> Subscriber has been provided with the most current version of the
> Subscriber Agreement" -- I think this language is *probably* fine, as
> long as "posted to the CA's policy document repository" counts as
> "provided". But I'd prefer not to have to split hairs, and so would prefer
> language which more clearly makes it obvious that the updated document does
> not have to proactively be given to each Subscriber individually and that
> simply posting it to the public repository is sufficient.
>
>
> In some cases, CAs point to a URL that contains the latest version of the
> Subscriber Agreement, so in one sense the Applicant agrees to that -latest-
> version without the need to see a different URL. The only concern here is
> what happens to implementations where the Applicant accepts the Subscriber
> Agreement at account creation and not at Certificate Issuance/Retrieval. In
> that scenario, the CA would not be able to claim that the Applicant has
> accepted the updated version, right?
>
>
> 2) "The Certificate Warranties specifically include [that]... the
> applicable Subscriber Agreement is the Subscriber Agreement that was
> accepted when the Certificate was issued" -- Again, this language is
> probably technically fine, in that the Subscriber Agreement can include
> language saying that Subscribers are assumed to have accepted future
> updates to the document. But I'd still prefer not to split hairs, and so I
> think that Wayne's suggestion of "...that was *in force* when the
> Certificate was issued" is a good one.
>
>
> I also prefer this language but would that address the concern mentioned
> above?
>
>
>
>
> Unrelated to the discussion above, our Counsel has suggested one other
> simplification of the language in the ballot: "if the CA and Subscriber are
> not Affiliated, the Subscriber and CA 

Re: [cabfpub] CABG: Follow-up actions to the creation of the new Definitions and Glossary Working Group

[Ben Wilson via Public]

Mozilla wants to participate in the new Definitions and Glossary Working
Group.

On Mon, Apr 22, 2024 at 10:27 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

>
> Dear Members,
>
> I have added the approved Charter of the Definitions and Glossary
> Working Group (DGWG) to the main GitHub Forum repository
> https://github.com/cabforum/forum/blob/main/DGWG-Charter.md.
>
> I welcome Tim Hollebeek (Chair) and Tim Callan (Vice-Chair) to
> coordinate with the Infrastructure Subcommittee to create the necessary
> mailing lists, area in the cabforum.org Public Website and possibly a
> separate area in the Member's Website (wiki.cabforum.org).
>
> According to the Bylaws and IPR Policy, each Member must declare its
> participation to the DGWG, preferably by replying to this email so the
> declaration can be registered on the Public Mailing List.
>
>
> Best regards,
>
> Dimitris Zacharopoulos
> CA/B Forum Chair
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

All,

Here is a revised Charter for the Forum IPR Subcommittee ("FIPR").

https://github.com/BenWilson-Mozilla/forum/blob/fipr-charter/FIPR-Charter.md

Thanks,

Ben

On Fri, Apr 19, 2024 at 11:59 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

> Hi  Ben,
>
> On 16/4/2024 7:48 μ.μ., Ben Wilson via Public wrote:
>
> All,
>
> As mentioned during the Forum teleconference of April 11, 2024, here is a
> draft charter for a Forum IPR Subcommittee. (This effort is separate, but
> somewhat in parallel to the work of the Patent Advisory Group, which will
> be handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in
> relation to Ballot SC-70.)
>
> Please provide your comments or questions.
>
> Thanks,
>
> Ben
>
>
>
> *Forum IPR Subcommittee Charter*
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.6 of
> the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the
> activities as specified in this Charter, subject to the terms and
> conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights
> (IPR) Policy, as such documents may change from time to time. The
> definitions found in the Forum’s Bylaws or IPR Policy shall apply to
> capitalized terms in this Charter.
>
>
> I'm not sure the IPR Policy needs to be invoked here. Please take a look
> at the Forum Infrastructure SC charter (
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/).
> Also, is it ok to use the acronym "FIS" as it is also referred in the Forum
> Subcommittee Charter?
>
> *Scope*
>
> The primary activity of the FIS shall be to review, and propose revisions
> to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice
> template, and similar documents.  The FIS may perform other activities
> ancillary to this primary activity.  The FIS will not create Final
> Guidelines or Final Maintenance Guidelines.
>
>
> Based on the last statement, I don't think we need to mention that this
> charter is subject to the IPR Policy.
>
> *Anticipated End Date*
>
> The FIS is chartered without a specific end date. However, it is expected
> that the FIS will deliver results of its initial work to the Forum prior to
> _ 2024.  Thereafter, the FIS will continue to exist, but may be
> dissolved at any time by Forum ballot.
>
>
> If the Subcommittee completes its deliverables and those deliverables are
> accepted by the Forum by ballot, the subcommittee should probably be
> dissolved automatically. We could renew its charter or duration if we find
> something else useful but based on the current expectations it looks like
> it will be dissolved if the proposed documents are approved.
>
> *Initial Chairs and Contacts*
>
> The proposer of the ballot adopting this Charter, Ben Wilson, will act as
> organizer of the FIS until the first teleconference is held for the FIS, at
> which time the FIS will elect a chair and vice-chair, either by vote or by
> acclamation of those present. The chair and vice-chair will normally serve
> two-year terms.  However, the first term will start upon their election
> and run through 31 October 2026.
>
> *Members Eligible to Participate*
>
> The FIS welcomes the participation of any Member organization of the Forum
> interested in this work.  Forum Members that have initially declared
> their participation in this Subcommittee are:
>
> Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla,
> Sectigo, SwissSign,
>
> *Voting and Voting Structure*
>
> Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single class, with one
> vote granted to each Member organization. Any decisions of the FIS needed
> to be voted upon by the FIS shall be considered adopted if the number of
> votes in favor exceeds 50% of the votes cast.
>
>
> This is not a WG so no voting or voting structure is necessary.
>
> *Primary Means of Communication*
>
> The FIS will communicate primarily through listserv-based email and shall
> conduct periodic calls or face-to-face meetings as needed.
>
>
> I suggest we combine some elements from
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/
> to improve this charter.
>
> Thanks Ben for putting this together!
>
> Dimitris.
>
>
>
> ___
> Public mailing 
> listPublic@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/public
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

Thanks, Dimitris.

I will make edits to the proposal and get back to everyone.

Ben

On Fri, Apr 19, 2024 at 11:59 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

> Hi  Ben,
>
> On 16/4/2024 7:48 μ.μ., Ben Wilson via Public wrote:
>
> All,
>
> As mentioned during the Forum teleconference of April 11, 2024, here is a
> draft charter for a Forum IPR Subcommittee. (This effort is separate, but
> somewhat in parallel to the work of the Patent Advisory Group, which will
> be handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in
> relation to Ballot SC-70.)
>
> Please provide your comments or questions.
>
> Thanks,
>
> Ben
>
>
>
> *Forum IPR Subcommittee Charter*
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.6 of
> the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the
> activities as specified in this Charter, subject to the terms and
> conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights
> (IPR) Policy, as such documents may change from time to time. The
> definitions found in the Forum’s Bylaws or IPR Policy shall apply to
> capitalized terms in this Charter.
>
>
> I'm not sure the IPR Policy needs to be invoked here. Please take a look
> at the Forum Infrastructure SC charter (
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/).
> Also, is it ok to use the acronym "FIS" as it is also referred in the Forum
> Subcommittee Charter?
>
> *Scope*
>
> The primary activity of the FIS shall be to review, and propose revisions
> to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice
> template, and similar documents.  The FIS may perform other activities
> ancillary to this primary activity.  The FIS will not create Final
> Guidelines or Final Maintenance Guidelines.
>
>
> Based on the last statement, I don't think we need to mention that this
> charter is subject to the IPR Policy.
>
> *Anticipated End Date*
>
> The FIS is chartered without a specific end date. However, it is expected
> that the FIS will deliver results of its initial work to the Forum prior to
> _ 2024.  Thereafter, the FIS will continue to exist, but may be
> dissolved at any time by Forum ballot.
>
>
> If the Subcommittee completes its deliverables and those deliverables are
> accepted by the Forum by ballot, the subcommittee should probably be
> dissolved automatically. We could renew its charter or duration if we find
> something else useful but based on the current expectations it looks like
> it will be dissolved if the proposed documents are approved.
>
> *Initial Chairs and Contacts*
>
> The proposer of the ballot adopting this Charter, Ben Wilson, will act as
> organizer of the FIS until the first teleconference is held for the FIS, at
> which time the FIS will elect a chair and vice-chair, either by vote or by
> acclamation of those present. The chair and vice-chair will normally serve
> two-year terms.  However, the first term will start upon their election
> and run through 31 October 2026.
>
> *Members Eligible to Participate*
>
> The FIS welcomes the participation of any Member organization of the Forum
> interested in this work.  Forum Members that have initially declared
> their participation in this Subcommittee are:
>
> Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla,
> Sectigo, SwissSign,
>
> *Voting and Voting Structure*
>
> Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single class, with one
> vote granted to each Member organization. Any decisions of the FIS needed
> to be voted upon by the FIS shall be considered adopted if the number of
> votes in favor exceeds 50% of the votes cast.
>
>
> This is not a WG so no voting or voting structure is necessary.
>
> *Primary Means of Communication*
>
> The FIS will communicate primarily through listserv-based email and shall
> conduct periodic calls or face-to-face meetings as needed.
>
>
> I suggest we combine some elements from
> https://cabforum.org/2019/10/08/ballot-forum-10-re-charter-forum-infrastructure-working-group/
> to improve this charter.
>
> Thanks Ben for putting this together!
>
> Dimitris.
>
>
>
> ___
> Public mailing 
> listPublic@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/public
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

Hi Martijn,

I was thinking that there may be miscellaneous decisions where the
Subcommittee might need to vote. There is no intent that the Subcommittee
would be able to "adopt" a new IPR Policy, if that is your concern.

I was proposing that only Forum Members would be eligible to participate on
the Subcommittee, so Associate Members, Probationary Members and Interested
Parties would not be participating on the Subcommittee, nor would they have
a vote.

Thanks,

Ben

On Fri, Apr 19, 2024 at 1:55 AM Martijn Katerbarg <
martijn.katerb...@sectigo.com> wrote:

> Ben, a few questions / clarifications:
>
>
>
> > Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single
>
> Does this mean the Subcommittee will run a ballot rather than the Forum,
> or will the Forum still run the actuall ballot?
>
>
>
> > Voting shall be egalitarian: all Members shall vote together as a
> single class
>
> Is the intent here to also allow Associated Members, Probationary Members
> and Interested Parties to vote?
>
> Regards,
>
> Martijn
>
>
>
> *From: *Public  on behalf of Ben Wilson via
> Public 
> *Date: *Thursday, 18 April 2024 at 17:37
> *To: *CA/Browser Forum Public Discussion List 
> *Subject: *Re: [cabfpub] Draft Charter for IPR Subcommittee
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> All,
>
> I will put this in ballot format. I am looking for endorsers.
>
> Thanks,
>
> Ben
>
>
>
> On Tue, Apr 16, 2024 at 10:48 AM Ben Wilson  wrote:
>
> All,
>
> As mentioned during the Forum teleconference of April 11, 2024, here is a
> draft charter for a Forum IPR Subcommittee. (This effort is separate, but
> somewhat in parallel to the work of the Patent Advisory Group, which will
> be handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in
> relation to Ballot SC-70.)
>
> Please provide your comments or questions.
>
> Thanks,
>
> Ben
>
>
>
> *Forum IPR Subcommittee Charter*
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.6 of
> the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the
> activities as specified in this Charter, subject to the terms and
> conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights
> (IPR) Policy, as such documents may change from time to time. The
> definitions found in the Forum’s Bylaws or IPR Policy shall apply to
> capitalized terms in this Charter.
>
> *Scope*
>
> The primary activity of the FIS shall be to review, and propose revisions
> to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice
> template, and similar documents.  The FIS may perform other activities
> ancillary to this primary activity.  The FIS will not create Final
> Guidelines or Final Maintenance Guidelines.
>
> *Anticipated End Date*
>
> The FIS is chartered without a specific end date. However, it is expected
> that the FIS will deliver results of its initial work to the Forum prior to
> _ 2024.  Thereafter, the FIS will continue to exist, but may be
> dissolved at any time by Forum ballot.
>
> *Initial Chairs and Contacts*
>
> The proposer of the ballot adopting this Charter, Ben Wilson, will act as
> organizer of the FIS until the first teleconference is held for the FIS, at
> which time the FIS will elect a chair and vice-chair, either by vote or by
> acclamation of those present. The chair and vice-chair will normally serve
> two-year terms.  However, the first term will start upon their election and
> run through 31 October 2026.
>
> *Members Eligible to Participate*
>
> The FIS welcomes the participation of any Member organization of the Forum
> interested in this work.  Forum Members that have initially declared their
> participation in this Subcommittee are:
>
> Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla,
> Sectigo, SwissSign,
>
> *Voting and Voting Structure*
>
> Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single class, with one
> vote granted to each Member organization. Any decisions of the FIS needed
> to be voted upon by the FIS shall be considered adopted if the number of
> votes in favor exceeds 50% of the votes cast.
>
> *Primary Means of Communication*
>
> The FIS will communicate primarily through listserv-based email and shall
> conduct periodic calls or face-to-face meetings as needed.
>
>
>
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

All,
I will put this in ballot format. I am looking for endorsers.
Thanks,
Ben

On Tue, Apr 16, 2024 at 10:48 AM Ben Wilson  wrote:

> All,
>
> As mentioned during the Forum teleconference of April 11, 2024, here is a
> draft charter for a Forum IPR Subcommittee. (This effort is separate, but
> somewhat in parallel to the work of the Patent Advisory Group, which will
> be handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in
> relation to Ballot SC-70.)
>
> Please provide your comments or questions.
>
> Thanks,
>
> Ben
>
>
>
> *Forum IPR Subcommittee Charter*
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.6 of
> the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the
> activities as specified in this Charter, subject to the terms and
> conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights
> (IPR) Policy, as such documents may change from time to time. The
> definitions found in the Forum’s Bylaws or IPR Policy shall apply to
> capitalized terms in this Charter.
>
> *Scope*
>
> The primary activity of the FIS shall be to review, and propose revisions
> to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice
> template, and similar documents.  The FIS may perform other activities
> ancillary to this primary activity.  The FIS will not create Final
> Guidelines or Final Maintenance Guidelines.
>
> *Anticipated End Date*
>
> The FIS is chartered without a specific end date. However, it is expected
> that the FIS will deliver results of its initial work to the Forum prior to
> _ 2024.  Thereafter, the FIS will continue to exist, but may be
> dissolved at any time by Forum ballot.
>
> *Initial Chairs and Contacts*
>
> The proposer of the ballot adopting this Charter, Ben Wilson, will act as
> organizer of the FIS until the first teleconference is held for the FIS, at
> which time the FIS will elect a chair and vice-chair, either by vote or by
> acclamation of those present. The chair and vice-chair will normally serve
> two-year terms.  However, the first term will start upon their election
> and run through 31 October 2026.
>
> *Members Eligible to Participate*
>
> The FIS welcomes the participation of any Member organization of the Forum
> interested in this work.  Forum Members that have initially declared
> their participation in this Subcommittee are:
>
> Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla,
> Sectigo, SwissSign,
>
> *Voting and Voting Structure*
>
> Voting in the FIS shall be limited to Forum members. Voting shall be
> egalitarian: all Members shall vote together as a single class, with one
> vote granted to each Member organization. Any decisions of the FIS needed
> to be voted upon by the FIS shall be considered adopted if the number of
> votes in favor exceeds 50% of the votes cast.
>
> *Primary Means of Communication*
>
> The FIS will communicate primarily through listserv-based email and shall
> conduct periodic calls or face-to-face meetings as needed.
>
>
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[cabfpub] Draft Charter for IPR Subcommittee

[Ben Wilson via Public]

All,

As mentioned during the Forum teleconference of April 11, 2024, here is a
draft charter for a Forum IPR Subcommittee. (This effort is separate, but
somewhat in parallel to the work of the Patent Advisory Group, which will
be handling GoDaddy's Patent Exclusion Notice, filed Mar. 22, 2024, in
relation to Ballot SC-70.)

Please provide your comments or questions.

Thanks,

Ben



*Forum IPR Subcommittee Charter*

Upon approval of the CAB Forum by ballot in accordance with section 5.6 of
the Bylaws, the Forum IPR Subcommittee (“FIS”) is created to perform the
activities as specified in this Charter, subject to the terms and
conditions of the CA/Browser Forum Bylaws and Intellectual Property Rights
(IPR) Policy, as such documents may change from time to time. The
definitions found in the Forum’s Bylaws or IPR Policy shall apply to
capitalized terms in this Charter.

*Scope*

The primary activity of the FIS shall be to review, and propose revisions
to, the Forum’s IPR Policy, IPR Policy Agreement, exclusion notice
template, and similar documents.  The FIS may perform other activities
ancillary to this primary activity.  The FIS will not create Final
Guidelines or Final Maintenance Guidelines.

*Anticipated End Date*

The FIS is chartered without a specific end date. However, it is expected
that the FIS will deliver results of its initial work to the Forum prior to
_ 2024.  Thereafter, the FIS will continue to exist, but may be
dissolved at any time by Forum ballot.

*Initial Chairs and Contacts*

The proposer of the ballot adopting this Charter, Ben Wilson, will act as
organizer of the FIS until the first teleconference is held for the FIS, at
which time the FIS will elect a chair and vice-chair, either by vote or by
acclamation of those present. The chair and vice-chair will normally serve
two-year terms.  However, the first term will start upon their election and
run through 31 October 2026.

*Members Eligible to Participate*

The FIS welcomes the participation of any Member organization of the Forum
interested in this work.  Forum Members that have initially declared their
participation in this Subcommittee are:

Amazon, Apple, DigiCert, GoDaddy, Google, HARICA, Let’s Encrypt, Mozilla,
Sectigo, SwissSign,

*Voting and Voting Structure*

Voting in the FIS shall be limited to Forum members. Voting shall be
egalitarian: all Members shall vote together as a single class, with one
vote granted to each Member organization. Any decisions of the FIS needed
to be voted upon by the FIS shall be considered adopted if the number of
votes in favor exceeds 50% of the votes cast.

*Primary Means of Communication*

The FIS will communicate primarily through listserv-based email and shall
conduct periodic calls or face-to-face meetings as needed.
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Patent Advisory Group Formation

[Ben Wilson via Public]

Just a reminder -
If you or your IP counsel are interested in participating in the Patent
Advisory Group, please let me know by close of business Friday.
Thanks.  Ben

On Thu, Mar 28, 2024 at 11:03 AM Ben Wilson via Public 
wrote:

> All,
> In today's Forum call, I announced that we are collecting the names and
> email addresses of participants in the Patent Advisory Group through
> Friday, April 12, 2024, and then we'll get started.
> Thanks,
> Ben
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [Smcwg-public] Ballot SMC06v2: Post implementation clarification and corrections

[Ben Wilson via Smcwg-public]

Mozilla votes "yes" on Ballot SMC-006v2.

On Fri, Apr 5, 2024, 7:58 AM Kateryna Aleksieieva via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> Certum votes "Yes" to Ballot SMC06v2
>
> Kind regards,
>
> *Kateryna Aleksieieva*
> --
> *Od:* Smcwg-public  w imieniu
> użytkownika Stephen Davidson via Smcwg-public 
> *Wysłane:* czwartek, 4 kwietnia 2024 20:15
> *Do:* smcwg-public@cabforum.org 
> *Temat:* *** Uwaga! Mozliwy SPAM / PHISHING *** [Smcwg-public] Ballot
> SMC06v2: Post implementation clarification and corrections
>
>
> *Ballot SMC06: Post implementation clarification and corrections*
>
>
>
> *Purpose of Ballot:*
>
>
>
> The ballot proposes changes to the S/MIME Baseline Requirements to provide
> clarifications and corrections arising from the implementation of the
> S/MIME BR and initial audits.
>
>
>
> The following motion has been proposed by Stephen Davidson of DigiCert and
> endorsed by Martijn Katerbarg of Sectigo and Roman Fischer of SwissSign.
>
>
>
> *— MOTION BEGINS —*
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted S/MIME Certificates” (“S/MIME Baseline
> Requirements”) resulting in Version 1.0.4.
>
>
>
> The proposed modifications to the S/MIME Baseline Requirements may be
> found at
> https://github.com/srdavidson/smime/compare/ed36440d7c967732aa08739b14cc29bed257a67d...246fab8b8880aa62cec95b6d055b872173d4dadf
> 
>
>
>
> The SMCWG Chair or Vice-Chair is permitted to update the Relevant Dates
> and Version Number of the S/MIME Baseline Requirements to reflect final
> dates.
>
>
>
> *— MOTION ENDS —*
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
>
> Discussion (9 days)
>
> Start Time: Tuesday March 26, 2024 17:00 UTC
>
> End Time: Thursday April 4, 2024 17:00 UTC
>
>
>
> Vote for approval (7 days)
>
> Start Time: Thursday April 4, 2024 17:00 UTC
>
> End Time: Thursday April 11, 2024 17:00 UTC
>
>
>
> IPR Review (30 days)
>
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [cabfpub] Voting Period Begins | Ballot FORUM-021: Form Definitions and Glossary WG

[Ben Wilson via Public]

Mozilla votes "yes" on Ballot FORUM-021.

Thanks.

On Thu, Apr 4, 2024 at 9:03 AM Clint Wilson via Public 
wrote:

> *Ballot FORUM-021*
>
> Proposed by Clint Wilson of Apple and endorsed by Tim Hollebeek of
> DigiCert and Tim Callan of Sectigo.
>
> *Purpose of Ballot*
>
> The CA/Browser Forum publishes Final Guidelines representing technical
> requirements about nuanced and challenging PKI implementations. It is
> proposed that the establishment of a Definitions and Glossary Working Group
> will assist the Forum as a whole, and its individual Chartered Working
> Groups, in the following ways:
>
> 1. *Clarity and Consistency*: Standardizing the definitions of terms will
> help Members and other interested parties have a clearer understanding of
> the terminology being used. This should reduce ambiguity and confusion,
> while increasing consistency in interpretation and use across Working
> Groups and Final Guidelines.
> 2. *Effective Communication*: A Glossary enables more effective
> communication among Members, as well as with external stakeholders such as
> industry partners, regulatory bodies, and other standardization
> organizations. It helps to ensure that everyone involved in the process is
> speaking the same language and, as such, may have a positive impact beyond
> the Forum alone.
> 3. *Quality*: By establishing a Glossary, the Forum can focus efforts on
> enhancing the quality and accuracy of the language used in published
> Guidelines. The availability of consistent, high-quality terminology
> reduces the risk of misunderstandings, errors, and misinterpretations that
> could undermine the effectiveness of the Forum.
> 4. *Accessibility and Learning*: For new Members or observers of the
> Forum, having a centralized Glossary provides a valuable resource for
> learning the specialized terminology used here. As with Guidelines in
> general, a focused Glossary can reduce the learning curve associated with
> understanding, implementing, and complying with complex baseline
> requirements documents.
> 5. *Cross-referencing and Interoperability*: A well-defined Glossary
> facilitates cross-referencing between Guidelines and promotes
> interoperability between the Forum’s Chartered Working Groups as well as
> external systems, products, processes, and people that rely on mutual
> understanding of shared terminology.
> 6. *Feedback and Iterative Improvement*: Building and maintaining a
> Glossary provides a framework for soliciting and receiving feedback from
> industry stakeholders and continuously improving the clarity and accuracy
> of the definitions over time. As new terms emerge or existing definitions
> evolve, the Glossary can be updated, ensuring that the Forum remains
> current and responsive to industry changes.
>
> *Following the passage of this ballot:*
>
>
>- A new Definitions and Glossary Chartered Working Group will be
>formed under the CA/Browser Forum, as outlined in section 5.3.1 of the
>Bylaws;
>- A Mailing list(s), GitHub repository(ies), and Wiki resource(s) will
>be established as needed to enable the D WG to fulfill its charter;
>- The D WG will collaborate with other CWGs in the Forum as
>stipulated in the charter found below; and
>- The D WG will produce and maintain a Glossary document.
>
>
> *MOTION BEGINS*
>
> *Establish Definitions and Glossary Working Group*
>
> Upon approval from the CA/Browser Forum by ballot in accordance with
> section 5.3 of the Forum Bylaws, the Definitions and Glossary Working Group
> (“DGWG”) is created to perform the activities as specified in the Charter
> as found here:
> https://github.com/cabforum/forum/compare/9805b6976e7a7ac391048d4eadb4379aa956110b...2b2b081a224031050aedf9404d9ce50344a468e8
>
> *MOTION ENDS*
>
> *The procedure for approval of this ballot is as follows:*
>
> *Discussion* (7+ days)
>
> *Start Time*: 2024-Mar-21 15:00 UTC
> *End Time*: 2024-April-4 14:59 UTC
>
> *Vote for approval* (7 days)
>
> Start Time: 2024-April-4 15:00 UTC
> End Time: 2024-April-11 15:00 UTC
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[cabfpub] Patent Advisory Group Formation

[Ben Wilson via Public]

All,
In today's Forum call, I announced that we are collecting the names and
email addresses of participants in the Patent Advisory Group through
Friday, April 12, 2024, and then we'll get started.
Thanks,
Ben
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [Servercert-wg] Notice of review period: Ballot SC70: Clarify the use of DTPs for Domain Control Validation

[Ben Wilson via Servercert-wg]

All,
I would like to help start up the patent advisory group. If you are
interested in participating or having your IP counsel involved, please
email me directly.
Thanks,
Ben

On Tue, Mar 26, 2024 at 3:32 AM Inigo Barreira via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> During the review period one member has filled an exclusion notice and
> according to article 2.4, point 9 of the bylaws, the results of the initial
> vote are rescinded and deemed null and void.
>
> A Patent Advisory Group (PAG) will be formed, in accordance with Section
> 7 of the IPR Policy, to address the conflict.
>
>
>
> *De:* Servercert-wg  *En nombre de *Inigo
> Barreira via Servercert-wg
> *Enviado el:* viernes, 23 de febrero de 2024 19:06
> *Para:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Asunto:* [Servercert-wg] Notice of review period: Ballot SC70: Clarify
> the use of DTPs for Domain Control Validation
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> *NOTICE OF REVIEW PERIOD*
>
> This Review Notice is sent pursuant to Section 4.1 of the CA/Browser
> Forum’s Intellectual Property Rights Policy (v1.3). This Review Period of
> 30 days is for one Final Maintenance Guidelines. The complete Draft
> Maintenance Guideline that is the subject of this Review Notice is attached
> to this email, both in red-line and changes-accepted draft format, in Word
> and PDF versions.
>
>
>
> *Summary of Review*
>
> *Ballot for Review: *Ballot SC70: Clarify the use of DTPs for Domain
> Control Validation
>
>
>
> *Start of Review Period: 23 February 2024 at 18:00 UTC*
>
> *End of Review Period: 23 March 2024 at 18:00 UTC*
>
>
>
> Members with any Essential Claim(s) to exclude must forward a written
> Notice to Exclude Essential Claims to the Working Group Chair (email to
> Iñigo Barreira ) and also submit a copy to
> the CA/B Forum public mailing list (email to public at 
> cabforum.org at cabforum.org >) before the end of the
> Review Period.
>
> For details, please see the current version of the CA/Browser Forum
> Intellectual Property Rights Policy
> 
> .
>
> (An optional template for submitting an Exclusion Notice is available at
> https://cabforum.org/wp-content/uploads/Template-for-Exclusion-Notice.pdf
> 
> )
>
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Approval of Firmaprofesional CA Root-A Web

[Ben Wilson]

All,



Public discussion regarding inclusion of the Firmaprofesional CA ROOT-A WEB
began on the CCADB Public List on January 31, 2024 (
https://groups.google.com/a/ccadb.org/g/public/c/3TXrvZC0isw/m/TMkE2rb_AAAJ)
and concluded on March 13 (
https://groups.google.com/a/ccadb.org/g/public/c/3TXrvZC0isw/m/PAU4VE0sAAAJ)




Additional details concerning this request may be found in the
above-referenced discussions, in *Bugzilla #1785215
*, and in CCADB Case
Number *1044
*
.



This is notice that I am recommending that Firmaprofesional’s request be
approved.



This begins a 7-day “last call” period for any final objections.

Thanks,

Ben

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabc4%3DqHy7JTmA6f8R%2BLPmKeL8mOd8ndywE-kuM6T-DfoQ%40mail.gmail.com.

Re: Public Discussion of Firmaprofesional CA Inclusion Request

[Ben Wilson]

 

On January 31, 2024, we began a six-week, public discussion[1] on the 
request from Firmaprofesional for inclusion of this root CA certificate:

FIRMAPROFESIONAL CA ROOT-A WEB 
<https://crt.sh/?sha256=BEF256DAF26E9C69BDEC1602359798F3CAF71821A03E018257C53C65617F3D4A>

The public discussion period ended on March 13, 2024.

We did not receive any objections or other questions or comments in 
opposition to Firmaprofesional’s request. We thank the community for its 
review and consideration during this period. Root Store Programs will make 
final inclusion decisions independently, on their own timelines, and based 
on each Root Store Member’s inclusion criteria. Further discussion may take 
place in the independently managed Root Store community forums (i.e., MDSP).
[1] 
https://groups.google.com/a/ccadb.org/g/public/c/3TXrvZC0isw/m/TMkE2rb_AAAJ 

On Monday, March 11, 2024 at 11:24:54 AM UTC-6 Ben Wilson wrote:

> All,
> This is just a reminder that the public discussion period ends this 
> Wednesday, March 13.
> Thanks,
> Ben
>
> On Wednesday, January 31, 2024 at 3:12:59 PM UTC-7 Ben Wilson wrote:
>
>> All,
>>
>> This email commences a six-week public discussion of Firmaprofesional’s 
>> request to include the “FIRMAPROFESIONAL CA ROOT-A WEB” as a publicly 
>> trusted root certificate in one or more CCADB Root Store Member’s program. 
>> This discussion period is scheduled to close on March 13, 2024.
>>
>> The purpose of this public discussion process is to promote openness and 
>> transparency. However, each Root Store makes its inclusion decisions 
>> independently, on its own timelines, and based on its own inclusion 
>> criteria. Successful completion of this public discussion process does not 
>> guarantee any favorable action by any root store.  
>>
>> Anyone with concerns or questions is urged to raise them on this CCADB 
>> Public list by replying directly in this discussion thread. Likewise, a 
>> representative of the applicant must promptly respond directly in the 
>> discussion thread to all questions that are posted.
>>
>> CCADB Case Number: 1044 
>> <https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=1044>;
>>  
>> Bugzilla: 1785215 <https://bugzilla.mozilla.org/show_bug.cgi?id=1785215>
>>
>> Organization Background Information (listed in CCADB):
>>
>>- 
>>
>>CA Owner Name: Autoridad de Certificacion Firmaprofesional; 
>>Firmaprofesional S.A.
>>- 
>>
>>Website(s): https://www.firmaprofesional.com/
>>- 
>>
>>Address: Passeig de Gracia 50, 2º1º, Barcelona E-08007, Spain
>>- 
>>
>>Problem Reporting Mechanism(s): sop...@firmaprofesional.com
>>- 
>>
>>Organization Type: Firmaprofesional S.A. is a commercial entity in 
>>Spain (NIF A62634068)
>>- 
>>
>>Repository URL: 
>>https://www.firmaprofesional.com/certification-policies-and-practices/
>>
>> Certificates Requesting Inclusion:
>>
>>1. 
>>
>>FIRMAPROFESIONAL CA ROOT-A WEB:
>>- 
>>   
>>   Certificate download links: (CA Repository 
>>   <https://crl.firmaprofesional.com/caroot-a_web.crt>, crt.sh 
>>   
>> <https://crt.sh/?sha256=BEF256DAF26E9C69BDEC1602359798F3CAF71821A03E018257C53C65617F3D4A>
>>   )
>>   - 
>>   
>>   Use cases served/EKUs: 
>>   - 
>>  
>>  Server Authentication 1.3.6.1.5.5.7.3.1
>>  - 
>>  
>>  Client Authentication 1.3.6.1.5.5.7.3.2
>>  - 
>>   
>>   Test websites:
>>   - 
>>  
>>  Valid: https://testsslev2022ec.firmaprofesional.com  
>>  - 
>>  
>>  Revoked: https://testrevokedsslev2022ec.firmaprofesional.com  
>>  - 
>>  
>>  Expired: https://testexpiredsslev2022ec.firmaprofesional.com 
>>  
>>
>> Existing Publicly Trusted Root CAs from Firmaprofesional S.A.:
>>
>>1. 
>>
>>Autoridad de Certificacion Firmaprofesional CIF A62634068:
>>
>>
>>- 
>>
>>Certificate download links: CA Repository 
>><https://crl.firmaprofesional.com/caroot.crt> (most recent),
>>- 
>>   
>>   crt.sh 
>>   
>> <https://crt.sh/?q=57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A>
>>  
>>   (most recent root certificate, included i

Re: [Infrastructure] Google doc for the CABF Handbook

[Ben Wilson via Infrastructure]

I took a first crack at it this afternoon.

On Thu, Mar 21, 2024 at 4:12 AM Inigo Barreira via Infrastructure <
infrastructure@cabforum.org> wrote:

> Hi all,
>
>
>
> See this link:
> https://docs.google.com/document/d/1GfisFGuFKFeY4kHr08zsQks1GwpRVyn2Gl6-eGSDmOw/edit?usp=sharing
>
>
>
> It´s a Google doc with what was shared initially in the email. It´s just a
> very first draft of a framework with the basics to handle to all
> new/old/potential responsible people in order to have it all in on document
> and organized.
>
> Some of these sections are already covered and some maybe need
> adjustments/updates/clarifications. Feel free to add anything that is
> correct and move the document where you think suits better.
>
>
>
> Regards
> ___
> Infrastructure mailing list
> Infrastructure@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
>
___
Infrastructure mailing list
Infrastructure@cabforum.org
https://lists.cabforum.org/mailman/listinfo/infrastructure

Re: [cabfpub] Discussion Period Begins | Ballot FORUM-021: Form Definitions and Glossary WG

[Ben Wilson via Public]

Looks good to me.
Ben

On Thu, Mar 21, 2024 at 9:00 AM Clint Wilson via Public 
wrote:

> *Ballot FORUM-021*
>
> Proposed by Clint Wilson of Apple and endorsed by Tim Hollebeek of
> DigiCert and Tim Callan of Sectigo.
>
> *Purpose of Ballot*
>
> The CA/Browser Forum publishes Final Guidelines representing technical
> requirements about nuanced and challenging PKI implementations. It is
> proposed that the establishment of a Definitions and Glossary Working Group
> will assist the Forum as a whole, and its individual Chartered Working
> Groups, in the following ways:
>
> 1. *Clarity and Consistency*: Standardizing the definitions of terms will
> help Members and other interested parties have a clearer understanding of
> the terminology being used. This should reduce ambiguity and confusion,
> while increasing consistency in interpretation and use across Working
> Groups and Final Guidelines.
> 2. *Effective Communication*: A Glossary enables more effective
> communication among Members, as well as with external stakeholders such as
> industry partners, regulatory bodies, and other standardization
> organizations. It helps to ensure that everyone involved in the process is
> speaking the same language and, as such, may have a positive impact beyond
> the Forum alone.
> 3. *Quality*: By establishing a Glossary, the Forum can focus efforts on
> enhancing the quality and accuracy of the language used in published
> Guidelines. The availability of consistent, high-quality terminology
> reduces the risk of misunderstandings, errors, and misinterpretations that
> could undermine the effectiveness of the Forum.
> 4. *Accessibility and Learning*: For new Members or observers of the
> Forum, having a centralized Glossary provides a valuable resource for
> learning the specialized terminology used here. As with Guidelines in
> general, a focused Glossary can reduce the learning curve associated with
> understanding, implementing, and complying with complex baseline
> requirements documents.
> 5. *Cross-referencing and Interoperability*: A well-defined Glossary
> facilitates cross-referencing between Guidelines and promotes
> interoperability between the Forum’s Chartered Working Groups as well as
> external systems, products, processes, and people that rely on mutual
> understanding of shared terminology.
> 6. *Feedback and Iterative Improvement*: Building and maintaining a
> Glossary provides a framework for soliciting and receiving feedback from
> industry stakeholders and continuously improving the clarity and accuracy
> of the definitions over time. As new terms emerge or existing definitions
> evolve, the Glossary can be updated, ensuring that the Forum remains
> current and responsive to industry changes.
>
> *Following the passage of this ballot:*
>
>
>- A new Definitions and Glossary Chartered Working Group will be
>formed under the CA/Browser Forum, as outlined in section 5.3.1 of the
>Bylaws;
>- A Mailing list(s), GitHub repository(ies), and Wiki resource(s) will
>be established as needed to enable the D WG to fulfill its charter;
>- The D WG will collaborate with other CWGs in the Forum as
>stipulated in the charter found below; and
>- The D WG will produce and maintain a Glossary document.
>
>
> *MOTION BEGINS*
>
> *Establish Definitions and Glossary Working Group*
>
> Upon approval from the CA/Browser Forum by ballot in accordance with
> section 5.3 of the Forum Bylaws, the Definitions and Glossary Working Group
> (“DGWG”) is created to perform the activities as specified in the Charter
> as found here:
> https://github.com/cabforum/forum/compare/9805b6976e7a7ac391048d4eadb4379aa956110b...2b2b081a224031050aedf9404d9ce50344a468e8
>
> *MOTION ENDS*
>
> *The procedure for approval of this ballot is as follows:*
>
> *Discussion* (7+ days)
>
> *Start Time*: 2024-Mar-21 15:00 UTC
> *End Time*: After 2024-Mar-28 15:00 UTC
>
> *Vote for approval* (7 days)
>
> Start Time: TBD
> End Time: TBD
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [Servercert-wg] Ballot to introduce linting in the TLS BRs

[Ben Wilson via Servercert-wg]

Hi Dimitris,
You can add me.
Thanks,
Ben

On Tue, Mar 19, 2024 at 9:01 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

>
>
> On 19/3/2024 5:27 π.μ., Corey Bonnell wrote:
>
> Hi Dimitris,
>
> I’d be happy to endorse and help flesh out the language.
>
>
> Thank you Corey, I added your name on the table with future ballots. Is
> there anyone else?
>
>
> Best regards,
> Dimitris.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Servercert-wg 
>  *On Behalf Of *Dimitris
> Zacharopoulos (HARICA) via Servercert-wg
> *Sent:* Sunday, March 17, 2024 8:20 AM
> *To:* CA/B Forum Server Certificate WG Public Discussion List
>  
> *Subject:* [Servercert-wg] Ballot to introduce linting in the TLS BRs
>
>
>
> Hi all,
>
> This is still very draft
> 
> based on the latest F2F. I would like to ask for 2 endorsers so we can work
> on the details of the ballot language in the next few of weeks.
>
>
> Thank you,
> Dimitris.
>
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Discussion Period Begins - Ballot SC-067 V1: "Require domain validation and CAA checks to be performed from multiple Network Perspectives”

[Ben Wilson via Servercert-wg]

Greetings Antti,
Somehow, our group (working on the Subscriber Agreement/Terms of Use
ballot) had selected ballot number 67 on the wiki, but there were two
different wiki pages with ballot numbers that people were unaware of (which
led to a second selection of #67 by Chris and Ryan).  So Dustin, Tadahiko,
and I decided to go with SC-071 (the next unallocated one) for our ballot.
Ben

On Mon, Mar 18, 2024 at 11:19 PM Backman, Antti via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Hi Chris
>
>
>
> Could there be a numbering clash with this ballot and the one being worked
> on by Ben Wilson?
>
>
>
> “[Servercert-wg] Draft Ballot SC-067: Applicant, Subscriber and Subscriber
> Agreements - Feedback r”
>
> As I am not completely sure how ballot numbering should work out, can the
> numbers be recycled or how that pans out?
>
>
>
>
>
>
>
> //Antti
>
>
>
> *From: *Servercert-wg  on behalf of
> Chris Clements via Servercert-wg 
> *Date: *Monday, 18. March 2024 at 17.32
> *To: *CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject: *[Servercert-wg] Discussion Period Begins - Ballot SC-067 V1:
> "Require domain validation and CAA checks to be performed from multiple
> Network Perspectives”
>
> *Purpose of Ballot SC-067*:
>
>
>
> This Ballot proposes updates to the *Baseline Requirements for the
> Issuance and Management of Publicly-Trusted TLS Server Certificates*
> (i.e., TLS BRs) related to “Multi-Perspective Issuance Corroboration”
> (“MPIC”).
>
>
>
> *Background*:
>
>
>
> - MPIC refers to performing domain validation and CAA checks from multiple
> Network Perspectives before certificate issuance, as described within the
> Ballot for the applicable validation methods in TLS BR Sections 3.2.2.4 and
> 3.2.2.5.
>
> - Not all methods described in TLS BR Sections 3.2.2.4 and 3.2.2.5 will
> require using MPIC.
>
> - This work was most recently motivated by research presented at
> Face-to-Face 58 [1] by Princeton University, but has been discussed for
> years prior as well.
>
> - The goal of this proposal is to make it more difficult for adversaries
> to successfully launch equally-specific prefix attacks against the domain
> validation processes described in the TLS BRs.
>
> - Additional background information can be found in an update shared at
> Face-to-Face 60 [2].
>
>
>
> *Benefits of Adoption*:
>
>
>
> - Recent publicly-documented attacks have used BGP hijacks to fool domain
> control validation and obtain malicious certificates, which led to the
> impersonation of HTTPS websites [3][4].
>
> - Routing security defenses (e.g., RPKI) can mitigate the risk of global
> BGP attacks, but localized, equally-specific BGP attacks still pose a
> significant threat to the Web PKI [5][6].
>
> - Corroborating domain control validation checks from multiple network
> perspectives (i.e., MPIC) spread across the Internet substantially reduces
> the threat posed by equally-specific BGP attacks, ensuring the integrity of
> domain validation and issuance decisions [5][7][8].
>
> - Existing deployments of MPIC at the scale of millions of certificates a
> day demonstrate the feasibility of this technique at Internet scale [7][9].
>
>
>
> *Intellectual Property (IP) Disclosure*:
>
>
>
> - While not a Server Certificate Working Group Member, researchers from
> Princeton University presented at Face-to-Face 58, provided academic
> expertise, and highlighted publicly-available peer-reviewed research to
> support Members in drafting this ballot.
>
> - The Princeton University researchers indicate that they have not filed
> for any patents relating to their MPIC work and do not plan to do so in the
> future.
>
> - Princeton University has indicated that it is unable to agree to the
> CA/Browser Forum IPR agreement because it could encumber inventions
> invented by researchers not involved in the development of MPIC or with the
> CA/B Forum.
>
> - Princeton University has instead provided the attached IPR statement.
> Pursuant to the IPR statement, Princeton University has granted a worldwide
> royalty free license to the intellectual property in MPIC developed by the
> researchers and has made representations regarding its lack of knowledge of
> any other Princeton intellectual property needed to implement MPIC.
>
> - For clarity, Princeton University’s IPR statement is NOT intended to
> replace the Forum’s IPR agreement or allow Princeton to participate in the
> Forum in any capacity.
>
> - Members seeking legal advice regarding this ballot should consult their
> own counsel.
>
>
>
> *Proposal Revis

Re: Public Discussion of Firmaprofesional CA Inclusion Request

[Ben Wilson]

All,
This is just a reminder that the public discussion period ends this 
Wednesday, March 13.
Thanks,
Ben

On Wednesday, January 31, 2024 at 3:12:59 PM UTC-7 Ben Wilson wrote:

> All,
>
> This email commences a six-week public discussion of Firmaprofesional’s 
> request to include the “FIRMAPROFESIONAL CA ROOT-A WEB” as a publicly 
> trusted root certificate in one or more CCADB Root Store Member’s program. 
> This discussion period is scheduled to close on March 13, 2024.
>
> The purpose of this public discussion process is to promote openness and 
> transparency. However, each Root Store makes its inclusion decisions 
> independently, on its own timelines, and based on its own inclusion 
> criteria. Successful completion of this public discussion process does not 
> guarantee any favorable action by any root store.  
>
> Anyone with concerns or questions is urged to raise them on this CCADB 
> Public list by replying directly in this discussion thread. Likewise, a 
> representative of the applicant must promptly respond directly in the 
> discussion thread to all questions that are posted.
>
> CCADB Case Number: 1044 
> <https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=1044>;
>  
> Bugzilla: 1785215 <https://bugzilla.mozilla.org/show_bug.cgi?id=1785215>
>
> Organization Background Information (listed in CCADB):
>
>- 
>
>CA Owner Name: Autoridad de Certificacion Firmaprofesional; 
>Firmaprofesional S.A.
>- 
>
>Website(s): https://www.firmaprofesional.com/
>- 
>
>Address: Passeig de Gracia 50, 2º1º, Barcelona E-08007, Spain
>- 
>
>Problem Reporting Mechanism(s): sop...@firmaprofesional.com
>- 
>
>Organization Type: Firmaprofesional S.A. is a commercial entity in 
>Spain (NIF A62634068)
>- 
>
>Repository URL: 
>https://www.firmaprofesional.com/certification-policies-and-practices/
>
> Certificates Requesting Inclusion:
>
>1. 
>
>FIRMAPROFESIONAL CA ROOT-A WEB:
>- 
>   
>   Certificate download links: (CA Repository 
>   <https://crl.firmaprofesional.com/caroot-a_web.crt>, crt.sh 
>   
> <https://crt.sh/?sha256=BEF256DAF26E9C69BDEC1602359798F3CAF71821A03E018257C53C65617F3D4A>
>   )
>   - 
>   
>   Use cases served/EKUs: 
>   - 
>  
>  Server Authentication 1.3.6.1.5.5.7.3.1
>  - 
>  
>  Client Authentication 1.3.6.1.5.5.7.3.2
>  - 
>   
>   Test websites:
>   - 
>  
>  Valid: https://testsslev2022ec.firmaprofesional.com  
>  - 
>  
>  Revoked: https://testrevokedsslev2022ec.firmaprofesional.com  
>  - 
>  
>  Expired: https://testexpiredsslev2022ec.firmaprofesional.com 
>  
>
> Existing Publicly Trusted Root CAs from Firmaprofesional S.A.:
>
>1. 
>
>Autoridad de Certificacion Firmaprofesional CIF A62634068:
>
>
>- 
>
>Certificate download links: CA Repository 
><https://crl.firmaprofesional.com/caroot.crt> (most recent),
>- 
>   
>   crt.sh 
>   
> <https://crt.sh/?q=57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A>
>  
>   (most recent root certificate, included in Google, Microsoft, and 
> Mozilla)
>   - 
>   
>   crt.sh 
>   
> <https://crt.sh/?q=04048028BF1F2864D48F9AD4D83294366A828856553F3B14303F90147F5D40EF>
>  
>   (prior root certificate, included in Apple, Microsoft)
>   - 
>
>Use cases served/EKUs: 
>- 
>   
>   Server Authentication 1.3.6.1.5.5.7.3.1
>   - 
>   
>   Client Authentication 1.3.6.1.5.5.7.3.2
>   - 
>
>Certificate Corpus (subCAs and OCSP): here 
>
> <https://search.censys.io/search?resource=certificates=parsed.extensions.authority_key_id%3A+65cdebab351e003e7ed574c01cb473470e1a642f>
>  
>(requires Censys account)
>- 
>
>Included in: Apple, Chrome, Microsoft, Mozilla
>
> Relevant Policy and Practices Documentation: 
>
>- 
>
>Firmaprofesional CPS in English 
>
> <https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-230413-EN-sFP.pdf>,
>  
>version 230413
>- 
>
>Firmaprofesional Website Authentication Certificates CP in English 
>
> <https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CP_Autenticacion_Web-230616-EN-sFP.pdf>,
>  
>version 230616
>
>
> Most Recent Self-Assessmen

Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

[Ben Wilson]

 the trusted services. 
> Deviations from the expected quality KPIs trigger the notification and 
> remediation process of our trained IT personnel during working hours and 
> standby. 
>
> Additionally, manual and automated self-audits are carried out on a 
> quarterly basis against a random percentage of all issued certificates as 
> required.
>
>  
>
> *Auditing* 
>
> e-commerce monitoring GmbH will continue to be evaluated by the auditor 
> “A-SIT Zentrum für sichere Informationstechnologie” – Austria under the 
> eIDAS / ETSI audit scheme.
>
> The most recent audit attestation including auditor’s accreditation scope 
> and team qualification can be found under the provided URl and follows the 
> ACAB-c template in its most recent version: 
> https://www.a-sit.at/wp-content/uploads/2023/05/VIG-23-044_audit-attestation_globaltrust-etsi-2023_final_signed.pdf
>
> The most recent eIDAS conformity assessment report can be found here:  
> https://service.globaltrust.eu/static/conformity-assessment-2023.pdf
>
> Here is a quick bottom-up way to reproduce the auditor's qualifications:
>
>
>-  Accreditation scope A-SIT: 
>https://akkreditierung-austria.gv.at/overview  (see A-SIT)
>-  Notification of  A-SIT as CAB: (Name “Zentrum für sichere 
>Informationstechnologie – Austria“ Acronym: “A-SIT”)
>-  Notification of Akkreditierung Austria as NAB: 
>https://eidas.ec.europa.eu/efda/browse/notification/cab-nab
>- Accreditation / “Akkreditierung Austria” at EA: 
>
> https://european-accreditation.org/ea-members/directory-of-ea-members-and-mla-signatories/
>
> A-SIT has been recorded as auditor in the CCADB with Audit Firm Confidence 
> Status as evaluated by Root Store Managers “High” 
> https://ccadb.my.site.com/s/detail/a0F1J1ICCfqUAH  
> <https://ccadb.my.site.com/s/detail/a0F1J1ICCfqUAH>
>
>
> On Thursday, February 8, 2024 at 1:19:33 PM UTC+1 e-commerce monitoring 
> wrote:
>
>> Dear All,
>>
>> e-commerce monitoring GmbH is now 100% subsidiary of AUSTRIA 
>> CARD-Plastikkarten und Ausweissysteme Gesellschaft m.b.H., which is 
>> classified as “große Kapitalgesellschaft” (large corporation) and therefore 
>> needs to comply with all regulations of the Austrian GmbHG (limited 
>> liabilities company Act) and UGB (Commercial Code).
>>
>> e-commerce monitoring GmbH was taken over as a fully functional and 
>> independent entity inside the AUSTRIA CARD group of companies. The 
>> certified policies, processes and commitments of e-commerce monitoring GmbH 
>> continue to apply.
>>
>> The takeover of the company also includes the taking over of the 
>> established staff which results in no changes except top management and 
>> e-commerce monitoring GmbH will continue to adhere and operate according to 
>> the respective policies.
>>
>> Best regards,
>> Daniel
>>
>> On Wednesday, February 7, 2024 at 12:22:36 AM UTC+1 Ben Wilson wrote:
>>
>>> Hi Aaron,
>>>
>>> On Tue, Feb 6, 2024 at 3:00 PM Aaron Gable  
>>> wrote:
>>>
>>>> e-commerce monitoring GmbH currently has multiple open bugzilla tickets 
>>>> which have not had any updates from their staff in multiple months:
>>>> - https://bugzilla.mozilla.org/show_bug.cgi?id=1815534
>>>> - https://bugzilla.mozilla.org/show_bug.cgi?id=1862004
>>>>
>>>
>>> Correct - the questions raised by these incidents still need to be 
>>> answered.
>>>  
>>>
>>>> Does the behavior of the CA being acquired factor into decisions like 
>>>> this, or just the behavior of the acquiring entity? 
>>>>
>>>
>>> The behavior of the entity being acquired and the capabilities and 
>>> history of the acquiring company are relevant, going back for an 
>>> unspecified period of time. (Factors to be considered in deciding how far 
>>> to go back include the nature and severity of any non-compliance and the 
>>> degree to which any incidents reveal persistent, systemic problems.) 
>>>  
>>>
>>>> If a distrust conversation were to arise in the future, how do root 
>>>> programs ensure that bugs filed under previous corporate names are still 
>>>> included in the analysis?
>>>>
>>>
>>> We have not experienced a lot of M/name-change activity recently. I 
>>> believe the Mozilla Community has sufficient continuity, institutional 
>>> memory, and community-based knowledge about the history of CA operators. 
>>> So, I think this concern can be handled wh

Re: [Servercert-wg] [Voting Period Begins]: SC65: Convert EVGs into RFC 3647 format v2

[Ben Wilson via Servercert-wg]

Mozilla votes "yes" on Ballot SC-65 - Convert EVGs to RFC 3647 format

On Mon, Mar 4, 2024 at 8:33 AM Inigo Barreira via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> *Summary: *
>
> The Extended Validation Certificates guidelines (EVGs) were developed and
> written in a specific format. Since then, the RFC 3647 has been the basis
> (and the de-facto standard) for the CA/Browser Forum to develop other
> documents.
>
> This ballot aims to update the EVGs to follow the RFC 3647 format without
> changing any content, just moving current sections to those defined in the
> RFC 3647. There are no normative requirements changes.
>
> This change also affects the Baseline Requirements for TSL certificates
> (BRs) which needs to point to the new sections of the EVGs. Both documents
> will be updated according to the latest version published.
>
> This ballot is proposed by Iñigo Barreira (Sectigo) and endorsed by Pedro
> Fuentes (OISTE) and Ben Wilson (Mozilla).
>
> --- Motion Begins ---
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted TLS Certificates" ("TLS Baseline
> Requirements"), based on Version 2.0.2 and the “Guidelines for the Issuance
> and Management of Extended Validation Certificates” (EVGs) based on Version
> 1.8.0.
>
> MODIFY the TLS EVGs and BRs as specified in the following Redline:
>
> Comparing
> 90a98dc7c1131eaab01af411968aa7330d315b9b...dedeebfe036fa5a6f0d7ae985ea08317ba60b8cb
> · cabforum/servercert (github.com)
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2F90a98dc7c1131eaab01af411968aa7330d315b9b...dedeebfe036fa5a6f0d7ae985ea08317ba60b8cb=05%7C02%7Cinigo.barreira%40sectigo.com%7C864b0df3402c4c71a48308dc3235d77c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638440454045736811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=9dyuwM9JFeGMUk4fRNcFdaLuNlOwQGoDI0XmWGbD%2BQE%3D=0>
>
> --- Motion Ends ---
>
> This ballot proposes a Final Maintenance Guideline for the BRs and EVGs.
> The procedure for approval of this ballot is as follows:
>
> Discussion (at least 7 days)
>
>1. Start time: 2024-02-20 17:00:00 UTC
>2. End time: not before 2024-03-04 15:00:00 UTC
>
> Vote for approval (7 days)
>
>1. Start time: 2024-03-04 15:30:00 UTC
>2. End time: 2024-03-11 15:30:00 UTC
>
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [Voting Period Begins]: SC-69v3 Clarify router and firewall logging requirements

[Ben Wilson via Servercert-wg]

Mozilla votes "yes" on Ballot SC-69v3 - Clarify router and firewall logging
requirements.

On Mon, Mar 4, 2024 at 3:59 AM Martijn Katerbarg via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> *Summary: *
>
> This ballot aims to clarify what data needs to be logged as part of the
> "Firewall and router activities" logging requirement in the Baseline
> Requirements.
>
> This ballot is proposed by Martijn Katerbarg (Sectigo) and endorsed by
> Daniel Jeffery (Fastly) and Ben Wilson (Mozilla).
>
> --- Motion Begins ---
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates" ("Baseline Requirements"),
> based on Version 2.0.2.
>
> MODIFY the Baseline Requirements as specified in the following Redline:
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...d5bd141e14de098ff00c10de7cf500668cbc6843
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2F41f01640748fa612386f8b1a3031cd1bff3d4f35...d5bd141e14de098ff00c10de7cf500668cbc6843=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C5eccf95fe1f248a869b808dc369891e2%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638445276113081044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=MRsVWWShRU8P7UpEJqlCypru27QkzR2BCFu0sUX1Xkw%3D=0>
>
> --- Motion Ends ---
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
> Discussion (at least 7 days)
>
>1. Start time: 2024-02-26 07:00:00 UTC
>2. End time: 2024-03-04 11:00:00 UTC
>
> Vote for approval (7 days)
>
>1. Start time: 2024-03-04 11:00:00 UTC
>2. End time: 2024-03-11 11:00:00 UTC
>
>
>
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

[kid3] [Bug 481394] Ability to sort search results in the import screen

[Ben Wilson-Hill]

https://bugs.kde.org/show_bug.cgi?id=481394

--- Comment #4 from Ben Wilson-Hill  ---
I can live with that my friend - sounds like it would involve a fairly
significant rewrite. I wish it was something I could help you with.

Thanks for the tip with the URL search though. I can't get it to work with or
without the API key, but I'll experiment some more. I'm sure it's something I'm
missing

Kid3 is still easily the best tagger I've used, so thank you for your efforts
mate.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kid3] [Bug 481394] Ability to sort search results in the import screen

[Ben Wilson-Hill]

https://bugs.kde.org/show_bug.cgi?id=481394

--- Comment #2 from Ben Wilson-Hill  ---
(In reply to Urs Fleisch from comment #1)
> The import results are sorted in exactly the order of the tracks. This order
> is fixed. The import results can be reordered by using the "Match with:"
> buttons or by drag'n'drop of rows. This concept does not allow another sort
> order. Normally it shouldn't be a problem to keep track of the results, as
> they only contain the tracks from a single album.

Thank you Urs. I should've been more specific sorry. The track-listing is quite
manageable, it's the album list I find I have the problem. If it could show
maybe a little more information - eg. Country of release, or something like
that, that could make identifying the specific release  more efficient is what
I was thinking. Or even the ability to search against release number could be a
good solution?!

Just to give you an idea, I was looking up "In Utero" by Nirvana. There are
over 400 entries in Discogs, and adding more search terms in Kid3, I can
eliminate most irrelevant results. I can find the details on the website, but
matching it against the search results in Kid3 can be a bit tedious in cases
like these. Just a way to sort those results more easily would be great. Let me
know if some screenshots could be useful.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kid3] [Bug 481394] New: Ability to sort search results in the import screen

[Ben Wilson-Hill]

https://bugs.kde.org/show_bug.cgi?id=481394

Bug ID: 481394
   Summary: Ability to sort search results in the import screen
Classification: Applications
   Product: kid3
   Version: 3.9.x
  Platform: Arch Linux
OS: Linux
Status: REPORTED
  Severity: wishlist
  Priority: NOR
 Component: general
  Assignee: uflei...@users.sourceforge.net
  Reporter: b...@wilsonhill.au
  Target Milestone: ---

When importing album details, from Discogs as an example, the results appear to
be parsed into more of a description field, and the list is not sorted in a
logical manner.

Could we introduce perhaps more of a table layout, with the ability to sort
results by columns e.g. Name, Title, Date? It would make sorting through the
results and little easier.

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [Servercert-wg] [Voting Period Begins] SC-070: Clarify the use of DTPs for Domain Control Validation

[Ben Wilson via Servercert-wg]

Mozilla votes "yes" to Ballot SC-070.

On Tue, Feb 13, 2024 at 9:56 AM Aaron Gable via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> This new voting period is to fix a typo in the End timestamp of the voting
> period for the previous version of this ballot. The contents of the motion
> itself are identical. My apologies for the confusion.
>
> This ballot aims to clarify the existing language around the use of
> delegated third-parties during domain and IP address control validation. It
> leaves the existing language in place, and adds specifics for the cases of
> DNS queries, WHOIS lookups, and contact with the Domain Name Registrat or
> IP Address Registration Authority.
>
> Additionally, it places these same restrictions on CAA checking, with an
> effective date of 2024-05-15.
>
> This ballot is proposed by Aaron Gable (ISRG / Let's Encrypt) and endorsed
> by Mads Henriksveen (Buypass) and Dimitris Zacharopoulos (HARICA). You can
> view and comment on the github pull request representing this ballot here:
> https://github.com/cabforum/servercert/puhttps://lists.cabforum.org/pipermail/servercert-wg/2024-February/004174.htmlll/475
> 
>
> The preceding discussion can be seen here:
> https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004174.html
>
> --- Motion Begins ---
>
> This ballot modifies the "Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates" ("Baseline Requirements")
> based on Version 2.0.2
>
> MODIFY the Baseline Requirements as specified in the following redline:
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...00ea6e24c474fd0ab6eecc25cb8eb733fffc60c3
>
> --- Motion Ends ---
>
> Discussion (at least 7 days):
> - Start: 2024-02-02 22:30 UTC
> - End: 2024-02-12 22:30 UTC
>
> Vote for approval (7 days):
> - Start: 2024-02-13 17:00 UTC
> - End: 2024-02-20 17:00 UTC
>
> Thanks,
> Aaron
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Seeking endorsers: SC-065: Convert EVGs into RFC 3647 format pre-ballot

[Ben Wilson via Servercert-wg]

I'm willing to endorse.

On Thu, Feb 8, 2024 at 10:52 AM Inigo Barreira via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Hi,
>
>
>
> As mentioned in the past SCWG call, I´m looking for 2 endorsers for this
> ballot.
>
>
>
> Regards
>
>
>
> *De:* Servercert-wg  *En nombre de *Inigo
> Barreira via Servercert-wg
> *Enviado el:* viernes, 19 de enero de 2024 13:28
> *Para:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>; Dimitris Zacharopoulos (HARICA) <
> dzach...@harica.gr>; Bruce Morton ; Tim
> Hollebeek 
> *Asunto:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format
> pre-ballot
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hi all,
>
>
>
> As per yesterday´s SCWG call, I´ve also updated the BRs with the new
> section numbers of the EVG. Only 2 sections have been affected and
> therefore updated.
>
> Section 3.2.2.4.7
>
> EVG 11.14.3 à 3.2.2.14.3
>
>
>
> Section 7.1.2.7.5
>
> EVG 9.2 à 7.1.4.2
>
>
>
> You can find all the information in the PR 440, EVGs based on RFC3647 by
> barrini · Pull Request #440 · cabforum/servercert (github.com)
> 
>
> First, I had to update the current version of the BRs I was working with
> (2.0.0) to the current one (2.0.2) and then make the changes to the newest
> one.
>
>
>
> Regards
>
>
>
> *De:* Inigo Barreira 
> *Enviado el:* viernes, 15 de diciembre de 2023 12:42
> *Para:* Inigo Barreira ; CA/B Forum Server
> Certificate WG Public Discussion List ;
> Dimitris Zacharopoulos (HARICA) ; Bruce Morton <
> bruce.mor...@entrust.com>; Tim Hollebeek 
> *Asunto:* RE: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format
> pre-ballot
>
>
>
> Hi everyone
>
>
>
> As per last week discussion during the SCWG, we agreed to follow section 6
> of the RFC 3647 for the new EVG format.
>
> With that in mind, I´ve updated the correspondent PR (#440) to reflect it
> that way, so:
>
>- Changed section 1.1 name from scope to overview
>- Created a new section 3.2.1 for possession of the private key
>- Moved all the other stuff of the old section 11 to a “new” section
>3.2.2 for organization identity.
>- Also created the remaining ones, 3.2.3, 3.2.4, etc.
>- Update section 8 removing section 8.1 and renumbering the others and
>putting the self audits under 8.1 and leaving section 8.7 for readiness
>audits because don´t know where it can fit better (this section does not
>exist in RFC 3647 section 6)
>- Checked all links
>
>
>
> In any case, see the comparison here: Comparing
> 90a98dc7c1131eaab01af411968aa7330d315b9b...238ff99fbe04f2aa24f2c58910d8133f2283f11e
> · cabforum/servercert (github.com)
> 
>
>
>
> If you´re ok with this change, we can move forward a propose the ballot
> for which I´ll need 2 endorsers.
>
>
>
> Regards
>
>
>
> *De:* Servercert-wg  *En nombre de *Inigo
> Barreira via Servercert-wg
> *Enviado el:* jueves, 7 de diciembre de 2023 13:08
> *Para:* Dimitris Zacharopoulos (HARICA) ; Bruce
> Morton ; CA/B Forum Server Certificate WG
> Public Discussion List ; Tim Hollebeek <
> tim.holleb...@digicert.com>
> *Asunto:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format
> pre-ballot
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hi there,
>
>
>
> See the comparing one.
>
> Comparing
> 90a98dc7c1131eaab01af411968aa7330d315b9b...13b4f85a494fefa52510512a2fb3c4d7c77a7a36
> · cabforum/servercert (github.com)
> 

Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

[Ben Wilson]

Hi Aaron,

On Tue, Feb 6, 2024 at 3:00 PM Aaron Gable  wrote:

> e-commerce monitoring GmbH currently has multiple open bugzilla tickets
> which have not had any updates from their staff in multiple months:
> - https://bugzilla.mozilla.org/show_bug.cgi?id=1815534
> - https://bugzilla.mozilla.org/show_bug.cgi?id=1862004
>

Correct - the questions raised by these incidents still need to be answered.


> Does the behavior of the CA being acquired factor into decisions like
> this, or just the behavior of the acquiring entity?
>

The behavior of the entity being acquired and the capabilities and history
of the acquiring company are relevant, going back for an unspecified period
of time. (Factors to be considered in deciding how far to go back include
the nature and severity of any non-compliance and the degree to which any
incidents reveal persistent, systemic problems.)


> If a distrust conversation were to arise in the future, how do root
> programs ensure that bugs filed under previous corporate names are still
> included in the analysis?
>

We have not experienced a lot of M/name-change activity recently. I
believe the Mozilla Community has sufficient continuity, institutional
memory, and community-based knowledge about the history of CA operators.
So, I think this concern can be handled when needed with comments from
community members, and changes in the names of CA operators should not
require that we create a new tracking solution. (If incidents are
sufficiently recent or still have relevance, then we could update the
Bugzilla bugs "Summaries" by replacing the name of the previous operator
with the name of the new entity when there is a name change or CA operator
replacement.)

Ben


>
> Thanks,
> Aaron
>
> On Fri, Feb 2, 2024 at 5:25 PM Ben Wilson  wrote:
>
>> Dear Suchan,
>> You make a valid point. However, in this case, I wasn't sure how other
>> root stores would be handling this. They may have their own processes.
>> Also, the distribution on this list is almost 3x greater than on the CCADB
>> public list, so I decided to post the discussion here.
>> If the other root stores want to have a public discussion of this
>> acquisition, then we can start a discussion on CCADB Public, too.
>> Sincerely yours,
>> Ben
>>
>> On Fri, Feb 2, 2024 at 5:53 PM Suchan Seo  wrote:
>>
>>>  While not have knowledge to comment about acquire itself, doesn't this
>>> more fit to ccadb mailing list? I thought root store policy about
>>> individual root was moved to there
>>> 2024년 2월 3일 토요일 오전 1시 45분 19초 UTC+9에 Ben Wilson님이 작성:
>>>
>>>> All,
>>>>
>>>> Recently we were advised that e-commerce monitoring GmbH is being
>>>> acquired by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH.
>>>>
>>>> e-commerce monitoring operates the GLOBALTRUST 2020 root CA that is
>>>> included in the Mozilla root store. They have advised us of the following:
>>>>
>>>> There are no changes to the operation of the CA and RA functions.
>>>>
>>>> Changes to the corporate structure:
>>>>
>>>> - New shareholder:
>>>> AUSTRIA CARD-Plastikkarten und Ausweissysteme Gesellschaft m.b.H.
>>>> registered under the number FN 98272v commercial court Vienna
>>>> Lamezanstraße 4-8
>>>> 1230 Vienna, Austria
>>>> https://www.austriacard.com/
>>>>
>>>> - New Management
>>>> new: CEO ("Geschäftsführer") Mr. Emmanouil Kontos
>>>> new: Attorney ("Prokurist") Mr. Markus Kirchmayr
>>>> old: CEO Hans Zeger
>>>>
>>>> - Registered headquarter
>>>> new: Handelskai 388/621, 1020 Vienna, Austria
>>>> old: Redtenbachergasse 20, 1160 Vienna, Austria
>>>>
>>>> According to section 8.1 of the Mozilla Root Store Policy, “If the
>>>> receiving or acquiring company is new to the Mozilla root store, it MUST
>>>> demonstrate compliance with the entirety of this policy. There MUST be a
>>>> public discussion regarding its admittance to the root store. If Mozilla
>>>> reaches a positive conclusion after public discussion, then the affected
>>>> certificate(s) MAY remain in the root store.”
>>>>
>>>> By this email, I am initiating a four-week public discussion period,
>>>> scheduled to close on Friday, 1-March-2024, to allow for at least three
>>>> full weeks of public discussion. The first week (Feb. 5 – 9) is intended to
>>>> give the acquiring company time to address the following topics:
>>>>
>>>>

Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

[Ben Wilson]

Dear Suchan,
You make a valid point. However, in this case, I wasn't sure how other root
stores would be handling this. They may have their own processes. Also, the
distribution on this list is almost 3x greater than on the CCADB public
list, so I decided to post the discussion here.
If the other root stores want to have a public discussion of this
acquisition, then we can start a discussion on CCADB Public, too.
Sincerely yours,
Ben

On Fri, Feb 2, 2024 at 5:53 PM Suchan Seo  wrote:

>  While not have knowledge to comment about acquire itself, doesn't this
> more fit to ccadb mailing list? I thought root store policy about
> individual root was moved to there
> 2024년 2월 3일 토요일 오전 1시 45분 19초 UTC+9에 Ben Wilson님이 작성:
>
>> All,
>>
>> Recently we were advised that e-commerce monitoring GmbH is being
>> acquired by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH.
>>
>> e-commerce monitoring operates the GLOBALTRUST 2020 root CA that is
>> included in the Mozilla root store. They have advised us of the following:
>>
>> There are no changes to the operation of the CA and RA functions.
>>
>> Changes to the corporate structure:
>>
>> - New shareholder:
>> AUSTRIA CARD-Plastikkarten und Ausweissysteme Gesellschaft m.b.H.
>> registered under the number FN 98272v commercial court Vienna
>> Lamezanstraße 4-8
>> 1230 Vienna, Austria
>> https://www.austriacard.com/
>>
>> - New Management
>> new: CEO ("Geschäftsführer") Mr. Emmanouil Kontos
>> new: Attorney ("Prokurist") Mr. Markus Kirchmayr
>> old: CEO Hans Zeger
>>
>> - Registered headquarter
>> new: Handelskai 388/621, 1020 Vienna, Austria
>> old: Redtenbachergasse 20, 1160 Vienna, Austria
>>
>> According to section 8.1 of the Mozilla Root Store Policy, “If the
>> receiving or acquiring company is new to the Mozilla root store, it MUST
>> demonstrate compliance with the entirety of this policy. There MUST be a
>> public discussion regarding its admittance to the root store. If Mozilla
>> reaches a positive conclusion after public discussion, then the affected
>> certificate(s) MAY remain in the root store.”
>>
>> By this email, I am initiating a four-week public discussion period,
>> scheduled to close on Friday, 1-March-2024, to allow for at least three
>> full weeks of public discussion. The first week (Feb. 5 – 9) is intended to
>> give the acquiring company time to address the following topics:
>>
>> ·Compliance with the Mozilla Root Store Policy
>>
>> ·Ownership and governance
>>
>> ·Investment and budget for CA operations, risk management, and
>> compliance
>>
>> ·Community engagement and involvement in industry groups
>>
>> ·Employee expertise and continuity
>>
>> ·Operational design and ongoing GRC management
>>
>> ·Auditors and auditing
>>
>> Thanks,
>>
>> Ben Wilson
>>
>> Mozilla Root Store Program
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabZVUgzo1rbr%3DyP-F0YzWCzjaO1sHKGYp%3DLTtQGzYEKrA%40mail.gmail.com.

Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

[Ben Wilson]

All,

Recently we were advised that e-commerce monitoring GmbH is being acquired
by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH.

e-commerce monitoring operates the GLOBALTRUST 2020 root CA that is
included in the Mozilla root store. They have advised us of the following:

There are no changes to the operation of the CA and RA functions.

Changes to the corporate structure:

- New shareholder:
AUSTRIA CARD-Plastikkarten und Ausweissysteme Gesellschaft m.b.H.
registered under the number FN 98272v commercial court Vienna
Lamezanstraße 4-8
1230 Vienna, Austria
https://www.austriacard.com/

- New Management
new: CEO ("Geschäftsführer") Mr. Emmanouil Kontos
new: Attorney ("Prokurist") Mr. Markus Kirchmayr
old: CEO Hans Zeger

- Registered headquarter
new: Handelskai 388/621, 1020 Vienna, Austria
old: Redtenbachergasse 20, 1160 Vienna, Austria

According to section 8.1 of the Mozilla Root Store Policy, “If the
receiving or acquiring company is new to the Mozilla root store, it MUST
demonstrate compliance with the entirety of this policy. There MUST be a
public discussion regarding its admittance to the root store. If Mozilla
reaches a positive conclusion after public discussion, then the affected
certificate(s) MAY remain in the root store.”

By this email, I am initiating a four-week public discussion period,
scheduled to close on Friday, 1-March-2024, to allow for at least three
full weeks of public discussion. The first week (Feb. 5 – 9) is intended to
give the acquiring company time to address the following topics:

·Compliance with the Mozilla Root Store Policy

·Ownership and governance

·Investment and budget for CA operations, risk management, and
compliance

·Community engagement and involvement in industry groups

·Employee expertise and continuity

·Operational design and ongoing GRC management

·Auditors and auditing

Thanks,

Ben Wilson

Mozilla Root Store Program

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaacDhGOcVgXcKG-nq32bFTdTVutYzAWb8uBzAOreJPv_Q%40mail.gmail.com.

Public Discussion of Firmaprofesional CA Inclusion Request

[Ben Wilson]

All,

This email commences a six-week public discussion of Firmaprofesional’s
request to include the “FIRMAPROFESIONAL CA ROOT-A WEB” as a publicly
trusted root certificate in one or more CCADB Root Store Member’s program.
This discussion period is scheduled to close on March 13, 2024.

The purpose of this public discussion process is to promote openness and
transparency. However, each Root Store makes its inclusion decisions
independently, on its own timelines, and based on its own inclusion
criteria. Successful completion of this public discussion process does not
guarantee any favorable action by any root store.

Anyone with concerns or questions is urged to raise them on this CCADB
Public list by replying directly in this discussion thread. Likewise, a
representative of the applicant must promptly respond directly in the
discussion thread to all questions that are posted.

CCADB Case Number: 1044
;
Bugzilla: 1785215 

Organization Background Information (listed in CCADB):

   -

   CA Owner Name: Autoridad de Certificacion Firmaprofesional;
   Firmaprofesional S.A.
   -

   Website(s): https://www.firmaprofesional.com/
   -

   Address: Passeig de Gracia 50, 2º1º, Barcelona E-08007, Spain
   -

   Problem Reporting Mechanism(s): sopo...@firmaprofesional.com
   -

   Organization Type: Firmaprofesional S.A. is a commercial entity in Spain
   (NIF A62634068)
   -

   Repository URL:
   https://www.firmaprofesional.com/certification-policies-and-practices/

Certificates Requesting Inclusion:

   1.

   FIRMAPROFESIONAL CA ROOT-A WEB:
   -

  Certificate download links: (CA Repository
  , crt.sh
  

  )
  -

  Use cases served/EKUs:
  -

 Server Authentication 1.3.6.1.5.5.7.3.1
 -

 Client Authentication 1.3.6.1.5.5.7.3.2
 -

  Test websites:
  -

 Valid: https://testsslev2022ec.firmaprofesional.com
 -

 Revoked: https://testrevokedsslev2022ec.firmaprofesional.com
 -

 Expired: https://testexpiredsslev2022ec.firmaprofesional.com


Existing Publicly Trusted Root CAs from Firmaprofesional S.A.:

   1.

   Autoridad de Certificacion Firmaprofesional CIF A62634068:


   -

   Certificate download links: CA Repository
    (most recent),
   -

  crt.sh
  

  (most recent root certificate, included in Google, Microsoft, and Mozilla)
  -

  crt.sh
  

  (prior root certificate, included in Apple, Microsoft)
  -

   Use cases served/EKUs:
   -

  Server Authentication 1.3.6.1.5.5.7.3.1
  -

  Client Authentication 1.3.6.1.5.5.7.3.2
  -

   Certificate Corpus (subCAs and OCSP): here
   

   (requires Censys account)
   -

   Included in: Apple, Chrome, Microsoft, Mozilla

Relevant Policy and Practices Documentation:

   -

   Firmaprofesional CPS in English
   
,
   version 230413
   -

   Firmaprofesional Website Authentication Certificates CP in English
   
,
   version 230616


Most Recent Self-Assessment:


   -

   https://bugzilla.mozilla.org/attachment.cgi?id=9369465 (reviewed
   12/19/2023)

Audit Statements:

   -

   Auditor: DEKRA Testing and Certification, S.A.U.
    (accredited by ENAC
   
   )
   -

   Audit Criteria: ETSI
   -

   Date of Audit Issuance: June 1, 2023
   -

   For Period Ending: March 27, 2023
   -

   Audit Statement(s): https://www.dekra.com/media/2302-fpr-fr-aal.pdf

Incident Summary (Bugzilla incidents from previous 24 months):

Bugzilla

Title

Opened

1769240 

Firmaprofesional: 2022 - SSL certificates issued with wrong Organization ID
number 

2022-05-13

1771715 

Firmaprofesional: 2022 - StateorProvince field


2022-05-30

1771722 

Firmaprofesional: 2022 - Title field


2022-05-30

1771724 

Re: [Infrastructure] New cabforum.org website

[Ben Wilson via Infrastructure]

I noticed there may be some YouTube videos on using Hugo with GitHub that
might be helpful, too.
If I see a good one, I'll let you know.
Ben

On Wed, Jan 31, 2024 at 9:09 AM Bruce Morton via Infrastructure <
infrastructure@cabforum.org> wrote:

> Hi Paul,
>
>
>
> The site looks great to me. Thanks for the great work!
>
>
>
>
>
> Bruce.
>
>
>
> *From:* Paul van Brouwershaven 
> *Sent:* Wednesday, January 31, 2024 6:43 AM
> *To:* Dimitris Zacharopoulos (HARICA) ; Bruce Morton <
> bruce.mor...@entrust.com>; Dean Coclin ; Inigo
> Barreira ; Stephen Davidson <
> stephen.david...@digicert.com>; Kiran Tummala ;
> Martijn Katerbarg ; Clint Wilson <
> cli...@apple.com>; David Kluge ; Paul van Brouwershaven
> 
> *Cc:* infrastructure@cabforum.org
> *Subject:* Re: New cabforum.org website
>
>
>
> If everyone is ok with the documentation and new website I suggest to
> switch to the new website to avoid any further divergence.
>
>
> --
>
> *From:* Infrastructure  on behalf of
> Paul van Brouwershaven via Infrastructure 
> *Sent:* Monday, January 29, 2024 12:58
> *To:* Dimitris Zacharopoulos (HARICA) ; Bruce Morton <
> bruce.mor...@entrust.com>; Dean Coclin ; Inigo
> Barreira ; Stephen Davidson <
> stephen.david...@digicert.com>; Kiran Tummala ;
> Martijn Katerbarg ; Clint Wilson <
> cli...@apple.com>; David Kluge 
> *Cc:* infrastructure@cabforum.org 
> *Subject:* [EXTERNAL] [Infrastructure] New cabforum.org website
>
>
>
> *WARNING: This email originated outside of Entrust.*
>
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
>
>
>
> Dear Chairs, Vice chairs and Infrastructure Committee,
>
>
>
> As discussed during some infrastructure calls and the last forum meeting I
> have been working on a new, more automated, website:
>
>
>
> https://cabforum.github.io/cabforum.org/
> 
>
>
>
> The content in this website is written in Markdown and some information is
> automatically pulled based on tags from other pages, directly from the
> Member Tools, GitHub content, issues and pull requests, etc.
>
>
>
> This includes the automatic publication and update of
> requirements/guidelines, charters, working group members, etc.
>
>
>
> Also ballots in draft, in discussion or IPR or those that have recently
> passed can be automatically shown based on the labels and status of GitHub
> pull requests. We do need to agree on the usage of some labels and probably
> create a pull request template, but this can be done after the new website
> is live.
>
>
>
> The latest releases is based on GitHub releases (only the S/MIME working
> group is using that currently). I have also been working on an update to
> the GitHub actions that build our guidelines to improve our release
> management, also this can be finished after the new website is live.
>
>
>
> *Instructions*
>
>
>
> I have created a website chapter on the wiki with some instructions and
> screenshots on how you can add pages, upload files, etc.:
>
>
>
> https://wiki.cabforum.org/books/forum/chapter/website
> 
>
>
>
> Please let me know if you have any questions or concerns about this new
> website and let me know if the instructions are sufficient and clear.
>
>
>
> I'm adding all new pages from the old website manually, but I would rather
> like to spend my time on further improvements and would there like to get
> your feedback and if there is anything that holds us back from switching to
> this new website.
>
>
>
> *Please let me know if you see any issues and if it's ok for you to switch
> or not!*
>
>
>
> Paul
>
>
>
> *Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.*
> ___
> Infrastructure mailing list
> Infrastructure@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
>
___
Infrastructure mailing list
Infrastructure@cabforum.org
https://lists.cabforum.org/mailman/listinfo/infrastructure

Re: [Infrastructure] New cabforum.org website

[Ben Wilson via Infrastructure]

Hi,
I'll take a look at the instructions later today, but as a general matter,
I think it is fine to switch the website over sooner rather than later.
Ben

On Wed, Jan 31, 2024 at 4:44 AM Paul van Brouwershaven via Infrastructure <
infrastructure@cabforum.org> wrote:

> If everyone is ok with the documentation and new website I suggest to
> switch to the new website to avoid any further divergence.
>
> --
> *From:* Infrastructure  on behalf of
> Paul van Brouwershaven via Infrastructure 
> *Sent:* Monday, January 29, 2024 12:58
> *To:* Dimitris Zacharopoulos (HARICA) ; Bruce Morton <
> bruce.mor...@entrust.com>; Dean Coclin ; Inigo
> Barreira ; Stephen Davidson <
> stephen.david...@digicert.com>; Kiran Tummala ;
> Martijn Katerbarg ; Clint Wilson <
> cli...@apple.com>; David Kluge 
> *Cc:* infrastructure@cabforum.org 
> *Subject:* [EXTERNAL] [Infrastructure] New cabforum.org website
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
>
> Dear Chairs, Vice chairs and Infrastructure Committee,
>
> As discussed during some infrastructure calls and the last forum meeting I
> have been working on a new, more automated, website:
>
> https://cabforum.github.io/cabforum.org/
> 
>
> The content in this website is written in Markdown and some information is
> automatically pulled based on tags from other pages, directly from the
> Member Tools, GitHub content, issues and pull requests, etc.
>
> This includes the automatic publication and update of
> requirements/guidelines, charters, working group members, etc.
>
> Also ballots in draft, in discussion or IPR or those that have recently
> passed can be automatically shown based on the labels and status of GitHub
> pull requests. We do need to agree on the usage of some labels and probably
> create a pull request template, but this can be done after the new website
> is live.
>
> The latest releases is based on GitHub releases (only the S/MIME working
> group is using that currently). I have also been working on an update to
> the GitHub actions that build our guidelines to improve our release
> management, also this can be finished after the new website is live.
>
> *Instructions*
>
> I have created a website chapter on the wiki with some instructions and
> screenshots on how you can add pages, upload files, etc.:
>
> https://wiki.cabforum.org/books/forum/chapter/website
> 
>
> Please let me know if you have any questions or concerns about this new
> website and let me know if the instructions are sufficient and clear.
>
> I'm adding all new pages from the old website manually, but I would rather
> like to spend my time on further improvements and would there like to get
> your feedback and if there is anything that holds us back from switching to
> this new website.
>
> *Please let me know if you see any issues and if it's ok for you to switch
> or not!*
>
> Paul
>
> *Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.*
> ___
> Infrastructure mailing list
> Infrastructure@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
>
___
Infrastructure mailing list
Infrastructure@cabforum.org
https://lists.cabforum.org/mailman/listinfo/infrastructure

Re: [Servercert-wg] Voting Begins for Ballot SC-68: Allow VATEL and VATXI for organizationIdentifier

[Ben Wilson via Servercert-wg]

Mozilla votes "Yes" to Ballot SC-68.

On Tue, Jan 23, 2024 at 2:00 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

> This email initiates the voting period for ballot SC-68. Please vote.
>
>
> Purpose of the Ballot
>
> The EV Guidelines have strict rules in the organizationIdentifier values
> and require the country code of all currently-allowed Registration Schemes
> (NTR, VAT, PSD) to follow the ISO 3166-1 for the 2-letter country prefix.
>
> The organizationIdentifier language mainly came from ETSI EN 319 412-1 and
> then the SCWG made several modifications. However, there is an exception
> for Greece specifically for the VAT Registration Scheme that is aligned
> with Article 215 of Council Directive 2006/112/EC
> <https://eur-lex.europa.eu/eli/dir/2006/112/oj> that allows Greece to use
> the country prefix "EL". In practice, Greece uses the prefix "EL" to
> identify itself next to the VAT number of all Legal Entities
> registered/incorporated/established in Greece, and all other European
> Countries use this prefix to identify Greek VAT numbers. This can easily be
> verified in the VIES VAT number validation website
> <https://ec.europa.eu/taxation_customs/vies/#/vat-validation> where
> Greece is listed as"EL".
>
> There is also Council Directive 2020/1756
> <https://data.europa.eu/eli/dir/2020/1756/oj> amending Directive
> 2006/112/EC that requires the prefix "XI" for the identification of taxable
> persons in Northern Ireland.
>
> This pull request <https://github.com/cabforum/servercert/pull/473>
> proposes updates to the EV Guidelines to allow those additional prefixes.
> It also fixes some formatting issues.
>
> The following motion has been proposed by Dimitris Zacharopoulos of HARICA
> and endorsed by Ben Wilson of Mozilla and Corey Bonnell of Digicert.
>
> MOTION BEGINS
>
> This ballot modifies the “Guidelines for the Issuance and Management of
> Extended Validation Certificates” (“EV Guidelines”), based on Version 1.8.0.
>
> MODIFY the EV Guidelines as specified in the following Redline:
>
>-
>
> https://github.com/cabforum/servercert/compare/da89d0e9700c6dd89a8263526addc39f472bf54c
>.
>
> MOTION ENDS
> The procedure for this ballot is as follows:
>
>
> *Start time (8:00 UTC)* *End time (8:00 UTC)*
> Discussion (at least 7 days) 2024-01-16 2024-01-23
> Expected Vote for approval (7 days) 2024-01-23
> 2024-01-30
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: CCADB Self-Assessment - Version 1.3 Released

[Ben Wilson]

Hello Antti,
That was a typo.  Thank you for spotting that for us. It has been corrected
to 1.7.
Thanks again,
Ben

On Wed, Jan 17, 2024 at 10:26 PM 'Antti Backman' via CCADB Public <
public@ccadb.org> wrote:

> Where can we obtain the NCSSR v1.8 which is referenced by the new
> Self-Assessment v 1.3? Could not find it from cabforum.org?
>
> BR, Antti
>
> keskiviikko 17. tammikuuta 2024 klo 20.39.38 UTC+2 Ben Wilson kirjoitti:
>
>> Greetings all,
>>
>>
>> The CCADB Steering Committee has updated the CCADB Self-Assessment to Version
>> 1.3
>> <https://docs.google.com/spreadsheets/d/1Kx9bwMdEnFG5INBpJJLjP2RAsFYyx055zCRfL6ClkcI>.
>> Additionally, CCADB.org has been updated
>> <https://www.ccadb.org/cas/self-assessment> to include version history
>> for the CCADB Self-Assessment.
>>
>>
>> This version of the Self Assessment includes updates for:
>>
>>
>>-
>>
>>Instructions for Cover Sheet (pointing to CCADB's "CA Hierarchy"
>>report that can be used to enumerate CAs covered by this Self-Assessment.)
>>-
>>
>>Mozilla Compliance Self-Assessment (now reflects MRSP Version 2.9
>>requirements)
>>-
>>
>>Chrome Root Program Policy v. 1.5 Self-Assessment (from Version 1.4)
>>-
>>
>>CCADB policy v 1.3 Self-Assessment (from Version 1.2.1)
>>-
>>
>>TLS BRs v 2.0.2 (from Version 2.0.0)
>>
>>
>> Thank you,
>>
>> Ben Wilson, on behalf of the CCADB Steering Committee
>>
> --
> You received this message because you are subscribed to the Google Groups
> "CCADB Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to public+unsubscr...@ccadb.org.
> To view this discussion on the web visit
> https://groups.google.com/a/ccadb.org/d/msgid/public/4875c15d-6ac9-4fb4-8251-d07cfbef5fe3n%40ccadb.org
> <https://groups.google.com/a/ccadb.org/d/msgid/public/4875c15d-6ac9-4fb4-8251-d07cfbef5fe3n%40ccadb.org?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to public+unsubscr...@ccadb.org.
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtabPuDOSBf2E95acRVvgJcJoxep%3D_GMy-Y6Gm23xHyHrUA%40mail.gmail.com.

CCADB Self-Assessment - Version 1.3 Released

[Ben Wilson]

Greetings all,


The CCADB Steering Committee has updated the CCADB Self-Assessment to Version
1.3
<https://docs.google.com/spreadsheets/d/1Kx9bwMdEnFG5INBpJJLjP2RAsFYyx055zCRfL6ClkcI>.
Additionally, CCADB.org has been updated
<https://www.ccadb.org/cas/self-assessment> to include version history for
the CCADB Self-Assessment.


This version of the Self Assessment includes updates for:


   -

   Instructions for Cover Sheet (pointing to CCADB's "CA Hierarchy" report
   that can be used to enumerate CAs covered by this Self-Assessment.)
   -

   Mozilla Compliance Self-Assessment (now reflects MRSP Version 2.9
   requirements)
   -

   Chrome Root Program Policy v. 1.5 Self-Assessment (from Version 1.4)
   -

   CCADB policy v 1.3 Self-Assessment (from Version 1.2.1)
   -

   TLS BRs v 2.0.2 (from Version 2.0.0)


Thank you,

Ben Wilson, on behalf of the CCADB Steering Committee

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to public+unsubscr...@ccadb.org.
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaZ%3Dop7Tx1iKrDKidyrGcNP2M-JXZPGXO9XmkQJTjmA2%2Bg%40mail.gmail.com.

Re: [Smcwg-public] Voting period begins for SMC-05: Adoption of CAA for S/MIME

[Ben Wilson via Smcwg-public]

Mozilla votes "yes" on Ballot SMC-005.

On Wed, Jan 10, 2024 at 4:32 PM Corey Bonnell via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> *Ballot SMC05: Adoption of CAA for S/MIME*
>
>
>
> *Purpose of Ballot:*
>
>
>
> The ballot proposes changes to the S/MIME Baseline Requirements to
> introduce the use of Certification Authority Authorization (CAA) Processing
> for Email Addresses as defined in RFC 9495. It also includes minor
> typographic corrections.
>
>
>
> The following motion has been proposed by Corey Bonnell of DigiCert and
> endorsed by Dimitris Zacharopoulos of HARICA and Ben Wilson of Mozilla.
>
>
>
> *— MOTION BEGINS —*
>
>
>
> This ballot modifies Version 1.0.2 of the “Baseline Requirements for the
> Issuance and Management of Publicly-Trusted S/MIME Certificates” (“S/MIME
> Baseline Requirements”) resulting in Version 1.0.3.
>
>
>
> The proposed modifications to the S/MIME Baseline Requirements may be
> found at
> https://github.com/cabforum/smime/compare/5fb2a7ee94d1c5684d5f32af11572e8c10cd2f8c...1fbbdc8f908e6eba779b4ea0de1cbfd20e156c3a
> <https://url.avanan.click/v2/___https:/github.com/cabforum/smime/compare/5fb2a7ee94d1c5684d5f32af11572e8c10cd2f8c...1fbbdc8f908e6eba779b4ea0de1cbfd20e156c3a___.YXAzOmRpZ2ljZXJ0OmE6bzowYjJjZTA4YzA2Mjg2MTNmZDY2ZDc0ZjE4YjZlMzY5NDo2OmE4NGY6MDAyNmY1Nzc0ZWY2MjBjNzhmYjM4MDc2MGE3MjE5ZDEzMGRkODY5Y2U1NTEzYmY5MTc3NDc5OTRlZjdjZTNjOTpoOkY>
>
>
>
> The SMCWG Chair or Vice-Chair is permitted to update the Relevant Dates
> and Version Number of the S/MIME Baseline Requirements to reflect final
> dates.
>
>
>
> *— MOTION ENDS —*
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
>
> Discussion (7 days)
>
> Start Time: Wednesday January 3, 2024 18:00 UTC
>
> End Time: Wednesday January 10, 2024 23:30 UTC
>
>
>
> Vote for approval (7 days)
>
> Start Time: January 10, 2024 23:30 UTC
>
> End Time: January 17, 2024 23:30 UTC
>
>
>
> IPR Review (30 days)
>
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: Seeking the public discussion of Algerian Root CA

[Ben Wilson]

Dear Peter,

It appears that there is a root CA certificate inclusion case open in the
CCADB, with information viewable here:
https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=1010

As you can see, some of the required information has not been populated
yet.

However, there is an "Add/Update Root Request" case open, too, Case #1444,
last edited in July 2023, but the information in that case is not complete
either and needs to be updated, and that case has not been submitted yet
for review and synchronization with the CCADB.

As stated in the Bugzilla bug you referenced, here is some guidance on the
root inclusion process used by Mozilla:
https://wiki.mozilla.org/CA/Application_Process.  Each root store has its
own separate inclusion process.

For assistance on a variety of topics related to Mozilla's CA program,
visit this web page:  https://wiki.mozilla.org/CA.

Sincerely yours,
Ben Wilson



On Wed, Jan 10, 2024 at 8:29 AM Peter Mate Erdosi  wrote:

> Hello all,
>
> thank you for being here.
>
> I seek the details of the public discussion of Algerian Root CA inclusion.
>
> I found only this: https://bugzilla.mozilla.org/show_bug.cgi?id=1736904
>
> Could somebody help me where can I find the details of this inclusion
> process if exists?
>
> Thank you in advance!
>
> Best Regards,
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "CCADB Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to public+unsubscr...@ccadb.org.
> To view this discussion on the web visit
> https://groups.google.com/a/ccadb.org/d/msgid/public/CADuWVBXsFqjXA6g-2gkDf%3D520eWRNB57OCVWWrx9cAwjAc%3DqRg%40mail.gmail.com
> <https://groups.google.com/a/ccadb.org/d/msgid/public/CADuWVBXsFqjXA6g-2gkDf%3D520eWRNB57OCVWWrx9cAwjAc%3DqRg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to public+unsubscr...@ccadb.org.
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaav7VWy7MFLWTFqo-%3DQXkh7%3DRhrbJGJGLECRreXZqJF-A%40mail.gmail.com.

Re: known bad certs blocklist

[Ben Wilson]

Hello Jan,
This OneCRL list might be what you are looking for -
https://crt.sh/mozilla-onecrl.
Ben

On Tue, Jan 9, 2024 at 9:17 AM 'Jan Schaumann' via
dev-security-policy@mozilla.org  wrote:

> Hello,
>
> Is there a community-shared blocklist of known bad
> certs (keys)?
>
> Chrome has
>
> https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/blocklist/README.md
>
> Apple / Safari has
> https://support.apple.com/en-us/103255
>
> I don't recall if Firefox has a list?
>
> Either way, it would be useful to have a community
> shared list of known compromised keys or otherwise
> revoked roots or intermediates.  Does that already
> exist?
>
> -Jan
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-policy+unsubscr...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZZ1xe9_3hGFovkqT%40netmeister.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabK%2B4988jZU9Z_Hsjjitr-NyinTrYUWOjUf4HDWBKAN5w%40mail.gmail.com.

Re: Improvements to Vulnerability Disclosure wiki page

[Ben Wilson]

Thanks, Roman

I have added "Email Address / Group Distribution List" as a clarification.
However, additional contact information such as a phone number might be
needed in exceptional cases, but we can request that if needed.

Ben

On Wed, Nov 22, 2023 at 11:07 PM Roman Fischer 
wrote:

> Dear Ben,
>
>
>
> Thanks for the effort you put into this and especially to align the
> markdown template to the regular incident reporting template as much as
> possible.
>
>
>
> Regarding the “Contact Information”: What is Mozilla’s expectation here?
> An e-mail address (personal or group mailbox), phone number (plus timezone
> so that people aren’t called in the middle of “their” night)? Or… ?
>
>
>
> As for the other details in such a report: They look plausible and I guess
> they are the result of previous incidents and details that were missing in
> the initial communication.
>
>
>
> Kind regards
> Roman
>
>
>
> *From:* dev-security-policy@mozilla.org  *On
> Behalf Of *Ben Wilson
> *Sent:* Mittwoch, 22. November 2023 20:35
> *To:* dev-secur...@mozilla.org 
> *Subject:* Re: Improvements to Vulnerability Disclosure wiki page
>
>
>
> All,
>
> For your review and comment, today I reorganized the security incident and
> vulnerability disclosure report's expected contents
> <https://wiki.mozilla.org/CA/Vulnerability_Disclosure#Reportable_Vulnerability.2FIncident_Disclosure_Contents>
> and added a markdown template
> <https://wiki.mozilla.org/CA/Vulnerability_Disclosure#Markdown_Template>
> that can be used in Bugzilla.
>
> Ben
>
>
>
> On Wed, Sep 27, 2023 at 11:47 AM Ben Wilson  wrote:
>
> All,
>
> As mentioned in a previous email, I am soliciting feedback regarding the 
> Vulnerability
> Disclosure wiki page
> <https://wiki.mozilla.org/CA/Vulnerability_Disclosure>. If you have any
> specific suggestions that we can use to enhance clarity or to make the page
> more complete, please don't hesitate to share them, either here or directly
> with me. Your feedback is instrumental in our commitment to maintain a safe
> and secure online environment.
>
> Thanks,
>
> Ben
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-policy@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-policy+unsubscr...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabbqDu6N7yPnU9uL0RZQXPiMquHh-1FxTmPbQSeOj8T5w%40mail.gmail.com
> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabbqDu6N7yPnU9uL0RZQXPiMquHh-1FxTmPbQSeOj8T5w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabhgCGjyeX_OtC9iT177XihXpCLHXgQvNgyrGh0rLCMMA%40mail.gmail.com.

Re: [cabfpub] Voting Period begins: Ballot FORUM-020 v2 - Amend Code Signing Certificate Working Group Charter

[Ben Wilson via Public]

Mozilla votes "Yes" on Ballot FORUM-020 v.2.

On Thu, Jan 4, 2024 at 1:02 PM Martijn Katerbarg via Public <
public@cabforum.org> wrote:

> *Ballot FORUM-020 **v2 - Amend Code Signing Certificate Working Group
> Charter*
>
>
>
> *Purpose of Ballot*
>
> This ballot proposes to amend the Code Signing Certificate Working Group
> (CSCWG) Charter with the following changes:
>
>- Bump the Charter version.
>- Add a limited scope for timestamp certificates.
>- Remove the version reference of the bylaws that we follow.
>- During a ballot, count only members that are in a voting class,
>disregarding associate members and interested parties.
>- Align Quorum definition as half the average, as the Bylaws have it
>set.
>
>
>
> The following motion has been proposed by Martijn Katerbarg of Sectigo and
> endorsed by Bruce Morton of Entrust and Dimitris Zacharopoulos of HARICA.
>
>
>
> - Motion Begins -
>
>
>
> MODIFY the Charter of the Code Signing Certificate Working Group as
> specified in the following redline:
>
> https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...b80c98b80ee132e2a3adf09bfa8ba7448084d11d
> 
>
>
>
> - Motion Ends -
>
>
>
> This ballot does not propose a Final Guideline or Final Maintenance
> Guideline.
>
>
>
> The procedure for approval of this ballot is as follows:
>
>
>
> Discussion Period (7+ days)
>
> Start Time: 2023-12-14 – 16:00 UTC
>
> End Time: 2024-01-04 – 20:00 UTC
>
>
>
> Vote for approval (7 days)
>
> Start Time: 2024-01-04 – 20:00 UTC
>
> End Time:  2024-01-11 – 20:00 UTC
>
>
>
>
>
>
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [Infrastructure] cabforum.org website with more automation

[Ben Wilson via Infrastructure]

This looks very good and very promising.  Thanks, Paul.
Ben

On Thu, Jan 4, 2024 at 1:29 PM Paul van Brouwershaven via Infrastructure <
infrastructure@cabforum.org> wrote:

> I started to convert the cabforum.org website to Hugo to give us more
> automation, you can see a preview here:
> https://cabforum.github.io/cabforum.org/
>
>
>- The homepage needs some work, currently just listing the latest
>posts.
>   - The homepage is currently always blue as GitHub does not publish
>   at the root "/" of the domain.
>- The latest documents are automatically included from GitHub
>(example,
>https://cabforum.github.io/cabforum.org/working-groups/smime/latest/)
>- The document release information is automatically downloaded and
>included in the sidebar, currently not working as of rate limiting, need to
>set a GitHub API key, also not all repositories create releases.
>- The post URLs need to be corrected; this should be a simple config.
>- I did not copy the dropdown menu's for now, this is quite
>complicated with pure bootstrap (like you can't have a hover that is also
>clickable) and want to keep things simple now. This is why I moved the sub
>menu to the right, only three levels are currently shown in the right menu,
>I need to make this recursive as we also have four levels.
>- I re-organized the pages/urls a bit, but included an alias for the
>original URLs, might need to tune this a bit further and will run a script
>to update all the URLs in the contents.
>- Search index is automatically updated on publication.
>- I will add a query to automatically list all minutes (posts with tag
>minutes and working group id)
>- We need to review the site contents for any other errors.
>- When the member tools can expose information in JSON (i.e., API) we
>can automatically include that information as well (such as members), the
>same for ballots (or we can get that information from GitHub
>issues/pull-requests), we can also query the old Google Sheets.
>
>
> On the right bottom of each page you will find an edit button, which will
> bring you to the markdown contents on GitHub.
>
> Some quick instruction are included in the readme of the repository:
> https://github.com/cabforum/cabforum.org/tree/main
>
> Let me know if you see any issues not mentioned above or if you have any
> other suggestions, comments or concerns.
>
> Paul
>
>
> *Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.*
> ___
> Infrastructure mailing list
> Infrastructure@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
>
___
Infrastructure mailing list
Infrastructure@cabforum.org
https://lists.cabforum.org/mailman/listinfo/infrastructure

Re: [Servercert-wg] Section 7.1.5 as required by RFC 3647 is no longer in the TLS BRs

[Ben Wilson via Servercert-wg]

I think this is listed as an issue in GitHub -
https://github.com/cabforum/servercert/issues/444.

On Thu, Jan 4, 2024 at 4:54 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

> Dear Members,
>
> While taking another pass at reviewing the new certificate profiles
> introduced in ballot SC62, I realized that there is some deviation from the
> RFC 3647 structure that the BRs should maintain to help alignment of CA
> CP/CPS documents.
>
> This is the structure defined by RFC 3647 for section 7:
>
>7.  CERTIFICATE, CRL, AND OCSP PROFILES
>7.1  Certificate profile
>7.1.1  Version number(s)
>7.1.2  Certificate extensions
>7.1.3  Algorithm object identifiers
>7.1.4  Name forms
>7.1.5  Name constraints
>7.1.6  Certificate policy object identifier
>7.1.7  Usage of Policy Constraints extension
>7.1.8  Policy qualifiers syntax and semantics
>7.1.9  Processing semantics for the critical Certificate Policies
>
>
> Section 7.1.5 does not exist anymore. The BRs have the name constraints
> information in 7.1.2.5.2, 7.1.2.10.8. I believe that, at a minimum, we
> should re-introduce 7.1.5 and point to other subsections of 7.1.2 for
> consistency with RFC 3647.
>
> Thoughts?
> Dimitris.
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Deutsche Telekom Security's Root Inclusion Request

[Ben Wilson]

 All,

Public discussion began on the CCADB Public List on Nov. 1, 2023 (
https://groups.google.com/a/ccadb.org/g/public/c/yiJ-bkv-Ftg/m/JsbbxpZJBAAJ)
and concluded on Dec. 13 (
https://groups.google.com/a/ccadb.org/g/public/c/yiJ-bkv-Ftg/m/lxwjZDvhAAAJ)
regarding Deutsche Telekom Security's request to include
the following root CA certificates in NSS:

   -

   Telekom Security SMIME ECC Root 2021 (email trust bit)


   -

   Telekom Security TLS ECC Root 2020 (websites trust bit)
   -

   Telekom Security SMIME RSA Root 2023 (email trust bit)
   -

   Telekom Security TLS RSA Root 2023 (websites trust bit)

Additional details concerning this request may be found in the
above-referenced discussions, in Bugzilla #1820592
, and in

CCADB Case Number 1269

.

This is notice that I am recommending approval of this request.

This begins a 7-day “last call” period for any final objections.

Thanks,

Ben

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaOjQuJ_zhkkbn6UymdBGxfw9k1SW94ER6-21PoVa%2BYyg%40mail.gmail.com.

Re: S/MIME BR Transition Wiki Page

[Ben Wilson]

All,

I am editing the S/MIME Baseline Requirements transition guidance wiki page
(https://wiki.mozilla.org/CA/Transition_SMIME_BRs) slightly to make it more
clear that existing CA operators are to submit their S/MIME BR audit
reports consistent with their existing audit cycles. Right now, the
language on the wiki page says, "For CA operators to maintain their current
annual audit cycles, new S/MIME BR audits should be provided when they
provide their other annual audits."  This seems pretty straightforward.
But then it says, "Any root CA certificate being considered for inclusion
after October 30, 2023, must be audited according to the S/MIME BRs if the
email trust bit is to be enabled, and the CA operator’s CP or CPS must
state that they follow the current version of the S/MIME BRs."

This latter sentence might be inferred to mean that an earlier,
out-of-cycle audit would be required for new root CA certificates created
by existing CAs. I am recommending that we change this to make it clear
that if an existing CA operator has an email-trust-bit-enabled CA
certificate in the root store, then it can submit its S/MIME BR audit (that
will include new, email-enabled root CAs) when it provides its other
regularly-scheduled, other audits. For example, if a CA operator in the
Mozilla root program usually submits their audits in July, and they are
requesting the inclusion of a new email-enabled root CA, then that S/MIME
BR audit can be submitted in July, too.

Here are my suggested revisions:

For CA operators *that already have ** an email-trust-bit-enabled CA
certificate in the root store* to *may* maintain their current annual audit
cycles *and provide*, *the* new S/MIME BR audits should be provided when
they provide their other annual audit *report*s*, even if they are in the
process of requesting inclusion of one or more new, email-trust-bit-enabled
root CA certificates*. *For instance, if a CA operator typically provides
audit reports in July 2024 and is requesting the inclusion of a new
email-bit-enabled root CA, the corresponding S/MIME BR audit encompassing
both existing and new * *email-trust-bit-enabled* *root CA certificates can
be submitted during the annual audit submission in July 2024.*

*For any new CA operator requesting inclusion of a* Any root CA
certificate being
considered for inclusion after October 30, 2023, *the root CA *must be
audited according to the S/MIME BRs if the email trust bit is to be enabled
*.*

*A* , and the CA operator’s CP or CPS must state that they follow the
current version of the S/MIME BRs.

Are there any comments or suggestions?

Thanks,

Ben



On Wed, Jul 19, 2023 at 11:01 AM Ben Wilson  wrote:

> All,
>
> I have created a wiki page (
> https://wiki.mozilla.org/CA/Transition_SMIME_BRs) to address
> miscellaneous issues that might arise for CAs in their transition toward
> compliance with the CA/Browser Forum’s Baseline Requirements for S/MIME
> Certificates (S/MIME BRs). (The wiki page is for items that are not
> directly explained in the upcoming version 2.9 of the Mozilla Root Store
> Policy.)
>
> The first issue addressed in the wiki page relates to the re-issuance of
> existing intermediate CAs used for issuing S/MIME certificates. Based on
> language provided by Corey Bonnell, the wiki page explains how Mozilla
> expects S/MIME CA re-issuance to occur.
>
> We may add explanations about other items of concern to the wiki page in
> the future, and if so, I’ll advise you accordingly.
>
> Thanks,
>
> Ben
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabGsE5N9mJeOWaROcu17dTKtKfZf8tpjLDGS7jA49jVzg%40mail.gmail.com.

D-Trust Inclusion Request (Email Trust Bit)

[Ben Wilson]

 All,

Public discussion concluded last Friday, Dec. 15, on the CCADB Public List,
for D-Trust's root inclusion request.
https://groups.google.com/a/ccadb.org/g/public/c/EPVczE_6oCc/m/jsZ0CsgdAAAJ

This is notice that I am recommending approval of D-Trust's request to
include the following root CA certificates in NSS with the email trust bit
enabled:

D-Trust SBR Root CA 1 2022.cer
   (CA Repository
, crt.sh

)
D-Trust SBR Root CA 2 2022.cer
(CA Repository
, crt.sh

)

This begins a 7-day “last call” period for any final objections.

Thanks,

Ben

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabh4uTWn%3DMoNF%2BBNz%2BzgghcBEEEz2U%3DHw6GwmX%2BXwab%3Dw%40mail.gmail.com.

Re: Public Discussion of D-Trust CA Inclusion Request

[Ben Wilson]

All,

On November 3, 2023, we began a six-week, public discussion[1] on the
following root CA certificates issued by D-Trust:

   1.

   D-Trust SBR Root CA 1 2022:
   -

  384-bit ECC
  -

  Certificate download links: (CA Repository
  <http://www.d-trust.net/cgi-bin/D-Trust_SBR_Root_CA_1_2022.crt>,
  crt.sh
  
<https://crt.sh/?sha256=D92C171F5CF890BA428019292927FE22F3207FD2B54449CB6F675AF4922146E2>
  )
  -

  Use cases served/EKUs:
  -

 Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
 -

 Client Authentication 1.3.6.1.5.5.7.3.2
 -

 Document Signing AATL 1.2.840.113583.1.1.5
 -

 Document Signing MS 1.3.6.1.4.1.311.10.3.12



   1.

   D-Trust SBR Root CA 2 2022:
   -

  4096-bit RSA
  -

  Certificate download links: (CA Repository
  <http://www.d-trust.net/cgi-bin/D-Trust_SBR_Root_CA_2_2022.crt>,
  crt.sh
  
<https://crt.sh/?sha256=DBA84DD7EF622D485463A90137EA4D574DF8550928F6AFA03B4D8B1141E636CC>
  )
  -

  Use cases served/EKUs:
  -

 Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
 -

 Client Authentication 1.3.6.1.5.5.7.3.2
 -

 Document Signing AATL 1.2.840.113583.1.1.5
 -

 Document Signing MS 1.3.6.1.4.1.311.10.3.12

The public discussion period ended last Friday, December 15, 2023.

We did not receive any objections or other questions or comments in
opposition to D-Trust’s request. We thank the community for its review and
consideration during this period. Root Store Programs will make final
inclusion decisions independently, on their own timelines, and based on
each Root Store Member’s inclusion criteria. Further discussion may take
place in the independently managed Root Store community forums (e.g. MDSP).

Thanks,

Ben Wilson

On behalf of the CCADB Steering Committee
[1]
https://groups.google.com/a/ccadb.org/g/public/c/EPVczE_6oCc/m/s90nO9-EBAAJ

On Fri, Dec 8, 2023 at 10:52 AM Ben Wilson  wrote:

> Greetings,
>
> This is a reminder that the public discussion period on the inclusion
> application of D-Trust will close next Friday, December 15, 2023.
>
> Thank you,
> Ben Wilson, on behalf of the CCADB Steering Committee
>
> On Mon, Nov 6, 2023 at 10:02 AM Ben Wilson  wrote:
>
>> All,
>>
>> Regarding the D-Trust Certification Practice Statement—instead of
>> referencing the D-Trust Root PKI CPS, it should have referenced the CPS of
>> the D-Trust CSM PKI, v.4.0, valid from 28-September-2023 (
>> https://www.d-trust.net/internet/files/D-TRUST_CSM_PKI_CPS.pdf) (from 19
>> July 2023, the CSM PKI CPS applies to certificates with policy levels
>> QEVCP-w, QNCP-w, EVCP, OVCP and LCP).
>>
>> Also, it didn’t mention the following Bugzilla bugs opened in the past 24
>> months:
>>
>> 1756122 <https://bugzilla.mozilla.org/show_bug.cgi?id=1756122>
>>
>> D-TRUST: Wrong key usage (Key Agreement)
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1756122>
>>
>> RESOLVED
>>
>> [dv-misissuance]
>>
>> 1793440 <https://bugzilla.mozilla.org/show_bug.cgi?id=1793440>
>>
>> D-TRUST: CRL not DER-encoded
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1793440>
>>
>> RESOLVED
>>
>> [crl-failure]
>>
>> 1861069 <https://bugzilla.mozilla.org/show_bug.cgi?id=1861069>
>>
>> D-Trust: Issuance of 15 DV certificates containing ‘serialNumber’ field
>> within subject <https://bugzilla.mozilla.org/show_bug.cgi?id=1861069>
>>
>> OPEN
>>
>> [dv-misissuance]
>>
>> 1862082 <https://bugzilla.mozilla.org/show_bug.cgi?id=1862082>
>>
>> D-Trust: Delay beyond 5 days in revoking misissued certificate
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1862082>
>>
>> OPEN
>>
>> [leaf-revocation-delay]
>>
>>
>>
>> Ben
>>
>> On Fri, Nov 3, 2023 at 9:39 AM Ben Wilson  wrote:
>>
>>> All,
>>>
>>> This email commences a six-week public discussion of D-Trust’s request
>>> to include the following CA certificates as publicly trusted root
>>> certificates in one or more CCADB Root Store Member’s program. This
>>> discussion period is scheduled to close on December 15, 2023.
>>>
>>> The purpose of this public discussion process is to promote openness and
>>> transparency. However, each Root Store makes its inclusion decisions
>>> independently, on its own timelines, and based on its own inclusion
>>> criteria. Successful completion of this public discussion process does not
>>> guarantee any favorable action by any root store.
>>>
>>>

Re: CCADB Update: Upcoming Addition of Network Security and S/MIME Audits in the CCADB

[Ben Wilson]

Greetings,
The previously mentioned updates to the CCADB have been made. Please let us
know if you have any questions.
Thanks,
Ben

On Wed, Dec 13, 2023 at 3:29 PM 'Hannah Sokol' via CCADB Public <
public@ccadb.org> wrote:

> All,
>
>
>
> On Thursday, December 14, 2023, we will be updating the CCADB to introduce
> the ability to upload Network Security and S/MIME audit statements to the
> AUDITS tab for ‘Add/Update Root Request' cases.
>
>
>
> CA Owners should not be impacted during this update.
>
>
>
> This new functionality should enable CA Owners to:
>
>
>
> + Add Network Security and S/MIME Audit Statements to Root CA root records
> using the AUDITS tab of an 'Add/Update Root Request' case.
>
> + Add Network Security and S/MIME Audit Statements to Subordinate CA
> records in the same manner as done today with other types of Audit
> Statements.
>
> + Archive Network Security and S/MIME Audit Statements.
>
>
>
> We will also have a new “All Cert Information v2” csv report hosted in
> parallel with the existing report, accessible from
> https://www.ccadb.org/resources. This new report will include data on
> S/MIME and Network Security audits. (Version 1 of the report will
> eventually be discontinued.)
>
>
>
> We will send a separate email on Friday, December 15th, 2023, when these
> functionalities are fully available.
>
>
>
> Thank you,
>
> - Hannah, on behalf of the CCADB Steering Committee
>
> --
> You received this message because you are subscribed to the Google Groups
> "CCADB Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to public+unsubscr...@ccadb.org.
> To view this discussion on the web visit
> https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR00MB1028130539F41B38D7E716989B8DA%40MW4PR00MB1028.namprd00.prod.outlook.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to public+unsubscr...@ccadb.org.
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtabcRVVcwTtepFY-0RMrRRnfTBnavfAOL%3Dp%2BquoPn0c7uQ%40mail.gmail.com.

[Infrastructure] Draft Minutes of Meeting 13-Dec-2023

[Ben Wilson via Infrastructure]

Here are the draft minutes from today's call:

*Minutes of Infrastructure Committee – 13-December-2023*

*Present:*  Ben Wilson, Dean Coclin, Iñigo Barreira, Paul Van
Brouwershaven, Wayne Thayer, and Roman Fischer

Ben read the Note Well.

The major topic for discussion was the creation of procedures documents for
handling tasks related to new and existing members. Iñigo asked whether
anything could be added to Member Tools to facilitate the processing of
applications and onboarding of new members.  The creation of a handbook for
working group chairs was also recommended. Process flows need to consider
applicants for full membership (Certificate Issuers and Certificate
Consumers), interested parties, associate members and probationary members.
Procedures need to address all possibilities and information needs to be
collected for which working group and subcommittees the member wants to
join, the names of voting representatives, etc. Checklist documents will be
needed, as well as a calendar that can be transitioned to a new working
group chair when the existing chair leaves office. (E.g. how would we track
the 6-month probationary period during a transition to new leadership?)

Iñigo said he would prepare a list of the documents of which he is aware
and provide a framework for dealing with the issues he encounters.  We’ll
need to prepare an outline of the handbook. The handbook could be generic
and useable by all working groups, with appendices for things that
specifically apply only to one working group.

Instructions for the Member Tools are also needed. It’s unclear how to
update a person’s record if they leave a company. Also, it was noted that
there are a couple of member self-management options that members should
use, which they should be able to find through links available on the wiki
– one using Member Tools and one using a Google Form.

Paul also suggested that we transition from WordPress to GoHugo (
https://gohugo.io). Then, we can manage the website’s member lists,
ballots, guideline documents, and minutes more easily using GitHub. He said
he has had a favorable experience doing so with another organization.

The meeting on December 27th is cancelled.

Meeting adjourned.
___
Infrastructure mailing list
Infrastructure@cabforum.org
https://lists.cabforum.org/mailman/listinfo/infrastructure

Re: [Infrastructure] Update of "old" documents

[Ben Wilson via Infrastructure]

I have an item on my to-do list to work on this with Iñigo.
Cheers,
Ben

On Tue, Dec 12, 2023 at 8:32 AM Dean Coclin via Infrastructure <
infrastructure@cabforum.org> wrote:

> These were tools that Dimitris created and I refer to from time to time.
> We should keep/update them and add someplace in the tool.
> Dean
>
>
>
> *Dean Coclin *
>
> Sr. Director Business Development
>
> M 1.781.789.8686
>
>
>
>
>
>
>
>
>
> *From:* Infrastructure  *On Behalf
> Of *Inigo Barreira via Infrastructure
> *Sent:* Tuesday, December 12, 2023 4:28 AM
> *To:* Ben Wilson via Infrastructure 
> *Subject:* [Infrastructure] Update of "old" documents
>
>
>
> Hi there,
>
>
>
> Maybe of interest for tomorrow´s call.
>
> While reviewing the application of TrustAsia, found this google doc with a
> checklist of what to do Checklist for New Member in SCWG/CAB Forum -
> Google Sheets
> <https://docs.google.com/spreadsheets/d/1ayGAM80rUTlccsX5F-zxuUks6jftBsqVi3Vll0er1Z0/edit#gid=0>
>
> Do we need to update all these google docs? Have these implemented somehow
> in the member tool?
>
> Another one could be the IPRs document, do we need to keep the old ones in
> the wiki? What to do when one organization/person changes status? For
> example, TrustAsia from associate member to full member?
>
>
>
> Regards
> ___
> Infrastructure mailing list
> Infrastructure@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
>
___
Infrastructure mailing list
Infrastructure@cabforum.org
https://lists.cabforum.org/mailman/listinfo/infrastructure

Re: Public Discussion of D-Trust CA Inclusion Request

[Ben Wilson]

Greetings,

This is a reminder that the public discussion period on the inclusion
application of D-Trust will close next Friday, December 15, 2023.

Thank you,
Ben Wilson, on behalf of the CCADB Steering Committee

On Mon, Nov 6, 2023 at 10:02 AM Ben Wilson  wrote:

> All,
>
> Regarding the D-Trust Certification Practice Statement—instead of
> referencing the D-Trust Root PKI CPS, it should have referenced the CPS of
> the D-Trust CSM PKI, v.4.0, valid from 28-September-2023 (
> https://www.d-trust.net/internet/files/D-TRUST_CSM_PKI_CPS.pdf) (from 19
> July 2023, the CSM PKI CPS applies to certificates with policy levels
> QEVCP-w, QNCP-w, EVCP, OVCP and LCP).
>
> Also, it didn’t mention the following Bugzilla bugs opened in the past 24
> months:
>
> 1756122 <https://bugzilla.mozilla.org/show_bug.cgi?id=1756122>
>
> D-TRUST: Wrong key usage (Key Agreement)
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1756122>
>
> RESOLVED
>
> [dv-misissuance]
>
> 1793440 <https://bugzilla.mozilla.org/show_bug.cgi?id=1793440>
>
> D-TRUST: CRL not DER-encoded
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1793440>
>
> RESOLVED
>
> [crl-failure]
>
> 1861069 <https://bugzilla.mozilla.org/show_bug.cgi?id=1861069>
>
> D-Trust: Issuance of 15 DV certificates containing ‘serialNumber’ field
> within subject <https://bugzilla.mozilla.org/show_bug.cgi?id=1861069>
>
> OPEN
>
> [dv-misissuance]
>
> 1862082 <https://bugzilla.mozilla.org/show_bug.cgi?id=1862082>
>
> D-Trust: Delay beyond 5 days in revoking misissued certificate
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1862082>
>
> OPEN
>
> [leaf-revocation-delay]
>
>
>
> Ben
>
> On Fri, Nov 3, 2023 at 9:39 AM Ben Wilson  wrote:
>
>> All,
>>
>> This email commences a six-week public discussion of D-Trust’s request to
>> include the following CA certificates as publicly trusted root certificates
>> in one or more CCADB Root Store Member’s program. This discussion period is
>> scheduled to close on December 15, 2023.
>>
>> The purpose of this public discussion process is to promote openness and
>> transparency. However, each Root Store makes its inclusion decisions
>> independently, on its own timelines, and based on its own inclusion
>> criteria. Successful completion of this public discussion process does not
>> guarantee any favorable action by any root store.
>>
>> Anyone with concerns or questions is urged to raise them on this CCADB
>> Public list by replying directly in this discussion thread. Likewise, a
>> representative of the applicant must promptly respond directly in the
>> discussion thread to all questions that are posted.
>>
>> CCADB Case Numbers:   # 1000
>> <https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=1000>
>> and # 1001
>> <https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=1001>
>>
>> Organization Background Information (listed in CCADB):
>>
>>-
>>
>>CA Owner Name: D-Trust GmbH
>>-
>>
>>Website:  https://www.d-trust.net/en
>>-
>>
>>Address:  Kommandantenstr. 15, Berlin, 10969, Germany
>>-
>>
>>Problem Reporting Mechanisms:
>>-
>>
>>   https://www.d-trust.net/en/support/reporting-certificate-problem
>>   -
>>
>>Organization Type: D-Trust GmbH is a subsidiary of the
>>Bundesdruckerei Group GmbH (bdr) and is fully owned by the German State.
>>-
>>
>>Repository URL:  https://www.bundesdruckerei.de/en/Repository
>>
>> Certificates Requested for Inclusion:
>>
>>1.
>>
>>D-Trust SBR Root CA 1 2022:
>>-
>>
>>   384-bit ECC
>>   -
>>
>>   Certificate download links: (CA Repository
>>   <http://www.d-trust.net/cgi-bin/D-Trust_SBR_Root_CA_1_2022.crt>,
>>   crt.sh
>>   
>> <https://crt.sh/?sha256=D92C171F5CF890BA428019292927FE22F3207FD2B54449CB6F675AF4922146E2>
>>   )
>>   -
>>
>>   Use cases served/EKUs:
>>   -
>>
>>  Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
>>  -
>>
>>  Client Authentication 1.3.6.1.5.5.7.3.2
>>  -
>>
>>  Document Signing AATL 1.2.840.113583.1.1.5
>>  -
>>
>>  Document Signing MS 1.3.6.1.4.1.311.10.3.12
>>
>>
>>
>>1.
>>
>>D-Trust SBR Root CA 2 2022:
>>-
>>
>>   409

Re: [Smcwg-public] CAA for S/MIME

[Ben Wilson via Smcwg-public]

It would be great if we could coordinate with a SCWG ballot that requires
that CAA be put in section 3.2.2.8.  However, as I said on the recent call,
there might be a CA or two that has already populated section 3.2.2.8 of
their CP/CPS with something else.

On Thu, Dec 7, 2023 at 8:59 AM Stephen Davidson via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> Thanks Bruce.  That section is planned to be deleted.
>
>
> https://github.com/srdavidson/smime/compare/241e92cde85c25d7e0d4a5c70118ecadacd4d72b...c8b0c9ff9fa28c2c7abeb2871aaa2d60a19842ed
>
>
>
> I can certainly move the content to 3.2.2.4 but I see that the TLS BR are
> considering gathering their the CAA information in 3.2.2.8 which may be
> confusing for CAs?
>
>
>
> The use of 4.2 would allow consistency across the two docs.
>
>
>
>
>
>
>
> *From:* Bruce Morton 
> *Sent:* Wednesday, December 6, 2023 9:09 PM
> *To:* Stephen Davidson ; SMIME Certificate
> Working Group 
> *Subject:* RE: CAA for S/MIME
>
>
>
> I think we need to fix this section:
>
>
>
> 3.2.2.4 CAA records
>
> This version of the S/MIME Baseline Requirements does not require the CA
> to check for CAA records. The CAA property tags for `issue`, `issuewild`,
> and `iodef` as specified in [RFC 8659](
> https://datatracker.ietf.org/doc/html/rfc8659) are not recognized for the
> issuance of S/MIME Certificates.
>
>
>
> I would really like to add all CAA requirements to section 3.2.2.4, since
> it is called CAA records. This would be in line with this TLS BR comment
> https://github.com/cabforum/servercert/issues/466.
>
>
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Smcwg-public  *On Behalf Of 
> *Stephen
> Davidson via Smcwg-public
> *Sent:* Wednesday, December 6, 2023 1:00 PM
> *To:* smcwg-public@cabforum.org
> *Subject:* [EXTERNAL] [Smcwg-public] CAA for S/MIME
>
>
>
> Hello:
>
>
>
> Here is an updated diff for the CAA text following our discussions today:
>
>
>
> -As suggested by Cade, to add the TTL/8hr reference consistent with the
> TLS BR.
>
> -To add the implementation dates in 2.2 and 4.2
>
>
>
>
> https://github.com/srdavidson/smime/compare/241e92cde85c25d7e0d4a5c70118ecadacd4d72b...43228a41a5cc99a3301c4066621787cde7e0f79a
>
>
>
> The plan will be to move this to ballot at the start of 2024, so I
> encourage CAs to engage with operations teams and/or software vendors on
> the suitability of the implementation dates.
>
>
>
> Best regards, Stephen
>
>
>
>
>
> *Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.*
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot

[Ben Wilson via Servercert-wg]

All,
See
https://github.com/BenWilson-Mozilla/pkipolicy/commit/1a94642cb95017cf382e4e93811db16a2342a806.
This proposed change was to clarify that the outline in section 6 of RFC
3647 is what is intended to be followed in CPs and CPSes, and not some
other outline found in RFC 3647.  Unfortunately, this change did not make
it into Mozilla Root Store Policy v. 2.9, but it is slated for inclusion in
version 3.0.
Thanks,
Ben

On Sat, Dec 2, 2023 at 3:26 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

> We still have a disagreement so please allow me one more attempt to
> clarify my position because it seems you didn't check the links included in
> my previous post. I will copy some of that text here for convenience.
>
> On 1/12/2023 11:31 μ.μ., Tim Hollebeek wrote:
>
> No.
>
>
>
> IETF has both Normative and Informative RFCs.  While it is true that
> compliance with a Normative RFC is voluntary, if you do choose to comply,
> the RFC has requirements stated in RFC 2119 standards language that make it
> clear what the compliance rules are.  Informative RFCs like 3647 do not
> have any normative requirements at all.  They merely contain information.
>
>
>
> “all sections of the RFC 3647 framework” is fine, this covers the sections
> enumerated in RFC 3647 section 4, which includes the TOP TWO levels of an
> outline in numbered form, e.g. the requirements for section 3.2 are
> described in RFC 3647 section 4.3.2.  There is no RFC 3647 section 4.3.2.1,
> which proves my point.  RFC 3647 only has a two level outline structure.
>
>
> I think I might have a hint on our disconnect. RFC 3647 has an indicative
> Table of Contents in Chapter 6 (
> https://datatracker.ietf.org/doc/html/rfc3647#section-6) outlining the
> proposed CP/CPS sections and subsections using 3 levels.
>
> Here is the text of the opening paragraph of that section (emphasis added):
>
>This section contains a recommended outline for a set of provisions,
>intended to serve as a checklist or (with some further development) a
>standard template for use by CP or CPS writers.  Such a common
>outline will facilitate:
>
>(a) Comparison of two certificate policies during cross-
>certification or other forms of interoperation (for the purpose
>of equivalency mapping).
>
>(b) Comparison of a CPS with a CP to ensure that the CPS faithfully
>implements the policy.
>
>(c) Comparison of two CPSs.
> *   In order to comply with the RFC, the drafters of a compliant CP or
>CPS are strongly advised to adhere to this outline.*  While use of an
>alternate outline is discouraged, it may be accepted if a proper
>justification is provided for the deviation and a mapping table is
>provided to readily discern where each of the items described in this
>outline is provided.
>
>
> The reason the CA/B Forum BRs were structured according to this outline
> was to assist with comparisons between CP/CPS documents of different CAs,
> making the review of these documents easier.
>
> That's why you see sections like 1.5.4 "CPS approval procedures" in the
> BRs as an empty section with "No Stipulation". There are many such sections
> in the BRs, all coming from section 6 of RFC 3647.
>
> I hope this is clearer now.
>
>
>
> BR Section 2.2 needs to be re-written, as there are no materials required
> by RFC 3647 (because RFC 3647 contains no requirements).  It needs to say
> something like “structured in accordance with RFC 3647 and MUST include all
> sections of the outline described in section 4” or something like that.
> What it says right now doesn’t capture the intent that you correctly
> summarized.
>
>
> During the last couple of years reviewing CP/CPS documents, I saw some
> uniformity at least in Publicly Trusted CAs, and they all seem to follow
> the BRs structure which comes from the outline of section 6 of RFC 3647.
> However, it's not a bad idea to further clarify BR section 2.2 to better
> meet the expectations.
>
>
>
> The MSRP language is better, I think I may have made all of these same
> points when it was being drafted, which is why it says “section and
> subsection” (two levels) and uses “structured according to” and not
> “complies with the requirements of”.
>
>
>
> But anyway, this is all background that supports what I’ve been saying all
> along: BR 3.2 is a RFC 3647 section.  BR 3.2.1 **is not** a RFC 3647
> required section, nor is it even a section that is even mentioned in RFC
> 3647.  If you don’t believe me, please go to RFC 3647, Section 4.3.2.1 and
> read what it says.  OH, WAIT, IT DOESN’T EXIST! 
>
>
> To my point, BR 3.2.1 IS an RFC 3647 required section as it is explicitly
> mentioned in the outline of section 6 of RFC 3647:
>
> 3.2.1  Method to prove possession of private key
>
>
> Details about the contents of that section can be found in the first
> bullet of section 4.3.2 of RFC 3647
> .
>
> Does that make 

Re: [cabfpub] Ballot FORUM-019 v.2 - Amend Server Certificate Working Group Charter - VOTING PERIOD

[Ben Wilson via Public]

Mozilla votes "yes" on Ballot FORUM-019 v.2.

On Mon, Nov 27, 2023 at 8:44 AM Ben Wilson via Public 
wrote:

> The voting period for Ballot FORUM-019 v.2 starts today. Votes must be
> cast on the Forum public list in accordance with the Forum's Bylaws.
> Voting will conclude at 16:00 UTC on 4 December 2023.
>
> *Ballot FORUM-019 v.2 - Amend Server Certificate Working Group Charter*
>
> *Purpose of Ballot*
>
> This ballot proposes to amend the Server Certificate Working Group (SCWG)
> Charter, based on existing version 1.2 of the Charter and on recent updates
> to the Forum’s Bylaws.
>
> During discussions at Face-to-Face Meeting 58, it was noted that the
> membership criteria for Certificate Consumers in the SCWG Charter lacked
> sufficient detail. Since then, through discussions on the mailing list of
> the SCWG and elsewhere, better criteria for membership of Certificate
> Consumers in the SCWG have been developed, and the ballot also adds a
> 6-month probationary period for all applicants to the SCWG before they
> become voting members.
>
> Additionally, section numbering has been added, the outdated "Root
> Certificate Issuer" voting category has been removed, and provisions
> regarding voting percentages and quorum have been clarified.
>
> The following motion has been proposed by Ben Wilson of Mozilla and
> endorsed by Martijn Katerbarg of Sectigo and Dimitris Zacharopoulos of
> HARICA.
>
>
>
> *- Motion Begins -*
>
> MODIFY the Charter of the Server Certificate Working Group as specified in
> the following redline:
>
>
> https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...3af42d2d9e38a0dfcdf9450d5ca772365d5b5dbb
>
>
> *- Motion Ends -*
>
>
> This ballot does not propose a Final Guideline or Final Maintenance
> Guideline.
>
> The procedure for approval of this ballot is as follows:
>
> Discussion Period (7+ days)
>
> Start Time: 2023-11-16  23:00 UTC
>
> End Time: Not before 2023-11-23  23:00 UTC
>
>
>
> Vote for approval (7 days)
>
> Start Time: 2023-11-27  16:00 UTC
>
> End Time:  2023-12-04  16:00 UTC
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [Infrastructure] WordPress Instructions

[Ben Wilson via Infrastructure]

Thanks.
I have added more instructions for posting meeting minutes, although I
might not have captured all that you envisioned regarding which tags to
use.  It might be good to add sub-sections specific to each Working Group.
Ben

On Mon, Nov 27, 2023 at 9:00 AM Inigo Barreira via Infrastructure <
infrastructure@cabforum.org> wrote:

> +1. I think that list would be a good adding.
>
> -Mensaje original-
> De: Infrastructure  En nombre de
> Dimitris Zacharopoulos (HARICA) via Infrastructure
> Enviado el: lunes, 27 de noviembre de 2023 11:59
> Para: infrastructure@cabforum.org
> Asunto: Re: [Infrastructure] WordPress Instructions
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> Hi Ben, thank you for working on those instructions,
>
> Except for the tags you have indicated, should we perhaps have a listing
> of the exact tags that should be used on each occasion? For example, when
> publishing minutes, there may be tasks to distinguish if the minutes are
> for a Teleconference or a Physical (F2F) Meeting.
>
>
> Thanks,
> Dimitris.
>
> On 8/11/2023 11:57 μ.μ., Ben Wilson via Infrastructure wrote:
> > Today I started to edit the WordPress instructions for the website and
> > bring them up to date. (They're quite out-of-date.) I have provided a
> > link to them on the wiki -
> >
> https://wiki.cabforum.org/books/infrastructure/page/wordpress-instructions
> .
> > If you'd like to help me edit them and need "edit" access, then please
> > let me know.
> > Thanks,
> > Ben
> >
> > ___
> > Infrastructure mailing list
> > Infrastructure@cabforum.org
> > https://list/
> > s.cabforum.org%2Fmailman%2Flistinfo%2Finfrastructure=05%7C01%7Cin
> > igo.barreira%40sectigo.com%7Cf7f52e76a8174abb9df708dbef37e87c%7C0e9c48
> > 946caa465d96604b6968b49fb7%7C0%7C0%7C638366795630643042%7CUnknown%7CTW
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > Mn0%3D%7C3000%7C%7C%7C=3c8iDFBeFZI%2FoQfYbm5BEz6LqCQUfF0rnT1oids
> > 6WnE%3D=0
>
> ___
> Infrastructure mailing list
> Infrastructure@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
> ___
> Infrastructure mailing list
> Infrastructure@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
>
___
Infrastructure mailing list
Infrastructure@cabforum.org
https://lists.cabforum.org/mailman/listinfo/infrastructure

[cabfpub] Ballot FORUM-019 v.2 - Amend Server Certificate Working Group Charter - VOTING PERIOD

[Ben Wilson via Public]

 The voting period for Ballot FORUM-019 v.2 starts today. Votes must be
cast on the Forum public list in accordance with the Forum's Bylaws.
Voting will conclude at 16:00 UTC on 4 December 2023.

*Ballot FORUM-019 v.2 - Amend Server Certificate Working Group Charter*

*Purpose of Ballot*

This ballot proposes to amend the Server Certificate Working Group (SCWG)
Charter, based on existing version 1.2 of the Charter and on recent updates
to the Forum’s Bylaws.

During discussions at Face-to-Face Meeting 58, it was noted that the
membership criteria for Certificate Consumers in the SCWG Charter lacked
sufficient detail. Since then, through discussions on the mailing list of
the SCWG and elsewhere, better criteria for membership of Certificate
Consumers in the SCWG have been developed, and the ballot also adds a
6-month probationary period for all applicants to the SCWG before they
become voting members.

Additionally, section numbering has been added, the outdated "Root
Certificate Issuer" voting category has been removed, and provisions
regarding voting percentages and quorum have been clarified.

The following motion has been proposed by Ben Wilson of Mozilla and
endorsed by Martijn Katerbarg of Sectigo and Dimitris Zacharopoulos of
HARICA.



*- Motion Begins -*

MODIFY the Charter of the Server Certificate Working Group as specified in
the following redline:

https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...3af42d2d9e38a0dfcdf9450d5ca772365d5b5dbb


*- Motion Ends -*


This ballot does not propose a Final Guideline or Final Maintenance
Guideline.

The procedure for approval of this ballot is as follows:

Discussion Period (7+ days)

Start Time: 2023-11-16  23:00 UTC

End Time: Not before 2023-11-23  23:00 UTC



Vote for approval (7 days)

Start Time: 2023-11-27  16:00 UTC

End Time:  2023-12-04  16:00 UTC
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: Improvements to Vulnerability Disclosure wiki page

[Ben Wilson]

All,
For your review and comment, today I reorganized the security incident and
vulnerability disclosure report's expected contents
<https://wiki.mozilla.org/CA/Vulnerability_Disclosure#Reportable_Vulnerability.2FIncident_Disclosure_Contents>
and added a markdown template
<https://wiki.mozilla.org/CA/Vulnerability_Disclosure#Markdown_Template>
that can be used in Bugzilla.
Ben

On Wed, Sep 27, 2023 at 11:47 AM Ben Wilson  wrote:

> All,
> As mentioned in a previous email, I am soliciting feedback regarding the 
> Vulnerability
> Disclosure wiki page
> <https://wiki.mozilla.org/CA/Vulnerability_Disclosure>. If you have any
> specific suggestions that we can use to enhance clarity or to make the page
> more complete, please don't hesitate to share them, either here or directly
> with me. Your feedback is instrumental in our commitment to maintain a safe
> and secure online environment.
> Thanks,
> Ben
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabbqDu6N7yPnU9uL0RZQXPiMquHh-1FxTmPbQSeOj8T5w%40mail.gmail.com.

[Infrastructure] WordPress Instructions

[Ben Wilson via Infrastructure]

Today I started to edit the WordPress instructions for the website and
bring them up to date. (They're quite out-of-date.) I have provided a link
to them on the wiki -
https://wiki.cabforum.org/books/infrastructure/page/wordpress-instructions.
If you'd like to help me edit them and need "edit" access, then please let
me know.
Thanks,
Ben
___
Infrastructure mailing list
Infrastructure@cabforum.org
https://lists.cabforum.org/mailman/listinfo/infrastructure

Re: Public Discussion of D-Trust CA Inclusion Request

[Ben Wilson]

All,

Regarding the D-Trust Certification Practice Statement—instead of
referencing the D-Trust Root PKI CPS, it should have referenced the CPS of
the D-Trust CSM PKI, v.4.0, valid from 28-September-2023 (
https://www.d-trust.net/internet/files/D-TRUST_CSM_PKI_CPS.pdf) (from 19
July 2023, the CSM PKI CPS applies to certificates with policy levels
QEVCP-w, QNCP-w, EVCP, OVCP and LCP).

Also, it didn’t mention the following Bugzilla bugs opened in the past 24
months:

1756122 <https://bugzilla.mozilla.org/show_bug.cgi?id=1756122>

D-TRUST: Wrong key usage (Key Agreement)
<https://bugzilla.mozilla.org/show_bug.cgi?id=1756122>

RESOLVED

[dv-misissuance]

1793440 <https://bugzilla.mozilla.org/show_bug.cgi?id=1793440>

D-TRUST: CRL not DER-encoded
<https://bugzilla.mozilla.org/show_bug.cgi?id=1793440>

RESOLVED

[crl-failure]

1861069 <https://bugzilla.mozilla.org/show_bug.cgi?id=1861069>

D-Trust: Issuance of 15 DV certificates containing ‘serialNumber’ field
within subject <https://bugzilla.mozilla.org/show_bug.cgi?id=1861069>

OPEN

[dv-misissuance]

1862082 <https://bugzilla.mozilla.org/show_bug.cgi?id=1862082>

D-Trust: Delay beyond 5 days in revoking misissued certificate
<https://bugzilla.mozilla.org/show_bug.cgi?id=1862082>

OPEN

[leaf-revocation-delay]



Ben

On Fri, Nov 3, 2023 at 9:39 AM Ben Wilson  wrote:

> All,
>
> This email commences a six-week public discussion of D-Trust’s request to
> include the following CA certificates as publicly trusted root certificates
> in one or more CCADB Root Store Member’s program. This discussion period is
> scheduled to close on December 15, 2023.
>
> The purpose of this public discussion process is to promote openness and
> transparency. However, each Root Store makes its inclusion decisions
> independently, on its own timelines, and based on its own inclusion
> criteria. Successful completion of this public discussion process does not
> guarantee any favorable action by any root store.
>
> Anyone with concerns or questions is urged to raise them on this CCADB
> Public list by replying directly in this discussion thread. Likewise, a
> representative of the applicant must promptly respond directly in the
> discussion thread to all questions that are posted.
>
> CCADB Case Numbers:   # 1000
> <https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=1000>
> and # 1001
> <https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=1001>
>
> Organization Background Information (listed in CCADB):
>
>-
>
>CA Owner Name: D-Trust GmbH
>-
>
>Website:  https://www.d-trust.net/en
>-
>
>Address:  Kommandantenstr. 15, Berlin, 10969, Germany
>-
>
>Problem Reporting Mechanisms:
>-
>
>   https://www.d-trust.net/en/support/reporting-certificate-problem
>   -
>
>Organization Type: D-Trust GmbH is a subsidiary of the Bundesdruckerei
>Group GmbH (bdr) and is fully owned by the German State.
>-
>
>Repository URL:  https://www.bundesdruckerei.de/en/Repository
>
> Certificates Requested for Inclusion:
>
>1.
>
>D-Trust SBR Root CA 1 2022:
>-
>
>   384-bit ECC
>   -
>
>   Certificate download links: (CA Repository
>   <http://www.d-trust.net/cgi-bin/D-Trust_SBR_Root_CA_1_2022.crt>,
>   crt.sh
>   
> <https://crt.sh/?sha256=D92C171F5CF890BA428019292927FE22F3207FD2B54449CB6F675AF4922146E2>
>   )
>   -
>
>   Use cases served/EKUs:
>   -
>
>  Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
>  -
>
>  Client Authentication 1.3.6.1.5.5.7.3.2
>  -
>
>  Document Signing AATL 1.2.840.113583.1.1.5
>  -
>
>  Document Signing MS 1.3.6.1.4.1.311.10.3.12
>
>
>
>1.
>
>D-Trust SBR Root CA 2 2022:
>-
>
>   4096-bit RSA
>   -
>
>   Certificate download links: (CA Repository
>   <http://www.d-trust.net/cgi-bin/D-Trust_SBR_Root_CA_2_2022.crt>,
>   crt.sh
>   
> <https://crt.sh/?sha256=DBA84DD7EF622D485463A90137EA4D574DF8550928F6AFA03B4D8B1141E636CC>
>   )
>   -
>
>   Use cases served/EKUs:
>   -
>
>  Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
>  -
>
>  Client Authentication 1.3.6.1.5.5.7.3.2
>  -
>
>  Document Signing AATL 1.2.840.113583.1.1.5
>  -
>
>  Document Signing MS 1.3.6.1.4.1.311.10.3.12
>
> Relevant Policy and Practices Documentation:
>
>-
>
>Certificate Policy - CP of D-Trust GmbH
><https://www.d-trust.net/internet/files/D-TRUST_CP.pdf>, v.5.1, v

Public Discussion of D-Trust CA Inclusion Request

[Ben Wilson]

All,

This email commences a six-week public discussion of D-Trust’s request to
include the following CA certificates as publicly trusted root certificates
in one or more CCADB Root Store Member’s program. This discussion period is
scheduled to close on December 15, 2023.

The purpose of this public discussion process is to promote openness and
transparency. However, each Root Store makes its inclusion decisions
independently, on its own timelines, and based on its own inclusion
criteria. Successful completion of this public discussion process does not
guarantee any favorable action by any root store.

Anyone with concerns or questions is urged to raise them on this CCADB
Public list by replying directly in this discussion thread. Likewise, a
representative of the applicant must promptly respond directly in the
discussion thread to all questions that are posted.

CCADB Case Numbers:   # 1000

and # 1001


Organization Background Information (listed in CCADB):

   -

   CA Owner Name: D-Trust GmbH
   -

   Website:  https://www.d-trust.net/en
   -

   Address:  Kommandantenstr. 15, Berlin, 10969, Germany
   -

   Problem Reporting Mechanisms:
   -

  https://www.d-trust.net/en/support/reporting-certificate-problem
  -

   Organization Type: D-Trust GmbH is a subsidiary of the Bundesdruckerei
   Group GmbH (bdr) and is fully owned by the German State.
   -

   Repository URL:  https://www.bundesdruckerei.de/en/Repository

Certificates Requested for Inclusion:

   1.

   D-Trust SBR Root CA 1 2022:
   -

  384-bit ECC
  -

  Certificate download links: (CA Repository
  ,
  crt.sh
  

  )
  -

  Use cases served/EKUs:
  -

 Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
 -

 Client Authentication 1.3.6.1.5.5.7.3.2
 -

 Document Signing AATL 1.2.840.113583.1.1.5
 -

 Document Signing MS 1.3.6.1.4.1.311.10.3.12



   1.

   D-Trust SBR Root CA 2 2022:
   -

  4096-bit RSA
  -

  Certificate download links: (CA Repository
  ,
  crt.sh
  

  )
  -

  Use cases served/EKUs:
  -

 Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
 -

 Client Authentication 1.3.6.1.5.5.7.3.2
 -

 Document Signing AATL 1.2.840.113583.1.1.5
 -

 Document Signing MS 1.3.6.1.4.1.311.10.3.12

Relevant Policy and Practices Documentation:

   -

   Certificate Policy - CP of D-Trust GmbH
   , v.5.1, valid
   from 28-Sept-2023
   -

   Trust Services Practice Statement - TSPS of D-Trust
   , v.1.8, valid
   from 28-Sept-2023
   -

   Certification Practice Statement - CPS of the D-Trust Root PKI
   ,
   v.3.10, valid from 31-May-2023

Most Recent Self-Assessment / CPS Review:

   -

   D-Trust - CCADB Self Assessment (v1.2) 2023
    (XLS)
   (2-November-2023)

Audit Statements:

   -

   Auditor: TÜV Informationstechnik GmbH
   -

   Audit Criteria:
   -

  ETSI EN 319 411-1, V1.3.1 (2021-05)
  -

  ETSI EN 319 401, V2.3.1 (2021-05)
  -

  Baseline Requirements, version 1.8.4
  -

  ETSI EN 319 403 V2.2.2 (2015-08)
  -

  ETSI TS 119 403-2 V1.2.4 (2020-11)
  -

   Date of Audit Issuance: December 16, 2022
   -

   For Period of Time: 2022-07-06 to 2022-10-07
   -

   Audit Statement(s):
   -


  
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2022121606_D-Trust_SBR_Root_CA_1_2022.pdf
  -


  
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2022121607_D-Trust_SBR_Root_CA_2_2022.pdf


Thank you,

Ben, on behalf of the CCADB Steering Committee

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to public+unsubscr...@ccadb.org.
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaZes1TUd8UefomNVXxXMn%3DamoGjQ95226zJZUuHPPZ%2BgQ%40mail.gmail.com.

Re: [Smcwg-public] VOTE FOR APPROVAL Ballot SMC04: Addition of ETSI TS 119 411-6 to audit standards

[Ben Wilson via Smcwg-public]

Mozilla votes "Yes" on Ballot SMC 004 (Addition of ETSI TS 119 411-6).

On Wed, Nov 1, 2023 at 11:07 AM Stephen Davidson via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> Hello:
>
>
>
> The voting period for Ballot SMC04 has started. Votes must be cast on the
> SMCWG public list and in accordance with the Charter and By-Laws.
>
> Voting on SMC04 concludes on 08 November 2023 at 17:00 UTC.
>
>
>
> Regards, Stephen
>
>
>
>
>
> *Ballot SMC04: Addition of ETSI TS 119 411-6 to audit standards*
>
>
>
> *Purpose of Ballot:*
>
>
>
> The ballot proposes changes to the S/MIME Baseline Requirements, and in
> others to make corrections.  The affected sections include:
>
>
>
>- Clarify the Revisions table in section 1.2.1 to more clearly
>differentiate the effective date (publication of the version) from
>additional compliance dates; and
>- Add ETSI TS 119 411-6 as an audit criteria in Sections 1.6.3, 8.4,
>and 8.6.
>
>
>
> The following motion has been proposed by Stephen Davidson of DigiCert and
> endorsed by Dimitris Zacharopoulos of HARICA and Paul van Brouwershaven of
> Entrust.
>
>
>
> *— MOTION BEGINS —*
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted S/MIME Certificates” (“S/MIME Baseline
> Requirements”) resulting in Version 1.0.2.
>
>
>
> The proposed modifications to the S/MIME Baseline Requirements may be
> found at
>
>
> https://github.com/cabforum/smime/compare/241e92cde85c25d7e0d4a5c70118ecadacd4d72b...c6916c7156a711b59f8e6790ff0ee0fedb7bd270
> 
> .
>
>
>
> The SMCWG Chair or Vice-Chair is permitted to update the Relevant Dates
> and Version Number of the S/MIME Baseline Requirements to reflect final
> dates.
>
>
>
> *— MOTION ENDS —*
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
>
> Discussion (7 days)
>
> Start Time: October 25, 2023 17:00 UTC
>
> End Time: November 1, 2023 17:00 UTC
>
>
>
> Vote for approval (7 days)
>
> Start Time: November 1, 2023 17:00 UTC
>
> End Time: November 8, 2023 17:00 UTC
>
>
>
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [cabfpub] Ballot FORUM-019 - Amend Server Certificate Working Group Charter - Discussion Period

[Ben Wilson via Public]

Thanks, Tobias.
I'll take a look at your suggestions and see if I can work in a few
revisions, and then we can restart the discussion period.
Ben

On Thu, Oct 26, 2023 at 12:30 PM Tobias S. Josefowitz 
wrote:

> Hi Ben,
>
> On Mon, 23 Oct 2023, Ben Wilson wrote:
>
> > *Ballot FORUM-019:  Amend Server Certificate Working Group Charter*
> >
> > *Purpose of the Ballot*
> >
> > This ballot proposes changes to the Server Certificate Working Group
> (SCWG)
> > Charter, based on existing version 1.2 of the Charter and on recent
> updates
> > to the Forum's Bylaws.
> >
> > During discussions at Face-to-Face Meeting 58, it was noted that the
> > membership criteria for Certificate Consumers in the SCWG Charter lacked
> > sufficient detail. Since then, through discussions on the mailing list of
> > the SCWG, better criteria for membership of Certificate Consumers in the
> > SCWG have been developed, and the ballot also adds a 6-month probationary
> > period for all applicants to the SCWG before they become voting members.
> >
> > *Motion Begins*
> >
> > MODIFY the Charter of the Server Certificate Working Group as specified
> in
> > the following redline:
> >
> >
> https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce?f029c48cfd8a53ca563904835d6bd5d4b41fa4c8
> >
> > *Motion Ends*
>
> My biggest concern with this Ballot is the language in 4. (d), which
> introduces the limitation of "upon the request of any Member that
> challenges the Applicant's adherence to all of the requirements of section
> 3(a) or 3(b)" for requesting the membership to be decided by a vote.
>
> I recognize that we have members that interpret the current mechanism of
> deciding membership by vote "upon the request of any Member" to only
> result in a vote about the applicant meeting the formal membership
> criteria. Understandably, from that perspective, adding pretty much any
> sensible requirement to the list of formal membership criteria for
> Certificate Consumer members is obviously beneficial and without any
> downsides.
>
> As someone who does not share that perspective but maintains that the
> current "upon the request of any Member" mechanism results in a vote in
> which members can apply a level of discretion which allows at least e.g.
> refusing membership to applicants who's membership (if granted) might
> substantially erode trust into the WebPKI ecosystem or endanger the SCWG's
> ability to maintain and produce documents that are incorporated into root
> program policies in a mostly verbatim fashion, the new language is
> extremely concerning.
>
> When taking into account that the new set of requirements for Certificate
> Consumers can indeed still be trivially met by even a single individual
> with a few hours of time on their hands (unless, maybe, "software product
> intended for use by the general public for browsing the Web securely"
> somehow will turn into a requirement that will not be considered to be
> trivially fulfilled), the new language in my opinion becomes
> disqualifying. I hope that this change to the mechanism can be reverted
> until we have a set of formal membership criteria for Certificate
> Consumers that makes such discretion obsolete.
>
> In addition, I have some minor concerns regarding the new formal
> membership criteria for Certificate Consumers in 3.(b). In particular, for
> the sake of the argument, I assume a browser that generally uses the OS
> root store as a base mechanism (potentially with the ability to exclude
> specific certificates that might be included in the OS root store). It is
> my understanding that for example Google Chrome has worked like this until
> somewhat recently, which to me kind of implies that it ought to be
> considered an acceptable practice for SCWG Certificate Consumer Member
> qualifying software products in good standing. From our discussion during
> the F2F #60 (I am not sure if this was in the SCWG or Forum plenary) I
> understand that you intend
>
>"its membership-qualifying software product uses a list of CA
>certificates to validate the chain of trust from a TLS certificate to a
>CA certificate in such list"
>
> to cover that case. However, such a software as described would indeed use
> different lists on different platforms. We could consider the specific
> version for one platform to be the "membership qualifying software", but
> that does not seem elegant, and might come into conflict with "for the
> general public" in a strict interpretation.
>
> In such a case, it would also be problematic to
>
>"pu

Re: [Servercert-wg] Draft Ballot SC-067: Applicant, Subscriber and Subscriber Agreements - Feedback requested

[Ben Wilson via Servercert-wg]

Just inside lines 276-279, I suggest we replace "Applicant" with
"Applicant/Subscriber" so it would read:

**Applicant/Subscriber Representative**: A natural person or human sponsor
who is either the Applicant/Subscriber, employed by the
Applicant/Subscriber, or an authorized agent who has express authority to
represent the Applicant/Subscriber:

  i. who signs and submits, or approves a certificate request on behalf of
the Applicant/Subscriber, and/or

  ii. who accepts a Subscriber Agreement on behalf of the
Applicant/Subscriber.

Thanks,

Ben

On Wed, Oct 25, 2023 at 7:47 PM Dustin Hollenback via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Hello all,
>
>
>
> This is a request for feedback for this draft ballot.
>
>
>
> Thank you,
>
>
>
>
>
> Dustin
>
>
>
>
>
>
> ---
>
>
>
> *Purpose of Ballot SC-067*
>
> This ballot proposes updates to the Baseline Requirements for the Issuance
> and Management of Publicly-Trusted Certificates related to Subscriber
> Agreements and Terms of Use. It combines the requirements for both into
> only the Subscriber Agreement and clarifies the requirement language. It
> removes the requirement and reference to "Terms of Use". It also modifies
> details related to Subscriber, Applicant, and representatives for them.
>
>
>
> Notes:
>
> •  This removes any ambiguity to ensure that there is no
> requirement that the Subscriber Agreement be legally enforceable when the
> CA and Subscriber are affiliated.
>
> •  This updates definitions for “Applicant”, “Subscriber” and
> “Subscriber Agreement” and removes the definition for “Terms of Use” as
> these separate concepts are creating unnecessary work for CAs and
> Subscribers without adding any value when separated.
>
> •  This adds a new definition for “Applicant/Subscriber” to
> account for scenarios where a person or entity may be either. And renames
> “Applicant Representative” to “Applicant/Subscriber Representative” and
> updated definition to account for reseller scenarios.
>
> •  As observed with other ballots in the past, minor
> administrative updates must be made to the proposed ballot text before
> publication such that the appropriate Version # and Change History are
> accurately represented (e.g., to indicate these changes will be represented
> in Version 2.0.2).
>
> •  This ballot does not modify the “Guidelines for the
> Issuance and Management of Extended Validation Certificates”. More work
> will be made to that document after changes are finalized in this one.
>
>
>
> The following motion has been proposed by Dustin Hollenback of Microsoft,
> and endorsed by Tadahiko Ito of SECOM and Ben Wilson of Mozilla.
>
>
>
> *— Motion Begins —*
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
> based on Version 2.0.1.
>
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
>
>
> Here is a link to the GitHub redline:
>
>
> https://github.com/cabforum/servercert/compare/90a98dc7c1131eaab01af411968aa7330d315b9b...9eebd9949810f698edd5087235acaf16e04ead21
>
>
>
> *— Motion Ends —*
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
>
> *Discussion (7+ days)*
>
> • Start time: -XX-XX 22:00:00 UTC
>
> • End time: -XX-XX 22:00:00 UTC
>
>
>
> *Vote for approval (7 days)*
>
> • Start time: -XX-XX 22:00:00 UTC
>
> • End time: -XX-XX 22:00:00 UTC
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [cabfpub] Forum Ballot to Amend Server Certificate WG Charter

[Ben Wilson via Public]

Thanks for your input, Dimitris.
I've amended section 4.d. as proposed -
https://github.com/cabforum/forum/commit/c6850e24eb49d5cfcb00eae4d11e82544504bffb
Thanks again,
Ben

On Wed, Oct 18, 2023 at 3:03 AM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

>
> Hello Ben,
>
> At F2F58
> <https://cabforum.org/2023/03/02/minutes-of-the-f2f-58-meeting-in-ottawa-canada-28-february-1-march-2023/>we
> had a discussion about the lessons learned from ballot SC60
> <https://cabforum.org/wp-content/uploads/11-CABF_Lessons-learned-from-SC60.pdf>.
> During that meeting, a proposal was made that seems to fix the ambiguity of
> the current Bylaws.
>
> In line 93 of the proposed ballot, it says:
>
> ***(d)** There is a mandatory six-month probationary period during which
> any representative of an Applicant must attend at least 30% of all SCWG
> teleconferences (not counting subcommittee meetings) and at least one SCWG
> face-to-face meeting (either physically or virtually). After successful
> completion of the mandatory probationary period and meeting all
> requirements of section 3(a) or 3(b), an Applicant may become a Voting
> Member, if the SCWG determines by consensus among the Members during a
> Meeting or Teleconference, or upon the request of any Member, by a Ballot
> among the Members, that the Applicant meets the requirements of section
> 3(a) or 3(b). Acceptance by consensus shall be determined, or a Ballot of
> the Members shall be held, as soon as the Applicant indicates that it has
> presented all information required and has responded to all follow-up
> questions from the SCWG and the Applicant has complied with the
> requirements of Section 5.5 of the CA/Browser Forum Bylaws.*
>
>
> Instead of:
>
> *"or upon the request of any Member, by a Ballot among the Members, by a
> Ballot among the Members, that the Applicant meets the requirements of
> section 3(a) or 3(b)" *
>
> please update to:
>
> *"or upon the request of any Member that challenges the Applicant's
> adherence to all of the requirements of section 3(a) or 3(b), by a Ballot
> among the Members."*
>
> I read the rest of the proposed changes and they look good. If you are ok
> with the change above, HARICA would be happy to endorse the ballot.
>
>
> Best regards,
> Dimitris.
>
> On 13/10/2023 1:23 π.μ., Ben Wilson via Public wrote:
>
> All,
>
> I am planning to introduce a Forum ballot to amend the Server Certificate
> Working Group Charter.
>
> At a high level, here are some of the proposed changes:
>
>- Section numbering added
>- "Root Certificate Issuer" voting category removed
>- Membership requirements for Certificate Consumers added
>- 6-month probationary period prior to voting membership added
>- Voting percentages and quorum clarified
>
> Because there are numerous proposed changes, here are a diff and a blob
> for your review.
>
> <http://goog_919727606>
>
> https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...85e569a43a5a2c9e5e16ce8bf1e569a98cfbd720
>
> <https://mail.google.com/mail/u/0/goog_919727603>
>
> https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md
>
> I look forward to your comments and suggestions.
>
> Thanks,
>
> Ben
>
>
> ___
> Public mailing 
> listPublic@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/public
>
>
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Updated Incident Reporting Requirements

[Ben Wilson]

All,

The framework for reporting compliance incidents has been updated on the
CCADB website. See https://www.ccadb.org/cas/incident-report.  Note that
the expected contents in Sections 1 through 7 of an incident report have
changed.

Effective immediately, incident reports should use the markdown template
 and
adhere to the guidance found on the CCADB website. (Additional,
Mozilla-specific guidance is also still provided on our CA wiki -
https://wiki.mozilla.org/CA/Responding_To_An_Incident.)

Thanks,

Ben

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabnQwqck4tO_cO8xCuBBL6OpQbqMWHkhm_zZG8UvHodPQ%40mail.gmail.com.

Re: [cabfpub] Forum Ballot to Amend Server Certificate WG Charter

[Ben Wilson via Public]

All,

I am looking for at least one more endorser for this ballot.

Thanks,

Ben

On Thu, Oct 12, 2023 at 4:23 PM Ben Wilson  wrote:

> All,
>
> I am planning to introduce a Forum ballot to amend the Server Certificate
> Working Group Charter.
>
> At a high level, here are some of the proposed changes:
>
>- Section numbering added
>- "Root Certificate Issuer" voting category removed
>- Membership requirements for Certificate Consumers added
>- 6-month probationary period prior to voting membership added
>- Voting percentages and quorum clarified
>
> Because there are numerous proposed changes, here are a diff and a blob
> for your review.
>
> <http://goog_919727606>
>
> https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...85e569a43a5a2c9e5e16ce8bf1e569a98cfbd720
>
> <https://mail.google.com/mail/u/0/goog_919727603>
>
> https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md
>
> I look forward to your comments and suggestions.
>
> Thanks,
>
> Ben
>
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: CCADB Update: Audit Team Qualifications

[Ben Wilson]

All,

The update to the CCADB, which adds an Audit Team Qualifications document
upload field to the AUDITS tab of  “Add/Update Root Request” cases, is now
complete. (This is mainly for audits that do not include this information
directly in audit statements.)  Under the AUDITS tab of  “Add/Update Root
Request” cases, there are now sections for "Audit Firm" and "Audit Team".

Instructions for this new upload functionality in the CCADB are available
here
<https://docs.google.com/document/d/12U4az-hjYDC_aWsVn8-Y5vVmJ10inVziAxrQoxP-hfI/edit#bookmark=id.q9frfps8jur5>.


As noted in a separate email
<https://groups.google.com/a/ccadb.org/g/public/c/hvhra7upKMU/m/zItEhBVLBgAJ>,
on October 25, 2023, we expect to add a new section 5.2 to the CCADB Policy
(Audit Firm and Audit Team Qualifications), which recounts the expected
contents of a statement of Audit Team Qualifications. Until then, please
refer to each separate root store policy for its audit team qualification
requirements.

Thank you

- Ben, on behalf of the CCADB Steering Committee



On Sun, Oct 15, 2023 at 11:26 AM Ben Wilson  wrote:

> All,
>
> Tomorrow, Monday, October 16, 2023, we will be updating the AUDITS tab of
> “Add/Update Root Request” Cases in the CCADB to provide upload
> functionality for Audit Team Qualifications documents (mainly for WebTrust
> audits, as ETSI audit teams already include this information directly in
> audit statements).
>
> CA Owners should not be impacted during this update and can perform
> routine CCADB functions as expected.
>
> We will send a separate email when the update is complete.
>
> Thank you,
>
> Ben, on behalf of the CCADB Steering Committee
>

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to public+unsubscr...@ccadb.org.
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaZVzsqBB4FT0-kO0myt-KQd7U%3Dzchdpxbjt3TQjwaFzuA%40mail.gmail.com.

CCADB Update: Audit Team Qualifications

[Ben Wilson]

All,

Tomorrow, Monday, October 16, 2023, we will be updating the AUDITS tab of
“Add/Update Root Request” Cases in the CCADB to provide upload
functionality for Audit Team Qualifications documents (mainly for WebTrust
audits, as ETSI audit teams already include this information directly in
audit statements).

CA Owners should not be impacted during this update and can perform routine
CCADB functions as expected.

We will send a separate email when the update is complete.

Thank you,

Ben, on behalf of the CCADB Steering Committee

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to public+unsubscr...@ccadb.org.
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaZmM7S%3DCiR2%3DN1p2AwX6topYKi08OTDn87gx0gy819ufA%40mail.gmail.com.

Intent to Approve Commscope's CA Inclusion Request

[Ben Wilson]

All,
We recently concluded a 6-week public discussion on the CCADB list of the
request for inclusion of root CA certificates by Commscope.  See
https://groups.google.com/a/ccadb.org/g/public/c/HVwBXDw6GnU/m/q2WRYe_TBQAJ.
In accordance with Step 7 of the Mozilla inclusion process,
https://wiki.mozilla.org/CA/Application_Process, this is notice that we
intend to approve Commscope's request. This begins a 7-day "last call" for
objections.
Thanks,
Ben

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZcbq3ZzZXetT_0WUfQCCcDRyz%3DxJBhEUDKS7Lkj05Gmw%40mail.gmail.com.

[cabfpub] Forum Ballot to Amend Server Certificate WG Charter

[Ben Wilson via Public]

All,

I am planning to introduce a Forum ballot to amend the Server Certificate
Working Group Charter.

At a high level, here are some of the proposed changes:

   - Section numbering added
   - "Root Certificate Issuer" voting category removed
   - Membership requirements for Certificate Consumers added
   - 6-month probationary period prior to voting membership added
   - Voting percentages and quorum clarified

Because there are numerous proposed changes, here are a diff and a blob for
your review.


https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce...85e569a43a5a2c9e5e16ce8bf1e569a98cfbd720


https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md

I look forward to your comments and suggestions.

Thanks,

Ben
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: Public Discussion of CommScope CA Inclusion Request

[Ben Wilson]

All,

On August 28, 2023, we began a six-week, public discussion[1] on the
following root CA certificates issued by Commscope:

   1.

   CommScope Public Trust RSA Root-01:

Use cases served/EKUs:

   -

   Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
   -

   Client Authentication 1.3.6.1.5.5.7.3.2


   1.

   CommScope Public Trust RSA Root-02:

Use cases served/EKUs:

   -

   Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
   -

   Client Authentication 1.3.6.1.5.5.7.3.2


   1.

   CommScope Public Trust ECC Root-01

Use cases served/EKUs:

   -

   Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
   -

   Client Authentication 1.3.6.1.5.5.7.3.2


   1.

   CommScope Public Trust ECC Root-02

Use cases served/EKUs:

   -

   Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
   -

   Client Authentication 1.3.6.1.5.5.7.3.2

The public discussion period ended today, October 10, 2023.

Summary of Questions and Responses

One question asked about the particular value that Commscope would add to
the web PKI.

Commscope replied that it had served companies like Motorola, Broadcom,
Verizon, and T-Mobile and that it had manufacturing experience provisioning
solutions for billions of IoT devices. In addition to device manufacturing,
Commscope said that it would serve “device manufacturers and operators of
device fleets, whose requirements are not the same as typical web site
operator.”

One commenter noted that embedded systems tend to run out-of-date software
that is never updated and that using publicly-trusted certificates with
embedded systems harms the WebPKI by holding back progress and that CAs
will sometimes misissue certificates to older devices for compatibility
reasons.

Follow-up questions from two commenters asked how CommScope would ensure
that devices with certificates would stay up-to-date with TLS and WebPKI
ecosystem requirements and how certificates on such devices would be
replaced in the event that an arbitrarily large number of certificates
needed to be revoked within the timelines specified by the CA/Browser
Forum’s Baseline Requirements.

Commscope responded that it participates in CA/Browser Forum discussions
and monitors root programs for rule changes and would take a proactive
approach to compliance with industry standards. They also said that they
would ensure compliance by notifying device manufacturers and service
providers and assist them with updates as needed. Commscope also claimed to
have the capacity for bulk, high-volume certificate revocation and
automated certificate replacement on devices.

Another comment pointed out that Commscope had issued test certificates
with empty SCT extensions.

Commscope explained the difficulty experienced in submitting certificates
to CT logs, and it agreed to revoke and replace the certificates in
question. It also filed an incident report.[2]

One commenter asked whether Commscope would be issuing certificates to
other entities or only to its own products.

Commscope said that it would be issuing certificates to other entities.

Another question was whether Commscope would use ACME?

Commscope said that it supported certificate enrollment using ACME and
CMPv2 and would use them if the deploying organization required their use.

Another question asked about the domain validation methods that Commscope
would use.

Commscope said that it currently uses email to the Domain Contact (BR §
3.2.2.4.2) and DNS Change (BR § 3.2.2.4.7) to perform domain validation,
but that it had the ability to support ACME (“Agreed-Upon Change to Website
– ACME” method (BR § 3.2.2.4.19)) when the business need arises.

Conclusion

We thank the community for its review and consideration during this period.
Root Store Programs will make final inclusion decisions independently, on
their own timelines, and based on each Root Store Member’s inclusion
criteria. Further discussion may take place in the independently managed
Root Store community forums (i.e., MDSP).

Ben

[1]
https://groups.google.com/a/ccadb.org/g/public/c/HVwBXDw6GnU/m/1LsNC19RAQAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1852404#c7

On Thu, Oct 5, 2023 at 10:44 AM 'So, Nicol' via CCADB Public <
public@ccadb.org> wrote:

> On Tue, 03 Oct 2023 05:41:50 -0700, Seo Suchan wrote:
>
>
>
> > what kind of validation methods you'll use for  your certificates? as in
> allowed method numbered in ca/b br? as you said will use acme I guess
> 3.2.2.4.7 /19/20 , right?
>
>
>
> As stated in our CP/CPS, CommScope currently support 2 methods for domain
> control validation:
>
>
>
>- Email to Domain Contact (BR § 3.2.2.4.2)
>- DNS Change (BR § 3.2.2.4.7)
>
>
>
> We have the technical capability to support ACME’s automated domain
> validation methods, but we currently don’t offer them. (ACME can be used
> with external account binding and have domain validation performed outside
> the protocol.) Going forward, we will support the “Agreed-Upon Change to
> Website – ACME” method (BR § 3.2.2.4.19) when the business 

Re: [Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs

[Ben Wilson via Smcwg-public]

gt;
>
> Best Regards,
>
> Rob
>
>
>
> *Dr. Robert Lee MEng PhD*
>
> Senior Software Engineer with Cryptography SME
>
> www.globalsign.co.uk|www.globalsign.eu
>
>
>
>
>
> *From: *Smcwg-public 
>  on behalf of Adriano Santoni via
> Smcwg-public  
> *Date: *Monday, 2 October 2023 at 07:57
> *To: *smcwg-public@cabforum.org 
> 
> *Subject: *Re: [Smcwg-public] [External Sender] Re: [EXTERNAL]-Re: Fields
> for S/MIME CSRs
>
> Not necessarily: the email address can be transmitted to the CA as a
> separate datum.
>
> Indeed, I would say that this is preferable because it allows syntax
> checking on the email address without even starting to look at the CSR,
> from which in my opinion only the public key should be taken.
>
> Adriano
>
>
>
> Il 29/09/2023 21:21, Ben Wilson via Smcwg-public ha scritto:
>
> NOTICE: Pay attention - external email - Sender is
> 0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000...@amazonses.com
>
>
>
>
>
> Shouldn't at least the email address be included, and verified, of course,
> by the CA?
>
>
>
> On Fri, Sep 29, 2023, 11:35 AM Pedro FUENTES  wrote:
>
> +1
>
>
>
>
>
> Le 29 sept. 2023 à 17:52, Clint Wilson via Smcwg-public <
> smcwg-public@cabforum.org> a écrit :
>
> Hi all,
>
>
>
> In my opinion, CSRs should really be limited to conveying the public key
> and a proof of possession of the private key; the fields included therein
> *may* act as confirmatory signals for a CA, but shouldn’t be directly
> relied upon e.g. to generate a tbsCertificate. Rather, the values placed in
> fields of a tbsCertificate should originate from the CA’s validated data
> store to ensure that the only paths for data to become part of a signed
> certificate are through static configurations (e.g. signatureAlgorithm) or
> known-validated data.
>
>
>
> There’s plenty of nuance we can discuss as well, but generally speaking I
> believe it’s bad practice to rely on fields in the CSR.
>
>
>
> Cheers,
>
> -Clint
>
>
>
> On Sep 29, 2023, at 8:27 AM, Ben Wilson via Smcwg-public <
> smcwg-public@cabforum.org> wrote:
>
>
>
> All,
>
> I'm interested in gathering information from Certificate Issuers about the
> kind of information that they would like to collect/extract from the CSRs
> they receive from S/MIME certificate applicants. This information could be
> used to refine a system to generate CSRs that result in certificates
> compliant with the various profiles defined in the S/MIME BRs.
> Alternatively, what is the minimum amount of information that CAs might
> expect to obtain from CSRs? In other words, which fields should a CSR
> generator integrated with a Certificate Consumer's software support?
>
> Thanks,
>
> Ben
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
>
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY=SdzPRXhti18pWLmVPVZwDOe4My0SBGtWzL3HSt02tHKsXpWQUw9YUb_QzXtxZYtw=5yodJ9UuvfVvN_CqY53dyFJyNwYRRJDEfhmuysvXrQA=
>
>
>
> ___
>
> Smcwg-public mailing list
>
> Smcwg-public@cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
>
>
> ___
>
> Smcwg-public mailing list
>
> Smcwg-public@cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
>
> --
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is
> toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
> te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
> welke aard ook, die verband houdt met risico's verbonden aan het
> elektronisch verzenden van berichten.
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. The State
> accepts no liability for damage of any kind resulting from the risks
> inherent in the electronic transmission of messages.
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: Public Discussion of CommScope CA Inclusion Request

[Ben Wilson]

This is just a reminder that this Public Discussion is scheduled to close 
next Tuesday, October 10, 2023.

On Wednesday, September 6, 2023 at 4:39:43 PM UTC-4 So, Nicol wrote:

> On Fri, 01 Sep 2023 08:19:04 -0700, Antonios Chariton wrote:
>
>  
>
> > Will you be a TLS Client Certificate-heavy CA, or will you issue mostly 
> Server certificates?
>
>  
>
> For the near term, we expect the certificates to be used mostly as server 
> certificates.
>
>  
>
> > Do you plan to offer certificates to other entities or will you only be 
> issuing certificates for your own products?
>
>  
>
> We plan to offer our service to external parties as well.
>
>  
>
> > You write:
>
>  
>
> >> CommScope is more than just a standard CA. With its wealth of 
> experience dealing with device manufacturing, deployment and operation, we 
> are also well positioned to serve device manufacturers and operators of 
> device fleets, whose requirements are not the same as typical web site 
> operators.
>
>  
>
> > Based on that, I wanted to ask: have you tried (or plan to use) ACME for 
> these types of operations? If not, what is preventing you from doing so?
>
>  
>
> We support certificate enrollment using ACME and CMPv2. We will use those 
> protocols if the deploying organization requires them.
>
>  
>
> > The WebPKI has evolved to serve website operators, and the vast amount 
> of requirements imposed on all of its CAs have been designed for browsers 
> and websites, so you may have to face challenging circumstances if you try 
> to deviate too far from that. Especially with IoT, where — as Andrew said — 
> revocation and renewal is difficult, especially at these volumes you 
> describe, every incident that occurs will be more difficult to deal with, 
> not just for CommScope, but potentially for other entities involved such as 
> user agents. CAs are also required to implement changes relatively quickly. 
> The typical time frame is either weeks or months. Does that match your 
> expectations and the lifecycle for software updates and changes to your 
> relying parties?
>
>  
>
> Not all revocation-triggering events will affect a large number of 
> devices, and not all issues are security-related and require a 24-hour 
> turnaround time. The devices that we expect to have publicly-trusted 
> certificates provisioned are typically managed devices. If there’s a common 
> cause that requires the certificates of multiple devices to be revoked, 
> determining the devices affected should not be a problem because of the 
> information maintained in the management system and in our own records. The 
> deploying organization can provide us with information about the devices 
> affected, we can quickly add the certificates to the CRL and the OCSP 
> responder.
>
>  
>
> Issues that would require a large number of certificates to be revoke are 
> also a possibility for CAs that serve primarily website operators. For 
> managed devices, there is usually a capability to automate and coordinate 
> the certificate replacement process, which may not be available when the 
> user base consists of website operators with diverse architectures and 
> varying degrees of automation.
>
>  
>
> We understand that the requirements on publicly-trusted certificates will 
> continue to evolve, and we accept that reality.
>
>  
>
> > It’s not clear to me what the purpose of this application is, but 
> perhaps you are limiting your flexibility quite a bit by going down that 
> path. I’m not saying you should, or shouldn’t, I just want to understand if 
> this is all clear from the beginning. You clearly have experience with 
> PKIs, so I just wanted to get your thoughts on the issues above.
>
>  
>
> There are use cases in which managed devices will need to accept 
> connections from devices not owned or controlled by the service provider. 
> Asking subscribers to configure the trust stores on their devices is either 
> technically not possible or unacceptable for other reasons. Being able to 
> issue publicly trusted certificates would enable CommScope to simplify the 
> solution architecture and offer a better solution to our customers.
>
>  
>
> Nicol So
>

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to public+unsubscr...@ccadb.org.
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/96def9a4-30f1-4193-8138-372da87e5b38n%40ccadb.org.

Re: [Smcwg-public] [EXTERNAL]-Re: Fields for S/MIME CSRs

[Ben Wilson via Smcwg-public]

Hi,
It seems simply, as a method of tracking, that Certificate Issuers might
find it helpful to have an email address in the CSR. Plus, if you're
establishing proof of possession, then doesn't it help to know something
about "who" is asserting possession of the key pair? (I don't think a CSR
with only a signed public key is sufficient.) I'm not disagreeing about how
this should be done securely, end-to-end, and I'm certainly not saying that
Certificate Issuers create certificates based solely on CSRs. I'm just
asking for suggestions from Certificate Issuers about a set of common
fields that might be in the most basic type of CSR that would then lead up
to the issuance of an S/MIME certificate, once all of that information has
been validated.
Thanks,
Ben

On Fri, Sep 29, 2023 at 1:33 PM Pedro FUENTES  wrote:

> That’s an interesting point, but the same than there’s no need to consider
> the domains coming in the CSR to issue TLS certificates, I personally don’t
> see the practical need here.
>
> For example… We could have an Enterprise RA that can issue certs for any
> email address in a set of preauthorized domains and this would just make
> the content of the CSR quite irrelevant.
>
> In our case, we rely on other security methods (e.g. authentication
> credentials to the certificate management system) to link the certificate
> request attributes, the domain validation method and the public key in the
> CSR. We just think is better to rely on the verified information and not on
> whatever the CSR had.
>
> Le 29 sept. 2023 à 21:21, Ben Wilson  a écrit :
>
> 
> Shouldn't at least the email address be included, and verified, of course,
> by the CA?
>
> On Fri, Sep 29, 2023, 11:35 AM Pedro FUENTES  wrote:
>
>> +1
>>
>>
>> Le 29 sept. 2023 à 17:52, Clint Wilson via Smcwg-public <
>> smcwg-public@cabforum.org> a écrit :
>>
>> Hi all,
>>
>> In my opinion, CSRs should really be limited to conveying the public key
>> and a proof of possession of the private key; the fields included therein
>> *may* act as confirmatory signals for a CA, but shouldn’t be directly
>> relied upon e.g. to generate a tbsCertificate. Rather, the values placed in
>> fields of a tbsCertificate should originate from the CA’s validated data
>> store to ensure that the only paths for data to become part of a signed
>> certificate are through static configurations (e.g. signatureAlgorithm) or
>> known-validated data.
>>
>> There’s plenty of nuance we can discuss as well, but generally speaking I
>> believe it’s bad practice to rely on fields in the CSR.
>>
>> Cheers,
>> -Clint
>>
>> On Sep 29, 2023, at 8:27 AM, Ben Wilson via Smcwg-public <
>> smcwg-public@cabforum.org> wrote:
>>
>> All,
>> I'm interested in gathering information from Certificate Issuers about
>> the kind of information that they would like to collect/extract from the
>> CSRs they receive from S/MIME certificate applicants. This information
>> could be used to refine a system to generate CSRs that result in
>> certificates compliant with the various profiles defined in the S/MIME BRs.
>> Alternatively, what is the minimum amount of information that CAs might
>> expect to obtain from CSRs? In other words, which fields should a CSR
>> generator integrated with a Certificate Consumer's software support?
>> Thanks,
>> Ben
>> ___
>> Smcwg-public mailing list
>> Smcwg-public@cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc=3Ai2uFDmuPvkjzx8-NXCPUEmAIzjkD-8sGOWakiphpuCLfulDVnTYuieselnddbL=DlmLTfjyPj2kGhM6d66NyUTRj15XswMU-gv6MKDY5F8=>
>>
>>
>> ___
>> Smcwg-public mailing list
>> Smcwg-public@cabforum.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY=SdzPRXhti18pWLmVPVZwDOe4My0SBGtWzL3HSt02tHKsXpWQUw9YUb_QzXtxZYtw=5yodJ9UuvfVvN_CqY53dyFJyNwYRRJDEfhmuysvXrQA=
>>
>>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Smcwg-public] [EXTERNAL]-Re: Fields for S/MIME CSRs

[Ben Wilson via Smcwg-public]

Shouldn't at least the email address be included, and verified, of course,
by the CA?

On Fri, Sep 29, 2023, 11:35 AM Pedro FUENTES  wrote:

> +1
>
>
> Le 29 sept. 2023 à 17:52, Clint Wilson via Smcwg-public <
> smcwg-public@cabforum.org> a écrit :
>
> Hi all,
>
> In my opinion, CSRs should really be limited to conveying the public key
> and a proof of possession of the private key; the fields included therein
> *may* act as confirmatory signals for a CA, but shouldn’t be directly
> relied upon e.g. to generate a tbsCertificate. Rather, the values placed in
> fields of a tbsCertificate should originate from the CA’s validated data
> store to ensure that the only paths for data to become part of a signed
> certificate are through static configurations (e.g. signatureAlgorithm) or
> known-validated data.
>
> There’s plenty of nuance we can discuss as well, but generally speaking I
> believe it’s bad practice to rely on fields in the CSR.
>
> Cheers,
> -Clint
>
> On Sep 29, 2023, at 8:27 AM, Ben Wilson via Smcwg-public <
> smcwg-public@cabforum.org> wrote:
>
> All,
> I'm interested in gathering information from Certificate Issuers about the
> kind of information that they would like to collect/extract from the CSRs
> they receive from S/MIME certificate applicants. This information could be
> used to refine a system to generate CSRs that result in certificates
> compliant with the various profiles defined in the S/MIME BRs.
> Alternatively, what is the minimum amount of information that CAs might
> expect to obtain from CSRs? In other words, which fields should a CSR
> generator integrated with a Certificate Consumer's software support?
> Thanks,
> Ben
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY=SdzPRXhti18pWLmVPVZwDOe4My0SBGtWzL3HSt02tHKsXpWQUw9YUb_QzXtxZYtw=5yodJ9UuvfVvN_CqY53dyFJyNwYRRJDEfhmuysvXrQA=
>
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Servercert-wg] Draft Ballot SC-0XX: Subscriber Agreement and Terms of Use Consolidation

[Ben Wilson via Servercert-wg]

gt; •      As observed with other ballots in the past, minor
> administrative updates must be made to the proposed ballot text before
> publication such that the appropriate Version # and Change History are
> accurately represented (e.g., to indicate these changes will be represented
> in Version 2.0.2).
>
>
>
>
>
> The following motion has been proposed by Ben Wilson of Mozilla and Dustin
> Hollenback of Microsoft. And, endorsed by  of  and 
> of .
>
>
>
> *— Motion Begins —*
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
> based on Version 2.0.1.
>
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
> https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3..663695b8319c0cd32e0060bb9304ecd32e3737a1
> <https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3..663695b8319c0cd32e0060bb9304ecd32e3737a1__;!!FJ-Y8qCqXTj2!cTf7q-EEAEVm0LT2ug70IF3s4t8FCXgREddMCUuLm1rTgEuN6Kse1ScaMIvCrxQiyQbZDkyGiDpbkZHIVjGH05JaZfEwqw$>
>
>
>
> *— Motion Ends —*
>
>
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
>
> *Discussion (13+ days)*
>
> • Start time: -MM-DD 19:00:00 UTC
>
> • End time: -MM-DD 19:00:00 UTC
>
>
>
> *Vote for approval (7 days)*
>
> • Start time: -MM-DD 19:00:00 UTC
>
> • End time: -MM-DD 19:00:00 UTC
>
>
>
>
>
> *Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.*
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

[Smcwg-public] Fields for S/MIME CSRs

[Ben Wilson via Smcwg-public]

All,
I'm interested in gathering information from Certificate Issuers about the
kind of information that they would like to collect/extract from the CSRs
they receive from S/MIME certificate applicants. This information could be
used to refine a system to generate CSRs that result in certificates
compliant with the various profiles defined in the S/MIME BRs.
Alternatively, what is the minimum amount of information that CAs might
expect to obtain from CSRs? In other words, which fields should a CSR
generator integrated with a Certificate Consumer's software support?
Thanks,
Ben
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Servercert-wg] Proposed Revision of SCWG Charter

[Ben Wilson via Servercert-wg]

Here is another revision based on comments received today -
https://github.com/cabforum/forum/blob/BenWilson-SCWG-charter-1.3/SCWG-charter.md,
which currently reads in relevant parts:

*3. (b) Certificate Consumer:* The Certificate Consumer voting class shall
consist of eligible organizations meeting the following criteria:

(1) it produces a software product intended for use by the general public
for browsing the Web securely;

(2) it provides updates for its membership-qualifying software product at
least every 6 months to ensure that customers of the Certificate Consumer
are getting regular security patches;

(3) it has public documentation stating that it requires Certificate
Issuers to comply with the TLS Baseline Requirements;

(4) its membership-qualifying software product uses a list of CA
certificates to validate the chain of trust from a TLS certificate to a CA
certificate in such list;

(5) it publishes the list of CA certificates used to validate the chain of
trust from a TLS certificate to a CA certificate in such list; *and*

(6) it publishes how it adds or removes a CA certificate from such list.

...

*4. (c)* Applicants that qualify as Certificate Consumers must supply the
following additional information:

   -

   URL from which to download its software product intended for use by the
   general public for browsing the Web securely;
   -

   URL or other evidence demonstrating that it provides updates for its
   membership-qualifying software product at least every 6 months;
   -

   URL to its statement requiring Certificate Issuer compliance with the
   TLS Baseline Requirements;
   -

   URL for its list of CA certificates that its membership-qualifying
   software product uses to validate the chain of trust from a TLS certificate
   to a CA certificate in such list; and
   -

   URL or other evidence explaining its process for adding or removing a CA
   certificate from such list.

...

*5. (a) Certificate Consumer:* A Certificate Consumer Member is suspended,
and its right to vote automatically ceases, if any of the following become
true:

   -

   six (6) months have elapsed since it last updated its
   membership-qualifying software product;
   -

   it ceases to require that Certificate Issuers comply with the TLS
   Baseline Requirements;
   -

   its membership-qualifying software product ceases to use a list of CA
   certificates to validate the chain of trust from a TLS certificate to a CA
   certificate in such list;
   -

   it ceases to publish such list of CA certificates used to validate the
   chain of trust; *or*
   -

   it ceases to publish how it adds or removes a CA certificate from such
   list.


I'm open to comments and suggestions.

Thanks,

Ben

On Tue, Sep 26, 2023 at 6:00 PM Aaron Gable  wrote:

> Totally understood regarding CT Logs. It's something I think we should
> pursue, but perhaps not on this timeline.
>
> I would prefer that Certificate Consumers be required to "maintain" a list
> of CA certificates. This maintenance can be as simple as copying some other
> Root Program's list of trusted certificates. But I think it's helpful to
> have a requirement that Certificate Consumers actively decide whether to
> include individual certificates, or whether to take updates from their
> upstream trust store, on an ongoing basis.
>
> Aaron
>
> On Mon, Sep 25, 2023 at 4:35 PM Ben Wilson  wrote:
>
>> Thanks, Martijn and Aaron,
>>
>> Aaron, I don't think I can add a CT-support requirement for Certificate
>> Consumers at this time, although we can take the issue up for further
>> conversation.
>>
>> Martijn, So that the duration of the probationary period is kept to six
>> months, it might be better to eliminate the F2F attendance requirement. If
>> we keep it, then a probationary member might have to wait until the next
>> F2F (but certainly not a year).  How do people feel about this?
>>
>> Also, I have received feedback regarding whether a Certificate Consumer
>> should be required to "maintain" a full list of CAs. (I think I didn't have
>> the term "maintain" in the GitHub draft of the charter, so I'm thinking
>> that we might eliminate the term from the proposal.) Similarly, I'm
>> concerned that a requirement to publish "how a CA can apply for
>> inclusion in its root store" might make it less likely for a ballot to
>> pass. So, instead of "maintaining" a (full) list, what if we left it just,
>> "(4) its membership-qualifying software product uses a list of CA
>> certificates to validate the chain of trust from a TLS certificate to a CA
>> certificate in such list"?  What are everyone's thoughts on this?
>>
>> Thanks,
>>
>> Ben
>>
>> On Thu, Sep 14, 2023 at 9:23 AM Aaron Gable 
>> wrote:
>

Improvements to Vulnerability Disclosure wiki page

[Ben Wilson]

All,
As mentioned in a previous email, I am soliciting feedback regarding
the Vulnerability
Disclosure wiki page .
If you have any specific suggestions that we can use to enhance clarity or
to make the page more complete, please don't hesitate to share them, either
here or directly with me. Your feedback is instrumental in our commitment
to maintain a safe and secure online environment.
Thanks,
Ben

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabWhCfgKCOiH75pgtw1AQcNaKWjq%3Dq832p-pQbp5KrfyQ%40mail.gmail.com.

Re: MRSP 2.9: Survey Results - August 2023 CA Communication and Survey

[Ben Wilson]

cident Reporting”, the guidance says that “information does
not need to be duplicated in the Reportable Vulnerability bug if it can be
provided in the public-facing incident report.” Given the overlap and link
between these processes, clarification is needed regarding the
interdependencies between Incident Reports and Reportable Vulnerability
bugs.

Mozilla Response:  As stated in the wiki page, the purpose of MRSP 2.4.1
and the “CA Security Vulnerability” Bugzilla component is to enable CAs to
provide Mozilla with “Information about security compromises that require
action from Mozilla” and “Security-sensitive information that needs to be
shared with Mozilla”. Thus, CAs need to be sure to mark the “CA Program
Security” checkbox in such Bugzilla reports.

We welcome specific suggestions about how to improve the text in the
Vulnerability Disclosure wiki page. For that purpose, I am sending out a
separate post to this list, and then we will update the wiki page and try
to clarify the use of these terms accordingly.

Thanks,

Ben and Kathleen

On Mon, Sep 18, 2023 at 10:01 AM Ben Wilson  wrote:

> All,
> The period for submitting survey responses has now concluded, and the
> results are in the sheet linked below (in my previous email).
> I will now summarize the comments and post them here.
> Thanks,
> Ben
>
> On Fri, Sep 8, 2023 at 2:12 PM Ben Wilson  wrote:
>
>> All,
>>
>> While survey responses are not due until Sept. 15th, here are the results
>> we've received thus far.
>>
>>
>> https://docs.google.com/spreadsheets/d/1xJ6VRs2R0tw3-QHoIRzIIO8MWWoqNs576KOxPKYsp3w/edit?usp=sharing
>>
>> Thanks,
>>
>> Ben
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZPf2-8jsqgNbTL%3DEqAOXC4DTDQhJgo0psNz_cvnVqSdg%40mail.gmail.com.

Re: [Servercert-wg] Proposed Revision of SCWG Charter

[Ben Wilson via Servercert-wg]

Thanks, Martijn and Aaron,

Aaron, I don't think I can add a CT-support requirement for Certificate
Consumers at this time, although we can take the issue up for further
conversation.

Martijn, So that the duration of the probationary period is kept to six
months, it might be better to eliminate the F2F attendance requirement. If
we keep it, then a probationary member might have to wait until the next
F2F (but certainly not a year).  How do people feel about this?

Also, I have received feedback regarding whether a Certificate Consumer
should be required to "maintain" a full list of CAs. (I think I didn't have
the term "maintain" in the GitHub draft of the charter, so I'm thinking
that we might eliminate the term from the proposal.) Similarly, I'm
concerned that a requirement to publish "how a CA can apply for inclusion
in its root store" might make it less likely for a ballot to pass. So,
instead of "maintaining" a (full) list, what if we left it just, "(4) its
membership-qualifying software product uses a list of CA certificates to
validate the chain of trust from a TLS certificate to a CA certificate in
such list"?  What are everyone's thoughts on this?

Thanks,

Ben

On Thu, Sep 14, 2023 at 9:23 AM Aaron Gable  wrote:

> Hi all,
>
> I have a very different proposal for a Certificate Consumer membership
> criterion. I have no objection to any of the currently-proposed criteria;
> this could easily be in addition to them. What if we added:
>
> > (c) Applicants that qualify as Certificate Consumers must supply the
> following additional information:
> > - URL for its list of CA certificates that its membership-qualifying
> software product uses to validate the chain of trust from a TLS certificate
> to a CA certificate in such list; and
> > *- URL for the Certificate Transparency log which it operates within
>  and which accepts all submissions for TLS
> certificates which chain up to any CA certificate in the list above*; and
>
> Frankly, the Certificate Transparency ecosystem is in peril at the moment.
> With the recent shutdown of Sectigo's Mammoth
> <https://groups.google.com/a/chromium.org/g/ct-policy/c/Ebj2hhe5QYA/m/Cl7IW33UAgAJ>
> log and retirement of DigiCert's Yeti
> <https://groups.google.com/a/chromium.org/g/ct-policy/c/PVbs0ZMVeCI/m/Hf8kwuuAAQAJ>
> and Nessie
> <https://groups.google.com/a/chromium.org/g/ct-policy/c/MXLJFHdHdFo>
> logs, the already-tiny handful of organizations
> <https://googlechrome.github.io/CertificateTransparency/log_list.html> 
> operating
> usable CT logs is feeling even smaller. So what if Certificate Consumers --
> the organizations which benefit most from a diverse and robust ecosystem of
> CT logs -- were required to bring their own to the table? Running a CT log
> is clearly non-trivial, so such a requirement would effectively demonstrate
> that potential Certificate Consumer members are serious about operating for
> the good of the ecosystem in the long term.
>
> Thanks,
> Aaron
>
> On Fri, Sep 1, 2023 at 1:42 AM Martijn Katerbarg via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
>> Ben,
>>
>>
>>
>> This seems like a good option. I’d say maybe we need to increase the 6
>> months period to 12, otherwise within a 6 months period there may only be 1
>> F2F. Requiring attendance (remote or in-person) if there’s only 1 F2F in
>> the time-span, could be hard if there’s a case of bad timing.
>>
>>
>>
>> Additionally, I’d like to request the addition of an additional criteria
>> (although it’s related to the “publish how it decides to add or remove a CA
>> certificate from its list.” item. I’d like to request we add a requirement
>> to:
>>
>>
>>
>>- Publish how a CA can apply for inclusion in its root store
>>
>>
>>
>> With this addition, I’d be happy to endorse
>>
>>
>>
>> Regards,
>>
>> Martijn
>>
>>
>>
>> *From:* Servercert-wg  *On Behalf Of
>> *Ben Wilson via Servercert-wg
>> *Sent:* Thursday, 31 August 2023 00:50
>> *To:* CA/B Forum Server Certificate WG Public Discussion List <
>> servercert-wg@cabforum.org>
>> *Subject:* [Servercert-wg] Proposed Revision of SCWG Charter
>>
>>
>>
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you recognize the sender and know
>> the content is safe.
>>
>>
>>
>> All,
>>
>>
>>
>> Thanks for your suggestions and recommendations. I think we are much
>> closer to an acceptable revision of the Server Certificate Working Grou