From dean.coclin at digicert.com Thu Dec 1 18:37:12 2022 From: dean.coclin at digicert.com (Dean Coclin) Date: Thu, 1 Dec 2022 18:37:12 +0000 Subject: [Cscwg-public] CSCWG Final Minutes November 17, 2022 Message-ID: Here are the final minutes of the November 17, 2022 call: 1. Roll Call - Bruce Morton (Entrust), Atsushi Inaba (GobalSign), Corey Bonnell (DigiCert), Dimitris Zacharopoulos (HARICA), Ian McMillan (Microsoft), Martijn Katerberg (Sectigo), Trevoli Ponds-White (Amazon Trust Services), Tomas Gustavsson, TimCrawford (BDO), Roberto Quinones (Intel), Joanna Fox (Trustcor) 2. Antitrust statement was read. 3. Minutes from 25 October are not yet available. Minutes from 3 November were approved. 4. Ballot: Signing Service Update - The draft text has been recirculated. Dimitris has some comments on the ETSI Time-stamping audit requirements. The Signing Service audit requirements were fine. Discussed allowing a Signing Service to be audited to a SANs standard; this would require more discussion. Ian plans to endorse. Ian would like to address FIPS 140-2 Level 3 requirement date for the Signing Service. Bruce reviewed the NetSec audit requirements and most appear they could apply to a Signing Service, if CA was replaced with Signing Service and other minor adjustments. 5. Ballot: Malware base revocation - A number of comments have been added and have been addressed. Martijn will push the changes to GitHub and will push the ballot forward in the next few days. 6. Other business - Dimitris has not received any other feedback on moving away from the SSL BRs. The direction is to try to replace references with text from the SSL BRs. Martijn will plan to put sometime to this over the next week. Bruce stated the plan was also to try to rationalize if the changes do not make sense for Code Signing. 7. Next Meeting - 1 December 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 1 18:41:08 2022 From: dean.coclin at digicert.com (Dean Coclin) Date: Thu, 1 Dec 2022 18:41:08 +0000 Subject: [Cscwg-public] Final CSCWG Minutes November 3, 2022 Message-ID: Here are the final minutes from the November 3, 2022 call: Attendees: Andrea Holland Atsushi Inaba Bruce Morton Corey Bonnell Dean Coclin Dimitris Zacharopoulos Ian McMillan Inigo Barreira Mohit Kumar Tim Crawford Tim Hollebeek Tomas Gustavsson Dean read the antitrust statement. - Signing Service Ballot Bruce said that he received no further feedback and would like to push this to ballot. Tim and Ian offered to review and endorse, barring any issues found. Dimitris mentioned that one of the takeaways from the F2F was that there is ETSI guidance for remote QSCDs for activation and we should consider incorporating. Tim H. said that we should look at these requirements and incorporate compatible criteria in the CSBRs instead of requiring any associated audit regime. Dimitris said that approach may have IP issues. Bruce proposed that we look at that guidance after the initial ballot is pushed out. There was agreement that the remote QSCD standards should be looked at further by the group. Bruce said he will circulate the current PR (https://github.com/cabforum/code-signing/pull/12) for this ballot for review and call for endorsers. Bruce said that the NetSec requirements document describes requirements for CAs but is silent on Signing Services, and so we may want to consider removing the NetSec requirement for Signing Services. Tim said that while some things are CA-specific, there are many requirements which cover good security practices that would be applicable to Signing Services. Tim also agreed with Bruce that the NetSec requirements solely address CA keys, which is not useful for Signing Services. Bruce raised a concern that if we require adherence to the NetSec document as a whole, then there is much room for interpretation as to which sections are applicable to Signing Services. Dimitris agreed with Bruce and added that similar challenges have occurred with RA audits. Ian asked if there are any ISO standards for cloud services. Tim said that there are not, and cloud services generally get the 2000-level security audit. Ian said that ISO 27001-7 audits for cloud services are common. - Importing TLS BR text into CSBRs Dimitris created a branch on GitHub(https://github.com/cabforum/code-signing/tree/importTLSBRrefs) to copy the TLS BR text to the CSBRs. He mentioned that there have been no significant issues thus far besides the references to the EV Guidelines, which will be handled in a second pass. He asked for volunteers for this effort. Next meeting is November 17th. Meeting adjourned. -------------- 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 Mon Dec 5 09:33:37 2022 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Mon, 5 Dec 2022 11:33:37 +0200 Subject: [Cscwg-public] Importing BRs to CSBRs In-Reply-To: <01000184289ff8f1-d6088750-4e6b-409a-bbd8-ce292e6d0eae-000000@email.amazonses.com> References: <01000184289ff8f1-d6088750-4e6b-409a-bbd8-ce292e6d0eae-000000@email.amazonses.com> Message-ID: I continued to work in this project and imported requirements all the way to section 7.1.4 (without working on 7.1.4) and would appreciate it if someone could pick up from there. The remaining references to a "BR Section" are very few but at the same time the editor must check every BR section that was not explicitly referenced by the CSBRs and import that language. Please check for additional comments/concerns that need to be addressed, marked with the word "EDITOR". Thanks, Dimitris. On 30/10/2022 1:21 ?.?., Dimitris Zacharopoulos (HARICA) via Cscwg-public wrote: > > Dear friends, > > With the publication of CSBRs version 3.2, I created a branch and > started importing TLS BRs (already completed sections 1 and 2). You > can monitor the progress in: > > * https://github.com/cabforum/code-signing/blob/importTLSBRrefs/docs/CSBR.md > > Since we will make a full pass of the TLS BRs and EVGs, I believe it > is a good opportunity to import the requirements from*the latest TLS > BRs/EVGs* (1.8.4/1.7.9 respectively). If we encounter some > controversial requirements between the latest versions and the ones > currently referenced that need more discussion, we will bring this > back to the WG to discuss/resolve. > > Digicert (Corey) and Sectigo (Martijn) have already declared their > intent to assist in this process. If there are more volunteers, please > reply to this thread so we can possibly break-down the sections. > > Please let me know if you have any questions or concerns. > > > Best regards, > > Dimitris. > > > _______________________________________________ > 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 martijn.katerbarg at sectigo.com Mon Dec 5 10:01:55 2022 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Mon, 5 Dec 2022 10:01:55 +0000 Subject: [Cscwg-public] Importing BRs to CSBRs In-Reply-To: <01000184e1a29ec4-69cb09c8-9332-4963-b8bc-d8e2a2e1d5a3-000000@email.amazonses.com> References: <01000184289ff8f1-d6088750-4e6b-409a-bbd8-ce292e6d0eae-000000@email.amazonses.com> <01000184e1a29ec4-69cb09c8-9332-4963-b8bc-d8e2a2e1d5a3-000000@email.amazonses.com> Message-ID: Dimitris, I?ll allot time this week to proceed from 7.1.4 From: Cscwg-public On Behalf Of Dimitris Zacharopoulos (HARICA) via Cscwg-public Sent: Monday, 5 December 2022 10:34 To: cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Importing BRs to CSBRs 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. I continued to work in this project and imported requirements all the way to section 7.1.4 (without working on 7.1.4) and would appreciate it if someone could pick up from there. The remaining references to a "BR Section" are very few but at the same time the editor must check every BR section that was not explicitly referenced by the CSBRs and import that language. Please check for additional comments/concerns that need to be addressed, marked with the word "EDITOR". Thanks, Dimitris. On 30/10/2022 1:21 ?.?., Dimitris Zacharopoulos (HARICA) via Cscwg-public wrote: Dear friends, With the publication of CSBRs version 3.2, I created a branch and started importing TLS BRs (already completed sections 1 and 2). You can monitor the progress in: * https://github.com/cabforum/code-signing/blob/importTLSBRrefs/docs/CSBR.md Since we will make a full pass of the TLS BRs and EVGs, I believe it is a good opportunity to import the requirements from the latest TLS BRs/EVGs (1.8.4/1.7.9 respectively). If we encounter some controversial requirements between the latest versions and the ones currently referenced that need more discussion, we will bring this back to the WG to discuss/resolve. Digicert (Corey) and Sectigo (Martijn) have already declared their intent to assist in this process. If there are more volunteers, please reply to this thread so we can possibly break-down the sections. Please let me know if you have any questions or concerns. Best regards, Dimitris. _______________________________________________ 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: smime.p7s Type: application/pkcs7-signature Size: 6827 bytes Desc: not available URL: From martijn.katerbarg at sectigo.com Thu Dec 8 12:40:44 2022 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Thu, 8 Dec 2022 12:40:44 +0000 Subject: [Cscwg-public] Importing BRs to CSBRs In-Reply-To: <01000184e1bc4ba0-49643391-2915-40ee-a43c-9e4f42dd8781-000000@email.amazonses.com> References: <01000184289ff8f1-d6088750-4e6b-409a-bbd8-ce292e6d0eae-000000@email.amazonses.com> <01000184e1a29ec4-69cb09c8-9332-4963-b8bc-d8e2a2e1d5a3-000000@email.amazonses.com> <01000184e1bc4ba0-49643391-2915-40ee-a43c-9e4f42dd8781-000000@email.amazonses.com> Message-ID: I?ve continued from the point where Dimitris left off. I?ve also given it another pass and updated a few more sections. Every update has an editor note added to it, and is now available in GitHub. The one section remaining to be done, is section 7.1.4.2.3. This section references BR Section 3.2 a number of times, so we appear to need to do a complete comparison of CSCBR Section 3.2 and BR Section 3.2, and import anything that?s ?missing but relevant?. I?ve also discovered 2 potential conflicts, which are called out in the text. I?ll add github comments on these so we they become more visible to everyone, and people can chime in on the items easily. Regards, Martijn From: Cscwg-public On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Monday, 5 December 2022 11:02 To: Dimitris Zacharopoulos (HARICA) ; cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Importing BRs to CSBRs 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. Dimitris, I?ll allot time this week to proceed from 7.1.4 From: Cscwg-public > On Behalf Of Dimitris Zacharopoulos (HARICA) via Cscwg-public Sent: Monday, 5 December 2022 10:34 To: cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Importing BRs to CSBRs 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. I continued to work in this project and imported requirements all the way to section 7.1.4 (without working on 7.1.4) and would appreciate it if someone could pick up from there. The remaining references to a "BR Section" are very few but at the same time the editor must check every BR section that was not explicitly referenced by the CSBRs and import that language. Please check for additional comments/concerns that need to be addressed, marked with the word "EDITOR". Thanks, Dimitris. On 30/10/2022 1:21 ?.?., Dimitris Zacharopoulos (HARICA) via Cscwg-public wrote: Dear friends, With the publication of CSBRs version 3.2, I created a branch and started importing TLS BRs (already completed sections 1 and 2). You can monitor the progress in: * https://github.com/cabforum/code-signing/blob/importTLSBRrefs/docs/CSBR.md Since we will make a full pass of the TLS BRs and EVGs, I believe it is a good opportunity to import the requirements from the latest TLS BRs/EVGs (1.8.4/1.7.9 respectively). If we encounter some controversial requirements between the latest versions and the ones currently referenced that need more discussion, we will bring this back to the WG to discuss/resolve. Digicert (Corey) and Sectigo (Martijn) have already declared their intent to assist in this process. If there are more volunteers, please reply to this thread so we can possibly break-down the sections. Please let me know if you have any questions or concerns. Best regards, Dimitris. _______________________________________________ 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: smime.p7s Type: application/pkcs7-signature Size: 6827 bytes Desc: not available URL: From dean.coclin at digicert.com Tue Dec 13 19:48:21 2022 From: dean.coclin at digicert.com (Dean Coclin) Date: Tue, 13 Dec 2022 19:48:21 +0000 Subject: [Cscwg-public] CSCWG Agenda December 15th Message-ID: Here's the agenda for this week's call: MINUTE TAKER: NEED A VOLUNTEER 1. Start recording 2. Roll Call 3. Antitrust statement 4. Approval of prior meeting minutes - 1 December and F2F meeting 5. Ballot: Malware base revocation (Martijn) 6. Ballot: Signing Service Update (Bruce) 7. Ballot: Remove SSL BR References (Dimitris) 8. Other business 9. Next Meeting - 29 December cancelled; next meeting on 12 January 10. 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 martijn.katerbarg at sectigo.com Thu Dec 15 09:59:36 2022 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Thu, 15 Dec 2022 09:59:36 +0000 Subject: [Cscwg-public] Proposal to make changes to revocation based on malware In-Reply-To: <01000184c2a8f953-1116042b-3c4c-425c-acaf-74b64334c6f9-000000@email.amazonses.com> References: <01000181a57a0c4b-466ccbbf-b733-4c26-9d10-458c02f48071-000000@email.amazonses.com> <010001821555b128-fde488e8-d88c-4f95-9407-10e2e31101a9-000000@email.amazonses.com> <01000183694d80cd-dd7796e2-e308-4cd2-ab91-c5f24a7ceab2-000000@email.amazonses.com> <010001836a6b13f5-50f0c7af-3d1e-413b-b70e-da0b01b9324e-000000@email.amazonses.com> <010001836b3e6385-52c92b78-eed1-4271-84b9-33dcb1704a21-000000@email.amazonses.com> <01000183793afb91-20f0e1ce-b55f-44b4-90ed-7c7093a7b301-000000@email.amazonses.com> <01000184be4a111a-f12bf3e9-89dc-4385-8518-82c412b114ed-000000@email.amazonses.com> <01000184c2a8f953-1116042b-3c4c-425c-acaf-74b64334c6f9-000000@email.amazonses.com> Message-ID: All, We had a good discussion on the malware proposal during the last call. I believe we?re nearly there. Trevoli and Tim you had suggestions (and thank you Dean for spelling it out in the minutes!) to make is more clear and also allow for the exceptional cases where revoking a CS cert would do more damage then not. Based on this, it seems we were leaning into making the following changes: Change: a. If the Subscriber responds within 72 hours, the CA and Subscriber MAY determine a "reasonable date" to revoke the certificate. The revocation date MUST NOT be more than 7 calendar days after the CA received the Certificate Problem Report. Into: a. If the Subscriber responds within 72 hours, the CA MAY determine a "reasonable date" to revoke the certificate. The CA: * MUST revoke the certificate no later than 7 calendar days after the CA received the Certificate Problem Report; or, * MUST submit a plan for revocation to all Application Software Suppliers based on discussions with the Subscriber no later than 7 calendar days after the CA received the Certificate Problem Report Thoughts on this? The one thought I have on this is, are Application Software Suppliers (i.e Certificate Consumers, but that?s not a CSCBR defined term) willing to take on these plans and provide responses to the CA? Cause if they don?t, it seems we again have a loop hole in which revocation can be done much later based upon subscriber request? Note: I won?t be able to attend todays call, but feel free to discuss. From: Cscwg-public On Behalf Of Dimitris Zacharopoulos (HARICA) via Cscwg-public Sent: Tuesday, 29 November 2022 10:13 To: cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Proposal to make changes to revocation based on malware 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. On 28/11/2022 2:50 ?.?., Martijn Katerbarg via Cscwg-public wrote: All, I just pushed a new commit (https://github.com/cabforum/code-signing/pull/10/commits/8e7e3b4e57960994edea267f0e753358aad99574 ) based on the discussions and comments I?ve had and received. The complete ballot ?redline? in GitHub is available for review on https://github.com/cabforum/code-signing/pull/10/files If the CA confirms that a Subscriber has signed "Suspect Code", how would the group feel with a proposal to require CAs to backdate revoke the Code Signing Certificate to a date and time that would neutralize the Suspect Code? If this date and time is unlikely to be determined, backdate revoke 1'' after the notBefore date and time of the Code Signing Certificate? Thanks, Dimitris. From: Cscwg-public On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Monday, 26 September 2022 11:58 To: Dimitris Zacharopoulos (HARICA) ; cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Proposal to make changes to revocation based on malware 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. Thank you Dimitris. That makes sense. I?ve pushed an update to the draft-PR From: Cscwg-public > On Behalf Of Dimitris Zacharopoulos (HARICA) via Cscwg-public Sent: Friday, 23 September 2022 18:47 To: cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Proposal to make changes to revocation based on malware 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. I posted some proposed changes for consistency and accuracy. 1. https://github.com/cabforum/code-signing/pull/10#pullrequestreview-1118760785 Thanks, Dimitris. On 23/9/2022 3:55 ?.?., Bruce Morton via Cscwg-public wrote: Hi Martjin, I will endorse the ballot. Thanks, Bruce. From: Cscwg-public On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Friday, September 23, 2022 3:44 AM To: cscwg-public at cabforum.org Subject: [EXTERNAL] Re: [Cscwg-public] Proposal to make changes to revocation based on malware WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. _____ All, As discussed on yesterdays call, the latest changes which Tim and I were discussing are pushed into Github. The complete change can be found at https://github.com/cabforum/code-signing/pull/10/files for review. Bruce, Ian, since I earlier had your endorsements, please let me know if they still stand. The changes since the endorsements, are captured in https://github.com/cabforum/code-signing/pull/10/commits/90fa38ab4dc5e5f9b25fce844b750d693f7256b7 If there are no other comments, then hopefully we can start a ballot process on this. Regards, Martijn From: Cscwg-public > On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Tuesday, 19 July 2022 09:22 To: Tim Hollebeek >; cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Proposal to make changes to revocation based on malware 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. Thanks Tim, 1. What is the motivation for allowing a waiver if approved by just ?at least one? of the stakeholders, instead of all of them? 2. I?m a bit concerned that language might be increasingly troublesome as we continue to expand the scope and participation of this group. I believe it might be difficult to get approval from all stakeholders within a certain amount of time, meaning the CA would possibly never get all approvals, and never be able to utilize the waiver. Considering that signed code is often (but not exclusively) targeted for a specific platform, stakeholders of other platforms might not be inclined to give approval for something that does not even affect them. I do share your concern, but I also don?t see a better path towards the same goal. 3. Similarly, I?m unsure how I feel about making compliance distinctions based on whether a particular root program has decided to have a contractual relationship with its issuers or not. That seems like an implementation detail of the relationship that the guidelines should remain silent on. But I appreciate what that definition is intended to do, and would like to perhaps find a different way to express the same intent. Good point, and maybe the word ?contract? is too much here? Although I would note this language is already part of the ?Certificate Beneficiaries? definition right now. I?m open for a different suggestion From: Tim Hollebeek > Sent: Friday, 15 July 2022 18:18 To: Martijn Katerbarg >; cscwg-public at cabforum.org Subject: RE: [Cscwg-public] Proposal to make changes to revocation based on malware 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. What is the motivation for allowing a waiver if approved by just ?at least one? of the stakeholders, instead of all of them? I?m a bit concerned that language might be increasingly troublesome as we continue to expand the scope and participation of this group. Similarly, I?m unsure how I feel about making compliance distinctions based on whether a particular root program has decided to have a contractual relationship with its issuers or not. That seems like an implementation detail of the relationship that the guidelines should remain silent on. But I appreciate what that definition is intended to do, and would like to perhaps find a different way to express the same intent. -Tim From: Cscwg-public > On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Monday, June 27, 2022 10:04 AM To: cscwg-public at cabforum.org Subject: [Cscwg-public] Proposal to make changes to revocation based on malware All, As already hinted during the last meeting during the F2F, Ian and I, have been working on a proposal affecting the guidelines regarding malware based revocation. The intent of this change is to: 1. Limit the number of days before a certificate needs to be revoked, especially when the subscriber is not responding to inquiries 2. Remove the OCSP log analysis requirements 3. Simplify the process that has to be followed I have attached 3 documents: one with the current language, one with the proposed language, as well as a redlined version. The changes have been made based on upcoming version 3.0 of the CSCBRs. In case you wish to compare with version 2.8, the relevant section is 13.1.5.3. Besides to that section, there is also a change to the ?Suspect Code? definition, as well as a new definition in the proposal. Once PR6 has been merged, I will also prepare the changes in GIT for those that prefer comparing there. Looking forward to comments to this and move towards a potential ballot. Regards, Martijn Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. _______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/cscwg-public _______________________________________________ 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: smime.p7s Type: application/pkcs7-signature Size: 6827 bytes Desc: not available URL: From dzacharo at harica.gr Thu Dec 15 13:26:40 2022 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Thu, 15 Dec 2022 15:26:40 +0200 Subject: [Cscwg-public] Proposal to make changes to revocation based on malware In-Reply-To: <010001851539d34e-6f3fa2a0-ec36-4c15-b176-5d3ac91cbdd6-000000@email.amazonses.com> References: <01000181a57a0c4b-466ccbbf-b733-4c26-9d10-458c02f48071-000000@email.amazonses.com> <010001821555b128-fde488e8-d88c-4f95-9407-10e2e31101a9-000000@email.amazonses.com> <01000183694d80cd-dd7796e2-e308-4cd2-ab91-c5f24a7ceab2-000000@email.amazonses.com> <010001836a6b13f5-50f0c7af-3d1e-413b-b70e-da0b01b9324e-000000@email.amazonses.com> <010001836b3e6385-52c92b78-eed1-4271-84b9-33dcb1704a21-000000@email.amazonses.com> <01000183793afb91-20f0e1ce-b55f-44b4-90ed-7c7093a7b301-000000@email.amazonses.com> <01000184be4a111a-f12bf3e9-89dc-4385-8518-82c412b114ed-000000@email.amazonses.com> <01000184c2a8f953-1116042b-3c4c-425c-acaf-74b64334c6f9-000000@email.amazonses.com> <010001851539d34e-6f3fa2a0-ec36-4c15-b176-5d3ac91cbdd6-000000@email.amazonses.com> Message-ID: On 12/15/2022 11:59 AM, Martijn Katerbarg via Cscwg-public wrote: > > All, > > We had a good discussion on the malware proposal during the last call. > I believe we?re nearly there. Trevoli and Tim you had suggestions (and > thank you Dean for spelling it out in the minutes!) to make is more > clear and also allow for the exceptional cases where revoking a CS > cert would do more damage then not. > > Based on this, it seems we were leaning into making the following changes: > > > Change: > > ?? a.? If the Subscriber responds within 72 hours, the CA and > Subscriber MAY determine a "reasonable date" to revoke the > certificate. The revocation date MUST NOT be more than 7 calendar days > after the CA received the Certificate Problem Report. > Into: > ?? a.? If the Subscriber responds within 72 hours, the CA MAY > determine a "reasonable date" to revoke the certificate. The CA: > > * MUST revoke the certificate no later than 7 calendar days after > the CA received the Certificate Problem Report; or, > * MUST submit a plan for revocation to all Application Software > Suppliers based on discussions with the Subscriber no later than 7 > calendar days after the CA received the Certificate Problem Report > > > Thoughts on this? > The one thought I have on this is, are Application Software Suppliers > (i.e Certificate Consumers, but that?s not a CSCBR defined term) > willing to take on these plans and provide responses to the CA? > Cause if they don?t, it seems we again have a loop hole in which > revocation can be done much later based upon subscriber request? > I have the same concerns with the second bullet. And how do we determine "all" Suppliers? CAs have no visibility on Relying Party software. I believe that the reason to "contact negatively-affected Application Software Suppliers" is to determine the proper "reasonable date" that would invalidate the malware signatures and not affect other "good signatures" that would have a significant impact on Relying Parties. If there is no response from the Application Software Supplier, the CA should revoke with a "reasonable date" based on its investigation at the time. Please take a look at the following proposal. I'd appreciate feedback and language improvements to describe the process accurately and safely in order to protect Relying Parties from executing Suspect Code as much as possible. Worse case, CAs will revoke the Certificate with a revocation date set at the time of the revocation event which does not affect any previously signed code, including the Suspect Code which will be executed successfully by Relying Parties even after the revocation of the Certificate. /4.9.1.3 Revocation Based on Reported or Detected Compromise or Use in Suspect Code/ // /Except for cases that fall under Section 4.9.1.1, if, while investigating a Certificate Problem Report, the CA determines the Subscriber's Private Key is compromised or likely being used for Suspect Code, the CA SHALL revoke the corresponding Code Signing Certificate in accordance with and within the following maximum time frames. Nothing herein prohibits a CA from revoking a Code Signing Certificate prior to these time frames./ // 1. /The CA SHALL contact the Subscriber within 24 hours after the CA received the Certificate Problem Report, notifying that the Certificate is scheduled to be revoked with a //revocation date set before the time that the //Private Key became compromised or likely used to sign Suspect Code//. This revocation date is set in the past to prevent Relying Parties from executing Suspect Code signed with the affected Code Signing Certificate.// / 2. /The CA SHALL request the Subscriber to respond with an impact assessment of affected Relying Parties if the revocation date is set before the time //that the Private Key became compromised or likely used to sign Suspect Code//, and to state the associated Application Software Supplier(s)./ 3. /The CA SHALL request the Subscriber to respond to the CA within 72 hours of the CA sending the notification. // / 4. /If the Subscriber responds within 72 hours, //then based on the Subscriber's impact assessment:/ 1. /the CA MAY submit a revocation plan to associated Application Software Suppliers no later than 7 calendar days after the CA received the Certificate Problem Report. The revocation plan:/ 1. /SHALL contain informing about the planned revocation date to be set for the to-be-revoked Certificate; and / 2. /SHALL request suggestions for a "more appropriate" revocation date in case the proposed revocation date has a significant impact on Relying Parties associated with that particular Application Software Supplier. / 3. /The CA SHALL request the Application Software Supplier to respond within 72 hours./ 2. /Based on the feedback received, the CA MAY determine a more appropriate revocation date to be associated with the revocation of the Certificate. / 3. /The CA SHALL revoke the Certificate within 7 days after the CA received the Certificate Problem Report./ 5. /If the CA does not receive a response from the Subscriber, then the CA SHALL revoke the Certificate within 24 hours from the end of the response period./ // /A CA revoking a Certificate because the Certificate was associated with signed Suspect Code or other fraudulent or illegal conduct SHOULD provide all relevant information and risk indicators to other CAs, Application Software Suppliers, or industry groups. The CA SHOULD contact the Application Software Suppliers within 24 hours after the CA received the Certificate Problem Report./ Thanks, Dimitris. > > Note: I won?t be able to attend todays call, but feel free to discuss. > > *From:*Cscwg-public *On Behalf Of > *Dimitris Zacharopoulos (HARICA) via Cscwg-public > *Sent:* Tuesday, 29 November 2022 10:13 > *To:* cscwg-public at cabforum.org > *Subject:* Re: [Cscwg-public] Proposal to make changes to revocation > based on malware > > 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. > > On 28/11/2022 2:50 ?.?., Martijn Katerbarg via Cscwg-public wrote: > > All, > > I just pushed a new commit > (https://github.com/cabforum/code-signing/pull/10/commits/8e7e3b4e57960994edea267f0e753358aad99574 > ) > based on the discussions and comments I?ve had and received. > > The complete ballot ?redline? in GitHub is available for review on > https://github.com/cabforum/code-signing/pull/10/files > > > > If the CA confirms that a Subscriber has signed "Suspect Code", how > would the group feel with a proposal to require CAs to *backdate > revoke* the Code Signing Certificate to a date and time that would > neutralize the Suspect Code? If this date and time is unlikely to be > determined, backdate revoke 1'' after the notBefore date and time of > the Code Signing Certificate? > > > Thanks, > Dimitris. > > > > *From:*Cscwg-public > *On Behalf Of *Martijn > Katerbarg via Cscwg-public > *Sent:* Monday, 26 September 2022 11:58 > *To:* Dimitris Zacharopoulos (HARICA) > ; cscwg-public at cabforum.org > *Subject:* Re: [Cscwg-public] Proposal to make changes to > revocation based on malware > > 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. > > Thank you Dimitris. That makes sense. I?ve pushed an update to the > draft-PR > > *From:*Cscwg-public *On Behalf > Of *Dimitris Zacharopoulos (HARICA) via Cscwg-public > *Sent:* Friday, 23 September 2022 18:47 > *To:* cscwg-public at cabforum.org > *Subject:* Re: [Cscwg-public] Proposal to make changes to > revocation based on malware > > 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. > > I posted some proposed changes for consistency and accuracy. > > 1. https://github.com/cabforum/code-signing/pull/10#pullrequestreview-1118760785 > > > > Thanks, > Dimitris. > > On 23/9/2022 3:55 ?.?., Bruce Morton via Cscwg-public wrote: > > Hi Martjin, > > I will endorse the ballot. > > Thanks, Bruce. > > *From:*Cscwg-public > *On Behalf Of > *Martijn Katerbarg via Cscwg-public > *Sent:* Friday, September 23, 2022 3:44 AM > *To:* cscwg-public at cabforum.org > *Subject:* [EXTERNAL] Re: [Cscwg-public] Proposal to make > changes to revocation based on malware > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender > and know the content is safe. > > ------------------------------------------------------------------------ > > All, > > As discussed on yesterdays call, the latest changes which Tim > and I were discussing are pushed into Github. > > The complete change can be found at > https://github.com/cabforum/code-signing/pull/10/files > > for review. > > Bruce, Ian, since I earlier had your endorsements, please let > me know if they still stand. The changes since the > endorsements, are captured in > https://github.com/cabforum/code-signing/pull/10/commits/90fa38ab4dc5e5f9b25fce844b750d693f7256b7 > > > If there are no other comments, then hopefully we can start a > ballot process on this. > > > Regards, > > Martijn > > *From:*Cscwg-public *On > Behalf Of *Martijn Katerbarg via Cscwg-public > *Sent:* Tuesday, 19 July 2022 09:22 > *To:* Tim Hollebeek ; > cscwg-public at cabforum.org > *Subject:* Re: [Cscwg-public] Proposal to make changes to > revocation based on malware > > 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. > > Thanks Tim, > > 1. What is the motivation for allowing a waiver if approved > by just ?at least one? of the stakeholders, instead of all > of them? > 2. I?m a bit concerned that language might be increasingly > troublesome as we continue to expand the scope and > participation of this group. > > I believe it might be difficult to get approval from all > stakeholders within a certain amount of time, meaning the CA > would possibly never get all approvals, and never be able to > utilize the waiver. > > Considering that signed code is often (but not exclusively) > targeted for a specific platform, stakeholders of other > platforms might not be inclined to give approval for something > that does not even affect them. > > I do share your concern, but I also don?t see a better path > towards the same goal. > > 3. Similarly, I?m unsure how I feel about making compliance > distinctions based on whether a particular root program > has decided to have a contractual relationship with its > issuers or not.? That seems like an implementation detail > of the relationship that the guidelines should remain > silent on.? But I appreciate what that definition is > intended to do, and would like to perhaps find a different > way to express the same intent. > > Good point, and maybe the word ?contract? is too much here? > > Although I would note this language is already part of the > ?Certificate Beneficiaries? definition right now. > > I?m open for a different suggestion > > *From:*Tim Hollebeek > *Sent:* Friday, 15 July 2022 18:18 > *To:* Martijn Katerbarg ; > cscwg-public at cabforum.org > *Subject:* RE: [Cscwg-public] Proposal to make changes to > revocation based on malware > > 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. > > What is the motivation for allowing a waiver if approved by > just ?at least one? of the stakeholders, instead of all of them? > > I?m a bit concerned that language might be increasingly > troublesome as we continue to expand the scope and > participation of this group. > > Similarly, I?m unsure how I feel about making compliance > distinctions based on whether a particular root program has > decided to have a contractual relationship with its issuers or > not.? That seems like an implementation detail of the > relationship that the guidelines should remain silent on.? But > I appreciate what that definition is intended to do, and would > like to perhaps find a different way to express the same intent. > > -Tim > > *From:*Cscwg-public *On > Behalf Of *Martijn Katerbarg via Cscwg-public > *Sent:* Monday, June 27, 2022 10:04 AM > *To:* cscwg-public at cabforum.org > *Subject:* [Cscwg-public] Proposal to make changes to > revocation based on malware > > All, > > As already hinted during the last meeting during the F2F, Ian > and I, have been working on a proposal affecting the > guidelines regarding malware based revocation. > > The intent of this change is to: > > 1. Limit the number of days before a certificate needs to be > revoked, especially when the subscriber is not responding > to inquiries > 2. Remove the OCSP log analysis requirements > 3. Simplify the process that has to be followed > > I have attached 3 documents: one with the current language, > one with the proposed language, as well as a redlined version. > > The changes have been made based on upcoming version 3.0 of > the CSCBRs. In case you wish to compare with version 2.8, the > relevant section is 13.1.5.3. Besides to that section, there > is also a change to the ?Suspect Code? definition, as well as > a new definition in the proposal. > > Once PR6 > > has been merged, I will also prepare the changes in GIT for > those that prefer comparing there. > > Looking forward to comments to this and move towards a > potential ballot. > > Regards, > > Martijn > > /Any email and files/attachments transmitted with it are > confidential and are intended solely for the use of the > individual or entity to whom they are addressed. If this > message has been sent to you in error, you must not copy, > distribute or disclose of the information it contains. _Please > notify Entrust immediately_ and delete the message from your > system./ > > _______________________________________________ > > Cscwg-public mailing list > > Cscwg-public at cabforum.org > > https://lists.cabforum.org/mailman/listinfo/cscwg-public > > > > > _______________________________________________ > > Cscwg-public mailing list > > Cscwg-public at cabforum.org > > https://lists.cabforum.org/mailman/listinfo/cscwg-public > > > _______________________________________________ > 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 dzacharo at harica.gr Thu Dec 15 17:34:53 2022 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Thu, 15 Dec 2022 19:34:53 +0200 Subject: [Cscwg-public] Importing BRs to CSBRs In-Reply-To: References: <01000184289ff8f1-d6088750-4e6b-409a-bbd8-ce292e6d0eae-000000@email.amazonses.com> <01000184e1a29ec4-69cb09c8-9332-4963-b8bc-d8e2a2e1d5a3-000000@email.amazonses.com> <01000184e1bc4ba0-49643391-2915-40ee-a43c-9e4f42dd8781-000000@email.amazonses.com> Message-ID: <1a7fc08f-40c2-845e-26d3-e210ff467464@harica.gr> Martijn, As we discussed on today's call, we can start reviewing the EDITOR comments at the upcoming meetings until we address all of them. Of course Members can comment in parallel on GitHub. For convenience, I created a Pull Request for people to review more easily against the current CSBRs. Thanks, Dimitris. On 12/8/2022 2:40 PM, Martijn Katerbarg wrote: > > I?ve continued from the point where Dimitris left off. I?ve also given > it another pass and updated a few more sections. Every update has an > editor note added to it, and is now available in GitHub. > > The one section remaining to be done, is section 7.1.4.2.3. ?This > section references BR Section 3.2 a number of times, so we appear to > need to do a complete comparison of CSCBR Section 3.2 and BR Section > 3.2, and import anything that?s ?missing but relevant?. > > I?ve also discovered 2 potential conflicts, which are called out in > the text. ?I?ll add github comments on these so we they become more > visible to everyone, and people can chime in on the items easily. > > Regards, > > Martijn > > *From:*Cscwg-public *On Behalf Of > *Martijn Katerbarg via Cscwg-public > *Sent:* Monday, 5 December 2022 11:02 > *To:* Dimitris Zacharopoulos (HARICA) ; > cscwg-public at cabforum.org > *Subject:* Re: [Cscwg-public] Importing BRs to CSBRs > > 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. > > Dimitris, I?ll allot time this week to proceed from 7.1.4 > > *From:*Cscwg-public *On Behalf Of > *Dimitris Zacharopoulos (HARICA) via Cscwg-public > *Sent:* Monday, 5 December 2022 10:34 > *To:* cscwg-public at cabforum.org > *Subject:* Re: [Cscwg-public] Importing BRs to CSBRs > > 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. > > > I continued to work in this project and imported requirements all the > way to section 7.1.4 (without working on 7.1.4) and would appreciate > it if someone could pick up from there. The remaining references to a > "BR Section" are very few but at the same time the editor must check > every BR section that was not explicitly referenced by the CSBRs and > import that language. > > Please check for additional comments/concerns that need to be > addressed, marked with the word "EDITOR". > > > Thanks, > Dimitris. > > On 30/10/2022 1:21 ?.?., Dimitris Zacharopoulos (HARICA) via > Cscwg-public wrote: > > > Dear friends, > > With the publication of CSBRs version 3.2, I created a branch and > started importing TLS BRs (already completed sections 1 and 2). > You can monitor the progress in: > > * https://github.com/cabforum/code-signing/blob/importTLSBRrefs/docs/CSBR.md > > > Since we will make a full pass of the TLS BRs and EVGs, I believe > it is a good opportunity to import the requirements from*the > latest TLS BRs/EVGs* (1.8.4/1.7.9 respectively). If we encounter > some controversial requirements between the latest versions and > the ones currently referenced that need more discussion, we will > bring this back to the WG to discuss/resolve. > > Digicert (Corey) and Sectigo (Martijn) have already declared their > intent to assist in this process. If there are more volunteers, > please reply to this thread so we can possibly break-down the > sections. > > Please let me know if you have any questions or concerns. > > Best regards, > > Dimitris. > > _______________________________________________ > > 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 15 17:36:19 2022 From: dean.coclin at digicert.com (Dean Coclin) Date: Thu, 15 Dec 2022 17:36:19 +0000 Subject: [Cscwg-public] Final minutes of CSCWG F2F Meeting October 26, 2022 Message-ID: CSCWG Meeting Leader: Dean Coclin (DigiCert) Minutes: Tim Callan (Sectigo) Attendees: Aaron Poulsen (Amazon), Adam Jones (Microsoft), Adrian Mueller (SwissSign), Andrea Holland (SecureTrust), Ben Wilson (Mozilla), Brianca Martin (Amazon), Bruce Morton (Entrust), Chris Clements (Google), Christophe Bonjean (GlobalSign), Corey Bonnell (DigiCert), Dean Coclin (DigiCert), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Eva van Steenberge (Globalsign), Ian McMillan (Microsoft), Inaba Atsushi (GlobalSign), Inigo Barreira (Sectigo), Janet Hines (SecureTrust), Jeremy Rowley (DigiCert), Joanna Fox (TrustCor Systems), Joris Minolla (D-Trust), Jozef Nigut (Disig), JP Hamilton (Cisco Systems), Li-Chun Chen (Chunghwa Telecom), Lynn Jeun (Visa), Marcelo Silva (Visa), Marco Schambach (IdenTrust), Martijn Katerbarg (Sectigo), Michael Sykes (SSL.com), Nargis Mannan (SecureTrust), Nick France (Sectigo), Nikolaos Soumelidis (ACAB Council), Rollin Yu (TrustAsia Technologies, Inc.), Stephen Davidson (DigiCert), Sven Rajala (Keyfactor), Tadahiko Ito (SECOM Trust Systems), Thomas Zermeno (SSL.com), Tim Callan (Sectigo), Tim Hollebeek (DigiCert), Tomas Gustavsson (PrimeKey), Trevoli Ponds-White (Amazon), Vijayakumar (Vijay) Manjunatha (eMudhra), Yoshiro Yoneya (Japan Registry Services) Discussion Signing Models . Subscriber uses token or server HSM verification . Subscriber uses cloud service verification . Signing service hosts HSM - audit . Signing service hosts HSM with protected private keys in cloud service - audit except cloud service . Signing service uses cloud service to generate and store private key s- audit except cloud service Bruce Morton (Entrust): Third is easiest to tackle. We have to figure out how to audit these. Clarification - it's subscriber keys. Tim Hollebeek (DigiCert): Applying NCSSRs as currently written for key protection is between problematic and impossible. Adopting the NCSSRs is hard. For 4, there is difficulty in the audit. How do I audit what the cloud service does? Jeremy Rowley (DigiCert): DigiCert mostly relies on cloud service providers' SOC audit and then looks at the configuration of services Ian McMillan (Microsoft): All public cloud has stated and confirmed FIPS-140-2 or -3. Jeremy: Rely on this certification of the audit. Same as relying on certification of HSM hardware requirement. For cloud: 1. Key creation and storage must remain in this cloud's bounds 2. Access is secure and proper This isn't in standard reports like SOC 2. Doug Beattie (GlobalSign): Maybe we need to say what do we want from the signing service. Dimitris Zacharopoulos (HARICA): What if a cloud provider could get a WebTrust for CA audit? We think this will be difficult. Nick France (Sectigo): Differentiate between who operates the service, like a CA or a third party, e.g. a partner or customer. We need some assurance these keys are being used correctly. Ian: Or should all signing services be trusted as a third party? Jeremy: But that would prevent a lot of reuse of WebTrust. Tim: Don't turn the easy case into the hard case. Jeremy: Third party is hard to detect and hard to enforce. Bruce: We need to think through: 1. What requirements do they have to meet? 2. Differentiate between CAs and third parties Dimitris: We have not yet received feedback from auditors as this is recent. Doug: We can decide what we want audited. Dimitris: The fourth and fifth bullets are based on real industry behavior. Martijn Katerbarg (Sectigo): How will CAs know a signing service is being used? Is this honor based? Dimitris: Yes, it's self-declared. Jeremy: it's an issue that we're relying on them to tell us. We should focus first on the CA case. This is a blurry line. Signing Service Requirements . Generation Subscriber Key Pair in hardware crypto module . Operate the hardware crypto module to a standard . Provide the Subscriber secure access to activate their Private Key for signing Doug: Have hardware crypto module and operate it to some standard. Provide subscriber secure access to activate private key for signing. What else? Ian: Full transparency on what was sighed (to subscriber, not CA). No limits on what can be signed, just logged. Dimitris: But today these could happen without us knowing. Maybe we remove signing services from the BRs and be done with it. Ian: Customers like this because they don't have to do all the tricky PKI stuff. Jeremy: Some customers want to import/export keys. Trevoli Ponds-White (Amazon): Processing. Bruce: But we don't want keys to be imported. Martijn: What is the definition of importing and exporting? Can I backup? Trev: Backup would have different requirements. Signing Service - Cloud-based Key Generation . Cloud-based key generation is allowed . How do we determine what cloud-based key generation is? . Can the CA provide cloud-based key generation? . If the CA provides cloud-based key generation, then what audit requirements apply? Bruce: What is cloud-based versus not? How does the CA know? How do you apply it? Jeremy: If CA controls the hardware, it's not cloud based. Dimitris: We have requirements on this in section 6.2.7.3. In all cases, CA needs some kind of report, so you can rely on them. Inigo Barreira (Sectigo): ETSI has no distinction between cloud-based and on prem. Bruce: Propose moving on drafted ballot and then go after these hard questions in phases. Two-year Goals Ian: Candidates to add: 1. Max validity period. Should we reduce it? 39 months now. 2. IS there a better way to enable short lived certs? 3. CT for code signing. Why to reduce from 39 months: They have signed too much code for a revocation action. We need the ability to be more surgical in revocations. Revoking a cert can be difficult because of the impact. Tim: For short lived certs, we need validation of authority. This is the only roadblock. We should fix it. Ian: CT logging is hard. Issue is different from what it was used to sign. It's missing a hugely important piece. Dimitris: Harmonization of CA quality is the most obvious benefit for me. Jeremy: You can detect CA hopping with CT logs. And log revocation reason codes. Tim: It also solves the problem of CAs not knowing about certs from known bad actors. Time ended and meeting was 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 Thu Dec 15 17:36:12 2022 From: dean.coclin at digicert.com (Dean Coclin) Date: Thu, 15 Dec 2022 17:36:12 +0000 Subject: [Cscwg-public] Final Minutes of CSCWG Meeting December 1, 2022 Message-ID: Here are the final minutes from the subject call: Attendees: Andrea Holland - (SecureTrust), Bruce Morton - (Entrust), Corey Bonnell - (DigiCert), Dean Coclin - (DigiCert), Dimitris Zacharopoulos - (HARICA), Ian McMillan - (Microsoft), Inaba Atsushi - (GlobalSign), Janet Hines - (SecureTrust), Martijn Katerbarg - (Sectigo), Roberto Quionones - (Intel), Tim Crawford - (CPA Canada/WebTrust), Tim Hollebeek - (DigiCert), Tomas Gustavsson - (PrimeKey), Trevoli Ponds-White - (Amazon) 1. The Anti-trust statement was read 2. Minutes of the last call were approved. Minutes from the F2F will be approved on the next call after the attendance is added. 3. Ballot: Malware based revocation: Here is the discussion on this topic: Martijn Katerbarg: I think the Dimitris commented on the public list on a proposal to actually requires you to backdate verification dates. I don't know if you intended that to be included in this ballot or have that a separate item. Dimitris Zacharopoulos: I just wanted to ask, how would people feel about a change like this since we are trying to address an issue for subscribers that are signing malware. I think this course of action would be actually more effective, to protect the relying parties trying to use that malware. Bruce Morton: Aren't we already allowed to backdate? Tim Hollebeek: Yes we are. That's where I kind of wanted to ask you about this Dimitris, because I understand your motivation, but there's a couple of problems with mandating it. Because if I'm understanding your intention correctly, it's like, you're basically saying that you have to choose a back date that guarantees that the ecosystem is no longer exposed to the identified malware. If that's your goal right? Dimitris: yes Tim Hollebeek: Okay I mean it's a noble goal, I think the problem is if you look at a lot of these scenarios they're very complicated and there's a lot of times there's close contact with the root programs and discussing sort of the various trade offs of various effective states that you might choose and a lot of times the date that ends up getting agreed on for various reasons is not the one that is as far back as possible just because there might be a very critical driver for a particular operating system that gets affected and you know we should move towards ways of doing single signings so that that doesn't happen as much but the reality is we can't quite. I don't know how you would write the requirements in such a way that they captured the reality of kind of how this works in real world scenarios today without writing a bunch of mandates that probably would cause more harm than good in at least some scenarios. Dimitris Zacharopoulos: Well, if there is a malware out there that causes real damage, for me it's pretty simple, there is existing language in CSBRs that we need to find if there's going to be an impact for are there good signatures let's say that are out there but in the lack of any of that information, backdating to the date of the not before would, also be an option. Tim Hollebeek: Well, it's certainly an option, but, I mean, going beyond what we currently have written, you would have to mandate some rules around how what dates you can and can't use. Right? And, I don't know, perhaps somebody smarter than I can come up with language for that would actually work but I'm kind of skeptical that the language can be written. I could be wrong. Ian McMillan: I'm with what Tim's saying here, and there's tons of cases that that will encounter with commodity malware that's been signed that a revocation of that certificate has very little impact of the broad ecosystem, but there are those edge cases, and they're becoming more and more prevalent. unfortunately, where the impact of that revocation is way too big, and it actually has more impact and damage than the malware is having on the ecosystem if we were to do that revocation. Drivers are a great case in point, where it can cause blue screens on devices, but I don't know how we write that language other than saying, you know what Tim was saying, you work with your root programs to determine what's the right backdating but I don't I don't know how we write good language that someone can actually audit that. Dimitris Zacharopoulos: Usually we write the requirements that, we serve the majority of cases and then we can focus on the edge cases. If you're saying, the edge cases are more than the normal cases, then it's a little bit reversed. And for this particular one, we are so flexible that a CA can decide whether to backdate or not back date, you know, depending on the language, so that's audited. I think it's pretty complicated to deal with this ballot. So, I think I will agree with both of you that we'll probably need more time to think about this. Trevoli: What ballot are we talking about? Dimitris Zacharopoulos: The ballot for the malware. Trevoli: Okay. Is there like a link someone can put in chat? Dimitris Zacharopoulos: I put it on the chat Dean Coclin-Any other actions you want to take on this? Martijn Katerbarg: No, I think everything else is pretty much settled. Unless anything else comes up right now. Cory did push 1 suggestion which I committed yesterday, which was a no brainer cause it matched everything else. I don't know if the original endorsers are still okay with that. If they are. I'd like to try and push forward with it. Ian McMillan: Yeah, let me have another review of the git hub of the current state and I'll probably be willing to endorse unless I find anything that really sticks out to me, but I was one of the original endorsers, I believe. Martijn Katerbarg: Yeah, and the 2nd was Bruce so. Bruce Morton: I've looked at it today. I was going to call out, we have a lower case problem report and I don't know whether that should be an upper case certificate problem report. Martijn Katerbarg: Line 508, I see it. Bruce Morton: I think that was the only thing. Dimitris Zacharopoulos: I think it's correct not to be a certificate problem report. Because you have a problem report, and then you are doing an additional investigation and you might discover some more things. Bruce: I don't think it'll impact anything in the big picture Dimitris: yes now I read it again I think you're correct Bruce Martijn Katerbarg: Okay, that makes sense to align it. I think we mentioned it 3 times elsewhere as well. Let me go do that right away and then wait for Ian and then we can move forward. Bruce Morton And what was the outcome about the number of days? For example, 7 days must be within 14 days. Is there an outcome there? Martijn Katerbarg: There were some comments from Chris from GlobalSign. I know personally, I don't think 14 days sounds acceptable. I've asked for other opinions, unless other people think waiting 14 days as maximum sounds reasonable, we can discuss that Bruce Morton: Ian, what do you think, what's tolerable from the Windows side. Ian McMillan: I really don't like waiting. We're trying to, just overall our trend is trying to reduce the time it takes to get a revocation out just even in our own programs and just generically in this space. We realize, if you look at other platforms, they don't take weeks, months, which some of these revocations can tak,e and for good reason. And not all of those are really related to a CA, taking a long time. It's more less around just overall how you do revocation in Windows. But we're trying to reduce that time, so I would like to see it be reduced for sure, but I don't want to be unreasonable and that's where I really lean on what you guys say and need because you're the ones who have to operationally do this. Bruce Morton: It seems that on the SSL side, you have 24 hours or 5 days and, there is no malware. And this side where you have malware, we're giving them an extra 2 days or we would give them an extra 9 days, we bumped up to 14 days, and there's malware. And it's the fault of the subscriber, right? It's their key, so I don't know why we're giving them so much grace. Dimitris Zacharopoulos: If they violate the subscriber agreement for signing suspect code. Ian McMillan: Yeah, it's for all those reasons, you should just revoke but what Tim called out is very real. A revocation, because the signing certificate, and those private keys can be used for 39 months maximum, they signed so much code and it could be one of those cases where the subscriber was a victim and now we revoke and we actually hurt the ecosystem more because of that revocation. Trevoli: So, one thing: I know this is carry over language from the previous. But one thing that stands out to me about these dates: Is there a strong need to include "the CA and subscriber may determine a reasonable date". But then the date can't be more than 7 days. Why offer that option to the subscriber when, you might, they might only be 3 days? It just seems like that's like an unnecessary back and forth step and you could just eliminate that and say, notify the subscriber the certificate will be revoked on this date. Bruce: So you're basically saying it should be 7 days, is the maximum and this, and we can revoke earlier and that's really the subscribers call. Trevoli: No I'm saying we shouldn't give the subscriber an option. The problem with giving the subscriber an option is, what if it's a three day weekend in the country that the subscriber is in? Bruce Morton: But if I have the subscriber who wants that certificate revoked now? And then why would I carry it out for 7 days? Trevoli: Oh, sure. I think we should we should change the language to be clear because it sounds like, negotiate with the subscriber to if it's tomorrow or if it's 2 days from now, I would read it, as a subscriber that didn't want my certificate revoked, as these rules say, I can have this max amount of time. I don't read this as a subscriber, I get to request that we revoked sooner. Martijn Katerbarg: No, I do agree with you and one of the reasons is that the current language already has this reasonable date, but it doesn't have any set time limit so basically it could determine, let's leave it for another year. That's really what I want to limit at this point. I think maybe it goes too far to right away set it at the maximum, maybe 2 days. Trevoli: Exactly. That's what I'm saying is, reasonable is in the eye of the beholder and what you need. And the language says reasonable date, but it has to be 7 days after the report was received. Martijn Katerbarg: But the CA doesn't need to agree with that. Even the CA can always revoke earlier. Trevoli: They can I, I guess what I'm saying is, including that language implies that we have to have a back and forth discussion and offer options. Tim Hollebeek: I actually think Trev is onto something. I don't see how the 72 hours actually makes this proposal a lot better. The contact within 24 hours is great. I don't see why whether the subscriber responds or not. I mean, starting with it, it's sometimes subscribers, like Trev said, there are a variety of reasons why they may not respond within 24 hours and having that language that implies that there is sort of this back and forth negotiation and a lot of times these emails take, because it's kind of a tense situation sometimes, you know, the conversations don't go particularly quickly. Having it this complicated is going to cause more problems than it solves. Ian McMillan: Unfortunately, though previously, it was even more complicated, wasn't it? While I see the subscriber in this case, there shouldn't be that much of a negotiation, Especially if they're unresponsive and you shouldn't be giving them a, well, it's implied that I can get a, a max of 7 days so, I always want the max of 7 days. It should be more of the control of the CA. The CA makes this determination if the CA Is looking at it and says, hey, I talked with the subscriber, I looked at the subscriber across the ecosystem, and I see revoking would have a bigger damage of the ecosystem, then you've made that choice and that's your justification. It's ultimately the choice unless the root program or, this goes to a different part of the requirements, comes and say,s no you must revoke at this time. Trevoli: Yeah, I guess I'm suggesting to the language, say something like the CA must notify the subscriber within 24 hours of the report. with the revocation date for the certificate. And then that revocation date must not be more than 7 calendar days after the report is received if the subscriber actually writes back. It's a reasonable amount of time and says, hey, can you just revoke it tomorrow? Instead, you know, can you revoke it immediately, we're totally cool with this. Please do. So then why don't we revoke it sooner? Ian McMillan: What if I go the other way, what if I'm Solar Winds and I come along and I say, hey, actually revoking, will put the entire ecosystem of all my customers at a security disadvantage. It actually reduces the security posture of all of these customers that I have immediately. I need revocation to happen, or I've shipped a new version that's signed with the new cert and I have all of my major customers or whatever number. Give me 6 months. Those are very rare cases, how do we manage that Trevoli: I think that kind of like two options off the top of my head are: We acknowledge that that is a situation that is untethered from the rules and undesirable but you have to notify the trust stores to let them know that this is a thing that you were going to do is you're just going to literally be in violation of the rules and this is why. Or, and, I'm dubious that this is ideal or that we should change the revocation requirements to carve out a process by which CAs can say, or submit a plan similar to the, In the network requirements, how there's that thing where you have to fix a critical, or you have to have a plan within 96 hours. But, I mean that's kind of the thing, like, I think that if you acknowledge that, that's always something someone has to make an incident report for. I mean, that it's a formal process through the browser programs and it's always a violation. In Mozilla, it would just go in your audit report. Tim Hollebeek: So maybe there's a couple of things we can put together maybe that help with this because we only have to write the rules for revocation based on malware so the hypothetical what if the customer wants the certificate revoked earlier we don't have to write special rules for that because that certificate must be revoked upon request from customer, we already have that as a revocation reason right now so you just got a second reason on top that you have to revoke and since the customer requested revocation, you don't have a choice, you have to revoke and the same thing with if Microsoft decides, we don't like what's going on in this particular situation, we want this particular revoked faster for this, that, or the other reason, we already have rules in the Microsoft root program that allows them to do that. So, those cases are already handled. Maybe we can say something like, you either have 7 days to revoke the certificate, or submit a plan for revocation to certificate consumers. And so now, these certificate consumers have a plan and if they think that the plan is not effective, their recourse is they have this ability to request revocation on their own. Ian McMillan: Yeah, that's great. Tim. Trevoli: I think that's a lot more clear to. Corey Bonnell: If the risk of making this more complicated, I'm wondering if maybe there should be another aspect we should be looking at additionally and that's with code signing certificates if you revoke code signing certificates, all signed software doesn't necessarily become invalidated. It's based on, if it's time stamped code, it could still be potentially valid, if the revocation date was after the time of signing. I'm wondering if maybe we want to add some language here like, you work with a subscriber to determine the earliest time of compromise, because, the case where you have device drivers or something like that, that might have been signed and timestamped before the time of compromise, there's no reason to invalidate those but the things that are signed after the compromise, reasonably you would want to invalidate. Tim Hollebeek: You're absolutely right, but I'm trying to avoid writing language around that just because I've been involved in these efforts and I think your chances of writing language that successfully captures what you said is zero, at least, in any meaningful way. It's going to have caveats where people are, that's sort of the world we live in today where it's like, yeah, you're supposed to make a best effort to determine what the appropriate revocation date is in backdated to the appropriate time and it's really messy and I think you do have to kind of make it a little bit more flexible in the way we discussed. This is one of those areas where at some point, there has to be some discretion for CAs, and root programs have to incorporate into their evaluation of CAs, how CAs use their discretion within the lines, in addition to whether they are crossing the lines. I think it's perfectly reasonable to have a conversation with a CA that consistently takes 6 days and 23 hours about whether they are actually following the spirit of the requirements even if they're following the strict requirements. I don't know that you can get better than that. Dimitris Zacharopoulos: Well, judging from the entire conversation, I think from what I've heard there is a lot of a burden being shifted from the certificate consumer here to the CA, about determining the impact to the ecosystem, meaning that, a successful hacker is going to 1st, sign the driver, distribute it everywhere, and then write malware to steal personal data from millions of people, and people are going to think that it's going to cause more impact to backdate that certificate, that would then invalidate the driver. So it's a very, delicate situation and there should be some better solutions within Microsoft to white list a driver or something rather than having the CA going through all these hoops to determine what's the correct date for not causing damage to the entire world. But, yeah, Tim, I agree with you. It's sounds impossible. We should probably take a stab at it at some point and just to confirm your theory. Tim: Like I said, there's some things we can do, I think, to submit a plan idea is a great one. The direction in which there might be a crack of light that we want to move towards is perhaps if we have some requirement around disclosure of a CA's practices around how fast they manage to revoke certificates so that there can at least be some transparency about which CAs are actively trying to do a good job to protect the ecosystem by finding reasonable dates and taking reasonable information into account and as I've mentioned, let's say the data shows that one CA 99.9% of the time takes six days and twenty three hours and fifty nine minutes to revoke certificates, well you know exactly what's going on there and then we can think about whether there needs to be ecosystem improvements, but maybe a little bit of transparency would go a long way towards causing people to behave better. 4. Ballot: Signing Service Update. Here's the discussion on this topic: Bruce Morton: We're working on updating our signing service requirements. No ballot number yet. Dimitris: It's CSCWG - 16 Bruce: We've done a bunch of proposed changes and there's a bunch of comments here, and I was just going through the comments and a lot of them were from Dimitris So, I don't think it's closed and we can just look at the document on the screen. We were talking about if should we be calling up the Net Sec document in a number of places, and you suggested that we strike it out I suggest that we want to make sure that someone running a timestamp authority or a signing service knew that applies to them since the NetSec document is talking about CAs. But then, I think maybe we just call it up in section 6.7, where NetSec called up and explicitly call it timestamp authorities and signing service. And then we've already put it into the subsections of 8.4 where it's called up as an audit requirement. Does that sound like it's a good direction to go to? (Dimitris-Yes) Bruce Morton: Okay, so I was just suggesting that we move this stuff regarding air gap stuff to the timestamp ballot that I think Ian will work on in the future some time. And then you said, should we allow combined reports? I agree. We should allow combined reports. If a CA is running a CA, a signing service and a timestamp authority, I don't believe we need multiple reports. So we can put that in I thought it was understood, since you called it out, then someone might understand it that you need separate reports. We're fine with combined audit reports? Dimitris Zacharopoulos: thumbs ups are from me and Ian. Bruce Morton: Okay, so Martijn is not on the call now but was asking if this fine that we changed it from manufacturer certificate to basically a certification type of certificate. Tim Hollebeek: I think that's what was meant, right? Bruce Morton: Yeah, but he, he said, he thought it meant key attestation and I, I don't think it ever meant that. Tim Hollebeek: No, it meant FIPS certificate. Manufacturers FIPS certificate is what it should have said. Bruce Morton: OK so we leave that. Dimitris Zacharopoulos: hold on which section exactly. Is that. It's in the service, not signing service. Tim Hollebeek: We need to be careful because we do use key attestation in the new key protection requirements. Dimitris Zacharopoulos: Private key storage for signing services Yes. Correct yeah, there's no key attestation here. Bruce Morton: Right. They're running an HSM and they're going to be audited. So why do we need key attestation? Dimitris Zacharopoulos: do we need to expand also on the FIPS or common criteria or are we basically accepting what's on the 2nd paragraph? (Bruce: no) So, we don't need to be very explicit here. Good. Bruce Morton: Right. It's applying the type of certificate not the type of HSM. So you're suggesting this update for the audit requirements, so I don't think there's any objections to that. That was the request. Dimitris Zacharopoulos: Yeah. Even though it's for the time stamping and, we agree to have a separate ballot. This is very basic. Bruce Morton: Just so everybody knows I broke out the audit criteria, so that rather than all being lumped into one under CA, I broke it out to CA, timestamp authority and signing service. So if we just broke out signing service, then the timestamp authority would be a snowflake, so I, we just made the 3 different items, so it is impacting it a little bit, but we're not providing the requirements to the timestamp authority we're just hopefully stating them differently. Tim: Wait, how is that not a requirement? Dimitris Zacharopoulos: it is a requirement per ETSI standard. Tim Hollebeek: Dimitris' fix looks like a good fix to me. I'm wondering why we aren't just applying it. Bruce Morton: I was suggesting we should apply it. Tim: Oh, okay. Sorry. I agree. Dimitris text looks right to me. Bruce Morton: Okay, Ian was asking about if we want to move from level 2 level 3. We should have a date when we have to go to that. I never thought of that. A date does make sense. The other question is, is there any existing signing service out there that's using Level 2? If there's none, then, maybe we don't need a date Ian McMillan: I don't know. Tim Hollebeek: the other thing is we could just put a date just because, but here's the problem and we need to look into that because we could put a date because if there isn't one, it doesn't matter. But the problem is, if we pick a date, and if somebody is using a level two HSM in a signing service, replacing an HSM is not something you do on a short timeline. So if there is anybody, I think we need everybody to just kind of go and say, hey, I'll check and make sure what we're using and, but, yeah, we should publicize it pretty widely. Bruce Morton: I would push this out to whatever, greater than 6 months after the ballot was approved. So I don't know what that date would be Ian McMillan: I would say, 12 months Tim Hollebeek: Yeah if we're just going to pick a random date to avoid having everybody go and look, I would pick 12. And I actually we're going to go and look anyway, because even 12 months can be a little bit interesting for changing HSMs at scale. Bruce Morton: I'm just going to say I need to do that. Dimitris Zacharopoulos: it's more than the HSM, it's also an audit. Tim Hollebeek: Exactly. But, I think it's good for everybody just look at whether level 2 signing services exist or not, and then maybe we can get away with just not having a date and just saying, okay. Bruce Morton: Dimitris would like to update the signing service definition to be this definition here (shown on screen). Dimitris Zacharopoulos: I explained it a little further down, because the way it's written, it says it that signs code. Bruce Morton: I didn't know if it just meant remotely signs a hash of the code or something of that, right? Dimitris Zacharopoulos: And I also didn't want to use the word hash. Ian McMillan: I've seen 2 types of signing services, there's the ones that ingest the content that they intend to sign and they're signing the code itself, or like, what Dimitris is calling out there, just ingesting the digest hash that needs to be signed. Bruce Morton: doesn't the service take the code, create a hash and that's what it signs or it gets a hash and that's what it signs? Doesn't it sign the same thing In both cases? Ian McMillan: not always, we have even in our internals, we have digests signing process where we have sign tool only send us a digest. We've created a plug in that works with sign tool that, we never ingest the code for our signing service. The signing service only ever gets and we only ever process the hash that needs to be signed that was created by the sign tool Bruce Morton: I'm in I'm in agreement with you there, but in the end, do we only sign the hash regardless of what we received? (Ian: yeah). Okay. So, why do we have an "or" if we're only signing 1 thing? Tim Hollebeek: So, that's the thing. I think it's an implementation detail. I think when you say the sentence signs code using a code signing certificate, what you mean in engineering language is either the hash is taken somewhere else or the hash is taken locally. And then the hash is signed, because that's kind of how signature signing works for objects. Having to restate that in the requirement in definition I think is unhelpful. Dimitris Zacharopoulos: I just wanted to I want to make sure that people that want to implement signing services, they will see that there are at least 2 dominating use cases that are used. Bruce Morton: It doesn't bother me to leave this as is Tim Hollebeek: So, if we want the clarification, we should, perhaps put a may, or a note somewhere stating that the hashing need not happen within the signing service it's okay if somebody submits just a hash, because that's actually a useful thing to say explicitly, because there are some reasons including, let's say in the future if we want to add some scanning requirements or things like that, there are some reasons why you might want some signing services to see the code instead of just a hash. But today, I think it's actually an interesting point. I just don't think we should muck with the definition. I think it's probably some verbiage that exists in some other section. Bruce Morton: I think I agree that definition isn't clear enough, right? Because someone's going to say, I'm not signing code. The definition I think needs to be fixed Tim Hollebeek: Really? Bruce Morton: Well, if someone's going to say, I'm not signing code, I'm signing a hash. And then you get into this little debate well that's what we meant and so I think Dimitris was trying to write down, that's what we meant. We meant it could be the code, or it could be data associated with the code Tim Hollebeek: I think I think we still have to say that outside of the definition. And that's because as I'm running through things I might say in my head I end up trying to say things like the hash may be calculated by the subscriber or by the signing service and that's a requirement and requirements don't belong in definitions Bruce Morton: Then should we put the word hash in this? Because I think code signing is more of a marketing term than it is a technical term. It doesn't sound like a spec term. Unless we go and define, or have we defined code signing? Dimitris Zacharopoulos: when we define a signing service, the best place to clarify what we mean by signing service is the definition itself. But for the implementation of and requirements around signing services I agree we should put it in a different place but we're just talking about the definition Tim Hollebeek: But that's the thing that I disagree with you about. I think the clarification isn't about the definition. The clarification is about what exactly the requirements are around how code signing works and where certain operations like hashing may or may not be performed and so I think it's more around the actual requirements of what we mean by signing service and what they're allowed to sign than it is around the actual definition of what a signing service is. Dimitris Zacharopoulos: If you see it signs code with the capital C, then that's what is described here is not the hash. It comes out of scope Tim Hollebeek: Well, I get the argument that you're saying, I think we need requirements to clarify that the interpretation that Bruce and you are saying that, that is not a correct reading of this, and that if you're signing objects that if you're signing a number of bites, that's short enough to be a hash, you are signing code. And that's just because that's how code signing works. Ian McMillan: The data that you sign associated with that code is actually the to be signed hash. The TBS hash Tim Hollebeek: Yeah, that's the thing, it's always a hash. So when you say, sign code, somebody can't really say I'm signing a hash therefore, I'm not signing code because when you sign code, you're always signing hashes. Bruce Morton: But sorry, the subscriber has a signing service. Subscriber has a signing application. Subscriber creates a hash and provides that to the signing service to sign and activates the key. They get back the signed hash and then the signer prepares the code signature because now it has the code, the signed hash, the certificate, so the code signing is done by the subscriber. It's getting an input from the signing service, but it's not getting that the signed code, not necessarily. Tim Hollebeek: You're right, the definition does need to be improved. I think the, the point that you made about the fact that the actual production of the signature doesn't necessarily happen at the signing service is actually a valid one and that's a bigger problem with this definition, beyond the whole thing about just, whether it's a hash or not. Trevoli: Do we need to define code? I know they're called code signing certificates. Tim: We do have a definition. It is defined. Trevoli: No, no, I'd say, do we need to? Does the word code need to be inside in the signing service definition. Bruce: I don't think so, but, Trevoli: I mean, we care more about who's controlling the keys then what is being signed? Bruce Morton: We don't know that it was code that was hashed actually. Right? Dimitris: We are a code signing working group. If you say it signs objects, then it becomes weird. Trevoli: then I'm saying that the signing service is the concern about control of the keys. So it feels like the signing service definition should talk about something like that. Dimitris Zacharopoulos: But we have a plan to add some more requirements to the signing service, like, checking, maybe in the future checking for malware. Tim Hollebeek: Right. And so that's the interesting thing is, it actually really is an interesting question of whether the signing services required to see the code or not. And, in fact, we may actually end up diverging into the spot where we may actually include in signatures at some point in the future, whether the signing service has seen the object it has signed or not. Because of the fact that, in the case of only the hash was submitted, obviously, it wasn't scanned. Ian McMillan: I don't I don't think it's requiring scanning. It's too overarching and it gets into confidentiality issues. I don't want to see missile targeting system software ever in a signing service. Bruce Morton It's the wrong direction as well. I thought the direction was we were trying to protect the keys and not.. Now all the signing service has to be the expert on finding malware Ian McMillan: No, and it shouldn't and we'll never have a consistent means to have a signing service properly, or even defining what's proper code signing or scanning is another really difficult problem. Bruce Morton: Okay, so I think we have to step back then and redefine signing service, so why don't we take that as an action item? Bruce Morton - Dimitris, do you want to try that or should I try that or? Dimitris Zacharopoulos: Somebody else should try a different definition. I think. Ian McMillan: I can take a stab at it too. Thanks again and Trev I'd love to have your feedback. You have a good fresh perspective. We've been talking about signing services for a long time. Bruce Morton: We were trying to remove this term that says signing services secure infrastructure. Because it says we transferred to subscriber outside of the signing service infrastructure. We don't want the signing service to transport any keys. But we do allow a CA to create keys for a subscriber, and I assume a CA can delegate that service to a delegated 3rd party. So that's why we swapped out signing service with CAs and delegated 3rd parties secure infrastructure. Dimitris Zacharopoulos: But the problem is that a signing service could be a delegated 3rd party. Bruce Morton: No the CA is not obligated to be a signing service. So you don't have to have a signing service. It's not an obligation. You can only delegate things that you're obligated to do. Dimitris Zacharopoulos: So, let's assume there is a signing service that is a partner of the CA, or affiliated with the CA. Then would that signing service be okay to generate keys and then sending those out to the subscriber? Bruce Morton: Well, there's nothing stopping a signing service from being a 3rd party or a associate or a partner or anything. We didn't say that the signing service has to be the CA. Dimitris Zacharopoulos: I thought we wanted to prevent this from happening, so we didn't want the keys to be transported outside. Bruce Morton Agreed. So we don't want the signing service to do this, so we're not allowing the signing service to transport the keys. So, we are allowing a CA to create a token and put keys on a token and transport them to the customer. Tim Hollebeek: The customer keys leaving the signing service, they're not signing service keys, leaving the signing service. Ian McMillan: Yeah, we don't want to allow the customer keys outside of the signing service. Dimitris Zacharopoulos: now I understand the intention, what you were trying to do, and thanks for that So just need to do a fresh read of this to make sure it delivers Tim Hollebeek: Ian is right so that, isn't this trying to do something that we didn't want to do, because the whole purpose of the signing service is to protect the end user keys, this is saying how you transport the end user keys to the customer. Bruce Morton: This doesn't apply to the signing service. This applies that if the CA wants to generate keys for the subscriber, how they would transport those keys to the subscriber. Tim Hollebeek: So these are non signing service keys. Bruce Morton: Yeah, this is what CAs are currently allowed to do. Right now we're allowed to generate soft keys and send them to them as long as they're encrypted using the 128 bit encryption. Tim Hollebeek: Yeah, I was just assuming we're in the signing service section due to the fact that the text previous said signing service, but Bruce: Right. So it's private key delivery to subscriber and it said signing service security. Tim: Yeah, that's an error in the current, right? Bruce; Yeah, we wanted to remove any call out to the signing service cause I would want them to deliver keys. Dimitris Zacharopoulos Bruce, would you be okay if we added an additional sentence that says that, signing services are not allowed to transport subscriber keys outside their infrastructure Tim: we should add that Dimitris: Yeah, because I read it 2 or 3 times and I also considered people could misunderstand the delegated 3rd party to also mean, a signing service. Which is not the CA. Trevoli: Yeah, I like that suggestion Dimitris. Or should we add to that specifically once consumed or once ingested. Once a signing service has ingested a key, then it should not be exported. Dean Coclin: We're coming up at the top of the hour and I think we're going to have to interrupt this spirited discussion at this point. Bruce can we just close out at this point and pick it up at the next meeting. Bruce Morton : Yeah, so we'll close that. So maybe Dimitris do you want to provide that sentence? Dimitris Zacharopoulos: Sure. Yeah. I'll add it. 7. Other business: None 8. Next Meeting December 15th Meeting 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 infra-bot at cabforum.org Sun Dec 18 07:34:34 2022 From: infra-bot at cabforum.org (Infrastructure Bot) Date: Sun, 18 Dec 2022 07:34:34 +0000 Subject: [Cscwg-public] Weekly github digest (Code Signing Certificate Working Group) Message-ID: <010001852427ecfe-7eb87fff-c507-405d-afed-04373670b4e1-000000@email.amazonses.com> Pull requests ------------- * cabforum/code-signing (+1/-0/?0) 1 pull requests submitted: - Import TLS BR references into CSBRs (by dzacharo) https://github.com/cabforum/code-signing/pull/16 Repositories tracked by this digest: ----------------------------------- * https://github.com/cabforum/code-signing -------------- next part -------------- An HTML attachment was scrubbed... URL: