Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not really, but a large number of auditors (not sure if it's "most" but it's still surprisingly many) do insist on EV for some reason (and as you point out, it's not even mandated in the spec itself, at least the current ones). The insurance aspect, well it depends, our lawyers said that "insurance" on EV products (by DigiCert and Globalsign at least) are simply legalese garbage but I can remember a broad-spectrum cyberinsurer insisting on EV certs. Oh well, it's ultimately their territory, not ours.

Edit: thanks for reminding me that PCI-DSS 4.0 is now released - but it only states that you must securely deliver sensitive information over open networks (including internet) and explicilty bans all SSL versions and TLS lower than 1.2, which is the same as 3.2.1. It even references a NIST document which shows methods for automatic cert issuance featuring Certbot (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...).



For what it's worth and given there is risk in doing this, but one can work with their contacts at the payment processor to manually pin certs on both sides. There is operational risk and both sides have to be vigilant with monitoring and communication but that can be an even better assurance of transport security in some fringe PCI cases. I recall two of the major processors were open to this. No idea if they still are. I just would not put it in the internal official documented PCI or SOC1/2 controls or one would be stuck doing this. Could be useful as due diligence if legal are that nervous about the PCI environment. Maybe just documented in a JIRA or internal ticketing system.


Makes sense. I was just making sure I was not missing something or that it was not quietly added to a recent addendum/revision of the PCI spec.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: