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

[Dustin Hollenback via Servercert-wg]

Purpose of Ballot SC-071
This ballot proposes updates to the Baseline Requirements for the Issuance and 
Management of Publicly-Trusted Certificates related to Subscriber Agreements 
and Terms of Use. It combines the requirements for both into only the 
Subscriber Agreement and clarifies the requirement language. It removes the 
requirement and reference to "Terms of Use".

Notes:
*  This removes any ambiguity to ensure that there is no 
requirement that the Subscriber Agreement be legally enforceable when the CA 
and Subscriber are affiliated.
*  This updates definitions for "Subscriber" and "Subscriber 
Agreement" and removes the definition for "Terms of Use" as these separate 
concepts are creating unnecessary work for CAs and Subscribers without adding 
any value when separated.
*  While drafting this ballot, there were concerns raised related 
to "Applicant" and "Applicant Representative". These definitions were 
intentionally not modified in this ballot as they will require more discussion 
after we implement the change to Subscriber Agreement and removal of Terms of 
Use.
*  As observed with other ballots in the past, minor administrative 
updates must be made to the proposed ballot text before publication such that 
the appropriate Version # and Change History are accurately represented (e.g., 
to indicate these changes will be represented in Version 2.0.3).
*  This ballot does not modify the "Guidelines for the Issuance and 
Management of Extended Validation Certificates". More work will be made to that 
document after changes are finalized in this one.

The following motion has been proposed by Dustin Hollenback of Microsoft, and 
endorsed by Tadahiko Ito of SECOM and Ben Wilson of Mozilla.

- Motion Begins -

This ballot modifies the "Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates" ("Baseline Requirements"), based on Version 
2.0.2.

MODIFY the Baseline Requirements as specified in the following Redline:

Here is a link to the GitHub redline:
https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...1a33a904c9f7d8c9d42289f2f458358551db9f2f

- 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-12 01:00:00 UTC
* End time: 2024-04-20 01:00:00 UTC

Vote for approval (7 days)
* Start time: -XX-XX 22:00:00 UTC
* End time: -XX-XX 22:00:00 UTC



___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Clint Wilson via Servercert-wg]

Hi Aaron,

Your proposed phrasing sounds good to me and matches what I had in mind as the 
end result of the changes represented in Set 1, just structured slightly 
differently.

Cheers,
-Clint

> On Apr 11, 2024, at 9:47 AM, Aaron Gable  wrote:
> 
> On Thu, Apr 11, 2024 at 9:12 AM Clint 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 that should obviate the need for a CA 
>> to check uncommon key sizes — which are otherwise in the key size ranges of 
>> that constrained set’s key sizes — should a CA allow those uncommon key 
>> sizes. 
> 
> I completely concur. 
> 
> I don't think that either of your Set 1 / Set 2 proposals quite hits the mark 
> for me, for one reason: they both contain the phrase "CAs must not issue 
> certificates containing Debian weak keys". As long as that statement exists, 
> the requirement is "evaluate everything yourself, and if new sets of weak 
> keys come to light, you're already behind" -- the existence of the github 
> repo is just a nicety.
> 
> Instead, I would phrase the requirement as "In the case of [list of common 
> RSA and ECDSA key sizes] Debian Weak Keys, the CA SHALL reject keys 
> identified by [link to CABF repository]. For other key sizes, the CA SHALL 
> reject Debian Weak Keys."
> 
> In other words -- for these common key sizes, the repository is the source of 
> truth. Every key in it is considered compromised and must be blocked, but you 
> don't need to waste time replicating the work of generating all of these keys 
> to prove to yourself that it has been done correctly. If you want to issue 
> for other key sizes, then the onus is on you to do the relevant due diligence.
> 
> Aaron



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] Compromised/Weak Keys Ballot Proposal

[Aaron Gable via Servercert-wg]

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 that should obviate the
> need for a CA to check uncommon key sizes — which are otherwise in the key
> size ranges of that constrained set’s key sizes — should a CA allow those
> uncommon key sizes.
>

I completely concur.

I don't think that either of your Set 1 / Set 2 proposals quite hits the
mark for me, for one reason: they both contain the phrase "CAs must not
issue certificates containing Debian weak keys". As long as that statement
exists, the requirement is "evaluate everything yourself, and if new sets
of weak keys come to light, you're already behind" -- the existence of the
github repo is just a nicety.

Instead, I would phrase the requirement as "In the case of [list of common
RSA and ECDSA key sizes] Debian Weak Keys, the CA SHALL reject keys
identified by [link to CABF repository]. For other key sizes, the CA SHALL
reject Debian Weak Keys."

In other words -- for these common key sizes, the repository is the source
of truth. Every key in it is considered compromised and must be blocked,
but you don't need to waste time replicating the work of generating all of
these keys to prove to yourself that it has been done correctly. If you
want to issue for other key sizes, then the onus is on you to do the
relevant due diligence.

Aaron
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Clint Wilson via Servercert-wg]

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 today, I think both of the below sets of 
changes make sense to me, though I sensed consensus on the call leaning towards 
the first set of changes. Set 2 is intended to be the same as what I previously 
described in Option 2.

I believe the only clarification I’ve added in Set 1, beyond what Aaron and Tim 
discussed, is the addition of a requirement for key sizes other than those 
specifically represented in a known complete (at this time) repository of 
Debian weak keys for common key sizes. At least, that was my only intentional 
addition, so if the described set of changes don’t otherwise align with the 
proposal represented in Aaron and Tim’s discussion, please let me know. 
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 that should obviate the need for a CA to 
check uncommon key sizes — which are otherwise in the key size ranges of that 
constrained set’s key sizes — should a CA allow those uncommon key sizes. 

I want to further clarify that I do expect any such repository representing 
this constrained set of Debian weak keys to be updated in the future if some 
meaningful change is identified to Debian weak keys generated in the included 
key size ranges, but this approach would allow that to be a structured process 
within the CA/BF, rather than some “surprise, here’s a random def con preso; 
block all the keys it describes as being possible to generate yesterday please” 
situation as we could otherwise (and currently) encounter.

Set 1:
1) Create a CA/BF repo with presently known Debian weak keys for the key sizes 
RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521 (the repo Rob pointed to seems 
the most complete from what I’ve seen, but no particularly strong opinions here)
2) Update TBRs: For RSA key sizes or smaller than 8193 bits and ECC key sizes 
smaller than 522 bits, CAs must not issue certificates containing Debian weak 
keys
3) Update TBRs: Include a reference to the above CA/BF repo as the set of 
Debian weak keys which meet the requirement of 2) specifically for the key 
sizes RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521 included in that repo
4) Update TBRs: Add an explanatory note clarifying that if a CA allows for 
issuance of certificates other than RSA 2048, 3072, 4096, 8192; ECC 256, 384, 
521, the CA must ensure certificates containing any other key size do not 
contain a Debian weak key

Set 2:
1) Create a CA/BF repo with presently known Debian weak keys for the key sizes 
RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521
2) Update TBRs: For RSA key sizes smaller than 8193 bits and ECC key sizes 
smaller than 522 bits, CAs must not issue certificates containing Debian weak 
keys
3) Update TBRs: Include a reference to the above CA/BF repo as an optional 
resource for CAs to use in checking for Debian weak keys

I hope I’m contributing something useful to this discussion; please reach out 
if I could do better here.

Thank you!
-Clint

[1] https://github.com/wthayer/servercert/pull/1/files

> On Apr 10, 2024, at 11:51 AM, Wayne Thayer  wrote:
> 
> Hi Clint,
> 
> I think my latest proposal [1] is essentially what you are proposing in 
> option #2, the only difference being that we would add repositories 
> containing weak keys to https://cabforum.org/resources/tools/ (and we can do 
> that without a ballot). If you are instead proposing that we require CAs to 
> check for a specified weak keys contained in one or more repositories, then 
> that is similar to Aaron's proposal except that I understand you want to 
> require CAs to also check for weak keys even if they sign non-standard key 
> sizes that are not included in the repository of weak keys.
> 
> The more I think about the two approaches, the more I prefer my current 
> proposal [1] that does not require CAs to check for specific keys found in 
> one or more repositories. The reason is that I believe CAs already have 
> Debian weak key checks in place and would likely prefer not to have to change 
> their systems to use different logic/data to meet the same requirement as 
> before.
> 
> Thanks,
> 
> Wayne
> 
> [1] https://github.com/wthayer/servercert/pull/1/files
> 
> 
> 
> On Tue, Apr 9, 2024 at 2:26 PM Clint Wilson  > wrote:
>> 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 much more defined 
>> boundary