X.509 absolutely lives on -- https://www.itu.int/rec/t-rec-x.509 last update was October 2024. However WebPKI uses PKIX which is fairly stubbornly stuck on RFC5280.
On the ITU side, they have made improvements including allowing a plain fully qualified domain name as the subject of a certificate, as an alternative to sequence of set of attributes.
AWS has stated that there is a "Nitro Card for Instance Storage"[0][1] which is a NVMe PCIe controller that implements transparent encryption[2].
I don't have access to an EC2 instance to check, but you should be able to see the PCIe topology to determine how many physical cards are likely in i4i and im4gn and their PCIe connections. i4i claims to have 8 x 3,750 AWS Nitro SSD, but it isn't clear how many PCIe lanes are used.
Also, AWS claims "Traditionally, SSDs maximize the peak read and write I/O performance. AWS Nitro SSDs are architected to minimize latency and latency variability of I/O intensive workloads [...] which continuously read and write from the SSDs in a sustained manner, for fast and more predictable performance. AWS Nitro SSDs deliver up to 60% lower storage I/O latency and up to 75% reduced storage I/O latency variability [...]"
This could explain the findings in the article - they only meared peak r/w, not predictability.
A couple of years ago I ran into the same confusion of the "TeletexString"/"T61String" data type in ASN.1. After going down the rabbit hole of what is T.61 and trying to map it to Unicode, I reread the ASN.1 (X.690) spec and realized that the authors never actually referenced T.61. Ever since the first edition of ASN.1 in 1988, those strings have not used T.61. They use a character set that is easily mapped to Unicode - https://www.itscj-ipsj.jp/ir/102.pdf, a subset of US ASCII.
Not to say the rest of the spec is notably better. If fully implemented, it requires supporting escape codes in strings to change character sets. I've never seen valid escape codes in real world data, but it probably exists.
As the original article shows, ASN.1 has lots of other challenges and complexity. Trying to write a code generator that supports all the complexity is no trivial task and the only open source one I've seen only generates C code. Protobuf has the advantage of having modern language support (including multiple type safe and memory safe languages).
It has one USB Type-C in with 3 USB Type-C out plus 4 USB Standard-A out. One of the C outputs supports downstream charging. Should just be a matter of time until hubs using this chip are widely available.
You can do 3840x2160@60Hz (and 24bpp/8bpc) over USB Type-C on newer displays. DisplayPort Alt Mode over USB-C using DisplayPort 1.3/1.4 can support 4K + USB 3 Gen2 on one cable.
I've been working on a similar system that is in the process of being adopted by at least one standards group (https://github.com/cabforum/documents ).
I would strongly recommend looking at weasyprint (http://weasyprint.org/ ) for HTML to PDF. It gives much better PDF output and offers CSS print support, so you get page control.
Unfortunately the "distributing a modified version of an open source project under that project's name" can be problematic from a trademark perspective. This has come up many times before in other projects and led Debian to not use trademarked project names for software. If you are not familiar with the discussions, just search for "IceWeasel".
It is important to note that "Dynamo" and "DynamoDB" are two very different things that happen to share many of the same letters. DynamoDB is not Dynamo.
I think that many newer vendors of certificates are following this model. Let's Encrypt and AWS Certificate Manager both simply have certificates with names. One name, two names, 50 names, still just a "certificate".
Both Smart Cards and HSMs can (and frequently do) contain FIPS validated cryptographic modules and can be USB devices. What seems to set them apart is content capacity and speed. A "HSM" can usually store dozens, hundreds, or even tens of thousands of keys and can do numerous cryptographic operations per second. Most "smart cards" can only store a few keys and frequently 1-2 operations per second.
Many HSMs also add advanced authentication capabilities, such as M-of-N access control and/or hardware authenticators (e.g. you need 3 of 5 smart cards to use the HSM). The other key feature usually found in HSMs but not smart cards is backup/cloning without exporting the key (in PKCS#11 terms). This means that the key can be moved between HSMs with all the protections in place. I've yet to see a smart card that does this.
The author brings up many reasonable points but seems to mix issues of HSMs & Smart Cards not providing a generic open hardware platform with possible security problems of a platform.
There is no question that there would be value in having a hardware platform that has certain security features, but that alone doesn't meet the requirements of most users of HSMs and Smart cards. The primary use cases I've seen are allowing a third party to have assurance of protection of data stored in the device and assurance of the rules for accessing the data. In most cases this assurance comes from a combination of the hardware itself and the software/firmware running on the hardware. A hardware platform only solves half the problem that most purchasers of HSMs and smart cards are asking vendors to solve.
When encoding those characters in UTF-8, you will never end up with 0x2F as a byte. On of the properties of UTF-8 is that bytes with the high bit not set (e.g. 0x0 to 0x7e) never appear unless the are representing the 0 - 127 codepoints.
How do you do that? Where do you draw the line? Basically every company I've worked for has, at some point and to varying levels, taken government funding. It could be buying off the shelf products in the same manner as every other customer, it could be the company creating a modified product for the government, or it could be taking funding in the form of R&D tax credits.
From first hand experience, big companies are hiring constantly from overseas to the US. If you can pass the interview, they will figure out how to legally get you on payroll. If you are flexible in which countries you will work, so much the better.
However, when you apply to big companies, don't go in saying "I want to be a senior engineer". That means different things at different companies. Quora has some great answers on how the ladders work at the big players; you will see that "Senior" can mean 10+ years of experience at some places. Feel free to send me an email if you want more info about one of the places you mentioned.
On the ITU side, they have made improvements including allowing a plain fully qualified domain name as the subject of a certificate, as an alternative to sequence of set of attributes.