Benjamin Franklin once said, 'a failure to plan is a plan to fail.' This adage often applies to long-term vulnerabilities in technology. Lack of planning often leads to inability to detect issues, a lack of data to assess the true severity and a lack of ability to respond. Firmware is a great example of this. Most firmware level issues stay unpatched. This is because firmware often lacks measurement and patching middleware that we’ve come to expect from software. Furthermore hardware vendors act like their job is done if they release a patch.

Today's firmware is bigger and more complex than ever before. Back in 1981, the IBM PC BIOS was only 8k. Fast forward to now, and UEFI can be 8MB or more! As firmware grows in size and complexity, it becomes harder to secure. With more surface area comes more vulnerabilities. The underbelly of technology is where the most impactful and hard-to-patch vulnerabilities lie. Firmware, file systems, BGP, and other plumbing we take for granted are becoming more susceptible to attacks. It's time to start prioritizing security for the foundation of our tech.

Zero trust in zero trust Zero trust “solutions” tend to be re-envisioning of perimeter products of the 90s.

I am conflicted on this topic, in the case of "AI" this generated code we end up with literal copies of copyrighted code. In the case of creative materials, it is largely "style" which isn't protectable in current legislative frameworks.

https://twitter.com/rene_mobile/status/1581724495433596928

In both cases, there is also subjective harm to the original creator but it's also obviously an inevitable outcome when automating time-consuming tasks.

If you have ever had to manage private certificate-related infrastructure at scale you surely have a horror story to share. The reason for this follows.....

https://twitter.com/awakecoding/status/1520172230667341824

1) Most of the protocols for servicing these scenarios that exist were designed in the 90s and the world looks a lot different in 2022.
2) Those protocols often presumed trusted networks, pre-shared secrets, and out-of-band trust establishment.

[1/13] Verifiable data structures like Merkle Trees and Verifiable Maps are better than sliced bread. They enable bringing verifiability at scale to so many different problems. What does not get talked about a lot though is how you monitor these data structures for tampering. [2/13] In 2020 we published a paper on how you can go about solving this problem at scale. It does this by introducing a gossip protocol for verifiable logs that uses compact ranges in Merkle trees to enable users to perform efficient audits. arxiv.org/abs/2011.04551

I imagine some people might ask the question why do we need more CAs that support ACME? From time to time a CA may need to halt issuance. If you take a critical dependency on a CA in your business this circumstance can cause you and your customers grief. There are also cases where for one reason or another a CA may no longer be available to you. As @AGL says have one joint and keep it well oiled, in the context of certificate lifecycle management you accomplish this by using ACME and having multiple CA providers.

I am happy to announce that GCP customers can now get certificates via ACME! This uses pki.goog so when customers terminate TLS in VM, x-cloud, or on-prem they can have the same great device ubiquity they enjoy when using GCP Managed TLS.
cloud.google.com/blog/products/… For those of you who do not already use ACME (datatracker.ietf.org/doc/html/rfc85…) for certificate lifecycle management you should! The most common source of TLS related outages is the lack of automation and monitoring. ACME is foundational to addressing this issue.

@iang_fc @Steve_Lockstep @validIDy @FIDOAlliance Today we would call the two cases Private PKI and WebPKI. The rumors of Private PKIs demise has been greatly exaggerated. It backs nearly all Zero Trust solutions, Mesh Authentication, and more. @iang_fc @Steve_Lockstep @validIDy @FIDOAlliance Only the Web PKI use cases necessarily has a community component and even then there was not consensus. The WoT camp (Thawte et-al) being an example of where community was core while the rest was only loosely community based.

Two important skills a product manager will master is information assimilation and story telling. Like with most things, practice makes perfect. When you find a interesting technology or product read a short brief or listen to a brief audio description of it and time yourself on how long it takes to create a one page progressive description extrapolating to determine the missing details.

So for web-based PKI applications to properly validate chains they need the ability to fetch crypto evidence such as CRLs, OCSP responses, and sometimes intermediate certs. This is problematic because the browser enforces the same-origin policy (as it should) which means a web application can not fetch these bits of evidence. The browser provides a mechanism to bypass this limitation, it is called Cross-Origin Resource Sharing (CORS).

Insider Risk is an area that is commonly underestimated despite how common it is. Here is some survey data on the topic: ca.com/content/dam/ca… There are lot's of ways to mitigate risk but one thing is for sure, you can not manage what you can not measure. For this reason, designing your systems in such a way they are transparent is one of the more impactful things you can do to address these risks.