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

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

aaomidi posted:

Thank you for this comment. Seriously. I hope root programs take note of this.

yeah, if nothing else I�d like to see them respond with what they think appropriate consequences should be other than stern wording from Official Ryan

maybe I should have sent it to the mailing list

# ? Apr 23, 2024 21:32

Adbot: ADBOT LOVES YOU

# ? May 5, 2024 23:24

infernal machines: Oct 11, 2012; we monitor many frequencies. we listen always. came a voice, out of the babel of tongues, speaking to us. it played us a mighty dub.

pleased to see Ligma Certificate Authority and Burger Barn, LLC recognized

# ? Apr 23, 2024 21:36

spankmeister: Jun 15, 2008

Doobies Dog Certs, LLC

# ? Apr 23, 2024 21:39

post hole digger: Mar 21, 2011

infernal machines posted:

pleased to see Ligma Certificate Authority and Burger Barn, LLC recognized

# ? Apr 23, 2024 21:39

Antigravitas: Dec 8, 2019; Die Rettung fuer die Landwirte:

Getting serious Honest Entrust's Used Cars and Certificates vibes tbh.

# ? Apr 23, 2024 21:45

Raymond T. Racing: Jun 11, 2019

new thread title: secfuck v18.509(a): Ligma Certificate Authority

# ? Apr 23, 2024 21:48

spankmeister: Jun 15, 2008

Digibofar

# ? Apr 23, 2024 21:53

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

Amir pointed me at a bug from 4 years ago where Entrust promised Old Official Ryan that they were really going to get their poo poo together

they did not

Sleevi, I know you�re reading this: make New Ryan and Ben make them go away

# ? Apr 23, 2024 22:11

Raymond T. Racing: Jun 11, 2019

new post is chefs-kiss

# ? Apr 23, 2024 22:12

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

hoooooooooooooooooooooo boy :f5h:

:f5h:

# ? Apr 23, 2024 22:13

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

Raymond T. Racing posted:

new thread title: secfuck v18.509(a): Ligma Certificate Authority

i recognize the request but we will be following our stated policy

# ? Apr 23, 2024 22:14

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

Raymond T. Racing posted:

new post is chefs-kiss

thank you; MSFT used to get very �have our CEO whine to your CEO� upset when I posted like that about their poo poo, but I miss it

# ? Apr 23, 2024 22:20

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

unrelated:

ok wait I�m hearing that the Palo vuln that destroyed the world is a loving ../ traversal bug in HTTP handling?

for real? for real real?

# ? Apr 23, 2024 22:27

SIGSEGV: Nov 4, 2010

Hey, a lot of people have that happen in their first year CS course httpd project.

# ? Apr 23, 2024 22:31

Winkle-Daddy: Mar 10, 2007

Subjunctive posted:

unrelated:

ok wait I’m hearing that the Palo vuln that destroyed the world is a loving ../ traversal bug in HTTP handling?

for real? for real real?

I reviewed access logs in TYOOL 2023 that showed some site was owned via url injection on a loving download.php file lmao -- the fact it wasn't popped in like 2014 was what impressed me most. it turns out that while technology may not be cyclical, vulnerabilities are.

# ? Apr 23, 2024 22:43

post hole digger: Mar 21, 2011

Winkle-Daddy posted:

I reviewed access logs in TYOOL 2023 that showed some site was owned via url injection on a loving download.php file lmao -- the fact it wasn't popped in like 2014 was what impressed me most. it turns out that while technology may not be cyclical, vulnerabilities are.

GAI solves this.

# ? Apr 23, 2024 22:49

akadajet: Sep 14, 2003

devmd01 posted:

this is a battle that was fought and lost a long time ago. our model requires technicians to be able to install diagnostic software, etc for the equipment they service at client sites.

Admin by request was the compromise so they are at least aren�t running as local admin all the time.

it�s a hell of a lot better than what used to happen, which was domain users automatically added to the local admin group via group policy.

I trialed admin by request for my it dept and it was a huge piece of poo poo

# ? Apr 23, 2024 22:51

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

wayne and amir rizzed down entrust but the ryans haven�t said the CA has no drip

# ? Apr 23, 2024 22:56

Wiggly Wayne DDS: Sep 11, 2010

there has been some movement today, noting this to make the thread readable at a future date

Entrust: Failure to revoke OV TLS - CPS typographical (text placement) error

Bruce Morton posted:

(In reply to Ryan Dickson from comment #7)

Ryan Dickson posted:
Comment 2 states:
"Our CDN statistics show that between March 22, 2024, 15:02 UTC and March 26, 2024, 17:07 UTC our CPS versions 3.18 and 3.19 were downloaded 30 times by desktop or mobile browsers, excluding Entrust networks.
- Of these 30 downloads we have been able to identify 10 downloads to specific subscribers.
- The downloads are divided over 9 unique IP addresses, one from a known subscriber, one from a known CA.
- The data likely includes downloads from Entrust employees which we have not been able to identify.
- The CPS covers the multiple certificate types we offer.
- This data indicates that the number of subscribers and relying parties that have seen this error is minimal."

Can you help me better understand this statement and how it relates to the principle expectation of a publicly-trusted CA adhering to its documented policies at all times? Also, can you share more about why this justification was offered?

One way of interpreting this statement is an attempt to justify and/or diminish non-compliance on the basis that very few people downloaded the CPS during the affected time period.
This data demonstrates the minimal impact on subscribers and relying parties contributing to the exceptional circumstances of this incident.

Ryan Dickson posted:
The underlying issue with this type of justification is that it appears to downplay the fundamental expectation that a CA must adhere to its stated policies and procedures at all times. The CA/Browser Forum Baseline Requirements and other related guidelines emphasize that compliance must be continuous and is not conditional on the extent to which documented policies are accessed by external parties.
We agree that we should adhere to the requirements, this is the reason that we have filed an incident report for not following the requirement to revoke all certificates that were not issued to the letter of the CPS within five days.

Ryan Dickson posted:
Fundamentally, a statement claiming that a mistake did not result in significant harm does not diminish the significance of that mistake. The principle at stake is the integrity and trustworthiness of Entrust, which is expected to uphold its commitments irrespective of the level of direct oversight or detection by others in the ecosystem.
We do believe in upholding our commitment to the requirements and our CPS, that we should be detecting these issues ourselves, which we also did for this incident. We also believe, however, that the impact to the ecosystem needs to be taken into consideration.

Ryan Dickson posted:
Additionally, as stated on https://www.ccadb.org/cas/incident-report, the Action Items section is supposed to contain a list of remediation items that will be undertaken to ensure that a similar incident does not reoccur in the future and that it is not sufficient for the actions to simply stop the incident in question. What actions will prevent this from happening again? Beyond that, �Transparency" is not one of the described Action categories listed on https://www.ccadb.org/cas/incident-report.
Please see the action items and our answer to question two in bug #1890896.

exceptional circumstances!!!

there were also sizable replies to:
Entrust: CPS typographical (text placement) error

Bruce Morton posted:

(In reply to Wayne from comment #5)

Wayne posted:
I'm looking for clarity here. Entrust states that there is no intention to revoke but cite no authority overriding their obligations.

The issue was noted internally at Entrust on 2024-03-26, but it took 16 days before any public notice appeared. We're still lacking any real information on what happened internally.
Please see bug #1890901 in which we filed for this delayed incident report.

Wayne posted:
I will also note that several of the certificates listed have been revoked (superseded):
https://crt.sh/?sha256=34DF91A45C4BF0D54A5879A241C763DB6969002E7739572C6C322E075136AEB7 (2024-03-26 17:08:49 UTC)
https://crt.sh/?sha256=3260F0A3FD4D68674686F6C4A8C2BDB642F2D2E4A8E02D0F0EF93CC0F9711C28 (2024-03-26 17:13:03 UTC)
https://crt.sh/?sha256=75CA61256BF5B55FC6B0B89EEA34F709FA1002350E31513AB6E11350D175F0D1 (2024-03-26 19:19:08 UTC)
https://crt.sh/?sha256=1E190D5B285DFD5A01781132707B4E54F20A4DF31C1F2E82A465E48B3C4DB4D5 (2024-03-26 19:35:29 UTC)
https://crt.sh/?sha256=CE480E4CC20F38C8860C79BE6ECE3583626CA3829AE1D08ADB650E8C3B2FD318 (2024-03-27 18:10:22 UTC)

I don't need to fully explain that the sample above does not paint a good light on Entrust's internal consistency and transparency to the public.
We uphold a commitment to full transparency with the public, and we appreciate your inquiry regarding any uncertainties in this regard. Please feel free to express any concerns or questions you may have, as we strive to ensure clarity and openness in all our communications.

Wayne posted:
Q1) Can you document what caused Entrust to start revocation for a day, and then stop?
We have never started or requested customers to revoke certificates in relation to this incident, but certificates are sometimes revoked by customers for other reasons. Except for one, all certificates you listed above belong to one customer. This customer was also impacted by our other incident, and they might have decided to revoke these certificates as well.

Wayne posted:
Q2) Can Entrust provide us with a breakdown of outstanding mis-issued certificates, expired certificates, revoked certificates, and a timeframe for each revocation batch (time issued to team, time taken to revoke)?
As stated above, in the impact section of this incident report, this incident involves 6,008 OV TLS certificates that were issued between March 22, 2024, 15:02 UTC and March 26, 2024, 17:07 UTC, a list with links to the certificates has been attached to this bug. In the summary above, we describe why we are not revoking these certificates.

Wayne posted:
Q3) What internal discussions occurred at Entrust to change this approach?
Per our response to Q1, we have not changed our approach to revocation in relation to this incident.

Wayne posted:
Q4) Did Entrust privately inform any Root Programs of this incident prior to this public report?
While we have spoken with some root programs about the delayed CPS publication, this specific incident has not been discussed.

Wayne posted:
Q5) Will there be any additional revocations as required?
We do not intend to revoke these certificates, see also bug #1890898.

Wayne posted:
Q6) Can Entrust please explain why they feel they feel they are under no obligation to abide by their own CPS for certificate mis-issuance revocation? The report does not explain what authorities they are relying on.
Please see bug #1890898.

Wayne posted:
Q7) Having read Entrust's CPS I can see no mechanism for 'exceptional circumstances' to avoid revocation. Could Entrust clarify where this is as it has been a common theme throughout these incidents?
The Mozilla Wiki describes that there are some exceptional circumstances where revoking the affected certificates within the prescribed deadline may cause significant harm and that the CA is ultimately responsible for deciding if the harm caused by not following the requirements of the Baseline Requirements outweighs the risks that are passed on to individuals who rely on the web PKI.

Neither delayed revocation nor non-revocation is described in the TLS Baseline Requirements.

Wayne posted:
Q8) If there will be an update to Entrust's CPS to carve out exceptional circumstances, I trust that there is an understanding that this is not applied retroactively?
We share this understanding.

Wayne posted:
Q9) Given the issues in the past month, can Entrust confirm that they are technically capable of mass revocation and reissuance within 24 hours?
Yes.

Wayne posted:
Q10) Given the issues in the past month, can Entrust confirm that they are organizationally capable of approving a mass revocation and reissuance event within 24 hours?
Yes, we are.

lot of digging a hole which we'll get into later

Bruce Morton posted:

(In reply to Ryan Dickson from comment #6)

Ryan Dickson posted:
Comment 3 states: "Regarding the action, today subscribers were informed of the CPS changes."

Question 1) Can you share more about this, specifically describing what was communicated to subscribers and how?

this is real??? posted:
Subject: A new ECS CPS is now available, including errata for version 3.16, 3.18 and 3.19

Please be advised that the ECS Public Trust Certificate Practices Statement (CPS) has been revised and errata have been added to CPS releases 3.16, 3.18 and 3.19. These errata have no impact on your certificate and are clearly marked in the respective CPS versions on our website at: https://www.entrust.com/legal-compliance/entrust-certificate-services-repository/archive.

Should you wish to view the updated document, go to our website under >Resources > Legal and Compliance > Entrust Certificates Services Repository > Certification Practice Statements > Certification Practice Statements.

You can also view the new document directly at: https://www.entrust.com/-/media/documentation/licensingandagreements/entrust-certificate-services-cps-3-20.pdf

Ryan Dickson posted:
It's possible to interpret "Regarding the action, today subscribers were informed of the CPS changes." (i.e., "Today, we told subscribers that we updated our CPS.") differently than "Inform subscribers of the CPS error" ("i.e., "We made a mistake.") as described in the Actions table.
We think that the message �errata have been added to CPS releases 3.16, 3.18 and 3.19� is a clear indication that there was an error in these versions.

Ryan Dickson posted:
Question 2) Can you please correct the Actions table? "Transparency" is not one of the described Action categories listed on https://www.ccadb.org/cas/incident-report.
It was not clear that we were limited to the categories included in the following paragraph.

CCADB Incident Report posted:
A classification of whether the action will help Prevent future incidents, Mitigate the impact of future incidents, or Detect future incidents. CA Owners are encouraged to propose action items in all three categories, with an emphasis on prevention and mitigation.
We think that the Transparency action items we included do not fit in any of the listed categories, can you let us know if you want us to post an updated table with these action items or categories removed?

Ryan Dickson posted:
Question 3) Looking at one of the CPS documents with an errata (example), I'm having a hard time understanding what is being communicated. Other than the (non-text searchable) phrase "This CPS contains an errata, please see version 3.20" it's not clear what the errata was, what changes were made, or what issues were being addressed.
We included the errata as a PDF comment so that we do not change the original published CPS version. The text "and must contain policyQualifier with cPSuri" on page 85 has been formatted with a red strikethrough, to clearly indicate that this was included as an error.

Ryan Dickson posted:
Can you share how this approach meets the intent of "Add errata to CPS version 3.18 and 3.19 to advise readers of the changes?" as described in the Actions table? Also, was adding the errata notice using an image that is not text-searchable intended? The combination of the non-text searchable phrase and the lack of detail make it challenging to understand what the errata has changed or intends to highlight - which does not clearly convey the intended goal of "Transparency" as presently described in the Actions list.
As stated above, the errata were added as a PDF comment, not as an image but as text, so that everyone can verify that we did not modify anything else in the CPS. In Acrobat Reader the comments are searchable and hyperlinked through a list. That stated, we are open to further improvements if you or the community think that would help subscribers and relying parties.

Ryan Dickson posted:
The ease of detecting changes across policy versions was a motivating factor for encouraging the use of Markdown as described in the latest version of the Chrome Root Program policy (i.e., "To promote simplicity and clarity, these CA policy documents SHOULD be available in Markdown.")
We are aware of the recent Chrome root program desire to use Markdown for CPS documents. This is something we would like to move forward with in the future but is not a small undertaking.

digging even deeper, but amir gets in a quick reply:

amir posted:

Bruce Morton posted:
The Mozilla Wiki describes that there are some exceptional circumstances where revoking the affected certificates within the prescribed deadline may cause significant harm and that the CA is ultimately responsible for deciding if the harm caused by not following the requirements of the Baseline Requirements outweighs the risks that are passed on to individuals who rely on the web PKI.
I don't think you're reading the link you're posting here? Specifically (emphasis mine):

Mozilla Root Program Requirements posted:
The decision and rationale for delaying revocation will be disclosed in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include detailed and substantiated explanations for why the situation is exceptional. Responses similar to �we do not deem this non-compliant certificate to be a security risk� are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.
Also, that link is JUST the Mozilla Root Program. Is there anything in the Chrome/Apple/Microsoft Root Programs that carves out exceptions for revocation?

and for avoiding this being illegible i'll only include my replies to Bruce and not the context, see the link for that

Wayne posted:

In the interest of openness and transparency this was based on a brief sampling of certificates and a more thorough report was produced and posted to the dev-security-policy mailing list (pending approval). I apologize for misunderstanding this as Entrust complying with the Baseline Requirements if but for only a brief period of time.

However in short: You have not answered my question at all. I am well aware of the 6,008 OV TLS certificates mentioned. Are Entrust willing to be transparent and provide a breakdown on: "'outstanding mis-issued certificates', 'expired certificates', 'revoked certificates'" in respect to this issue?
...
I am not seeing an answer to my question in that bug.
...
Unfortunately as amir has pointed out that is not what the Mozilla Root Program states. Additionally you are correct, delayed revocation nor non-revocation are not described in the TLS Baseline Requirements. To that end, what authorities are you relying on to reach your current understanding that such possibilities exist while being compliant?
...
I will note that this does not add up to the current pace at which Entrust is handling incidents. Please see the dev-security-policy mailing list for further detail shortly.

Post is pending approval and is an updated (and more professional) version of the CRL post with a focus on transparency and investigating an ongoing issue with a non-compliant CA.

still can't get over 'These errata have no impact on your certificate', i'm still not convinced they realise just how deep a grave they're digging

# ? Apr 23, 2024 23:29

shackleford: Sep 4, 2006

Wiggly Wayne DDS posted:

if you'll recall a mentioned a few days ago that entrust's contact info on ccadb is out of date.

so i may have been kind and lobbed a softball to entrust to get them to lower their guard over the weekend, and it's worked:

this was the only thing entrust responded to yesterday presumably given it seemed so innocent, anyway sectigo noticed:

thanks sectigo
thectigo

lmao the softball was actually a live grenade

# ? Apr 23, 2024 23:50

Methylethylaldehyde: Oct 23, 2004; BAKA BAKA

Wiggly Wayne DDS posted:

still can't get over 'These errata have no impact on your certificate', i'm still not convinced they realise just how deep a grave they're digging

"I will note that this does not add up to the current pace at which Entrust is handling incidents. Please see the dev-security-policy mailing list for further detail shortly."

I can't wait for you to emptyquote it at them in 2 weeks when they gently caress the dog again and end up having to pretend they never said those words to avoid being forced to eat them.

# ? Apr 24, 2024 00:01

Quackles: Aug 11, 2018; Pixels of Light.

akadajet posted:

I trialed admin by request for my it dept and it was a huge piece of poo poo

We have admin by request at our office.

Because it creates a temp admin account and doesn't use an existing one, it doesn't work with Visual Studio :shrug:

:shrug:

# ? Apr 24, 2024 00:22

Kuvo: Oct 27, 2008; Blame it on the misfortune of your bark!; Fun Shoe

i am enjoying this thread :suspense:

:suspense:

(the effort posts are good, thank u for doing them)

# ? Apr 24, 2024 00:22

necrotic: Aug 2, 2005; I owe my brother big time for this!

Kuvo posted:

i am enjoying this thread

(the effort posts are good, thank u for doing them)

the whole entrust debacle has reminded me very clearly when I educated a couple non-tech people about how the entire internet is built on a trust model and how their reaction was �how the gently caress does any of this actually get enforced� and� well, here we are.

# ? Apr 24, 2024 00:31

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

necrotic posted:

the whole entrust debacle has reminded me very clearly when I educated a couple non-tech people about how the entire internet is built on a trust model and how their reaction was �how the gently caress does any of this actually get enforced� and� well, here we are.

a shitposting forum notices a slapfight, and so on

# ? Apr 24, 2024 01:21

Raymond T. Racing: Jun 11, 2019

Captain Foo posted:

a shitposting forum notices a slapfight, and so on

excuse me, we're enterprise shitposters now

we're just as competent as your favorite CA

# ? Apr 24, 2024 01:25

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

maybe we�re going about this all wrong. perhaps we should just start a CA and be lovely at our jobs and rake it in for years

# ? Apr 24, 2024 01:27

Raymond T. Racing: Jun 11, 2019

Subjunctive posted:

maybe we�re going about this all wrong. perhaps we should just start a CA and be lovely at our jobs and rake it in for years

jeffrey of yospos needs a new income stream

# ? Apr 24, 2024 01:28

rafikki: Mar 8, 2008; I see what you did there. (It's pretty easy, since ducks have a field of vision spanning 340 degrees.)

~SMcD

Subjunctive posted:

maybe we�re going about this all wrong. perhaps we should just start a CA and be lovely at our jobs and rake it in for years

way ahead of you bud

# ? Apr 24, 2024 01:28

Farmer Crack-Ass: Jan 2, 2001; this is me posting irl

i'll run the wiki

# ? Apr 24, 2024 01:28

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

rafikki posted:

way ahead of you bud

cofounder material for sure!

# ? Apr 24, 2024 01:28

SeaborneClink: Aug 27, 2010; MAWP... MAWP!

Subjunctive posted:

maybe we�re going about this all wrong. perhaps we should just start a CA and be lovely at our jobs and rake it in for years

I said this earlier and got threatened with a probe

edit: it would require intentional effort to be worse at it than some active CAs

SeaborneClink fucked around with this message at 01:32 on Apr 24, 2024

# ? Apr 24, 2024 01:30

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

SeaborneClink posted:

I said this earlier and got threatened with a probe

I�m threatening you with revenue

# ? Apr 24, 2024 01:34

psiox: Oct 15, 2001; Babylon 5 Street Team

you could probably automate the special pleading about how the requirements are wrong and your customers are special with an LLM, anyway

# ? Apr 24, 2024 01:40

rafikki: Mar 8, 2008; I see what you did there. (It's pretty easy, since ducks have a field of vision spanning 340 degrees.)

~SMcD

psiox posted:

you could probably automate the special pleading about how the requirements are wrong and your customers are special with an LLM, anyway

yeah, train it on entrust comms

# ? Apr 24, 2024 01:41

psiox: Oct 15, 2001; Babylon 5 Street Team

what went well:

quote:

In addressing the concerns regarding our handling of the recent certificate issuance incident, we must first acknowledge the complexity and unprecedented nature of the challenges we faced. Throughout this process, our team has been steadfast in its commitment to maintaining service continuity and ensuring minimal disruption to our stakeholders. Despite our rigorous protocols and the dedicated efforts of our team, some certificates were issued that did not meet our usual standards of excellence.

We understand the importance of adherence to best practices and the expectations of our community. It is imperative to recognize that the decision-making framework at the time was based on a comprehensive analysis of the situation, prioritizing the integrity of the infrastructure and the broader implications of a mass revocation.

We are currently undertaking a thorough review of our systems and processes to better understand the root causes and to identify opportunities for improvement. This includes enhancing our monitoring capabilities and revising our incident response strategies to better manage and mitigate such incidents in the future.

Your feedback is invaluable to us as we continue to strive for excellence in our operations. We are committed to learning from this experience and to making the necessary adjustments to prevent recurrence, ensuring the reliability and trustworthiness of our services moving forward.

# ? Apr 24, 2024 01:43

Shame Boy: Mar 2, 2010

is it just me or do they keep using the term 'best practices' when they actually mean 'hard and fast agreed-upon rules that we ourselves helped write'

# ? Apr 24, 2024 02:54

MononcQc: May 29, 2007

�Best practices� is often just a stand-in for whatever norms people have established within an org. If the norms are bad, the best practices might be as well.

# ? Apr 24, 2024 03:25

spankmeister: Jun 15, 2008

i have but one comment:

Please do the needful and revoke

# ? Apr 24, 2024 05:06

Adbot: ADBOT LOVES YOU

# ? May 5, 2024 23:24

NFX: Jun 2, 2008; Fun Shoe

I have a question about certificate transparency logs. as far as I can tell CAs only need to submit a pre certificate to the log, and that's what they usually do (according to wayne's comment some pages back).

what mechanism ensures that the CA then issues a certificate that matches the pre-cert? as far as I can tell that's entirely up to the client?

I suppose there's no other place to put the responsibility (and a cert that's never seen by a client is pointless anyway, regardless if it's malicious or not), but it seems like something that could be prevented by requiring the issued cert to be logged

# ? Apr 24, 2024 06:22

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