<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div style="margin:0px;font-size:12pt">Jacob wrote:</div>
<div style="margin:0px;font-size:12pt">> Lastly, I think we should archive openssl-blacklist, and include in the BRs: "A CA may reject the full set of Debian weak keys by rejecting this superset of the Debian weak keys:</div>
<div style="margin:0px;font-size:12pt">><br>
<div>> - All RSA public keys with modulus lengths other than 2048 or 4096, and</div>
<div>> - All RSA public keys with exponents other than 65537, and</div>
<div><br>
</div>
<div>Hi Jacob. 65537 (aka 0x10001) is hard-coded here...</div>
<div><span style="background-color:rgb(255, 255, 255);display:inline !important"><br>
</span></div>
<div><span style="background-color:rgb(255, 255, 255);display:inline !important"><a href="https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/req.c#L768">https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/req.c#L768</a><br>
</span></div>
<div><br>
</div>
<div>Would it therefore be fair to say that keys with public exponents other than 65537 are implicitly
<u>not</u> Debian weak keys?</div>
<div><br>
</div>
> - All RSA public keys that are detected as vulnerable by the openssl-vulnkey program in the openssl-blacklist package version 0.5-3 (see addendum), or an equivalent program."</div>
</div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Servercert-wg <servercert-wg-bounces@cabforum.org> on behalf of Jacob Hoffman-Andrews via Servercert-wg <servercert-wg@cabforum.org><br>
<b>Sent:</b> 12 December 2020 02:21<br>
<b>To:</b> Christopher Kemmerer <chris@ssl.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys</font>
<div> </div>
</div>
<div>
<p></p>
<div style="background-color:#FAFA03; width:100%; border-style:solid; border-color:#000000; border-width:1pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align:left">
<span style="color:000000">CAUTION:</span> 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.</div>
<br>
<p></p>
<div>
<div dir="ltr">Thanks for your continued efforts to improve this part of the BRs! Let's Encrypt is in theory interested in endorsing, but I think it still needs a bit of work. Thanks for incorporating my most recent comments on endianness and word size vs 11
platforms.<br>
<br>
Goals: We want CAs to consistently not issue certificates for weak keys in general, and also in the specific case of Debian and ROCA keys. We want the definition of Debian and ROCA keys to be clear and actionable for as long as possible - say, at least twenty
years.<br>
<br>
We have three ways to specify Debian and ROCA keys: With a list, with a tool, or with an algorithm*. The original revision of this ballot proposed to use a list (<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2020-April%2F001821.html&data=04%7C01%7Crob%40sectigo.com%7C725d14b0028d483970d608d89e44afd7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637433365135815531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o0lw97H4L%2FCCP0YpBPPD9BkpSKF3GxENe6a3zJ%2FZfQ8%3D&reserved=0" originalsrc="https://lists.cabforum.org/pipermail/servercert-wg/2020-April/001821.html" shash="EmirU0xJxniukRMdFLhnDBTfgDHtzoXc9QmThJidZfBi9CsIJXfszcXIL23zdr3qXmTgfPWwvynA/5iAJePyN1Y63XfA+wuVTdVFoBFax8yu1WpY4++vW0a1IwLeNS6etWYJl/aFksjQymEotwl1alITHBLYNzmT1XaY7v2puJs=">https://lists.cabforum.org/pipermail/servercert-wg/2020-April/001821.html</a>).
There were two objections:<br>
<br>
- The list (openssl-blacklist) is subject to change or removal.<br>
- The list only covers 2048 and 4096 bit keys.<br>
<br>
The current draft proposes specifying a tool for ROCA (<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcrocs-muni%2Froca&data=04%7C01%7Crob%40sectigo.com%7C725d14b0028d483970d608d89e44afd7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637433365135825523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fzEpy%2Bnzn4VIuysD6Os0y8QwLbn5AMcpi6pppPmUafM%3D&reserved=0" originalsrc="https://github.com/crocs-muni/roca" shash="K0O8lVjBNZ0fKZJp4YiDqUgvCwYTVL+l7EN3j+31yJGgTONV2FHOSEggoBT7P2dWfkes/eX9xAav4uzZIUXXC7UISw5aPBNAjKRSxasPjIP6qwIdmJ3jXOlWNw8JWvEA3mPvoR2cUzs7TrpOiaupUjx30xEyw0C5N5laTTb42ak=">https://github.com/crocs-muni/roca</a>)
and an algorithm for Debian keys.<br>
<br>
The ROCA tool is subject to change or removal, just like the openssl-blacklist package. I propose we instead specify ROCA detection in terms of the paper (<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrocs.fi.muni.cz%2Fpublic%2Fpapers%2Frsa_ccs17&data=04%7C01%7Crob%40sectigo.com%7C725d14b0028d483970d608d89e44afd7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637433365135835517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uSJlr5l%2B%2BV%2FSdLl2pXAlm99KamucJ9za0CPyrkJZLBI%3D&reserved=0" originalsrc="https://crocs.fi.muni.cz/public/papers/rsa_ccs17" shash="ifeGu9CttLgYQT3z5gl9EDKfsvETmE37FMtSCQR+QZLRjeSFpjrs9DfKvjc94xsnDVEYwMZjnT3JjRSFPS9Jn/y+t+uVYgKLs60GVelq1hI4rWWFob5R2F7kaI8qnfG9+GiY957/76twjUyv0b7xkeRk5Tu5rw7maGDC1X0whGQ=">https://crocs.fi.muni.cz/public/papers/rsa_ccs17</a>)
and ask for permission from the authors to archive an unchanging copy as an addendum to the BRs.<br>
<br>
For Debian keys, what looks like an algorithm specification is actually a tool + algorithm specification. The tool is "OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based operating systems" (per CVE-2008-01666 -
<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvename.cgi%3Fname%3D2008-0166&data=04%7C01%7Crob%40sectigo.com%7C725d14b0028d483970d608d89e44afd7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637433365135835517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tMrATEIilzafZgpkuPskXI%2BqOtEbV32Ifi3tXZAYtCc%3D&reserved=0" originalsrc="https://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-0166" shash="rSr2QtnwkgP5QdBwFa/oXcZxgeUfXQvaJtt+cAtAsYxzb9XEBR/jzaCUBhTmY69wZIRFi1TnsUU+Zf1vVe73MTefHMnyoewJ5HNXvgweWwdKKooc6ijot33j/15+6X56TlEptwHFD6EctdKWfZDJxF1dWyJGaIodg1Jrlfj57v4=">
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-0166</a>). To ensure an unchanging copy of that, we should archive 3 copies of Debian, for the 3 word size + endianness combinations.<br>
<br>
The algorithm also needs an additional line: "v) using the command 'openssl req -nodes -subj / -newkey rsa:<Public Key length>'" (adapted from
<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsources.debian.org%2Fdata%2Fmain%2Fo%2Fopenssl-blacklist%2F0.5-3%2Fexamples%2Fgen_certs.sh&data=04%7C01%7Crob%40sectigo.com%7C725d14b0028d483970d608d89e44afd7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637433365135845510%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gqJerriYbuEngbYTuTC96PiqEq5OVIyw3NYqPZX6hZ0%3D&reserved=0" originalsrc="https://sources.debian.org/data/main/o/openssl-blacklist/0.5-3/examples/gen_certs.sh" shash="hF0vRxjlcI0ptReC7G4Bt9tnvfdUllB4OOc3/W+HfRxMTYLZM8kjxq2C1vkdEIEEeIKkePQck3PlcCick2WUBjnN4HCeinlfvKvdOy65f3RPtt9QN8cDotQhGFRYPi8kjR57wQIyCDubCUm84GlsCO7NHJ7xngblQqXcKR+zZ2E=">
https://sources.debian.org/data/main/o/openssl-blacklist/0.5-3/examples/gen_certs.sh</a>). Other tools that linked OpenSSL, like openvpn and openssh, generated different sets of keys. We can include or exclude openvpn and openssh keys, but should thoroughly
specify.<br>
<br>
Lastly, I think we should archive openssl-blacklist, and include in the BRs: "A CA may reject the full set of Debian weak keys by rejecting this superset of the Debian weak keys:<br>
<br>
- All RSA public keys with modulus lengths other than 2048 or 4096, and<br>
- All RSA public keys with exponents other than 65537, and<br>
- All RSA public keys that are detected as vulnerable by the openssl-vulnkey program in the openssl-blacklist package version 0.5-3 (see addendum), or an equivalent program."<br>
<br>
My reasoning: Given the difficulty of correctly setting up old Debian versions and generating weak keys for sizes that are not part of openssl-blacklist, I expect most CAs will choose this path. Given that, we should just say what we mean: the pregenerated
list is fine if you restrict key sizes, but you don't *have* to restrict key sizes, so long as you have an alternate method to ensure you're not issuing for Debian weak keys at other sizes.<br>
<br>
*I'm considering specifying an algorithm to be functionally equivalent to specifying an "outcome," though I recognize this may be too hand-wavy.<br>
</div>
</div>
</div>
</div>
</body>
</html>