[Cscwg-public] Proposal to make changes to revocation based on malware

Fri Sep 23 12:55:29 UTC 2022

Hi Martjin,

I will endorse the ballot.

Thanks, Bruce.

From: Cscwg-public <cscwg-public-bounces at cabforum.org> 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 <cscwg-public-bounces at cabforum.org<mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Martijn Katerbarg via Cscwg-public
Sent: Tuesday, 19 July 2022 09:22
To: Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>; cscwg-public at cabforum.org<mailto: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,

  *   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.

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.

  *   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 <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>
Sent: Friday, 15 July 2022 18:18
To: Martijn Katerbarg <martijn.katerbarg at sectigo.com<mailto:martijn.katerbarg at sectigo.com>>; cscwg-public at cabforum.org<mailto: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 <cscwg-public-bounces at cabforum.org<mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Martijn Katerbarg via Cscwg-public
Sent: Monday, June 27, 2022 10:04 AM
To: cscwg-public at cabforum.org<mailto: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:

  *   Limit the number of days before a certificate needs to be revoked, especially when the subscriber is not responding to inquiries
  *   Remove the OCSP log analysis requirements
  *   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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F6&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C0a91a06103a94b96adf008da69575c2d%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637938121195022126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BaODhyht2Dvw56UXKIt47jk14XlswOCarDkBIOJs72U%3D&reserved=0> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220923/b59077c4/attachment-0001.html>