Re: [Servercert-wg] [EXTERNAL]-Re: Ballot SC-75 - Pre-sign linting

IMHO… 1. Currently CAs are expected already to do pre-issuance linting… I don’t know if a “SHOULD” changes effectively the situation… For me it seems that this initiative seems more for a “MUST” than a “SHOULD”… or it could also be a “SHOULD” linked to an effective date and a “MUST” linked to

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

I also oversaw that… Anyhow… @Clint, what are the audit requirements for these clientAuth CAs? In your program you mention WTBR as a requirement for "TLS CAs”, but there’s no distinction between clientAuth or serverAuth… while both are used to secure TLS handshakes. > On 17 May 2024, at 11:22,

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

hat are intended to > serve website authentication use cases? > > Thanks, > Ryan (on behalf of the Chrome Root Program) > > > On Thu, May 16, 2024 at 5:20 AM Pedro FUENTES via Servercert-wg > mailto:servercert-wg@cabforum.org>> wrote: >> Hello Dimitris, >

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

Sorry, small correction… Where I said “you can’t propose clientAuth-only certs that work in Chrome” I wanted to say “you can’t propose clientAuth-only certs that chain to Chrome Store” P > On 16 May 2024, at 11:20, Pedro FUENTES via Servercert-wg > wrote: > > Hello Dim

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

Hello Dimitris, I’m following closely this as I find very important. About… > This is easy to answer. Some use cases need single-purpose client > authentication certificates. There are numerous use cases where client > authentication certificates are used for strong authentication, I'm sure you

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

OISTE changes its vote to No, given the latest developments Le 9 mai 2024 à 18:05, Dimitris Zacharopoulos (HARICA) via Servercert-wg a écrit : Based on comments received during -unfortunately- the voting period, it appears that more attention to detail like the case of the

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

OISTE votes YES to SC-74 > >> 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

Re: [Servercert-wg] [EXTERNAL]-Re: [Discussion Period Begins]: SC-72 - Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED

OISTE votes YES to SC-72 > > From: Servercert-wg > On Behalf Of Paul van > Brouwershaven via Servercert-wg > Sent: Friday, March 15, 2024 11:01 AM > To: CA/B Forum Server Certificate WG Public Discussion List > mailto:servercert-wg@cabforum.org>> >

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

OISTE votes “Yes” to SC-69v3. > From: Servercert-wg > On Behalf Of Martijn Katerbarg > via Servercert-wg > Sent: Monday, March 4, 2024 4:59 AM > To: CA/B Forum Server Certificate WG Public Discussion List > mailto:servercert-wg@cabforum.org>> >

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

OISTE votes YES to SC65 From: Servercert-wg on behalf of Inigo Barreira via Servercert-wg Date: Monday, 4. March 2024 at 17.34To: CA/B Forum Server Certificate WG Public Discussion List Subject: [Servercert-wg] [Voting Period Begins]: SC65: Convert EVGs into RFC 3647 format v2Summary: The

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

OISTE Votes Yes to SC-070 > On 13 Feb 2024, at 17:56, Aaron Gable via Servercert-wg > 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

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

Count me inLe 8 févr. 2024 à 18:53, Inigo Barreira via Servercert-wg a écrit :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-wgEnviado el: viernes, 19 de enero de 2024 13:28Para: CA/B

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

OISTE votes YES to SC-68 > On 23 Jan 2024, at 10:00, 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

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

Hi guys, I didn’t want to trigger any controversy. My question was more related to understand how a so impacting Pull Request like the one to convert to RFC format could be managed in GitHub with other PR related to the non-RFC version. On my side, I prepared the PR#439

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

I just wonder if this change could have been made in a more generic way, so it could be applied in other similar cases, where there’s a conflict between the BR and the applicable laws. > On 16 Jan 2024, at 09:07, Dimitris Zacharopoulos (HARICA) via Servercert-wg > wrote: > > Purpose of the

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

ever to help you update the existing proposed > change, to the new language format. (That is, if we want to do the RFC > conversion before this ballot). > > Regards, > > Martijn > > From: Servercert-wg <mailto:servercert-wg-boun...@cabforum.org>>

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

Should we try to integrate here the proposed change to regulate de use and disclosure of QGIS?I made the PR some time ago, but on the old version. BR/PLe 12 sept. 2023 à 20:18, Tim Hollebeek via Servercert-wg a écrit :This is perfect, thank you.  I’ll run it through our internal ballot review

Re: [Servercert-wg] [EXTERNAL]- Voting Period Begins - Ballot SC-59 v2 "Weak Key Guidance"

OISTE Abstains to SC-59 v2. Too many relevant discussions were still happening when the voting started, and we had preferred to see those resolved to build our opinion. Even so, we don’t feel like voting “No” as in general we understand the intent of the ballot is positive. > On 6 Jul 2023,