[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-capicom
Subject:    Re: RE : .net crypto-dev strategy
From:       "Ryan M. Hurst" <rmh () WINDOWS ! MICROSOFT ! COM>
Date:       2003-03-20 19:01:13
[Download RAW message or body]

Yes they do, and they are reasonable approach if you only need the basic \
functionality they offer but you should consider this a short term solution as the \
platform will natively support this capability in a future release.

Ryan

-----Original Message-----
From: SZNITEN, David [mailto:dszniten@DICTAO.COM] 
Sent: Thursday, March 20, 2003 6:27 AM
To: CAPICOM@DISCUSS.MICROSOFT.COM
Subject: RE : .net crypto-dev strategy

Ryan, Michel,

I've been looking for some time at the Web Services Enhancements \
(http://msdn.microsoft.com/webservices/building/wse/default.aspx) for .NET Framework. \
These libraries seem to enable certificate store features fully in managed code.

Am I right? What are the drawbacks of deploying these assemblies with the executables \
(beside package size)?

Thanks for your help.

David Szniten
DICTAO

dszniten@dictao.com 

-----Message d'origine-----
De : Ryan M. Hurst [mailto:rmh@WINDOWS.MICROSOFT.COM] 
Envoyé : mercredi 19 mars 2003 21:43
À : CAPICOM@DISCUSS.MICROSOFT.COM
Objet : Re: .net crypto-dev strategy

Michel --
It really depends on the application and the developer so it's hard to
give a one size fits all answer here.

In general my recommendation is to use CAPICOM in lieu of P/INVOKING
CryptoAPI directly. There are cases where this isn't the right answer,
some of these include:
* If your application needs to run on 64bit platforms, since VB doesn't
support 64bit neither does CAPICOM.
* If your application needs to use functionality not available in
CAPICOM or the current .NET Cryptography classes you will need to
P/INVOKE.

Unfortunately both of these solutions require an application to be fully
trusted; we are working on new capabilities for the .NET Framework (that
I will be showing off at RSA if any of you want to stop by!) that will
allow you to do this all in managed code.

In my opinion developing on CAPICOM will make it easier for you to
migrate to these new classes in the future (although the new work is not
modeled directly after CAPICOM).

As for deployment, I suggest SNing the interop library and deploying
that way. We are investigating the possibility of a interim release of
CAPICOM we can look into providing such a MS SNed interop library at
that time.


Ryan



-----Original Message-----
From: Michel Gallant (MVP) [mailto:neutron@ISTAR.CA] 
Sent: Wednesday, March 19, 2003 8:07 AM
To: CAPICOM@DISCUSS.MICROSOFT.COM
Subject: .net crypto-dev strategy

What approach is recommended for building .net crypto-enabled
applications
with current released technology? Assume I need cert store capability
not
available in .net framework 1.0 / 1.1 classes:

 - design application with P/Invoke only to access capi capability

 - generate  CAPICOM interop dll with tmbimp.exe and use
   COM interop classes therein?  (requires com interop dll deployment;)

 - embed CAPICOM declarations in my own assembly
    (no interop library deployment required but trickier)


From a *secure application*  (as opposed to security application) point
of
view, which approach is recommended ... i.e. less likely to have
security
vulnerabilities?

If I use the 2nd approach (CAPICOM interop dll),  I can either include
the interop lib (currently ~ 76 kb) with every deployment, or
strong-name
sign that lib and have my clients install to their GAC.  Which approach
does MS recommend?

Can I strong-name sign the capicom.dll interop assembly, say with a
self-signed
certificate,  and deploy it legally from my web site? Shouldn't the
developer of
the COM component strong-name sign it as "primary" (i.e. Microsoft)?


As we go forward with .net, we expect to see some of the current CAPICOM
functionality migrated to .net.  Any recommendations for developers who
want to design for the future, but need to deploy .net product now?

Cheers,
 - Mitch


[prev in list] [next in list] [prev in thread] [next in thread]