[Servercert-wg] RV: Redline for SC-59: Weak keys ballot

[Aaron Gable]

Without getting to the meat of the ballot, three minor editorial comments:
- the phrase "[based] on the Public Key in the Certificate" should not be
removed from 4.9.1.1(4). If there is a method which can compute the private
key based on other data, unassociated with the certificate itself, that's
simply a Key Compromise. If the authors strongly believe that this phrase
should be dropped, then the word "based" must also be removed.
- It's unclear to me why the phrase "conditions are met" is replaced with
"occurs", when the following items are not active verb phrases. One would
not say that "the Key Pair does not meet the requirements set forth in..."
is something that *occurs*, it is something that is always statically true
or false, i.e. it is a condition that is met.
- The sentence beginning "Suggested tools..." should be part of numbered
item 6.1.1.3(4), not a separate paragraph at the top level of section
6.1.1.3

Aaron

On Thu, Mar 16, 2023 at 9:11 AM Inigo Barreira via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Forwarding it to the Sever Certificate WG
>
>
>
> *De:* Smcwg-public <smcwg-public-bounces at cabforum.org> *En nombre de *Chris
> Kemmerer via Smcwg-public
> *Enviado el:* jueves, 16 de marzo de 2023 15:46
> *Para:* smcwg-public at cabforum.org
> *Asunto:* [Smcwg-public] Redline for SC-59: Weak keys ballot
>
>
>
> 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.
>
>
>
> Hello,
>
>
>
> A diff for our proposed changes may be found here:
> https://github.com/cabforum/servercert/compare/2c63814...9ecc201?diff=split
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2F2c63814...9ecc201%3Fdiff%3Dsplit&data=05%7C01%7Cinigo.barreira%40sectigo.com%7C9d27ee5b4bb7400b1fa908db262d2483%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638145747577702166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FaXtQOTrKeZMl523hWU9ts32%2B05OaGiT8S%2BdJzsczq4%3D&reserved=0>
>
>
> This compares the current BR branch (2c63814) with our latest updates. Ben
> Wilson and Martijn Katerbarg have offered extremely useful suggestions,
> some of which we have accommodated and others we offer for discussion.
> Specifically, in 6.1.1.3:
>
>    - Our version removes the provision "2. There is clear evidence that
>    the specific method used to generate the Private Key was flawed" as we
>    believe that this case is essentially the same as the next one (i.e. "clear
>    evidence" of a flawed method must lead to awareness of the "demonstrated or
>    proven method")
>    - The four items 4 (b) (i though iv) are inclusive (i.e all parameters
>    combined) and are now joined by an "and"
>    - As this ballot covers various weak key issues, "Debian" has been
>    removed where not specifically required
>    - The directive that "CAs MUST check for Debian weak keys for all RSA
>    modulus lengths and exponents that they accept" was added via discussion in
>    our SCWG calls and in our view reinforces and extends the provision in
>    4(b). It should be decided if there will be a cutoff point or not. If a CA
>    wants to support 16384-bit RSA keys, do they have to generate first all
>    Debian weak keys of that size or could it be assumed that such Debian weak
>    keys are not expected to have been generated before?
>    - We had included links to specific tools but now see that these (and
>    more!) may be found at https://cabforum.org/resources/tools/ under
>    "Check for Bad Private Keys". We have edited the section to direct to this
>    resource.
>
> Regards,
>
> Chris K
>
>
>
>
>
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230316/558879b3/attachment-0001.html>