All,

Joe was asking for a 3rd party plug-in supporting
also CRL checking.
I've made very good experiences with a plug-in
called CryptoEx. CryptoEx is based on a
multi crypto engine technology and is currently
supporting OpenPGP and S/MIME within one plug-in
and one user interface.
For more information see www.cryptoex.com

Carsten.

> All,
>
> To touch on a couple of thing that Sam has said.
>
> "you can modify the default password behavior by
loaded an exported
> certificate into IE FIRST and then create the
outlook profile"
>
> This is not going to work because Outlook looks
at the cert every time it
> retrieves it and checks to see what Exchange
says the cipher strength is.
>
> "Publish a web front end (one comes with Cert
Server, IIRC) , have the user
> import into the browser and then use outlook to
import the cert from IE
> rather than over LDAP"
>
> The problem I face with this is that I am
dealing with over 200K users on
> the small end and over 2.5 million on the large
end, growing to even more
> once we start bridging CA's. We have to make
this as transparent as we can
> because even though you might only need to send
1 email to a person and
> never email him again it is going to have to be
signed and encrypted. This
> is why doing a manual key exchange would be
counter productive, due to the
> time it would take to exchange keys and verify
it and all the other good
> stuff. This is also the reason that we don't
want them to have to go to a
> web page and search for the user, or users.
Think of how long it would take
> if you were sending an email out to 15 people!
>
> Now to touch on a couple of things that David
Renardson said.
>
> the actual X.509 certificates themselves are
stored in the windows registry
>
> Yes this happens when you import a cert. But
this does not affect my
> situation because it is being pulled from a
exchange server
>
> Is there a field in the x.509 certificate which
indicates supported cipher
> strengths? (I think "no")
>
> There is nothing in an X.509 cert that defines
the cipher strength of the
> client.
>
>
> I have said this before but I think I need to
clarify it better.
>
> The problem lies in the fact that the users are
retrieving the cert from an
> exchange directory.
>
> 1. When the user retrieves the cert from the
exchange server it is wrapped
> with the information pertaining to the cipher
strength of the client.
> A. If the users publishes his own cert to
the GAL then the client tells
> the exchange server what its cipher strength is
and there is no problem
> B. If you use an automatic procedure to
populate the Exchange Directory
> for the users, by doing a field for field LDAP
transfer, there is no client
> information added so it defaults to 40bit
>
> 2. If the users manually do a key exchange then
the client wraps the cert
> with the cipher strength and there is not a
problem.
>
> What I really need is some one who knows
Exchange directory (I wish MS would
> help with this, I know you read this list Bill)
and know what I need to
> change on the directory to make the default
cipher strength 128bit. I am
> not putting anyone down because what has been
said on the list has helped me
> and has given me some ideas, and I thank you all
for that.
>
> BTW The other thing I am looking for is 3rd
party plug-ins for outlook that
> do CRL checking ........If any one has any
information I would like to hear
> what you have to say.
>
> ***** I Love PKI *****
>
> Joe
>
>
> -----Original Message-----
> From: Sam Stern
[mailto:samsternMAILANDNEWS.COM]
> Sent: Wednesday, January 17, 2001 4:31 PM
> To: FOCUS-MSSECURITYFOCUS.COM
> Subject: Re: Outlook Encryption problem (bug)
>
>
> All,
>
> I was wondering about a short term workaround.
In outlook, you can modify
> the default password behavior by loaded an
exported certificate into IE
> FIRST and then create the outlook profile. I was
wondering if that would
> have effect on the issue at hand? Publish a web
front end (one comes with
> Cert Server, IIRC) , have the user import into
the browser and then use
> outlook to import the cert from IE rather than
over LDAP.
>
> As a process this stinks, but it may do the
trick in the near term.
>
> The other work around I can think of works in a
similar fashion:
>
> Export the cert somehow (PGP would work) to a
file from the LDAP server
> directly and then have the user import into
their Outlook. This one is
> probably not that workable as the question of
who is generating the cert and
> password (PKI) infrastructure and protection
become critical. Also this more
> complex than the last one on the end user.
>
> HTH
>
>
>
>
> Sam Stern
> Bethesda, MD, USA
> PGP ID: 0x949342F9
>
>
> -----Original Message-----
> From: CHSPR Security
[mailto:securitypowerline.chspr.ubc.ca]
> Sent: Wednesday, January 17, 2001 2:49 PM
> To: Seitzer Mr Joseph W
> Subject: RE: Outlook Encryption problem (bug)
>
>
> Hi
>
> I have seen this problem before : when you
retrieve a certificate from an
> LDAP directory (as opposed to stripping it from
a received, signed email)
> Outlook always seems to default to using 40bit
encryption when encrypting to
> that key. The only way I ever found to enable
strong encryption was to have
> first received an email signed with the
certificate in question (and
> obviously sent by a client that supports strong
encryption). I strongly
> suspect that this is something to do with the
way Outlook stores certificate
> information in the address book. It's
interesting that you don't have this
> problem with Outlook Express, because I always
did have the same problem
> with both apps. Of course, this may also mean I
am way off base on
> understanding your problem.
>
> Sorry I can't offer a fix, but I'd sure be
interested in any solutions you
> come up with.
>
>
> David Renardson
> Systems & Security Manager
> Centre for Health Services & Policy Research
> University of British Columbia.
>
>
>
>
>
>
> [ attachment: <A CLASS=slink
HREF="/templates/archive.pike?part=.1&list=88&mid=
156985&"> (text/html)</A> ]
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]