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
> 
>
>
>
> 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
>

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

[Clint Wilson via Servercert-wg]

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 can be used.

Presumably when 5280 was drafted, the authors were aware of the updates 2817 
made to 2616, but chose not to reference those updates. Even if not, I concur 
with Ryan and my recollection is also that the discussion during SC-62’s 
formation did include this topic with the consensus (at that time) being that 
some fields would be restricted to using only HTTP URIs.

To your original questions:
 Do Members agree with that interpretation? 

Yes

 
 If this is the correct interpretation, would it be considered a violation 
 of the BRs if a CA or end-entity certificate contains https:// URL in the 
 id-ad-caIssuers accessMethod ? 

Yes, at least for certificates issued after SC-62 went into effect (maybe also 
for those prior, I just haven’t looked).

 
 I'm afraid that this might not be as clear in the BRs as it should be, so 
 if people agree with the above, we should probably update section 
 7.1.2.7.7 
 
  (and possibly other parts) to explicitly state that the allowed scheme is 
 "http" and not "https", just like we do for the CRLDP in section 
 7.1.2.11.2 
 
  . 

I’m not convinced a clarification is worthwhile here. To be clear, I’m not 
opposed, I’m just not sure it’s something CAs are actively getting or likely to 
get wrong — if some are, then I would instead support such a clarification.

Cheers!
-Clint

> On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg  wrote:
> 
> Hi Ryan,
> 
> The question is not between HTTP vs FTP vs LDAP but specifically for "HTTP 
> URL" that could have two schemes "http" and "https".
> 
> RFC 2616 (June 1999) included only "http" and was updated in May 2000 by RFC 
> 2817  to include TLS Within 
> HTTP/1.1 ("https").
> 
> I hope this clarifies the issue.
> 
> 
> Dimitris.
> 
> On 25/4/2024 3:29 μ.μ., Ryan Dickson via Servercert-wg wrote:
>> It's my understanding that the intent of the updates made in SC-62 were to 
>> prohibit any non-HTTP URI. This was discussed in:
>> 
>> 1) at least one historical GitHub discussion 
>>  (referenced in ballot 
>> preamble 
>> ):
>> 
>> "authorityInformationAccess: This is a new requirement.
>> BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL of the Issuing 
>> CA's certificate and MAY contain the HTTP URL of the Issuing CA's OCSP 
>> responder.
>> Some questions were raised about whether this means other URLs, other 
>> schemes, or multiple URLs can be included. Similar to crlDistributionPoints, 
>> the ordering of URLs implies processing semantics on clients, and only 
>> particular URL schemes are supported. Namely, if one of the two supported 
>> access methods are present (CA issuer or OCSP), then the only URLs present 
>> MUST be HTTP URLs, and MUST be listed in order of priority.
>> This prohibits the use of other access methods, as they are not used in the 
>> Web PKI."
>> 
>> and 2) Corey's Validation Subcommittee presentation at F2F 56 
>> 
>>  (slide 14 
>> ,
>>  "Non-HTTP (i.e., LDAP and FTP) OCSP and CA Issuers URIs are prohibited").
>> 
>> D-Trust volunteered to propose an update to the BRs to address the issue in 
>> this  Bugzilla Bug 
>> (Actions Table).
>> 
>> Thanks,
>> Ryan
>> 
>> On Thu, Apr 25, 2024 at 3:44 AM Adriano Santoni via Servercert-wg 
>> mailto:servercert-wg@cabforum.org>> wrote:
>>> Hi,
>>> 
>>> IMO, including an HTTPS URI in the id-ad-caIssuers accessMethod is at least 
>>> a bad practice and very unwise (if done on purpose), as it may give rise to 
>>> unbounded loops, as it is clearly explained in RFC5280:
>>> 
>>> 
  CAs SHOULD NOT include URIs that specify https, ldaps, or similar
 schemes in extensions.  CAs that include an https URI in one of these
 extensions MUST ensure that the server's certificate can be validated
 without using the information that is pointed to by the URI.  Relying
 parties that choose to validate the server's certificate when
 obtaining information pointed to by an https URI in the
 cRLDistributionPoints, 

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

[Bruce Morton via Servercert-wg]

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 

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 
mailto:wtha...@gmail.com>> 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 
mailto: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 
mailto:bwil...@mozilla.com>> 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 
mailto: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 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Dimitris Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, April 21, 2024 1:24 AM
To: Aaron Gable mailto:aa...@letsencrypt.org>>; CA/B 
Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
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 mailto:servercert-wg@cabforum.org>> 
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] Voting Period Begins - Ballot SC-073: Compromised and Weak Keys

[Rollin.Yu via Servercert-wg]

TrustAsia votes YES on Ballot SC-073.

Best regards,
Rollin Yu





> On Apr 26, 2024, at 08:00, Wayne Thayer via Servercert-wg 
>  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



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Doug Beattie via Servercert-wg]

GlobalSign votes yes on Ballot SC-073.

 

Doug

 

From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Thursday, April 25, 2024 8:00 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

 

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



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Aaron Gable via Servercert-wg]

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 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] Voting Period Begins - Ballot SC-073: Compromised and Weak Keys

[Inigo Barreira via Servercert-wg]

Sectigo votes yes

 

De: Servercert-wg  En nombre de Wayne
Thayer via Servercert-wg
Enviado el: viernes, 26 de abril de 2024 2:00
Para: CA/B Forum Server Certificate WG Public Discussion List

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

 

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.

 

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/a65402cff89affe1fc0a1f0e49807
c7e42e1608a...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



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Bruce Morton via Servercert-wg]

Entrust votes Yes to ballot SC-073.


Bruce.

From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Thursday, April 25, 2024 8:00 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

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


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

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

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

[Backman, Antti via Servercert-wg]

Telia Company votes ‘Yes’ on Ballot SC-073 

//Antti 


From: Servercert-wg  on behalf of Wayne 
Thayer via Servercert-wg 
Date: Friday, 26. April 2024 at 3.00
To: CA/B Forum Server Certificate WG Public Discussion List 

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

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 
<_blank>: 

* 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 
<_blank> and 
https://lists.cabforum.org/pipermail/servercert-wg/2024-April/004422.html 
<_blank> 
* 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
 <_blank> 
— 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 







smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Adriano Santoni via Servercert-wg]

Actalis votes 'yes'

Il 26/04/2024 02:00, Wayne Thayer via Servercert-wg ha scritto:
NOTICE: Pay attention - external email - Sender is 
0100018f17b415ae-778c107a-354f-4239-9c91-1848b0fd4f07-000...@amazonses.com 





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


smime.p7s
Description: Firma crittografica S/MIME
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg