search

JamesTheAwesomeDude / cerdicator

Enhanced TLS indicator with an emphasis on information about the Root Certificate Authority from which the connection's authenticity is derived
https://addons.mozilla.org/en-US/firefox/addon/cerdicator/
1 stars 3 forks source link

Integrate NSPW findings #25

Closed JamesTheAwesomeDude closed 3 years ago

JamesTheAwesomeDude commented 3 years ago

According to this guy, who seems quite sharp and has written extensively on X.509:

The PKI Technology Survey and Blueprint, presented at the 2006 New Security Paradigms Workshop looks at the question “If you asked experienced programmers, sysadmins, and technical project managers how they would implement certificate management, what would the technology framework for your PKI look like?”, and creates a PKI technology blueprint based on the recommendations made by respondents. The resulting design is noteworthy in that it is almost completely unlike the one proposed in X.509 and related standards, which would indicate that at least some of the deployment difficulties being encountered with X.509-style PKIs are due to their sub- optimal choice of technology.

There may be some benefit to the project from reading this paper. We can "bolt on" much more security than browser vendors are at liberty to.

JamesTheAwesomeDude commented 3 years ago

…unfortunately, their "blueprint" appears to contain nothing workable for this project:

5.PKI Implementation Blueprint

Using the results presented in the preceding sections, we can now look at how a PKI might be implemented with a particular goal of using the most practical real-world technology in order to increase the chances of successful deployment. As was already mentioned earlier, this implementation blueprint covers only the “How” aspect and leaves issues such as policy and legal concerns to the appropriate entities.

The basic certificate-management system is built on top of the database of choice, and uses an HTTP (or HTTPS) interface for communication. Certificates are generally identified by user name (CommonName in X.500 terminology) and email address, with alternatives such as an account number, IP address, or device name being used where this isn’t feasible.

Certificate issue is handled via a minimal one-click interface, which can be accomplished on most systems in a reasonably automated manner by reading the user name and email address from the user account information (for example the GCOS field under Unix or the Windows user information), and using it to populate the certificate request. The generated certificate is obtained by fetching it from the certificate store.

The process of obtained a certificate is also the mechanism used for freshness/validity checking, with the certificate store returning only known-good certificates. Historical queries and similar issues are handled through the standard auditing and accounting mechanisms built into the database, which are used to track certificate additions and deletions and similar operations.

The basic mechanisms presented here can (obviously) be garnished to taste. For example some CAs may require a private-key proof-of-possession operation before issuing a certificate, which may require a two-stage process to be used when requesting a certificate. Potential implementers should however bear in mind that the goal of this work was to determine how to build a practical PKI. A workable (but not quite theoretically perfect) practical PKI is still better than theoretically perfect vapourware.

(No; I did not exclude anything. That's the entire section.)