secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking - The Something Awful Forums

Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking

Raymond T. Racing: Jun 11, 2019

Subjunctive posted:

someone at work today asked if we should join CA/BF because we do a lot of stuff with certs and why not, and I eventually became relatively sure that they aren�t Wayne

(no, we should not)

ironically, I�d laugh if the adventures of secfuck and CA/B means that everyone here takes a deeper interest in CA/B and brings it back to our respective orgs to push for better standards

# ? Apr 18, 2024 22:24

Adbot: ADBOT LOVES YOU

# ? May 3, 2024 07:04

Kovacs: Jul 19, 2006

Subjunctive posted:

someone at work today asked if we should join CA/BF because we do a lot of stuff with certs and why not, and I eventually became relatively sure that they aren�t Wayne

(no, we should not)

Come along, you can join us in fun places like Bergamo and Seattle.

# ? Apr 18, 2024 22:27

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Raymond T. Racing posted:

ironically, I�d laugh if the adventures of secfuck and CA/B means that everyone here takes a deeper interest in CA/B and brings it back to our respective orgs to push for better standards

we�re definitely not renewing our BIMI cert with Entrust when it expires! one down!

# ? Apr 18, 2024 22:28

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

the adventures of secfuck and ca/b

# ? Apr 18, 2024 22:35

spankmeister: Jun 15, 2008

BIMI sounds an awful lot like EV but for email.

# ? Apr 18, 2024 22:35

Raymond T. Racing: Jun 11, 2019

spankmeister posted:

BIMI sounds an awful lot like EV but for email.

except there's more support for BIMI than EV

# ? Apr 18, 2024 22:49

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

spankmeister posted:

BIMI sounds an awful lot like EV but for email.

yep sure does but it actually shows up in UI

# ? Apr 18, 2024 23:00

Wiggly Wayne DDS: Sep 11, 2010

spankmeister posted:

BIMI sounds an awful lot like EV but for email.

you can guess who's been pushing for EV to be a more generic validation mechanism to be put on top of any type of certificate...

# ? Apr 19, 2024 01:55

fins: May 31, 2011; Floss Finder

Wiggly Wayne DDS posted:

you can guess who's been pushing for EV to be a more generic validation mechanism to be put on top of any type of certificate...

https://bimigroup.org/vmc-issuers/

ding ding ding!

# ? Apr 19, 2024 02:01

fins: May 31, 2011; Floss Finder

of course they're doing well already with their VMC.

https://bugzilla.mozilla.org/show_bug.cgi?id=1802916

quote:

Why did it take so long to discover the problematic EV certificates?
Did you start searching for EV certificates with this issue before 2022-11-28? If not, why? If yes, why did take until 2022-11-28 before you got results?
The jurisdiction information is very complicated. Some of the reasons is a single registry could be accessed by multiple sites. The multiple sites may be interpreted that the site is for a different jurisdiction. There are also issues where the state for place of business and the jurisdiction state might be different. So there was no easy search methodology to find miss-issued certificates. There was a lot of investigation to confirm if a certificate was miss-issued.

# ? Apr 19, 2024 02:09

Wiggly Wayne DDS: Sep 11, 2010

p0 put out a good series on the windows registry and lpes:
https://googleprojectzero.blogspot.com/2024/04/the-windows-registry-adventure-1.html
https://googleprojectzero.blogspot.com/2024/04/the-windows-registry-adventure-2.html

# ? Apr 19, 2024 02:44

redleader: Aug 18, 2005; Engage according to operational parameters

Subjunctive posted:

I dunno who’s fuzzing the Postgres protocol handler but I bet they aren’t using exactly the same config as you are

yeah, i was just thinking that a bunch of three letter agencies are definitely sitting on a bunch of postgres vulns

# ? Apr 19, 2024 03:15

Quackles: Aug 11, 2018; Pixels of Light.

redleader posted:

yeah, i was just thinking that a bunch of three letter agencies are definitely sitting on a bunch of postgres vulns

clearly everyone should just switch back to my :v:

:v:

# ? Apr 19, 2024 04:34

Shame Boy: Mar 2, 2010

Quackles posted:

clearly everyone should just switch back to my

your what

# ? Apr 19, 2024 04:53

Quackles: Aug 11, 2018; Pixels of Light.

Shame Boy posted:

your what

my sql

:haw:

# ? Apr 19, 2024 05:08

Carbon dioxide: Oct 9, 2012

Reminder:

> MySQL is named after co-founder Monty Widenius's daughter, My.

# ? Apr 19, 2024 11:07

Truga: May 4, 2014; Lipstick Apathy

mysql got oracle'd so the new goodness is mariadb

which is named by after other daughter lol

# ? Apr 19, 2024 12:04

Hed: Mar 31, 2004; Fun Shoe

I always thought naming your dogs Inno and ISAM was weird but I guess it worked out

# ? Apr 19, 2024 12:21

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

my daughter is named postgre

# ? Apr 19, 2024 12:31

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

Wiggly Wayne DDS posted:

p0 put out a good series on the windows registry and lpes:
https://googleprojectzero.blogspot.com/2024/04/the-windows-registry-adventure-1.html
https://googleprojectzero.blogspot.com/2024/04/the-windows-registry-adventure-2.html

looking forward to my office reading today, Ben wondering where they�ve been

# ? Apr 19, 2024 13:06

Wiggly Wayne DDS: Sep 11, 2010

Captain Foo posted:

looking forward to my office reading today, Ben wondering where they�ve been

it's more a historical overview of the registry, more parts coming later

i didn't include this in the open issues A-Z list as i was awaiting more info but it just dropped...

2024-03-22: Chunghwa Telecom: Wrong Extended Key Usage setting by GTLSCA
2024-04-19: Chunghwa Telecom: Instructions for Delayed Revocation Due to GTLSCA EKU Misissuance
- initially informed of 3 invalid certs 2024-03-19, investigated and noticed it affected 6450
- action item for original report notes 'revoke all problematic certs' by 2024-04-05
- on 2024-03-22 this changes to 2024-04-17
- they finally attach a list of all 6450 certs on 2024-04-10 after prompting
- their latest response is.. uh..

Leo Fang (trimmed) posted:

amir posted:
Beyond the IR being necessary for delayed revocation, there is an additional question on why there is a delay in making the delayed revocation IR.
==>In response to this incident of mistaken issuance, the verification targets are all government units and government agency websites. We have assessed that the cause of this mis-issuance does not involve a key issue, but only a certificate field issue, which will not affect the customer's information security. In addition, in accordance with the administrative efficiency of government agencies, from notification to the start of processing, it requires agency supervisors at all levels. Signing and approval, and some public agencies need to find information vendors for processing, so it is difficult to complete the replacement within 5 days. Therefore, the certificate is postponed and revoked within a time limit so that the certificates of all websites can be updated smoothly.

We understand Mozilla's position that CA should comply with BR's requirements. However, considering different circumstances, the harm caused may exceed the choice to meet this requirement, and the risk cannot be transferred to users who use TLS certificates.

[b]In addition, we have not encountered such a large number of requests for certificate abolition and renewal. The original program basically provides for revocation, but the package does not preset a large number of certificate renewals, so this incident has a large part The time lies in developing the program for renewing certificates.[b/]

amir posted:
The initial IR was also delayed, being opened ~3 days after receiving the report.
==>We received the notice on March 19 and are not familiar with the reporting mechanism. After listening to the opinions of experienced colleagues, we first asked experienced colleagues to forward the post on our behalf on March 22. Unfortunately, it is still not possible to present the bug immediately.

i'm uh, bolding the part that stood out to me. they're outright saying they don't have the technical capability to revoke and reissue. this is another ca making up exceptional circumstances rules where this doesn't appear in any policy
- their new incident report just posted changes the 'Revoke all problematic certs' due date to 2024-05-15 and says it's "Not yet started"
- but they have reissued all certs in batches, delayed due to the Ching Ming Festival holiday taking them 10 days
- they do not appear to have revoked a single certificate so far

# ? Apr 19, 2024 13:10

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

im gonna start a CA and just reply "soz cant do it chief" to all my tickets

# ? Apr 19, 2024 14:11

Shame Boy: Mar 2, 2010

Carthag Tuek posted:

my daughter is named postgre

so does this mean there's a Mr. SQL too

# ? Apr 19, 2024 14:31

Shame Boy: Mar 2, 2010

wait no that joke only works if it were mrssql not mssql, i'm not entirely awake yet :sigh:

:sigh:

# ? Apr 19, 2024 14:32

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

the reg stuff was a good intro but i want mooooooreeee

# ? Apr 19, 2024 14:44

Wiggly Wayne DDS: Sep 11, 2010

Carthag Tuek posted:

im gonna start a CA and just reply "soz cant do it chief" to all my tickets

well here's a model: entrust have replied to a variety of questions, to make this legible i'm just quoting their answers for the full context check the links:

Entrust: EV TLS Certificate cPSuri missing

Paul van Brouwershaven posted:

As described previously, we examined the issue and made a determination that it would be in the best interests of the Web PKI to not revert to a practice that the CA/Browser Forum had adopted as �not recommended.�
...
See above; we do not have additional information to share beyond our reasoning at the time. We have acknowledged that we should have stopped issuance of EV certificates without the policy qualifier upon confirmation of the issue, and then followed up to pursue what we saw as a possible oversight in the EV Guidelines.
...
Our experience and knowledge as an active member of the community led us to view these circumstances as exceptional.
...
We did not retroactively change any rules. In the CPS incidents, we have decided to not revoke these certificates as described in those respective incident reports, i.e., because they would result in the issuance of identical certificates, there were no security implications due to the mis-issuance and the revocation and reissuance of these would have been disruptive to the web ecosystem.
...
We do not assume that revocation events will go away. As previously noted, we are undertaking a great deal of effort to make our subscribers more agile.
...
We are open to constructive discussion and dialogue with members of this community to see how we can better deal with incidents such as these, i.e., where there is no impact to security, revocation and reissuance would result in identical certificates or certificates in conflict with other guidelines due to guideline inconsistencies and cause disruption to the web ecosystem.
...
We do not agree there is a moral hazard here for all of the reasons articulated in our answers above. This type of incident is not something we have seen before and is one from which we and other CAs can learn.

Paul van Brouwershaven posted:

We have explained that we are dealing with different subscribers than other CAs that might issue much larger volumes than we do. We hope that members of the community who have experience in the field where Entrust operates understand our challenges and that we are doing everything we can to make our subscribers better prepared and more agile for security incidents. We have had teams working with our subscribers and walk them through the revocation and reissuance process. This process has included multiple touchpoints with subscribers by phone, email, and text message. The impact to subscribers is an important consideration in certain instances like these where security issues are not at play, because when subscribers fail to act this will directly impact relying parties.

Entrust: Failure to revoke EV TLS certificates issued before CPS update

Bruce Morton posted:

Ryan and all � As previously noted, we believe that the incident described in this bug is an exceptional circumstance that merits a reasonable decision not to revoke, as we have outlined. We have taken responsibility for our mistakes and are addressing issues with attention to requirements and the overall health of the Web PKI ecosystem.
...
See general comment above. In this instance, we are not advocating for change or correction to the standards. We are recognizing that in this circumstance, revoking certificates and replacing them with identical certificates would create unnecessary confusion and disruption in a non-security context.
...
Subscribers have been notified of the CPS error both via messaging to subscribers and errata messages placed in the Certificate Practice Statement (CPS) documents. Based on our decision not to revoke, we have not communicated an expectation for revocation.
...
We have not tried to determine this due to the limited time available to perform such research. However, as noted previously, these certificates were issued in accordance with the EV Guidelines and with the certificate profile intended by Entrust. The applicable CPS has been updated with an erratum.
...
We are referring to the confusion, time, and effort required by subscribers to revoke and reissue certificates that were reissued in response to a very recent revocation and balancing this with the issue at hand � that is, no security risk, replacement with identical certificates, minimal number of subscribers and relying on parties that have seen this error.

We are not able to calculate specific time and effort required by our customers. However, we are aware from feedback that significant effort is required to ensure that changes do not create an adverse impact on web services and back-end processing.
...
We consider scope of impact based on the scale of web ecosystem users served by the subscribers affected, which include national and global banks and other institutions providing critical services. We balanced potential disruption with the knowledge that there is no security issue presented, and a minimal number of subscribers and relying parties with very few users that had downloaded the CPS during the timeframe in question, as noted previously.
...
That a certificate is not directly exposed to everyone on the internet does not mean that it is not exposed to a subset of the internet. We do believe that in some cases subscribers can move to private PKIs. Entrust operates many private and shared PKIs, and this is a solution we encourage our subscribers to consider where the Web PKI is not required.
...
Our position is that this case is exceptional: These certificates were issued in accordance with the EV Guidelines and with the certificate profile intended by Entrust. The applicable CPS has been updated with an erratum. If the certificates were re-issued, they would be re-issued with the identical certificate profile. Our analysis above indicates that the number of subscribers and relying parties that have seen this error is minimal.
...
We believe that in this instance, if we initiated revocation per the TLS Baseline Requirements, it could cause errors for many certificates � for reasons that relate to a policy statement error rather than to a critical security issue.

Even if we filed a delayed revocation report, many subscribers might not replace their certificates due to confusion about what to re-issue and what not to re-issue, given the concurrent incidents. We already see many of our subscribers struggling with replacements today.
...
We have outlined efforts in this direction in Comment 7. In the event of a mis-issuance, Entrust has the capability to revoke certificates within the timelines established by the TLS Baseline Requirements.
...
[e/n: this is a breakdown of domain validation methods]
code:
Method 	Domains
3.2.2.4.2 	15998
3.2.2.4.4 	1058
3.2.2.4.7 	19568
3.2.2.4.13 	61
3.2.2.4.14 	905
3.2.2.4.15 	6
3.2.2.4.18 	374
Note that many certificates have more than one domain name.
...
As we have stated before, our decision in this instance is not related to the capabilities of our systems or the automation we provide to our subscribers.

We do have ideas to further improve, such as the implementation of ACME ARI, the direct exposure of the renewal request in reports, and other APIs. In the postmortem of these incidents, we plan to further explore the possibilities to improve our systems, policies, and procedures and can share this with the community.
...
We think that root programs could support our idea of an industry-wide fire drill to collect information about what percentage of certificates can be automatically replaced. An industry-wide fire drill on a future date could also be used to generate wide media attention for more awareness.

In addition, root programs can help to encourage cloud service providers to expose ACME configuration options, such as ACME server addresses and external account bindings, and request providers to support for ACME auto discovery for servers and authorized clients.
...
Based on this and the other incidents, we will increase our efforts to educate and push subscribers to adopt automated certificate lifecycle management.
...
As we noted in the comment you cited, we are committed to ensuring that our actions are in full compliance with the requirements. Our focus is on ensuring that this kind of error does not recur, and one of the ways to accomplish this is to help the industry advance its ability to automate reissuance and revocation.

If a similar incident were to occur, our decisions would reflect our dedication to the BRs and secure internet practices, informed by constructive dialogue within the industry.

Bruce Morton posted:

Paul, we acknowledge your comments. One thing we will note is that we have been educating our customers on the need for agility and will continue to advance these efforts.

...i ... i don't know where to start.

# ? Apr 19, 2024 14:48

Shame Boy: Mar 2, 2010

lmao i love it when companies tell me they acknowledge my comments, it definitely fulfills my psychological need to be heard and understood just as well as if they had actually heard and understood me and demonstrated it behaviorally

# ? Apr 19, 2024 15:12

Raymond T. Racing: Jun 11, 2019

what a bunch of words to tell me jack poo poo

there�s no SMART goals, just vibes

# ? Apr 19, 2024 15:30

Main Paineframe: Oct 27, 2010

Wiggly Wayne DDS posted:

i'm uh, bolding the part that stood out to me. they're outright saying they don't have the technical capability to revoke and reissue. this is another ca making up exceptional circumstances rules where this doesn't appear in any policy
- their new incident report just posted changes the 'Revoke all problematic certs' due date to 2024-05-15 and says it's "Not yet started"
- but they have reissued all certs in batches, delayed due to the Ching Ming Festival holiday taking them 10 days
- they do not appear to have revoked a single certificate so far

the honesty is kinda refreshing after a few weeks of watching Entrust's flailing

# ? Apr 19, 2024 15:39

Raymond T. Racing: Jun 11, 2019

quote:

If a similar incident were to occur, our decisions would reflect our dedication to the BRs and secure internet practices, informed by constructive dialogue within the industry.

but Paul, you�ve just shown that your decisions do not follow the BRs with this incident, how are we supposed to take that seriously

# ? Apr 19, 2024 15:42

Pendragon: Jun 18, 2003; HE'S WATCHING YOU

Raymond T. Racing posted:

but Paul, you�ve just shown that your decisions do not follow the BRs with this incident, how are we supposed to take that seriously

We understand how serious this issue is. Please be assured that we are undertaking a great deal of effort. We will work hard to better deal with incidents like these, and continue to work with our customers on this.

# ? Apr 19, 2024 15:48

Raymond T. Racing: Jun 11, 2019

Pendragon posted:

We understand how serious this issue is. Please be assured that we are undertaking a great deal of effort. We will work hard to better deal with incidents like these, and continue to work with our customers on this.

I know that this is just a satire bit but I instinctively went �come the gently caress on� when reading

# ? Apr 19, 2024 15:53

Pendragon: Jun 18, 2003; HE'S WATCHING YOU

Raymond T. Racing posted:

I know that this is just a satire bit but I instinctively went �come the gently caress on� when reading

whenever I needed inspiration for a sentence, I scrolled up to Wayne's post, read a line or two, and immediately knew what to put down. it's just such brilliant and transparent bullshitery.

# ? Apr 19, 2024 15:57

Hed: Mar 31, 2004; Fun Shoe

Shame Boy posted:

lmao i love it when companies tell me they acknowledge my comments, it definitely fulfills my psychological need to be heard and understood just as well as if they had actually heard and understood me and demonstrated it behaviorally

"we see you, we hear you" but for certs

# ? Apr 19, 2024 16:09

Shame Boy: Mar 2, 2010

Raymond T. Racing posted:

but Paul, you�ve just shown that your decisions do not follow the BRs with this incident, how are we supposed to take that seriously

if you read it one way, they're saying they only have to follow the BR's when and in ways that would be "informed by constructive dialog within the community", and if they've demonstrated one thing they sure can have lots of constructive dialog within the community!!

# ? Apr 19, 2024 16:34

Wiggly Wayne DDS: Sep 11, 2010

it's important to note there are many overlapping requirements for a CA when it comes to revocation due to mis-issuance, none of them give any leeway other "do it within 24h; or 5d" where there's different circumstances for both.

Mozilla's policy: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
Mozilla's incident response guide: https://wiki.mozilla.org/CA/Responding_To_An_Incident

CAB's TLS BR (2.0.4, latest): https://cabforum.org/working-groups/server/baseline-requirements/documents/TLSBRv2.0.4.pdf

CAB posted:

4.9 Certificate revocation and suspension
4.9.1 Circumstances for revocation
4.9.1.1 Reasons for Revoking a Subscriber Certificate
The CA MAY support revocation of Short‐lived Subscriber Certificates.

With the exception of Short‐lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:

The Subscriber requests in writing, without specifying a CRLreason, that the CA revoke the Certificate (CRLReason �unspecified (0)� which results in no reasonCode extension being provided in the CRL);

The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason #9, privilegeWithdrawn);

The CA obtains evidence that the Subscriber�s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason #1, keyCompromise);

The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber�s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys) (CRLReason #1, keyCompromise);

The CA obtains evidence that the validation of domain authorization or control for any Fully‐Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded).

With the exception of Short‐lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:

The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6 (CRLReason #4, superseded);

The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn);

The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use (CRLReason #9, privilegeWithdrawn);

The CA is made aware of any circumstance indicating that use of a Fully‐Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant�s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name) (CRLReason #5, cessationOfOperation);

The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully‐Qualified Domain Name (CRLReason #9, privilegeWithdrawn);

The CA is made aware of a material change in the information contained in the Certificate (CRLReason #9, privilegeWithdrawn);

The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA�s Certificate Policy or Certification Practice Statement (CRLReason #4, superseded);

The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason #9, privilegeWithdrawn);

The CA�s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository (CRLReason �unspecified (0)� which results in no reasonCode extension being provided in the CRL);

Revocation is required by the CA�s Certificate Policy and/or Certification Practice Statement for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason �unspecified (0)� which results in no reasonCode extension being provided in the CRL); or

The CA is made aware of a demonstrated or proven method that exposes the Subscriber�s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed (CRLReason #1, keyCompromise)

...

4.9.2 Who can request revocation
The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.

4.9.3 Procedure for revocation request
The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. The process MUST be described in the CA�s Certificate Policy or Certification Practice Statement. The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports.

The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS.

4.9.4 Revocation request grace period
No stipulation.

4.9.5 Time within which CA must process the revocation request
Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report. After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation‐related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate. The period from receipt of the Certificate Problem Report or revocation‐related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1. The date selected by the CA SHOULD consider the following criteria:

The nature of the alleged problem (scope, context, severity, magnitude, risk of harm);

The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties);

The number of Certificate Problem Reports received about a particular Certificate or Subscriber;

The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that they didn�t receive the goods they ordered); and

Relevant legislation.

that's the baseline and -generally- aligns with entrust's version (they merge code-signing segments in), but the important part is there is no mechanism for not revoking within the timeframe (see 4.9.5).

# ? Apr 19, 2024 17:02

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

e: i was gonna change it to be about entrust but i cant be arsed

# ? Apr 19, 2024 17:09

Raymond T. Racing: Jun 11, 2019

Wiggly Wayne DDS posted:

it's important to note there are many overlapping requirements for a CA when it comes to revocation due to mis-issuance, none of them give any leeway other "do it within 24h; or 5d" where there's different circumstances for both.

Mozilla's policy: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
Mozilla's incident response guide: https://wiki.mozilla.org/CA/Responding_To_An_Incident

CAB's TLS BR (2.0.4, latest): https://cabforum.org/working-groups/server/baseline-requirements/documents/TLSBRv2.0.4.pdf

that's the baseline and -generally- aligns with entrust's version (they merge code-signing segments in), but the important part is there is no mechanism for not revoking within the timeframe (see 4.9.5).

so basically: they�ve flagrantly violated the Mozilla and Google requirements, right?

if I�m a person in charge of a root program, and I�m seeing this, I�m absolutely having that internal discussion of how much letting it slide is too much. let this poo poo go and it shows that CA/B has no teeth

# ? Apr 19, 2024 17:26

MononcQc: May 29, 2007

To play stick in the mud by coming in with incident theory talk, if you have a policy and find it is never respected, then you have to wonder if the policy actually is realistic and practical to implement. I'm not saying Entrust is in the right here, but that if what you find in aggregate is that pretty much no one meets the policy properly, then the problem isn't necessarily that everyone fails while the policy is correct; it might be that the expectations and consequences of the revocations do clash with what the policy wishes the world were like when it isn't.

I don't actually know any of these numbers because I've only read this thread and not any of the other stuff. If we find that pretty much only a few CAs constantly fail with these things while others succeed (which is different from "not failing by never exercising the policy"), then yeah the policy might be fine and corrective action on the CA required. If it's 50-50 you also gotta wonder if there's any population-level distinction that could be in play: what is the difference between the context of those who succeed and those who don't, aside from their lack of adherence to rules?

But for all the normative "you gotta follow the rules" approaches, there's always a real risk that said rules are based on an inaccurate or impractical view of the world and that can't be successfully met predictably.

# ? Apr 19, 2024 19:40

Adbot: ADBOT LOVES YOU

# ? May 3, 2024 07:04

Raymond T. Racing: Jun 11, 2019

MononcQc posted:

To play stick in the mud by coming in with incident theory talk, if you have a policy and find it is never respected, then you have to wonder if the policy actually is realistic and practical to implement. I'm not saying Entrust is in the right here, but that if what you find in aggregate is that pretty much no one meets the policy properly, then the problem isn't necessarily that everyone fails while the policy is correct; it might be that the expectations and consequences of the revocations do clash with what the policy wishes the world were like when it isn't.

I don't actually know any of these numbers because I've only read this thread and not any of the other stuff. If we find that pretty much only a few CAs constantly fail with these things while others succeed (which is different from "not failing by never exercising the policy"), then yeah the policy might be fine and corrective action on the CA required. If it's 50-50 you also gotta wonder if there's any population-level distinction that could be in play: what is the difference between the context of those who succeed and those who don't, aside from their lack of adherence to rules?

But for all the normative "you gotta follow the rules" approaches, there's always a real risk that said rules are based on an inaccurate or impractical view of the world and that can't be successfully met predictably.

that's absolutely true, but I think it's unheard of for a CA to know that they're mis-issuing certs, then continue to issue them until being called out by everyone in the community

something very clearly seems wrong at the helm of entrust where they're not even making lip service to the policies

# ? Apr 19, 2024 20:36

1
2
3
4
5

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking

Powered by: vBulletin Version 2.2.9 (SABB-v2.24.05)
Copyright ©2000, 2001, Jelsoft Enterprises Limited.
Copyright ©2024, Jeffrey of YOSPOS