Re: [Servercert-wg] Timeline for compromised key blocking

Hi Aaron, This seems reasonable to me. It might also be worth adding a similar timeline to 6.1.1.5.(1) so that, under a circumstance in which the Debian-weak-keys repo is updated, there is some amount of time for CAs to ensure their own systems are also updated. Since that repo is under the

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

Hi Tim, > On May 10, 2024, at 8:52 AM, Tim Hollebeek via Servercert-wg > wrote: > > Whether the comparison should be case sensitive or not is not a question of > how “strict” the linter should be, but what the requirements are. Linters > MUST NOT make their own determinations as to what the

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

I did a quick check, but was only able to find one recently issued leaf certificate that contained an https CA Issuers URI. There seems to be about 26 CA certificates that do as well, but all were issued before 2019 except for 2. Of the 1 leaf and 2 CA certificates that are more recent, they’re

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

Hi Dimitris, My understanding is that the intent was indeed to restrict these to HTTP specifically. That is, the phrase “the only URLS present MUST be HTTP URLs” is intended to preclude the use of HTTPS, and not just to indicate that any scheme which relies on the Hypertext Transfer Protocol

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

the changes represented in Set 1, just structured slightly >> differently. >> >> Cheers, >> -Clint >> >>> On Apr 11, 2024, at 9:47 AM, Aaron Gable >> <mailto:aa...@letsencrypt.org>> wrote: >>> >>> On Thu, Apr 11, 2024 at 9:1

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

nt Wilson via Servercert-wg > mailto: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 t

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

Hi Wayne, Agreed, your proposal [1] is basically what I was describing; I only added that it would be useful, in my mind, to add a repository usable by Certificate Issuers (but not required to be used) similar to what we’ve provided for ROCA and Close Primes. However, based on the discussion

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

Hi Wayne, I think this does seem like it could be a tractable solution, however I’d like to understand why one of the proposals I’ve brought up a couple times on the calls isn’t also a suitable option. From what I can gather, they’re nearly identical in practical impact, but one provides a

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

Apple votes YES on Ballot SC-072. > On Mar 25, 2024, at 5:00 AM, Paul van Brouwershaven via Servercert-wg > wrote: > > This ballot updates the TLS Extended Validation Guidelines (EVGs) by removing > the exceptions to policyQualifiers​ in section 9.7, to align them with the > Baseline

Re: [Servercert-wg] [External Sender] Re: [EXTERNAL]- Subject attribute encoding order requirement (rationale for)

Hi Adriano, I haven’t looked through minutes and such yet, but as I recall this ordering was discussed a number of times on Validation Subcommittee calls during the creation of SC-062 (i.e. sometime in 2020-2023). The resultant ordering originated from the combination of 3 primary sources: 1.

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

Hi Paul, There are a lot of ways that the EVGs differ from the TBRs; that’s basically the point of them, as I understand it. Specifically it’s within the profiles that most non-process-oriented differences can be found between EV, OV, IV, and DV TLS certificates. Are all of these differences

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

Hi, Could the ballot author and endorsers please provide some additional explanation and context surrounding this ballot? As far as I can recall, this topic hasn’t been discussed since SC-062, so it’s rather coming out of nowhere as a ballot proposal (which is, of course, totally fine, but

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

Hi Wayne, Thank you for carrying this work item forward. I have a few concerns regarding the proposed removal of Debian weak key checking, outlined below. I don’t believe there has been sufficient explanation or data presented to justify the removal of the requirement to check for Debian weak

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

Hi Martijn, This is a nit, but is there an extra quotation mark in line 1556? Sorry for not spotting this earlier :( Thanks! -Clint > On Feb 22, 2024, at 11:50 AM, Martijn Katerbarg via Servercert-wg > wrote: > > Summary: > > This ballot aims to clarify what data needs to be logged as

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

Apple votes Yes on Ballot SC-070. > On Feb 13, 2024, at 8:56 AM, 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

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

Hi Martijn, Thanks for sending this out for discussion. Just a few comments at this point: I’m not sure the wording "Router and firewall activities" is considered an unspecified term, and leaves the exact definition and scope up to the CA, however” is necessary or even really helpful. I think

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

Apple votes YES on Ballot SC-068. > On Jan 23, 2024, at 1: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

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

Hi Inigo, These changes look good to me as well (though the rearranging of P-Label did get me for a second there, thinking it had been removed) and I’d be willing to endorse if needed. Cheers, -Clint > On Sep 13, 2023, at 4:45 AM, Inigo Barreira via Servercert-wg > wrote: > > Hello all, >

Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

Hi all, Is anyone able to identify the product in question such that we can review its documentation and behavior in greater detail and collectively determine whether (and if so, how) the certificates it’s issuing should fit into or be accounted for by the BRs? The profiles ballot — version

Re: [Servercert-wg] SC-XXX: Modify Subscriber Agreement and Terms of Use

Hi Ben, As I understand it the goal of these changes is just to simplify the terms used in the BRs — and, as has been brought up separately, potentially other CA/BF Final Guidelines — in order to enable collapsing their use of “Terms of Use” into the concept of the “Subscriber Agreement”. Is

Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

Hi Wendy, Thanks for this additional information and context. Is there publicly available documentation for the product and this functionality? I think that might be the most efficient way to answer some of the questions arising around this. If not, I have a few follow-on questions. In what

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

Hi Wayne, This is helpful and much appreciated! > On Jul 18, 2023, at 11:15 AM, Wayne Thayer wrote: > > Hi Clint, > > Thank you for helping to unpack my concerns. > > On Mon, Jul 17, 2023 at 2:28 PM Clint Wilson > wrote: >> Hi Wayne, >> >> I’d like to better

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

Hi Wayne, I’d like to better understand your worry and perhaps interpretation of BR 6.1.1.3(4) and 4.9.1.1(3,4,16). Just to restate for my benefit, the concern is that: IF we interpret Tim’s message regarding the testkeys draft as qualifying the keys present in the draft as “[All] CAs

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

Apple votes YES on Ballot SC-059. > On Jul 6, 2023, at 9:17 AM, Tom Zermeno via Servercert-wg > wrote: > > Purpose of the Ballot SC-59 > > This ballot proposes updates to the Baseline Requirements for the Issuance > and Management of Publicly-Trusted Certificates related to the

Re: [Servercert-wg] Voting Period Begins - Ballot SC-063 V4: “Make OCSP Optional, Require CRLs, and Incentivize Automation”

Apple votes YES on Ballot SC-063. > On Jul 6, 2023, at 8:59 AM, Ryan Dickson via Servercert-wg > wrote: > > Purpose of Ballot SC-063 > This Ballot proposes updates to the Baseline Requirements for the Issuance > and Management of Publicly-Trusted Certificates related to making Online >