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

That makes sense. I guess I'm saying that the intent of "Intermediates which are part of the WebPKI must not issue certificates which are not part of the WebPKI" makes sense to me. Imagine that a publicly trusted Subordinate CA issues a "certificate" which is so badly malformed that it does not

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

On Tue, May 14, 2024, 02:33 Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: > Is it ok for such an Issuing CA to create a single-purpose client > authentication TLS Certificate, one that is structured according to RFC > 5280 (thus can be successfully parsed by Relying Party RFC

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

At the request of the authors, Let's Encrypt changes our vote on Ballot SC-74 to No so that the ballot can be modified and resubmitted. On Tue, May 7, 2024 at 3:21 PM Aaron Gable via Servercert-wg < servercert-wg@cabforum.org> wrote: > Let's Encrypt / ISRG votes Yes on Ballot SC-074. &

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

a step too far. > > thanks, > > Wendy > > > Wendy Brown > > Supporting GSA > > FPKIMA Technical Liaison > > Protiviti Government Services > 703-965-2990 (cell) > > > On Wed, May 8, 2024 at 6:06 PM Aaron Gable via Servercert-wg < > servercert-

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

Of course! Done: https://github.com/cabforum/servercert/issues/513 On Wed, May 8, 2024 at 8:37 AM Dimitris Zacharopoulos (HARICA) < dzach...@harica.gr> wrote: > Thanks Aaron, > > Would it be ok for you to create a GitHub issue > to identify the

[Servercert-wg] Timeline for compromised key blocking

Section 6.1.1.3 (4) of the Baseline Requirements (as of Ballot SC-073) says "The CA SHALL reject a certificate request if... the CA has previously been notified that the Applicant's Private Key has suffered a Key Compromise using the CA's procedure for revocation request". Section 4.9.1.1 (3) of

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

Let's Encrypt / ISRG votes Yes on Ballot SC-074. On Sun, May 5, 2024 at 1:24 AM 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

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

Two notes on this ballot, findings from our process for handling upcoming requirements: 1) Let's Encrypt has created and open-sourced a tool for linting a CPS to confirm compliance with RFC 3647 Section 6 and Ballot SC-074. If you

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

Let's Encrypt / ISRG votes Yes on SC-073. On Thu, Apr 25, 2024 at 5:00 PM 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

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

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

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

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

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

On Tue, Apr 16, 2024 at 8:12 AM Wayne Thayer via Servercert-wg < servercert-wg@cabforum.org> wrote: > I have three questions about the implications of changes proposed by this > ballot: > > 1. Section 9.6.1 adds language that imposes or makes the following > requirements explicit: > >> i. the

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg < servercert-wg@cabforum.org> wrote: > In other words, I believe it satisfactory to establish a constrained set > of Debian weak keys which CAs must block (rather than leaving the > requirement fully open-ended), but I don’t believe

Re: [Servercert-wg] Fixing lag between requirements changes and linter updates

Thank you both for the thoughts and feedback! I agree that it shouldn't be a requirement; I mostly included that option just to mark the extreme end of the possibility space we're working in. Additional replies inline below: On Tue, Apr 2, 2024 at 12:38 AM Martijn Katerbarg <

[Servercert-wg] Fixing lag between requirements changes and linter updates

In the last six months, by our count there have been at least: - 7 bugzilla incident reports due to not marking the basicConstraints extension critical (1 , 2 , 3

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

I concur that it is a misrepresentation to say that a "NOT RECOMMENDED" in the BRs and a "MUST" in the EVGs is a conflict. It is no more of a conflict than we saw recently where European law allowed two identifiers to be used while the EVGs

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

Let's Encrypt / ISRG votes Yes on Ballot SC-69v3. On Mon, Mar 4, 2024 at 2: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

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

;for any purpose, and there shall be no appeal, re-vote (except in the case >of a new ballot submitted to all Voting Members) or other recourse. > > > > I think it´s not “clearly indicating” even though it´s an obvious typo. So > I´d suggest to start the voting period again. &g

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

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

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

; The vote period end should be changed to 2024-02-19. > > > Regards > > Mads > > > > *From:* Servercert-wg *On Behalf Of > *Aaron > Gable via Servercert-wg > *Sent:* Monday, February 12, 2024 11:56 PM > *To:* CA/B Forum Server Certificate WG Public Discussion List

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

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

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

Thank you Wayne! I think this gets close to the sweet spot for me, personally. I've left two small comments on the ballot, but on the whole I think I like this approach. Thanks again, Aaron On Mon, Feb 12, 2024 at 8:18 AM Wayne Thayer via Servercert-wg < servercert-wg@cabforum.org> wrote: >

Re: [Servercert-wg] [DIscussion Period Begins] SC-070: Clarify the use of DTPs for domain control validation

ropriate sources, > using an internal service completely developed and controlled by the CA? > > > > Kind regards, > > > > Eva > > > > *From:* Servercert-wg *On Behalf Of > *Aaron > Gable via Servercert-wg > *Sent:* 02 February 2024 22:20 > *To:* CA/B

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

On Fri, Feb 2, 2024, 16:13 Clint Wilson via Servercert-wg < servercert-wg@cabforum.org> wrote: > Hi Martijn, > > Thanks for sending this out for discussion. Just a few comments at this > point: > > >1. I’m not sure the wording "Router and firewall activities" is >considered an unspecified

[Servercert-wg] [DIscussion Period Begins] SC-070: Clarify the use of DTPs for domain control validation

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

Re: [Servercert-wg] Seeking endorsers: Ballot SC-XX: Measure all hours and days to the second

gt; > > That is very clear, but it is not the only reasonable interpretation. > Claiming the “minimum” interpretation is the only “reasonable” one is a bit > more opinionated and pejorative than is necessary. It also doesn’t add > anything. > > > > -Tim > > > >

Re: [Servercert-wg] Seeking endorsers: Ballot SC-XX: Measure all hours and days to the second

“minimum” interpretation is the only “reasonable” one is a bit > more opinionated and pejorative than is necessary. It also doesn’t add > anything. > > > > -Tim > > > > *From:* Servercert-wg *On Behalf Of > *Aaron > Gable via Servercert-wg > *Sent:* Thursda

Re: [Servercert-wg] Seeking endorsers: Ballot SC-XX: Measure all hours and days to the second

Hi all, Thanks for the great discussion in the ServerCert WG call this morning! I have updated this draft ballot to attempt to use Clint's language around interpreting time periods to be their minimum value. Please take a look! https://github.com/cabforum/servercert/pull/470/files Thanks

Re: [Servercert-wg] Seeking endorsers: Ballot SC-XX: Measure all hours and days to the second

hanks Aaron. > > I feel like the shall in "For purposes of measuring periods of time, one > hour shall be defined to be exactly 3,600 seconds" should be capitalized. > > Regards, > > Martijn > ---------- > *From:* Servercert-wg on behalf of > A

[Servercert-wg] Seeking endorsers: Ballot SC-XX: Measure all hours and days to the second

Hi all, As a result of this bugzilla incident , and inspired by Ballot SC-52 which never came to a vote, I would like to re-propose that the Baseline Requirements clarify that all "hour" and

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

It's also worth noting that the Baseline Requirements also diverge from RFC 3647 in this way: for example, Section 1.5 of RFC 3647 is concerned with the contact information of the group *administering the CP/CPS*, while Section 1.5(.2) of the BRs is concerned with contact information of the group

[Servercert-wg] Suggestions for requirements on Certificate Consumers

Hi all, I have two proposals for requirements that the Servercert Charter could place on Certificate Consumer members. As a whole, the SCWG maintains documents that place many more requirements on Certificate Issuers than they do on Certificate Consumers. I believe that this is a good thing,

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

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

Re: [Servercert-wg] Draft ballot SCXX- Fall 2023 Clean-up

This cleanup looks good to me, and I'm happy to endorse. Aaron On Wed, Sep 13, 2023 at 4:45 AM Inigo Barreira via Servercert-wg < servercert-wg@cabforum.org> wrote: > Hello all, > > > > We are looking for feedback on the following draft ballot as well as > endorsers. > > Thank you, > > > >

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

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

Re: [Servercert-wg] Notice of Review Period: Ballot SC63 - Make OCSP optional, require CRLs and Incentivize Automation

In addition, I would state that I believe the ballot is clear that operating OCSP is still required as long as any unexpired certificate contains an AIA OCSP URL: Sections 4.9.9 and 4.9.10 state that they "apply for communicating the status of Certificates which include an Authority Information

Re: [Servercert-wg] Message

Agreed, I look forward to discussing this with the whole group. In general I strongly approve of having CAA checks for all forms of issuance. However, this version of CAA (implemented as a new second layer hidden service descriptor) requires the CA to operate a Tor Client in order to inspect it.

Re: [Servercert-wg] Fw: New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi Paul, I'm sorry that I wasn't able to be at the ACME session last week; I've enjoyed reading the presentation slides and the draft notes that were taken during the session. In general, I'm very in favor of a system that allows for natural configuration of and fallback between multiple ACME

Re: [Servercert-wg] [secdir] Secdir last call review of draft-gutmann-testkeys-04

On Tue, Jul 18, 2023 at 4:59 PM Clint Wilson via Servercert-wg < servercert-wg@cabforum.org> wrote: > >- After exploring these possibilities (and quite probably missing >others), I’m personally left with the same conclusion as I shared >previously (and it sounds like there hasn’t been