Geoff Thorpe schrieb: > (b) any/all "access information" (eg. control commands, authorisation > data, the ENGINE "id" if necessary, etc) that you *want* to include > in the key file should not go into the raw PEM format itself but > instead should be embedded in the per-'nid' data blob. This way, you > can define bigger and better 'nid's later on rather than having to > figure out how to fit new ideas into old structures.
I don't agree here. This seems to be a way to handle some few keys on one machine. But imagine: You have to work with >= 100 keys one >= 2 machines. And you have to change your configuration. This way you must open the key file, decrypt the PEM encryption, access and change the configuration, encrypt and save the key data. And this for 100 keys with different pass phrases. The "rack" with your servers get's a new meaning... > Note that Goetz's reply mentioned he would rather not include all access > information in the key files - I don't necessarily think that is required > by this approach. However the idea of having to configure and manage the > information in a distinct service is no better - you have to solve all the > same problems, you have to manage an interface between the OpenSSL code > and this general service, and you've got two points where things can go > wrong rather than one. But storing all access information in the key files results in 2 points where things can go wrong, too: 1. The key file and 2. the configuration in your programms to access the key files The data you have to change for a changed configuration is: * key access data stored in pem files: 2 * (number of) keys * key access data stored in configuration: 2 * (number of) applications Have you more keys or applications ? At least we have more keys than key using applications... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
smime.p7s
Description: S/MIME Cryptographic Signature
