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

Fri Sep 23 07:43:33 UTC 2022

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220923/de998990/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6827 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220923/de998990/attachment-0001.p7s>