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

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Thu Feb 2 17:12:08 UTC 2023



On 2/2/2023 5:56 μ.μ., Bruce Morton wrote:
>
> Hi Martijn,
>
> I don’t think I can endorse the current proposal as it does not appear 
> to be meeting the goal I was hoping for, which was to simplify the 
> process. I do like the way that the requirements are defined in the 
> SSL and S/MIME BRs. These documents give revocation time deadlines and 
> reasons for each deadline.
>
> I do understand that signing of suspect code is a little more 
> complicated as the Subscriber may have good signatures, but then get 
> compromised. I think we tried to address this issue, by providing 
> 7-days to revoke a certificate which has signed suspect code. This 
> would allow the CA, Subscriber and perhaps the Application Software 
> Supplier to provide the earliest revocation date. Note, with private 
> keys in hardware, the Subscriber will more likely be an attacker and 
> will not respond.
>

If there is no response, then the CA revokes and can set the revocation 
date to the date before the signing of the Suspect Code. My suggestion 
on a previous meeting was the following:

  * If the CA has reasonable assurance that a Certificate was used to
    sign Suspect Code, then the CA shall revoke the Certificate within
    24h and set a revocation date to a date and time before the signing
    of the Suspect Code.

There were concerns raised that this backdate revocation might 
invalidate other Code, not classified as "Suspect" and may cause more 
harm than good. I can't really see why we should allow Suspect Code to 
be executed and risk user's safety and personal data, because that 
Subscriber has signed other "good" Code after signing the Suspect Code.


> Note, I don’t believe “Revoking a certificate at current time has 
> absolutely no impact on existing signed malware” is true. If the 
> suspect code is not time-stamped, then revoking at the current time 
> will impact the suspect code signature and all other signatures which 
> are not time-stamped. This might be the easiest and quickest way to 
> deal with non-time-stamped signatures on suspect code.
>

We rarely see non-timestamped code out there but Ian might be able to 
share some more insight with real numbers (timestamped code executed vs 
non-timestamped).

I don't disagree with revoking immediately (at "current date") and 
setting a revocation date in the past after 5, 7 or 10 days to further 
mitigate the Relying Party risk.

> On the other hand, 7-days would allow the Subscriber to resign code 
> they did not time-stamp. Although, I am not really in favor of 
> providing extra time for Subscribers which are not time-stamping.
>
Agreed. Please see my previous comment.

> It would be great if after this ballot and the ballot that Dimitris is 
> doing is if we had just sections 4.9.1.1 for 24-hour revocation and 
> 4.9.1.2 for 7-day revocation. This would align the sections with the 
> SSL and S/MIME BRs and probably our CPS documents.
>

If Ian is ok with not requiring long delays for Subscriber impact 
assessments and contacting Application Software Suppliers at a Global 
level (which in my opinion wouldn't really scale), we could do the 
following:

  * set the revocation timelines according to 4.9.1.1 and 4.9.1.2 to
    align with TLS and S/MIME BR numbering, setting the "revocation
    date/time" at "current time"
  * AND provide an option with a hard 7-days deadline after a
    Certificate Problem Report is received only to set the best
    "revocation time". The output of this second process will be either
    a "revocation time" before the signing of the Suspect Code, or a
    "more appropriate" one.

Does that seem to work?

Thanks,

Dimitris.



> Bruce.
>
> *From:*Cscwg-public <cscwg-public-bounces at cabforum.org> *On Behalf Of 
> *Martijn Katerbarg via Cscwg-public
> *Sent:* Friday, January 27, 2023 6:04 AM
> *To:* cscwg-public at cabforum.org; Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr>
> *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, the language has been updated and is available on 
> https://github.com/cabforum/code-signing/pull/10/files for review
>
> *From: *Cscwg-public <cscwg-public-bounces at cabforum.org> on behalf of 
> Martijn Katerbarg via Cscwg-public <cscwg-public at cabforum.org>
> *Date: *Tuesday, 24 January 2023 at 22:45
> *To: *Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>, 
> cscwg-public at cabforum.org <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.
>
> > There is nothing preventing the CA to revoke a certificate right away. 
> Revoking a certificate *at current time* has absolutely no impact on 
> existing signed malware. The impact assessment affects cases of 
> backdating the revocation. I'm afraid this "SHOULD" is just going to 
> be ignored, unless you feel that the CA has enough evidence to 
> backdate revoke a certificate and does not want to wait for an impact 
> assessment of affected Relying Parties by the Subscriber. If it's the 
> latter, I agree but we need to write it a bit clearer.
>
> That latter case is indeed the one I’d like to address. I’ll take a 
> look at appropriate language for it.
>
> > Yes. 7 days seem reasonable to pause the revocation process waiting 
> for a response from the Application Software Supplier but IMO no more 
> than that.
>
> No objection from my end with that approach, but I would then like to 
> combine bullet 2 and 3 into one since they are strongly connected. It 
> takes away any doubt in interpretation.
>
> I’ll get on adding these changes in GH
>
> *From:*Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Sent:* Tuesday, 24 January 2023 16:25
> *To:* Martijn Katerbarg <martijn.katerbarg at sectigo.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.
>
> On 24/1/2023 11:47 π.μ., Martijn Katerbarg wrote:
>
>     Thanks for the proposal Dimitris.
>
>     I have a few remarks on this:
>
>     “/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).”/
>     I’d like to propose  we change this into:
>     “/The CA SHALL request the Subscriber to respond with an
>     acknowledgement and SHOULD 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)./”
>
>     This offers CA’s the option not to request an impact assessment if
>     they deem the evidence clear enough warranting revocation right away.
>
>
> There is nothing preventing the CA to revoke a certificate right away. 
> Revoking a certificate *at current time* has absolutely no impact on 
> existing signed malware. The impact assessment affects cases of 
> backdating the revocation. I'm afraid this "SHOULD" is just going to 
> be ignored, unless you feel that the CA has enough evidence to 
> backdate revoke a certificate and does not want to wait for an impact 
> assessment of affected Relying Parties by the Subscriber. If it's the 
> latter, I agree but we need to write it a bit clearer.
>
>
>     I’m also wondering on the interpretation of the following 2 clauses:
>
>     “/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./”
>
>     I like to think this means that even with a plan submitted to the
>     Application Software Suppliers, revocation MUST occur no later
>     than 7 days after the CPR was received. Is that what you also
>     intend here?
>
>
> Yes. 7 days seem reasonable to pause the revocation process waiting 
> for a response from the Application Software Supplier but IMO no more 
> than that.
>
>
>
>     In my option that should be the maximum time before revocation
>     needs to happen, however, it feels like the whole impact
>     assessment may be a lot of work for a Subscriber, in order to only
>     get 48 hours of extra time before a revocation needs to happen
>     (Although to be fair these may be the very few edge cases, for
>     which it could be useful).
>
>
>     Thoughts?
>
>
> We may need some more feedback from CAs that have actually experienced 
> such cases. From my perspective, 48 hours for an quick impact 
> assessment, seems reasonable considering the impact of a malware to 
> millions of users worldwide that could be stopped by a single backdate 
> revocation action from the CA.
>
>
> Thanks,
> Dimitris.
>
>
>     *From:*Cscwg-public <cscwg-public-bounces at cabforum.org>
>     <mailto:cscwg-public-bounces at cabforum.org> *On Behalf Of *Dimitris
>     Zacharopoulos (HARICA) via Cscwg-public
>     *Sent:* Thursday, 15 December 2022 14:27
>     *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 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:
>
>         1.MUST revoke the certificate no later than 7 calendar days
>         after the CA received the Certificate Problem Report; or,
>
>         2.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 <cscwg-public-bounces at cabforum.org>
>         <mailto:cscwg-public-bounces at cabforum.org> *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
>             <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F10%2Fcommits%2F8e7e3b4e57960994edea267f0e753358aad99574&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cb0ad76f0d0d84163312b08dafe543e45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638101935049093423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4VTnkUUEk8p7Cykjw8c1Ga3wAOAuNu7ohnm4sX88Rik%3D&reserved=0>)
>             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
>             <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F10%2Ffiles&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cb0ad76f0d0d84163312b08dafe543e45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638101935049093423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ps7Oy4e3YBZnHgi5BlCIRceY0N71PJuPm47v8QecEMM%3D&reserved=0>
>
>
>         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 <cscwg-public-bounces at cabforum.org>
>             <mailto:cscwg-public-bounces at cabforum.org> *On Behalf Of
>             *Martijn Katerbarg via Cscwg-public
>             *Sent:* Monday, 26 September 2022 11:58
>             *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
>             <mailto:dzacharo at harica.gr>; 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 <cscwg-public-bounces at cabforum.org>
>             *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
>                 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F10%23pullrequestreview-1118760785&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cb0ad76f0d0d84163312b08dafe543e45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638101935049093423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2mK8YkkM4ZtzE3XAuW4S6iAjpMorn%2FpysXEhmB3WR4s%3D&reserved=0>
>
>
>             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
>                 <cscwg-public-bounces at cabforum.org>
>                 <mailto: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
>                 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F10%2Ffiles&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cb0ad76f0d0d84163312b08dafe543e45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638101935049249631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N6vnfTt1i%2B06M%2BDgN35FV45DEdGMSTgdTvm26dLZTPM%3D&reserved=0>
>                 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
>                 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F10%2Fcommits%2F90fa38ab4dc5e5f9b25fce844b750d693f7256b7&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cb0ad76f0d0d84163312b08dafe543e45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638101935049249631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aDQ3AJP4g4mv2wmkPaEKDe%2BAcgM45AXNOFBDrSPuHo4%3D&reserved=0>
>
>                 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,
>
>                  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 <tim.hollebeek at digicert.com>
>                 *Sent:* Friday, 15 July 2022 18:18
>                 *To:* Martijn Katerbarg
>                 <martijn.katerbarg at sectigo.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.
>
>                 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> *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
>                 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F6&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cb0ad76f0d0d84163312b08dafe543e45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638101935049249631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1iFOtQNrpUfGxTg8MxDcRq4n8q4fzjYYLmtxcy4gTHk%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./
>
>                 _______________________________________________
>
>                 Cscwg-public mailing list
>
>                 Cscwg-public at cabforum.org
>
>                 https://lists.cabforum.org/mailman/listinfo/cscwg-public  <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cb0ad76f0d0d84163312b08dafe543e45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638101935049249631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3vC3Zsi9ykJceVKVsVAof8R7UAzWtcr7nCjJL0X6454%3D&reserved=0>
>
>
>
>
>
>             _______________________________________________
>
>             Cscwg-public mailing list
>
>             Cscwg-public at cabforum.org
>
>             https://lists.cabforum.org/mailman/listinfo/cscwg-public  <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cb0ad76f0d0d84163312b08dafe543e45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638101935049405854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1XHkYB4Ul4%2BdzUkhxGK1QMhwbpS%2B%2BsJ82ueHvRyD7%2Fs%3D&reserved=0>
>
>
>
>
>         _______________________________________________
>
>         Cscwg-public mailing list
>
>         Cscwg-public at cabforum.org
>
>         https://lists.cabforum.org/mailman/listinfo/cscwg-public  <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cb0ad76f0d0d84163312b08dafe543e45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638101935049405854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1XHkYB4Ul4%2BdzUkhxGK1QMhwbpS%2B%2BsJ82ueHvRyD7%2Fs%3D&reserved=0>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230202/5dd8e084/attachment-0001.html>


More information about the Cscwg-public mailing list