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

List:       ms-cryptoapi
Subject:    Re: CSP Development for CAPI 2.0
From:       Rob Price <robp () MICROSOFT ! COM>
Date:       1996-12-18 16:35:27
[Download RAW message or body]


Susan,

Re your (perceptive) questions on certificate and key storage:

The current developer's release of CAPI 2 handles certificate storage
itself, as you observe. In the (very) near future we'll be expanding on
the capability to install certificate storage providers, as well as key
storage providers (the idea being that you may want to take an existing
CAPI CSP and provide enhanced key storage and management, without
reimplementing the part of the CSP that implements a suite of
cryptographic algorithms). We also have explicit work underway here as
part of our smartcard development to enable card-based storage  using
these mechanisms (we just released some specifications in this area last
week!).

You can be assured that (a) we'll unify these things so a single code
module or medium can provide storage for both keys and certificates, if
desired, as well as passwords or other 'secrets' (so no, you won't need
two smartcads), and (b) the application-level interfaces won't need to
change -- existing code that calls Crypto API and uses named key
containers or certificate stores won't need changing and the API will
transparently be able to store this data on various media in various
formats.

Directories are good places to look up other peoples' certificates, but
generally speaking for your own certificates you'll want local copies
you can always access. And of course, directories are not ideal to say
the least for storing your private keys...

As a pragmatic note, for the next year or so smartcards will have barely
enough storage, if at all, to store certificates, so in practice most
systems will want to store only key material on the smartcard and store
certificates locally, in a directory, or both.

>----------
>From:  Susan Chapin[SMTP:schapin@MITRE.ORG]
>Sent:  Monday, December 16, 1996 6:15 AM
>To:    CryptoAPI@LISTSERV.MSN.COM
>Subject:       Re: CSP Development for CAPI 2.0
>
>This seems to mean that all the certificate management code is in the CAPI
>2.0 DLLs, which only interact with the CSP through the CAPI 1.0 interfaces.
>Supposing you wanted to store certificates on your hardware token CSP, you
>couldn't do it, right?  (because there is nothing in CAPI 1.0 that addresses
>certificate storage.)  So for certificate off-line storage you have to wait
>for Wallet. And then you would need two cards and two card readers, one for
>your CSP and one for your Wallet card.
>
>Am I missing something?  Are we waiting for Directory as the true and only
>place to store certificates?
>
>Thanks,
>
>       - susan
>
>----------
>From:  Keith Vogel[SMTP:keithv@MICROSOFT.COM]
>Sent:  Friday, December 13, 1996 5:35 PM
>To:    CryptoAPI@LISTSERV.MSN.COM
>Subject:       Re: CSP Development for CAPI 2.0
>
>CryptoAPI 2.0 does not add additional CSP requirements on CSP
>developers. Crypt 2.0 is an additional set of APIs to help develop a
>public key certificate based environment. Crypto 1.0 deals with the
>specifics of cryptography. Crypto 2.0 adds X509 certificates, ASN.1, and
>PKCS support.
>
>        Thanks
>        KeithV
>
>>----------
>>From:  Susan Chapin[SMTP:schapin@MITRE.ORG]
>>Sent:  Friday, December 13, 1996 1:00 PM
>>To:    CryptoAPI@LISTSERV.MSN.COM
>>Subject:       Re: CSP Development for CAPI 2.0
>>
>>Brian,
>>
>>Thank you for your response, but I don't think it answers my question.  CAPI
>>2.0 adds some certificate management functions to the user and also supports
>>the CAPI 1.0 functions.  The CAPI 1.0 functions are a thin passthrough to
>>the
>>CSP interfaces.  I wondered whether CSP developers now have to support
>>additional certificate management interfaces.  Microsoft's high-level
>>published briefings/documents don't say yea or nea to that.
>>
>>       - susan
>>
>>----------
>>From:  Brian Sherrell[SMTP:briansh@MICROSOFT.COM]
>>Sent:  Thursday, December 12, 1996 7:25 PM
>>To:    CryptoAPI@LISTSERV.MSN.COM
>>Subject:       Re: CSP Development for CAPI 2.0
>>
>>Please someone, correct me if I'm wrong, and Susan you should look at the
>>CryptoAPI 2.0 overview.  The Overview is in PowerPoint format so you'll
>>need to download the PowerPoint Viewer if you don't already have it or
>>PowerPoint.  Viewer and Crypto 2.0 overview can be found on:
>>
>> http://microsoft.com/intdev/sdk/dtctrl/
>>
>>Question #1: Are there any changes to the CSP interface functions between
>>CAPI 1.0 and
>>        CAPI 2.0, either tweaks to existing interface definitions or new
>>interface
>>         definitions to support CSP-based management of certificates?
>>
>>Answer #1: To my knowledge, no, because CryptoAPI 1.0 provides a mechanism
>>for developers to create CSPs.  Apps communicate with CSPs via APIs'
>>exposed by Advapi32.dll which is filtered by the OS and passed to the
>>appropriate CSPs through the CryptoSPI (CryptoAPI 1.0).  API for
>>Certificate Functions and Higher-level Encapsulation are provided by
>>CryptoAPI 2.0.
>>
>>Brian
>>
>>-----Original Message-----
>>From:   Susan Chapin [SMTP:schapin@MITRE.ORG]
>>Sent:   Thursday, December 12, 1996 10:42 AM
>>To:     CryptoAPI@LISTSERV.MSN.COM
>>Subject:        CSP Development for CAPI 2.0
>>
>>Are there any changes to the CSP interface functions between CAPI 1.0 and
>>CAPI 2.0, either tweaks to existing interface definitions or new interface
>>definitions to support CSP-based management of certificates?
>>
>>I ask because at the recent ICE Workshop there was some mention of
>>certificate storage within the CSP, and I wondered how the CAPI 2.0 layer
>>would communicate with a CSP-based certificate store.
>>
>>I have CSPDK 1.0.  Is there a version 2.0?
>>
>>Thank you,
>>
>>        - Susan Chapin
>>
>>
>>
>>
>
>
>

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