What was the name of the HSM you mentioned.

Since you mention the prices, can you please give an educated estimate for the Luna, nShield/nCipher and the Luna Pin-Entry Device, according to current prices?

1) Can you please elaborate on "[...] Or maybe you are limited to how many times you can use the key[...]" and on eIDAS? 2) Also, regarding eIAS that uses a remote/cloud signing service. How are the eIDAS requirements satisfied when the signer/customer isn't actually the one controlling the key? Sure, the signer uses a password and 2FA to authorize a signature, but how does that prevent the signing service from using the activation data to sign something arbitrary? Or, is the 2FA credential and the password controlled by the HSM?

@rexkogitans My sincerest apologies for the grammatical mistake; it has been fixed. Nevertheless, most people, wrongly, always use "who"; hence, it has become somewhat acceptable.

Is Intel's PTT/TPM actually running in the PCH/chipset or is it just stored there and loaded into the CPU afterwards?

AFAIK, the TPM can't make measurements itself; rather, the firmware and/or bootloader, etc. provide them to it. So, if Secure Boot is disabled, isn't it possible that a malicious bootloader give a measurement of the valid firmware to the TPM? Without Secure Boot, how can the TPM trust that the measurements haven't been tampered with and that they are indeed genuine?

I haven't read the 210-page document, but my guess is that the iPhone uses a secure element to store the keys and it releases them after verifying the PIN. When locked, it also possibly removes the keys from RAM and keeps two partitions in storage, one for private data and one for the application binaries, etc. The secure element+PIN is the same as TPM+PIN. I doubt that the iPhone has encrypted RAM, so the only additional measure it ahs is that it deletes the keys from RAM when locked. My comments are based on the presupposition that the system is using Secure Boot and SRTM in TPM.

I don't use Linux, so I can't answer your question. A reasonably secure setup would be Full-Disk Encryption with a Pre-Boot Authentication password or TPM+PIN. To remedy the RAM issue, you could use RAM encryption, for devices that support it (I think AMD announced a consumer CPU that supports this). Nevertheless, please have in mind that the BIOS password can, in most cases, be easily bypassed/reset. You called the TPM PIN a "mild" annoyance; to me, that is acceptable since it raises significantly the security of the system. Also, I don't think that the iPhone protects the RAM, either.

I think the poster is interested more in what happens during and immediately after installation and not as much about TLS in-general or the handshaking process.

we STILL have to trust in some hardcoded signing keys to avoid DNS hijacking. It makes sense to enforce DNSSEC everywhere and use it for TLS, too. Disclaimer: These comments were written "casually" and off the top of my head; it is possible that I have missed something or that I haven't considered all cases.

significant advantages. The current method of using CAs with Certificate Transparency, is quite effective to keep CAs in check. In any case, I believe that DANE is the most viable alternative to CAs+CT. We already have to trust DNS and, if someone can hijack the DNS resolution, they probably have the means to do it when contacting the peers/"Notaries" and give a false response as to the authenticity; which means that

@mti2935 The method you describe about the peers could take two paths: 1) Check the certificate with random servers worldwide and see if they reach consensus, 2) Use the "Notaries", as Convergence (SSL) describes. The Convergence basically is the same as having multiple CAs sign the same public key (using the same CSR) and sending all the certificates to the client. In both paths, you would have to trust the peers, somehow; which, automatically, makes them similar to CAs. Just as a CA is compromised, so could the peers. The proposal didn't really take off and for good reason -it doesn't confer