[Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Mon Oct 14 11:28:12 UTC 2024
On 10/10/2024 5:42 μ.μ., Ryan Dickson via Servercert-wg wrote:
> Hi Yoshihiko,
>
> Thanks for clarifying your question.
>
> In my opinion, as currently written, the phrase “direct contact" is
> not well-defined by the TLS BRs.
>
> My interpretation of “direct contact" between a CA and the Domain Name
> Registrar is a phone-call or email between representatives of the two
> organizations, possibly also involving some sort of automated system.
>
> To help better describe my interpretation, please see the illustrative
> examples below:
>
> Phone or Email:
> - CA representative calls/emails the Registrar.
> - A representative of the Registrar authenticates the CA representative.
> - The CA representative asks the Registrar representative to look up
> the Domain Contact information for the target domain.
> - The Registrar representative looks up the Domain Contact information
> by relying on its authoritative database / source of truth, and shares
> this with the CA representative.
> - The CA representative uses the Domain Contact information as
> permitted by the TLS BRs.
>
> Automated System:
> - CA representative submits a form requesting Domain Contact
> information from the Registrar.
> - The Registrar authenticates the requestor.
> - The Registrar looks up the Domain Contact information by relying on
> its authoritative database / source of truth, and shares this with the
> CA representative (e.g., phone or email).
> - The CA representative uses the Domain Contact information as
> permitted by the TLS BRs.
>
Hi Ryan,
I don't think the Registrar needs to necessarily authenticate the CA
representative. Some Registrars offer the Domain Contact information
publicly. It is similar to the WHOIS process where no authentication is
needed by default.
> My interpretation is heavily influenced by language in the TLS EVGs
> which, in my opinion, establishes framing for the communication
> mechanisms considered by “direct contact" through phrasing such as “or
> by direct contact with the Incorporating or Registration Agency in
> person or via mail, e‐mail, Web address, or telephone, using an
> address or phone number obtained directly from the Qualified
> Government Information Source, Incorporating or Registration Agency,
> or from a Qualified Independent Information Source.” (from 3.2.2.2.2
> (“Acceptable Method of Verification"))
Equally, the Applicant doesn't need to "authenticate" the CA for the
communication to be considered "direct".
>
> Consequently, I would not consider querying a Registrar’s WHOIS
> service to constitute “direct contact.” I further interpret the
> WatchTowr report [1] to have demonstrated flaws with several Registrar
> WHOIS-function websites.
I kind of disagree because the intent of the requirement has always been
to allow the WHOIS/RDAP service to be used in "direct contact" with the
Registrar. I'm sure the Registrar's website was considered part of the
"Web address" language of the EV Guidelines, so discovering Domain
Contact information by using the Registrar's web site is also considered
acceptable.
>
> If this interpretation is misaligned with others’ expectations,
> discussion is welcome.
I'm sure others can join the discussion as well.
Thank you,
Dimitris.
>
> Thanks,
> Ryan
> [1]
> https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/
>
> On Thu, Oct 10, 2024 at 6:27 AM Matsuo Yoshihiko
> <yoshihiko at jprs.co.jp> wrote:
>
> Hi Ryan,
>
> Thank you for your reply.
>
> I feel like I didn't express my points clearly in the previous
> email, so please disregard it.
>
> I apologize for the confusion, but I have reorganized the point I
> would like to confirm as follows:
>
> I am considering updating our system implementation for obtaining
> Domain Contact in light of this revision.
>
> BR defines the source of Domain Contact as follows.
> #1 WHOIS record
> #2 DNS SOA record
> #3 direct contact with the Domain Name Registrar
>
> The questions I would like to ask is...
>
>
> Could it be interpreted that retrieving Domain Contact information
> from the Whois operated by the Domain Name Registrar itself falls
> under "3 direct contact with the Domain Name Registrar"?
> I would like to hear your opinion on this.
>
> Thanks,
>
> Yoshihiko Matsuo(JPRS)
>
>
> On Tue, 8 Oct 2024 15:10:38 -0400
> Ryan Dickson <ryandickson at google.com> wrote:
>
> > Hi Yoshihiko,
> >
> > The definition for “Domain Contact" (unchanged by the proposal)
> is: “The
> > Domain Name Registrant, technical contact, or administrative
> contact (or
> > the equivalent under a ccTLD) as listed in the WHOIS record of
> the Base
> > Domain Name or in a DNS SOA record, or as obtained through
> direct contact
> > with the Domain Name Registrar.”
> >
> > The definition for “Domain Name Registrar" (also unchanged by
> the proposal)
> > is: “A person or entity that registers Domain Names under the
> auspices of
> > or by agreement with:
> > - the Internet Corporation for Assigned Names and Numbers (ICANN),
> > - a national Domain Name authority/registry, or
> > *- a Network Information Center (including their affiliates,
> contractors,
> > delegates, successors, or assignees)*.”
> >
> > For the circumstances described in your message, can you please
> confirm
> > whether the organization operating the CA is considered:
> > - ONLY the ccTLD Domain Name Authority/Registry
> > - ONLY the Domain Name Registrar
> > - BOTH the ccTLD Domain Name Authority/Registry and sometimes a
> Domain Name
> > Registrar
> > - BOTH the ccTLD Domain Name Authority/Registry and always the
> Domain Name
> > Registrar
> >
> > Given the definition of “Domain Contact" and its reference in
> 3.2.2.4.2,
> > 3.2.2.4.12, and 3.2.2.4.15, I believe the distinction between
> roles (Domain
> > Name Authority/Registry and Domain Name Registrar) is important.
> >
> > Thanks,
> >
> > Ryan
> >
> >
> >
> >
> > On Tue, Oct 8, 2024 at 7:29?AM Yoshihiko Matsuo via Servercert-wg <
> > servercert-wg at cabforum.org> wrote:
> >
> > > All,
> > >
> > > > The only method relying on identifying a “Domain Contact" via
> > > registration data left by the ballot is 3.2.2.4.12
> (“Validating Applicant
> > > as a Domain Contact"). This was originally excluded from the
> scope of
> > > sunsets given the expectation that in cases where the organization
> > > operating the CA was also the Domain Name Registrar (or an
> Affiliate),
> > > there would be (1) a lower likelihood of unreliable Domain Contact
> > > information given a direct relationship with the
> subscriber/subscriber
> > > organization, and (2) a higher potential for seamless
> certificate lifecycle
> > > management because of that relationship. Regardless of whether
> this
> > > expectation is misguided, nothing stops a future ballot from
> contemplating
> > > the further improvement or sunset of 3.2.2.4.12 (“Validating
> Applicant as a
> > > Domain Contact").
> > >
> > > We are the CA, and at the same time we are also the gTLD
> Registrar and the
> > > ccTLD Registry.
> > > In this case, I understand that it is acceptable to use the Domain
> > > Contacts we hold as The gTLD Registrar for DCV.I would like to
> hear your
> > > opinions on whether the same can be said for the Domain
> Contacts we hold as
> > > the ccTLD Registry.
> > >
> > > Note: We require that ccTLD Domain Contacts be kept current as
> the contact
> > > information for the domain name registrant.
> > >
> > > With this question, I would like to clarify whether the BR
> allows the
> > > following cases.
> > >
> > > 1. The CA that is also the ccTLD Registry retrieves Domain
> Contacts from
> > > its own database and performs validation in accordance with
> 3.2.2.4.2.
> > >
> > > 2. The CA that is also the ccTLD Registry retrieves Domain
> Contacts from
> > > the WHOIS operated by the ccTLD Registry (which is also a CA)
> and performs
> > > validation in accordance with 3.2.2.4.2.
> > >
> > > Thanks,
> > > Yoshihiko Matsuo(JPRS)
> > >
> > >
> > > On 2024/10/08 4:49, Ryan Dickson via Servercert-wg wrote:
> > > > Hi Doug,
> > > >
> > > > > The title, purpose and background of this ballot define
> the removal
> > > of WHOIS and does not discuss any other changes, but we’re
> actually
> > > sunsetting other aspects of domain validation while also
> leaving method
> > > 3.2.2.4.12 that can continue to use WHOIS.
> > > >
> > > > I feel “Objective 2", included in the “Background" section,
> makes the
> > > intent to sunset methods clear (the objective's description
> is: "/Sunset
> > > Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain
> Contact”) and
> > > 3.2.2.4.15 (“Phone Contact with Domain Contact")/").
> > > >
> > > > Would changing the title to something like “/Strengthen
> registration
> > > data lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15/" help?
> > > >
> > > > > I understand the desire to remove WHOIS based on the recent
> > > incident(s), but if we’re going to focus on sunsetting WHOIS,
> we should
> > > 100% sunset it for all uses and we should not include the
> removal of other
> > > methods within this ballot.
> > > >
> > > > All methods relying on identifying Domain Contacts via
> registration data
> > > are strengthened by this ballot, beginning January 15, 2025.
> This includes
> > > methods:
> > > > - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain
> Contact")
> > > > - 3.2.2.4.12 (“Validating Applicant as a Domain Contact")
> > > > - 3.2.2.4.15 (“Phone Contact with Domain Contact")
> > > >
> > > > The ballot goes on to sunset the following methods,
> beginning July 15,
> > > 2025:
> > > > - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain
> Contact")
> > > > - 3.2.2.4.15 (“Phone Contact with Domain Contact")
> > > >
> > > > The only method relying on identifying a “Domain Contact" via
> > > registration data left by the ballot is 3.2.2.4.12
> (“Validating Applicant
> > > as a Domain Contact"). This was originally excluded from the
> scope of
> > > sunsets given the expectation that in cases where the organization
> > > operating the CA was also the Domain Name Registrar (or an
> Affiliate),
> > > there would be (1) a lower likelihood of unreliable Domain Contact
> > > information given a direct relationship with the
> subscriber/subscriber
> > > organization, and (2) a higher potential for seamless
> certificate lifecycle
> > > management because of that relationship. Regardless of whether
> this
> > > expectation is misguided, nothing stops a future ballot from
> contemplating
> > > the further improvement or sunset of 3.2.2.4.12 (“Validating
> Applicant as a
> > > Domain Contact").
> > > >
> > > > If there’s a case to make for including 3.2.2.4.12 in the
> sunsets
> > > covered in the proposal, it’s also welcome.
> > > >
> > > > > The VWG can be tasked to review methods we think are weak
> and discuss
> > > removing them, for example, imo, all the methods that rely on
> phone calls
> > > (Domain and IP address both), which to me are weaker than
> automated methods
> > > like using they SOA record.
> > > >
> > > > I agree that it’s important for this community to routinely
> re-evaluate
> > > the DCV methods permitted by the TLS BRs and consider them
> against a set of
> > > desirable security and operational properties that best enable
> subscriber
> > > organizations to make securely managing their TLS
> implementations “boring"
> > > (effortless, routine, reliable, and without excitement - even
> when facing
> > > the unexpected).
> > > >
> > > > Periodically over the past three years (when I joined this
> community),
> > > I’ve participated in discussions where members have expressed
> a desire for
> > > improved DCV methods, which has included suggestions to remove
> perceived
> > > weak methods (with those that are phone or email-based cited
> as examples).
> > > While very few of these discussions have led to direct action,
> this ballot
> > > presents a proactive opportunity to address some of those
> concerns, along
> > > with mitigating concerns related to registration data lookups
> identified by
> > > recent events.
> > > >
> > > > I do not believe a holistic evaluation of the DCV-methods
> permitted by
> > > the TLS BRs needs to be a blocking function on this ballot,
> and that both
> > > activities can take place independently of one another.
> > > >
> > > > Thanks,
> > > > Ryan
> > > >
> > > >
> > > > On Mon, Oct 7, 2024 at 7:35?AM Doug Beattie
> <doug.beattie at globalsign.com
> > > <mailto:doug.beattie at globalsign.com>> wrote:
> > > >
> > > > Hi Ryan,____
> > > >
> > > > __ __
> > > >
> > > > The title, purpose and background of this ballot define
> the removal
> > > of WHOIS and does not discuss any other changes, but we’re
> actually
> > > sunsetting other aspects of domain validation while also
> leaving method
> > > 3.2.2.4.12 that can continue to use WHOIS. Part of this is the
> > > unfortunately extremely broad definition of “Domain Contact”
> and “Domain
> > > Name Registrant” and the wide scope of 3.2.2.4.2, which I
> agree we need to
> > > clarify and fix. I understand the desire to remove WHOIS
> based on the
> > > recent incident(s), but if we’re going to focus on sunsetting
> WHOIS, we
> > > should 100% sunset if for all uses and we should not include
> the removal of
> > > other methods within this ballot. The VWG can be tasked to
> review methods
> > > we think are weak and discuss removing them, for example, imo,
> all the
> > > methods that rely on phone calls (Domain and IP address both),
> which to me
> > > are weaker than automated methods like using they SOA record.____
> > > >
> > > > __ __
> > > >
> > > > Doug____
> > > >
> > > > __ __
> > > >
> > > > *From:*Ryan Dickson <ryandickson at google.com <mailto:
> > > ryandickson at google.com>>
> > > > *Sent:* Friday, October 4, 2024 2:55 PM
> > > > *To:* Doug Beattie <doug.beattie at globalsign.com <mailto:
> > > doug.beattie at globalsign.com>>
> > > > *Cc:* CA/B Forum Server Certificate WG Public Discussion
> List <
> > > servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>>
> > > > *Subject:* Re: [Servercert-wg] Discussion Period Begins
> - Ballot
> > > SC-080 V2: "Sunset the use of WHOIS to identify Domain
> Contacts and relying
> > > DCV Methods”____
> > > >
> > > > __ __
> > > >
> > > > Hi Doug,____
> > > >
> > > > __ __
> > > >
> > > > Your interpretation of the latest version of the ballot
> is correct.
> > > ____
> > > >
> > > > __ __
> > > >
> > > > As currently presented, Method 3.2.2.4.2 (“Email, Fax,
> SMS, or
> > > Postal Mail to Domain Contact”) and Method 3.2.2.4.15 (“Phone
> Contact with
> > > Domain Contact”) are sunset, in their entirety, effective July
> 15, 2025.
> > > ____
> > > >
> > > > __ __
> > > >
> > > > Specific to domain contact email addresses from SOA
> records, can you
> > > share your perspective for adding this specific option given
> the existence
> > > of (1) other email-based alternatives (e.g., 3.2.2.4.4,
> 3.2.2.4.13 and
> > > 3.2.2.4.14) and (2) other far more heavily relied upon DCV
> methods that
> > > present an opportunity for improved automation and scalability
> (and also
> > > benefit from MPIC)?____
> > > >
> > > > __ __
> > > >
> > > > For example, detailing responses below would be helpful for
> > > understanding:____
> > > >
> > > > * existing reliance on this specific approach in
> comparison to the
> > > other DCV methods offered?____
> > > > * how this reliance has trended over time (e.g., last
> 1 / 3 / 5
> > > years)?____
> > > > * how the sunset would affect subscribers?____
> > > > * a general description of the level of effort for
> affected
> > > subscribers to transition to another method?____
> > > > * what barriers exist that prevent subscribers from
> transitioning
> > > to other methods?____
> > > >
> > > > __ __
> > > >
> > > > I think it’s reasonable for the community to approach
> RNAME lookups
> > > with the same degree of concern for accuracy and reliability as
> > > registration data due to the potential for:____
> > > >
> > > > * neglected configurations (e.g., in 2020, [1]
> indicated only
> > > 39.74% of a set of “top” 1M domains contained “reachable” SOA
> contacts, and
> > > only approximately 20% of the sampled .com and .net domains
> did).____
> > > > * potential CA reliance on third-party tools with unknown
> > > operational characteristics for performing SOA lookups (the
> same concern as
> > > WHOIS lookups using HTTPS websites).____
> > > > * a lack of oversight and enforcement for ensuring SOA
> record
> > > updates (e.g, accuracy/correctness and timeliness).____
> > > > * use of automated DNS management solutions that can
> result in an
> > > unintended and/or unknown delegation of authority to approve TLS
> > > certificates, while also representing a single point of
> failure (or
> > > attack).____
> > > >
> > > > __ __
> > > >
> > > > Thanks,____
> > > >
> > > > Ryan____
> > > >
> > > > __ __
> > > >
> > > > [1] https://mkorczynski.com/WTMC2020.pdf <
> > > https://mkorczynski.com/WTMC2020.pdf>____
> > > >
> > > > __ __
> > > >
> > > > __ __
> > > >
> > > > On Thu, Oct 3, 2024 at 9:57?AM Doug Beattie <
> > > doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com>>
> > > wrote:____
> > > >
> > > > Hey Ryan,____
> > > >
> > > > ____
> > > >
> > > > The way I read the ballot is that using domain
> approver email
> > > addresses from SOA records is being removed since that’s part of
> > > 3.2.2.4.2. Should we add a new method specifically for that,
> or was the
> > > intent to remove that as a valid location to obtain domain
> approver email
> > > addresses?____
> > > >
> > > >
> > > > Doug____
> > > >
> > > > ____
> > > >
> > > > *From:*Servercert-wg <servercert-wg-bounces at cabforum.org
> > > <mailto:servercert-wg-bounces at cabforum.org>> *On Behalf Of
> *Ryan Dickson
> > > via Servercert-wg
> > > > *Sent:* Tuesday, October 1, 2024 12:59 PM
> > > > *To:* ServerCert CA/BF <servercert-wg at cabforum.org
> <mailto:
> > > servercert-wg at cabforum.org>>
> > > > *Subject:* [Servercert-wg] Discussion Period Begins
> - Ballot
> > > SC-080 V2: "Sunset the use of WHOIS to identify Domain
> Contacts and relying
> > > DCV Methods”____
> > > >
> > > > ____
> > > >
> > > > *_Purpose of Ballot SC-080 V2:
> > > > _*This ballot proposes updates to the Baseline
> Requirements for
> > > the Issuance and Management of Publicly-Trusted TLS Server
> Certificates
> > > (TLS BRs) to address concerns regarding the use of WHOIS and
> HTTPS websites
> > > for identifying Domain Contacts.
> > > >
> > > > *_Background:
> > > > _*This ballot intends to accomplish two objectives,
> originally
> > > described in [1].____
> > > >
> > > > Objective 1: Enhance WHOIS/RDAP validation of gTLDs with
> > > comparable security properties to DNS-based validation and sunset
> > > WHOIS/RDAP for ccTLDs.
> > > >
> > > > _Justification:_____
> > > >
> > > > * A recent disclosure [2] demonstrated how threat
> actors could
> > > exploit deficiencies in the WHOIS protocol and WHOIS tools
> served via HTTPS
> > > websites to obtain fraudulent TLS certificates.____
> > > > * Discussions within the Mozilla Dev Security
> Policy (MDSP)
> > > community [3] further expressed corresponding risks related to
> WHOIS, while
> > > also noting that ccTLDs may not maintain accurate or
> up-to-date WHOIS
> > > server records. Several examples of inoperative WHOIS servers
> for ccTLDs
> > > were identified.____
> > > > * Discussion in [4] further called into question the
> > > reliability of ccTLD WHOIS servers given, per IANA, there is
> no global
> > > policy requirement for ccTLD managers to operate a WHOIS
> server, and if
> > > they do, what kind of information is provided.____
> > > > * Solutions to strengthen existing WHOIS lookup
> methods were
> > > proposed in [5] and are considered in this ballot.____
> > > >
> > > > ____
> > > >
> > > > Objective 2: Sunset Methods 3.2.2.4.2 (“Email, Fax,
> SMS, or
> > > Postal Mail to Domain Contact”) and 3.2.2.4.15 (“Phone Contact
> with Domain
> > > Contact”).
> > > >
> > > > _Justification:_____
> > > >
> > > > * While solutions to strengthen WHOIS-relying DCV
> methods are
> > > considered in this ballot (see above), there is limited public
> evidence of
> > > significant reliance on these methods, including in response
> to [3] and
> > > [6].____
> > > > * Instead, discussion has identified at least one
> CA Owner has
> > > already sunset reliance on WHOIS [7], and another that has
> changed its
> > > approach [8] for relying on WHOIS since disclosure of [2].____
> > > > * More modern and heavily relied-upon DCV methods
> offer
> > > advantages over the existing WHOIS-based methods, including
> greater
> > > opportunity for seamless certificate lifecycle management
> automation (e.g.,
> > > [9] and [10]), while also benefiting from recently improved
> security
> > > practices [11]. These methods can also more effectively align
> subscriber
> > > capabilities with agility and resilience expectations
> necessary to respond
> > > to the revocation timelines described in the TLS BRs [12].____
> > > > * Beyond the above, previous discussions within
> the CA/Browser
> > > Forum have raised concerns about the perceived value (e.g.,
> [13]) and
> > > security (e.g., [14]) of the DCV methods relying on WHOIS, further
> > > supporting the rationale for their gradual sunset.____
> > > >
> > > >
> > > > *_Benefits of adoption:_*____
> > > >
> > > > * Enhanced Security: Eliminates reliance on
> outdated and
> > > vulnerable DCV methods that cannot consistently provide the
> security
> > > required by the TLS BRs, or benefit from recent DCV security
> enhancements
> > > (i.e., Multi-Perspective Issuance Corroboration [11]). ____
> > > > * Increased Agility: Encourages site owners to
> transition to
> > > modern DCV methods, creating opportunities for faster, more
> efficient, and
> > > less error-prone certificate lifecycle management. ____
> > > > * Opportunity for Innovation: Promotes the
> development of new
> > > and/or improved DCV methods, fostering innovation that may
> enhance the
> > > overall security and agility of the ecosystem.____
> > > >
> > > >
> > > > *_Proposed Key Dates:_*____
> > > >
> > > > The effective dates considered in this update are
> intended to 1)
> > > address the immediate concerns identified by [2], and 2) offer
> near-term
> > > and longer-term transition periods for subscribers and CA
> Owners relying on
> > > existing implementations of these methods.____
> > > >
> > > > * January 15, 2025: (1) Prohibit the use of RFC
> 3912 (WHOIS)
> > > and HTTPS websites to identify Domain Contact information. (2)
> Prohibit the
> > > reuse of DCV relying on information obtained using these
> technologies. (3)
> > > Prohibit WHOIS-based DCV methods for Subscriber Certificates
> containing
> > > ccTLDs. (4) CAs MUST NOT rely on cached WHOIS/RDAP data more
> than 48 hours
> > > old. ____
> > > > * July 15, 2025: (1) Sunset DCV Methods 3.2.2.4.2
> ("Email,
> > > Fax, SMS, or Postal Mail to Domain Contact") and 3.2.2.4.15
> ("Phone Contact
> > > with Domain Contact"). (2) Prior validations using these
> methods and
> > > validation data gathered therein MUST NOT be used to issue new
> Subscriber
> > > Certificates.____
> > > >
> > > >
> > > > *_Proposal Revision History:_*____
> > > >
> > > > * Pre-Ballot Version #1 [4]____
> > > > * Ballot Version #1 [7]____
> > > > * Version #2 Pre-Release [17] and discussion [18]____
> > > > * Version #2 (this version) [19]____
> > > >
> > > >
> > > > The following motion has been proposed by Ryan
> Dickson and Chris
> > > Clements of Google (Chrome Root Program) and endorsed by Arvid
> Vermote
> > > (GlobalSign) and Pedro Fuentes (OISTE).____
> > > >
> > > >
> > > > ? Motion Begins ?
> > > >
> > > > This ballot modifies the “Baseline Requirements for
> the Issuance
> > > and Management of Publicly-Trusted TLS Server Certificates”
> (“Baseline
> > > Requirements”), based on Version 2.0.7.
> > > >
> > > > MODIFY the Baseline Requirements as specified in the
> following
> > > Redline:
> > > >
> > > >
> > >
> https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804
> > > <
> > >
> https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804
> > > >
> > > >
> > > > ? Motion Ends ?
> > > >
> > > > This ballot proposes a Final Maintenance Guideline. The
> > > procedure for approval of this ballot is as follows:
> > > >
> > > > _Discussion (no less than 7 days)_____
> > > >
> > > > * Start: 2024-10-01 17:00:00 UTC____
> > > > * End no earlier than: 2024-10-08 17:00:00 UTC____
> > > >
> > > >
> > > > _Vote for approval (7 days)_____
> > > >
> > > > * Start: TBD____
> > > > * End: TBD____
> > > >
> > > > ____
> > > >
> > > > Comments are welcome either on-list or with
> suggested edits via
> > > GitHub (preferred) at [19].____
> > > >
> > > > ____
> > > >
> > > > Thanks,____
> > > >
> > > > Ryan____
> > > >
> > > > ____
> > > >
> > > > ____
> > > >
> > > > *References:*____
> > > >
> > > > [1]
> > >
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html
> > > <
> > >
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html
> > > >
> > > > [2]
> > >
> https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/
> > > <
> > >
> https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/
> > > >
> > > > [3]
> > >
> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ
> > > <
> > >
> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ
> > > >
> > > > [4]
> > >
> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ
> > > <
> > >
> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ
> > > >
> > > > [5]
> > >
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html
> > > <
> > >
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html
> > > >
> > > > [6]
> > >
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html
> > > <
> > >
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html
> > > >
> > > > [7]
> > >
> https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/
> > > <
> > >
> https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/
> > > >
> > > > [8]
> https://bugzilla.mozilla.org/show_bug.cgi?id=1917896 <
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1917896>
> > > > [9]
> > >
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change
> > > <
> > >
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change
> > > >
> > > > [10]
> > >
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme
> > > <
> > >
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme
> > > >
> > > > [11]
> > >
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration
> > > <
> > >
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration
> > > >
> > > > [12]
> > >
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation
> > > <
> > >
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation
> > > >
> > > > [13]
> > >
> https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html
> > > <
> > >
> https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html
> > > >
> > > > [14]
> > >
> https://lists.cabforum.org/pipermail/validation/2024-July/001995.html
> <
> > >
> https://lists.cabforum.org/pipermail/validation/2024-July/001995.html>
> > > > [15]
> > >
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html
> > > <
> > >
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html
> > > >
> > > > [16]
> > >
> https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac
> > > <
> > >
> https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac
> > > >
> > > > [17]
> > >
> https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac
> > > <
> > >
> https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac
> > > >
> > > > [18] https://github.com/ryancdickson/staging/pull/9 <
> > > https://github.com/ryancdickson/staging/pull/9>
> > > > [19] https://github.com/cabforum/servercert/pull/551 <
> > > https://github.com/cabforum/servercert/pull/551>____
> > > >
> > > > ____
> > > >
> > > >
> > > > _______________________________________________
> > > > Servercert-wg mailing list
> > > > Servercert-wg at cabforum.org
> > > > https://lists.cabforum.org/mailman/listinfo/servercert-wg
> > >
> > > _______________________________________________
> > > Servercert-wg mailing list
> > > Servercert-wg at cabforum.org
> > > https://lists.cabforum.org/mailman/listinfo/servercert-wg
> > >
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20241014/8e011506/attachment-0001.html>
More information about the Servercert-wg
mailing list