<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hello,<o:p></o:p></p><p class=MsoNormal>To provide more context and help facilitate discussion, below are the questions that originally prompted the conversation on today’s call regarding SHA-1 sunset dates and RSA key size requirements for roots:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>---<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Appendix A of the CSBRs denotes that SHA-1 certificates may be issued until the end of this year to support legacy platforms. However, the Appendix is silent on the allowed signature algorithms for OCSP responses and OCSP delegated responder certificates that are issued by a codesigning or timestamping ICA. Our interpretation of the requirements is that OCSP delegated responder certificates and OCSP responses signed using SHA-1 are acceptable after the transition date, otherwise legacy clients will be unable to check the OCSP status of issued certificates if they are signed with an algorithm besides SHA-1. Does Microsoft share this interpretation?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In a similar vein, the requirements set forth for Timestamp Responder certificates in Appendix A indicate that the SHA-1 transition date is end of 2020, but SHA-1 signatures on timestamp tokens has been moved back to end of April 2022. However, section 9.4 of the CSBRs indicates that Timestamp Authority certificates can only be used in production for a maximum of 15 months. For those CAs who issue end-entity timestamp responder certificates and immediately place them in production, this means that there is a period in 2022 where they cannot provide SHA-1 timestamping services to legacy clients as they will need to rotate their timestamp responder certificate before April 30 to remain compliant with the 15-month rule but will be unable to issue a replacement due to the certificate issuance SHA-1 sunset date being set to end of 2020. For CAs in this situation, would it be acceptable to issue timestamp responder certificates until the timestamp token SHA-1 sunset date of April 30, 2022?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Lastly, from recent conversations in the Code Signing working group, Microsoft appears to be supportive of CAs creating new RSA 3072 roots to comply with the June 2021 requirement for larger key sizes. However, section B of the Microsoft Root Program requirements specifies that the minimum key size for new roots is RSA 4096, which would preclude the submission of RSA 3072 roots. RSA 3072 roots are desirable as there is greatly increased performance realized as opposed to larger keys, which in turn would decrease application startup times. Clarity regarding Microsoft’s expectations for minimum RSA key sizes for new roots would be appreciated.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p></div></body></html>