Jan Meijer wrote:
>
> but I'd like to know (if it is possible) the
> fingerprint before certifying.
> It all has to do with the verification
> process we want to do before certifying a key.
>
> The process can be described as follows:
> [..]
> During 4 the verification of the identity is done fairly easily (passport
> etc.),
Verification by passport is not easy. Well it's easy in a Office CA but
not with external users.
> but the applicant also needs to be sure the key he submitted for
> certification is the key described on the form he is about to sign
Unfortunately Netscape itself cannot show outstanding certificate
requests with additional data like fingerprints or save certificate
requests for transporting them in a secure way to the CA. Well, during
download of the own certificate (application/x-x509-user-cert) Netscape
checks if the public key matches an own private key. But until then
Netscape users cannot tell if the public key is there own one.
> (the form
> states: Yes, I'm the person described here and yes, what is described here
> in keysize, algorithm and "fingerprint" is MY public key. Yes, I'm sure.
> Yes, I'm sure, sign my key! Sorry, need to go home.)
> but: I hope I've made my problem clear. Both the applicant and the CA need
> to know what public key they're talking about.
Issue an initial master secret which is given to the user by secure
out-of-band communication. That's the way proposed in PKIX for handling
the first contact of a user with a PKI.
Here's my way of certificate processing (partially implemented in pyCA):
Step 0. The users contacts the CA admin or RA in any way sending his
identity informations. After checking identity an initial master secret
is generated by the CA admin or a RA and transported to the user in a
secure way (no one except CA admin or RA can read or falsify it).
Real-life in our case: Within the office this is done by closed
envelopes and personal hand-outs.
Step 1. The user generates a certificate request which is stored
together with the initial master secret in a secure way. (pyCA: up to
now saves files with fairly secure permissions, e.g. read-only into a
directory write-only for the httpd user, etc.)
Step 1.a pyCA: A random number and MD5 hash of the certificate request
is generated as challenge ID for a simple mail dialogue (Well, this is
only for recognizing very simple attacks).
Step 2. The identity of the certificate requester is checked by checking
the Initial Master Secret against identity informations given in Step 0.
Step 2.a The initial master secret is marked as "already used".
Step 3. The certificate is issued.
Step 4. The certificate is published (for download via WWW).
Critical comments are appreciated.
Further improvements planned in pyCA (sigh!):
Step 0. Make automated process with web forms and automated printing on
a (physically) secured printer.
Step 1. Store certificate requests and initial master secret together in
signed files.
Step 2. Do automated checking against database holding identity
informations.
Step 3.a Challenge user to send an encrypted & signed e-mail to confirm
the correct public and private key combination before publishing the
certificate. (this is another hint found in PKIX, if I remember
correctly).
> Another project of us aims at providing good documentation for our
> customers [..] "how-to-build your own ca using openssl",
Well, pyCA needs more documentation...help's appreciated.
Ciao, Michael.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
