At 10:03 PM 8/24/01 +0200, you wrote:
>On Fri, Aug 24, 2001 at 05:28:43PM +0100, Andrew Cooke wrote:
> > What I should have asked is how to detect a *substitute* request. It will
> > be self-consistent, but will not match the correct private key.
> >
> > One solution is to show that the certificate and private key are
> consistent
> > after signing, but there does not seem to be a way of doing this using
> openssl.
> >
> > For example, Alice generates a request, sending it to Bob. Mallory
> > intercepts the message and substitutes a different request. Bob sign's
> > Mallory's request and returns it to Alice. Alice thinks she has a
> > certificate that matches her key and distributes it. Mallory then sends
> > data in Alice's name and people verify it against what is apparently
> > Alice's certificate.
>
>This is an organizational issue in the first place. The CA (you name it Bob)
>must make sure that it only signs the correct request. Your security
>concept is void, if you allow Bob to sign the request without checking
>it to be authentic.
>In our university the scenario is as follows. Alice creates the request,
>then creates a fingerprint (e.g. MD5) of the request. She then sends the
How does she create the fingerprint? - I looked and could not find a way to
do it with openssl (only fingerprints for certificates seem to be supported).
I agree with everything else you write (snipped) - I just cannot find any
support in the tools that helps (either fingerprint or later
cross-checking). The best I can come up with is using PGP to send in the
request, which of course just pushes the problem back a level, but
fingerprinting is available for PGP requests (I believe).
Thanks,
Andrew
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
