From dean.coclin at digicert.com Wed Dec 2 23:33:26 2020 From: dean.coclin at digicert.com (Dean Coclin) Date: Wed, 2 Dec 2020 23:33:26 +0000 Subject: [Cscwg-public] Agenda CSCWG December 3 Message-ID: Here is the agenda for the subject call 1. Roll call 2. Antitrust statement 3. Approval of minutes of last call 4. Ballot Status: Endorsers needed on CSCWG-7 5. 3072 root updates from Ian 6. Open items from email list (Tomas email on 16.2/16/3) 7. Next meeting: December 17 8. Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4916 bytes Desc: not available URL: From dean.coclin at digicert.com Thu Dec 3 21:46:46 2020 From: dean.coclin at digicert.com (Dean Coclin) Date: Thu, 3 Dec 2020 21:46:46 +0000 Subject: [Cscwg-public] 3072 timeline - update Message-ID: Although Ian was not able to join today's call, he supplied me with this update afterwards: One thing I did want to share today with GoDaddy in particular regarding the key length requirement deadline is that the date is not moving in our eyes, but in speaking with the fine folks on Mike's team (Karina), they have an opportunity every month to get any new roots or CAs into a CTL update for Windows. I am hoping this helps reduce challenges GoDaddy has in getting a hierarchy in place to meet the requirements by June 1, 2021. For the key protection and high risk requests, I am going to be out of the office starting next Thursday (12/10) for the remainder of the calendar year. I plan to have proposed updates to both for ballots in mid-January 2021. Further discussions on the key topic should continue on this list. Dean Coclin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4916 bytes Desc: not available URL: From dean.coclin at digicert.com Fri Dec 4 20:58:39 2020 From: dean.coclin at digicert.com (Dean Coclin) Date: Fri, 4 Dec 2020 20:58:39 +0000 Subject: [Cscwg-public] Final minutes of CSCWG call Nov 19, 2020 Message-ID: These are the approved minutes of the subject call: Attendees: Dean Coclin, Atsushi Inaba, Tomas Gustavson, Tadahiko Ito, Mike Reilly, Bruce Morton, Joanna Fox, Daniela Hood, Corey Bonnell, Tim Crawford, Jeff Ward, Chris Kemmerer, Hugh Mercer, Nicole Murray, Tim Hollebeek, Ian McMillan (joined after 30 mins). 1. Antitrust statement was read 2. Prior minutes approved with minor correction on next meeting date 3. Pre-ballot CSCWG-7: Needs ballot endorsers. Dean asked everyone to review the ballot over the next two weeks and consider endorsing 4. Discussion of Tadahiko email: Are following statements (1) to (3) all True? 1. On Appendix A (2) of BR for Code sign, it says it is for "Timestamp Root, Subordinate CA, and Timestamp Certificates". "Timestamp Certificates" include "TSA certificates (Defined in RFC3161)" Discussion: Yes, we believe this is true as stated. 2)on Appendix A (3), It only say about hash, but not for RSA key length. It is only because requirement for RSA key length is defined in (2), so there is not anything to say about RSA key. Hence, "signed value" which is signed by TSA certificate to Timestamp token need to be more than 3072 bits. Discussion result: In table 3, the transition date for hashing algorithm is April 30, 2022, but in Table 2, the key size change is June 1, 2021 for 3072 key size. Hence the distinction. (3) Appendix A (3) is only for "The digest algorithms used to sign Timestamp tokens ", so (for example) some IDs which is derived with sha1 and written inside of timestamp token is not scope of that requirement. Discussion result: Yes, we believe this is true (with an asterisk). It's not possible to determine what is written inside the TS token. If it were HMAC SHA1 it is YES. 5. Discussion of Tomas topic: Section on key protection (16.2). Tomas had reached out to HW vendors that make the silicon for the HW security modules. They need clear explanations of what is expected. Not sure if this is something this forum should do. Decided to hold off discussion until Ian joins the call 6. Parking lot list: reviewed a few items but some needed Ian's assistance so further discussion was postponed. Audit regimes were discussed but that is still evolving. Updated the latest status here: https://drive.google.com/file/d/1aJTWNj28ENBKRNowIgR1AsvRTD63jU47/view?usp=s haring 7. Requirement for 3072 roots in June 2021: Daniela said this is problematic if the root needs to be 3072. Could affect 6,000 customers. Ian said the whole chain will need to be minimum 3072, including the root. CAs that don't have this will need to get this in place. Bruce said this is fine for Microsoft but would also affect other applications like Java. Discussion around the problem of getting new roots in place in time (requirement was not clear in the document). People didn't think that the root needed to be that size. Daniela asked about pushing the date out further to accommodate CAs that don't have 3072 roots yet. Ian said he would go back and review the impact by the next call. Corey asked about using the lifetime signing OID to help solve this issue. Ian didn't think that would be a good customer experience as the developer would have to get another cert and resign everything with the cert that had the lifetime signing OID. Tim said we should look at the overall 10 year requirements for code signing at a separate meeting. 8. Short discussion on FIPS 140-2 vs -3 reqts. Ian would like to add -3 but we will pick this up on the next call. 9. Next call December 3rd 10. Adjourned Dean Coclin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4916 bytes Desc: not available URL: From dean.coclin at digicert.com Mon Dec 7 18:40:27 2020 From: dean.coclin at digicert.com (Dean Coclin) Date: Mon, 7 Dec 2020 18:40:27 +0000 Subject: [Cscwg-public] 3072 timeline - update In-Reply-To: <010001762a929134-6945c397-01bb-444f-9773-07c64ec0b1e4-000000@email.amazonses.com> References: <010001762a929134-6945c397-01bb-444f-9773-07c64ec0b1e4-000000@email.amazonses.com> Message-ID: I think one question that this raises is backwards compatibility, which was brought up on one of the last call. Perhaps, Daniela, you want to expand on that comment. Thanks Dean From: Cscwg-public On Behalf Of Dean Coclin via Cscwg-public Sent: Thursday, December 3, 2020 4:47 PM To: cscwg-public at cabforum.org Subject: [Cscwg-public] 3072 timeline - update Although Ian was not able to join today's call, he supplied me with this update afterwards: One thing I did want to share today with GoDaddy in particular regarding the key length requirement deadline is that the date is not moving in our eyes, but in speaking with the fine folks on Mike's team (Karina), they have an opportunity every month to get any new roots or CAs into a CTL update for Windows. I am hoping this helps reduce challenges GoDaddy has in getting a hierarchy in place to meet the requirements by June 1, 2021. For the key protection and high risk requests, I am going to be out of the office starting next Thursday (12/10) for the remainder of the calendar year. I plan to have proposed updates to both for ballots in mid-January 2021. Further discussions on the key topic should continue on this list. Dean Coclin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4916 bytes Desc: not available URL: From dean.coclin at digicert.com Tue Dec 15 00:15:36 2020 From: dean.coclin at digicert.com (Dean Coclin) Date: Tue, 15 Dec 2020 00:15:36 +0000 Subject: [Cscwg-public] Ballot CSC-7: Update to merge EV and Non-EV clauses In-Reply-To: References: Message-ID: Hey Bruce, This doesn't change the need to have 2 separate audits for EV and non EV CS, correct? Thanks Dean From: Cscwg-public On Behalf Of Bruce Morton via Cscwg-public Sent: Friday, November 6, 2020 3:35 PM To: cscwg-public at cabforum.org Subject: [Cscwg-public] Ballot CSC-7: Update to merge EV and Non-EV clauses Purpose of Ballot CSC-7: The CSC-2 merger of the Code Signing BRs and the EV Code Signing Guidelines was done without technical changes. The result is that we have some sections where there is different text for Non-EV and EV Code Signing certificates. In many cases there was no reason to have two different requirements. In other cases, it made sense that they both have the same requirement. There were of course some items where EV is different and these clauses were not touched for now. These items were all discussed in our bi-weekly meetings. Other minor changes were the adding in a table for document revision and history and another table for effective dates within the BRs. There were also some errors corrected from the merger. The proposed changes are redlined in the attached document. I am looking for two endorsers. Thanks, Bruce. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4916 bytes Desc: not available URL: From Bruce.Morton at entrust.com Tue Dec 15 13:40:02 2020 From: Bruce.Morton at entrust.com (Bruce Morton) Date: Tue, 15 Dec 2020 13:40:02 +0000 Subject: [Cscwg-public] Ballot CSC-7: Update to merge EV and Non-EV clauses In-Reply-To: References: Message-ID: HI Dean, My interpretation is that if you issue EV Code Signing certificates, then you will be audited to the new CSBR audit criteria which covers both Non-EV and EV Code Signing certificates, Since the CSBRs have references to both the SSL BRs and the SSL EV Guidelines, the CA will need controls to support requirements from those documents. I assume for a CA which issues DV/OV SSL, EV SSL, Non-EV CS and EV CS certificates, these audits will be all blended together as there are many requirements which address more than one certificate type. Not sure if that answers the question. Bruce. From: Dean Coclin Sent: Monday, December 14, 2020 7:16 PM To: Bruce Morton ; cscwg-public at cabforum.org Subject: [EXTERNAL]RE: Ballot CSC-7: Update to merge EV and Non-EV clauses Hey Bruce, This doesn't change the need to have 2 separate audits for EV and non EV CS, correct? Thanks Dean From: Cscwg-public > On Behalf Of Bruce Morton via Cscwg-public Sent: Friday, November 6, 2020 3:35 PM To: cscwg-public at cabforum.org Subject: [Cscwg-public] Ballot CSC-7: Update to merge EV and Non-EV clauses Purpose of Ballot CSC-7: The CSC-2 merger of the Code Signing BRs and the EV Code Signing Guidelines was done without technical changes. The result is that we have some sections where there is different text for Non-EV and EV Code Signing certificates. In many cases there was no reason to have two different requirements. In other cases, it made sense that they both have the same requirement. There were of course some items where EV is different and these clauses were not touched for now. These items were all discussed in our bi-weekly meetings. Other minor changes were the adding in a table for document revision and history and another table for effective dates within the BRs. There were also some errors corrected from the merger. The proposed changes are redlined in the attached document. I am looking for two endorsers. Thanks, Bruce. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.coclin at digicert.com Tue Dec 15 21:28:48 2020 From: dean.coclin at digicert.com (Dean Coclin) Date: Tue, 15 Dec 2020 21:28:48 +0000 Subject: [Cscwg-public] Agenda CSCWG December 17 Message-ID: PLEASE REVIEW THE PROPOSED BALLOT CSCWG-7 FOR POTENTIAL ENDORSEMENT BEFORE THE CALL! Here is the agenda for the subject call 1. Roll call 2. Antitrust statement 3. Approval of minutes of last call 4. Ballot Status: Endorsers needed on CSCWG-7 5. Any updates from Microsoft on open issues? 6. Open items from email and parking lot list 7. Next meeting: No meeting December 31, next meeting Jan 14th. 8. Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4916 bytes Desc: not available URL: From dzacharo at harica.gr Wed Dec 16 06:54:03 2020 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Wed, 16 Dec 2020 08:54:03 +0200 Subject: [Cscwg-public] Ballot CSC-7: Update to merge EV and Non-EV clauses In-Reply-To: References: Message-ID: <3169ad21-fa89-74fc-83e2-9eb118b6e784@harica.gr> In section 11.8 we point to section 11.12 of the EV Guidelines. Perhaps this is a typo and we intend to point to 11.13 "Final Cross-Correlation and Due Diligence". The change in 14.1 might probably require an effective date for CAs issuing *non-EV* Code Signing Certificates. That's because if they hadn't vetted their staff with the provisions of 14.1 of the EV Guidelines, they will probably need to re-vet them. If we intend this to be a "going forward" requirement, perhaps we can update this section to state that until date X, the older provisions applied and after date X the new provisions apply. The same applies for 16.2. It is possible that CAs operating a Signing Service for non-EV Certificates, were not using FIPS 140-2 level 2 crypto modules and will be non-compliant as soon as this ballot becomes effective. I'd also like a clarification on section 17.5. "a randomly selected sample of at least three percent of *both *the *Non-EV and the* EV Code Signing Certificates" On first read, I wasn't sure if this means that CAs must calculate a 3% for all Non-EV Certificates issued and another 3% for EV Certificates, or a 3% of a population which includes Non-EV and EV Certificates. I think this language needs to be updated to make it unambiguously clear that we intend for the former. Similarly for the 6%. Hoping that the above can be addressed, I'd be happy to endorse the ballot :-) Dimitris. On 6/11/2020 10:34 ?.?., Bruce Morton via Cscwg-public wrote: > > Purpose of Ballot CSC-7: > > The CSC-2 merger of the Code Signing BRs and the EV Code Signing > Guidelines was done without technical changes. The result is that we > have some sections where there is different text for Non-EV and EV > Code Signing certificates. In many cases there was no reason to have > two different requirements. In other cases, it made sense that they > both have the same requirement. There were of course some items where > EV is different and these clauses were not touched for now. These > items were all discussed in our bi-weekly meetings. > > Other minor changes were the adding in a table for document revision > and history and another table for effective dates within the BRs. > There were also some errors corrected from the merger. > > The proposed changes are redlined in the attached document. I am > looking for two endorsers. > > Thanks, Bruce. > > > _______________________________________________ > Cscwg-public mailing list > Cscwg-public at cabforum.org > https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Morton at entrust.com Thu Dec 17 14:46:59 2020 From: Bruce.Morton at entrust.com (Bruce Morton) Date: Thu, 17 Dec 2020 14:46:59 +0000 Subject: [Cscwg-public] [EXTERNAL]Re: Ballot CSC-7: Update to merge EV and Non-EV clauses In-Reply-To: <010001766a5459fb-853e7ad0-fb86-4093-9352-94ffc3db64ce-000000@email.amazonses.com> References: <010001766a5459fb-853e7ad0-fb86-4093-9352-94ffc3db64ce-000000@email.amazonses.com> Message-ID: Hi Dimitris, Thanks for your comments. I agree with all of them. To make it easier for all changes, perhaps we should just add an effectivity date to the ballot. We could make it 1 July 2020, which will give all CAs time to make any changes. We can discuss the date on the call or just add a number of months from ballot approval. This should cover your comments to sections 14.1 and 16.2. For 11.8, yes this was a typo. For 17.5, I will make some changes that will state: * self-audits against a randomly selected sample of at least three percent of the Non-EV Code Signing Certificates and at least three percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. * self-audits against a randomly selected sample of at least six percent of both the Non-EV Code Signing Certificates and at least six percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. Thanks, Bruce. From: Cscwg-public On Behalf Of Dimitris Zacharopoulos (HARICA) via Cscwg-public Sent: Wednesday, December 16, 2020 1:55 AM To: cscwg-public at cabforum.org Subject: [EXTERNAL]Re: [Cscwg-public] Ballot CSC-7: Update to merge EV and Non-EV clauses WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________ In section 11.8 we point to section 11.12 of the EV Guidelines. Perhaps this is a typo and we intend to point to 11.13 "Final Cross-Correlation and Due Diligence". The change in 14.1 might probably require an effective date for CAs issuing non-EV Code Signing Certificates. That's because if they hadn't vetted their staff with the provisions of 14.1 of the EV Guidelines, they will probably need to re-vet them. If we intend this to be a "going forward" requirement, perhaps we can update this section to state that until date X, the older provisions applied and after date X the new provisions apply. The same applies for 16.2. It is possible that CAs operating a Signing Service for non-EV Certificates, were not using FIPS 140-2 level 2 crypto modules and will be non-compliant as soon as this ballot becomes effective. I'd also like a clarification on section 17.5. "a randomly selected sample of at least three percent of both the Non-EV and the EV Code Signing Certificates" On first read, I wasn't sure if this means that CAs must calculate a 3% for all Non-EV Certificates issued and another 3% for EV Certificates, or a 3% of a population which includes Non-EV and EV Certificates. I think this language needs to be updated to make it unambiguously clear that we intend for the former. Similarly for the 6%. Hoping that the above can be addressed, I'd be happy to endorse the ballot :-) Dimitris. On 6/11/2020 10:34 ?.?., Bruce Morton via Cscwg-public wrote: Purpose of Ballot CSC-7: The CSC-2 merger of the Code Signing BRs and the EV Code Signing Guidelines was done without technical changes. The result is that we have some sections where there is different text for Non-EV and EV Code Signing certificates. In many cases there was no reason to have two different requirements. In other cases, it made sense that they both have the same requirement. There were of course some items where EV is different and these clauses were not touched for now. These items were all discussed in our bi-weekly meetings. Other minor changes were the adding in a table for document revision and history and another table for effective dates within the BRs. There were also some errors corrected from the merger. The proposed changes are redlined in the attached document. I am looking for two endorsers. Thanks, Bruce. _______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.coclin at digicert.com Thu Dec 17 17:32:09 2020 From: dean.coclin at digicert.com (Dean Coclin) Date: Thu, 17 Dec 2020 17:32:09 +0000 Subject: [Cscwg-public] Final minutes of CSCWG call December 3, 2020 Message-ID: Here are the final minutes of the subject call 1. Attendees: Dean Coclin, Bruce Morton, Atsushi Inaba, Doug Beattie, Corey Bonnell, Tomas Gustavson, Tim Crawford, Daniela Hood, Hugh Mercer 2. Anti-Trust statement was read by Dean 3. Minutes of prior call on November 19th: Approved 4. Ballot Status: CSCWG-7: Bruce is still looking for endorsers and asked everyone to please review the draft and get any comments back to him. We would like to move this ballot forward as it should be non-controversial. 5. 3072 root update: Ian was not on the call. Subsequent to the call, Ian sent a note stating that the date of June 2021 is firm and that CAs should submit roots to the root program that are appropriate 6. Tomas' email regarding FIPS: Suggest we say either 140-2 OR 140-3. Also, recommend not using the words "or equivalent" as there is push back from token vendors. Need to check with Ian on this. Wasn't clear if Microsoft had requested this language. Also may present issues for auditors. 7. Next call is Dec 17th Dean Coclin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4916 bytes Desc: not available URL: From Bruce.Morton at entrust.com Thu Dec 17 21:48:22 2020 From: Bruce.Morton at entrust.com (Bruce Morton) Date: Thu, 17 Dec 2020 21:48:22 +0000 Subject: [Cscwg-public] [EXTERNAL]Re: Ballot CSC-7: Update to merge EV and Non-EV clauses In-Reply-To: <01000176712b45dd-273e4b51-bc6e-4e23-877f-5424dbb4fd75-000000@email.amazonses.com> References: <010001766a5459fb-853e7ad0-fb86-4093-9352-94ffc3db64ce-000000@email.amazonses.com> <01000176712b45dd-273e4b51-bc6e-4e23-877f-5424dbb4fd75-000000@email.amazonses.com> Message-ID: Attached is the draft update for ballot CSC-7. This update addresses Dimitris? comments and proposes an effectivity date of 1 July 2021, which will allow CAs to implement the changes. Dimitris has said that he would endorse the ballot, so I am just looking for one more endorsement. If I get the endorsement soon, I would plan to propose the formal ballot for discussion the week of 4 January 2021. All the best, Bruce. From: Cscwg-public On Behalf Of Bruce Morton via Cscwg-public Sent: Thursday, December 17, 2020 9:47 AM To: Dimitris Zacharopoulos (HARICA) ; cscwg-public at cabforum.org Subject: Re: [Cscwg-public] [EXTERNAL]Re: Ballot CSC-7: Update to merge EV and Non-EV clauses Hi Dimitris, Thanks for your comments. I agree with all of them. To make it easier for all changes, perhaps we should just add an effectivity date to the ballot. We could make it 1 July 2020, which will give all CAs time to make any changes. We can discuss the date on the call or just add a number of months from ballot approval. This should cover your comments to sections 14.1 and 16.2. For 11.8, yes this was a typo. For 17.5, I will make some changes that will state: * self-audits against a randomly selected sample of at least three percent of the Non-EV Code Signing Certificates and at least three percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. * self-audits against a randomly selected sample of at least six percent of both the Non-EV Code Signing Certificates and at least six percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. Thanks, Bruce. From: Cscwg-public > On Behalf Of Dimitris Zacharopoulos (HARICA) via Cscwg-public Sent: Wednesday, December 16, 2020 1:55 AM To: cscwg-public at cabforum.org Subject: [EXTERNAL]Re: [Cscwg-public] Ballot CSC-7: Update to merge EV and Non-EV clauses WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________ In section 11.8 we point to section 11.12 of the EV Guidelines. Perhaps this is a typo and we intend to point to 11.13 "Final Cross-Correlation and Due Diligence". The change in 14.1 might probably require an effective date for CAs issuing non-EV Code Signing Certificates. That's because if they hadn't vetted their staff with the provisions of 14.1 of the EV Guidelines, they will probably need to re-vet them. If we intend this to be a "going forward" requirement, perhaps we can update this section to state that until date X, the older provisions applied and after date X the new provisions apply. The same applies for 16.2. It is possible that CAs operating a Signing Service for non-EV Certificates, were not using FIPS 140-2 level 2 crypto modules and will be non-compliant as soon as this ballot becomes effective. I'd also like a clarification on section 17.5. "a randomly selected sample of at least three percent of both the Non-EV and the EV Code Signing Certificates" On first read, I wasn't sure if this means that CAs must calculate a 3% for all Non-EV Certificates issued and another 3% for EV Certificates, or a 3% of a population which includes Non-EV and EV Certificates. I think this language needs to be updated to make it unambiguously clear that we intend for the former. Similarly for the 6%. Hoping that the above can be addressed, I'd be happy to endorse the ballot :-) Dimitris. On 6/11/2020 10:34 ?.?., Bruce Morton via Cscwg-public wrote: Purpose of Ballot CSC-7: The CSC-2 merger of the Code Signing BRs and the EV Code Signing Guidelines was done without technical changes. The result is that we have some sections where there is different text for Non-EV and EV Code Signing certificates. In many cases there was no reason to have two different requirements. In other cases, it made sense that they both have the same requirement. There were of course some items where EV is different and these clauses were not touched for now. These items were all discussed in our bi-weekly meetings. Other minor changes were the adding in a table for document revision and history and another table for effective dates within the BRs. There were also some errors corrected from the merger. The proposed changes are redlined in the attached document. I am looking for two endorsers. Thanks, Bruce. _______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Baseline Requirements for the Issuance and Management of Code Signing - CSC-7 v3.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 129263 bytes Desc: Baseline Requirements for the Issuance and Management of Code Signing - CSC-7 v3.docx URL: From Corey.Bonnell at digicert.com Thu Dec 17 21:51:33 2020 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Thu, 17 Dec 2020 21:51:33 +0000 Subject: [Cscwg-public] Today's discussion on SHA-1 and RSA 3072 Message-ID: Hello, 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: --- 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? 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? 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. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4990 bytes Desc: not available URL: