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

List:       ms-cryptoapi
Subject:    Re: SP4 version of CryptoAPI (long)
From:       Brian LaMacchia <bal () MICROSOFT ! COM>
Date:       1998-11-25 0:13:32
[Download RAW message or body]


Bill Brice (bill.brice@IDTRUST.COM) wrote:
>Brian,
>
>Thanks very much for the updates. A few questions and clarifications:
>
>1) Re: Automatic cert importing to a store. If I launch the cert
>import routine by double-clicking on a cert file that HAS the
>basicConstraints extension set to end-entity (ASN.1=04 02 30 00),
>the import routine still tries to import it as an intermediate
>CA. This cert is a standard Verisign Class 1 cert.

Going back over my previous post I realize my answer wasn't as clear as it
could have been (and it fact may have contributed to the confusion).  Let me
try again & see if I can do a better job this time:

We have three cert stores that we consider "system stores" which are created
for every user: ROOT, MY and CA.  ROOT holds trusted self-signed root
certificates.  MY holds certificates that are for public keys for which the
user holds the corresponding private key.  The CA store holds "everything
else": all certificates that are neither self-signed trusted roots or
correspond to held private keys.  The name "CA" is somewhat of a misnomer,
but there's code out there that references the store by that name.

The confusion arises because of the presence today of the AddressBook store,
which is used by the mail clients for storing end-entity certs (certs for
people with whom you wish to communicate).  While certs may be stored
directly in the AddressBook store, this is not its normal mode of use; in
general the AddressBook store gets modified by the mail clients as mail
"Contacts" are modified.

When the import wizard picks the default cert store for an import, it
chooses from among only the MY, CA and ROOT stores.  Since the cert you were
importing didn't look like a self-signed root (it was a VS Class 1), that
rules out the ROOT store.  Assuming you didn't have an associated private
key the default place for it to end up is the CA store.

Now, that's what happens at the store level for the "everyone has one"
system stores.  For the common user interface that users will use to manage
certs, we wanted to hide the store structure and present certs in more
meaningful groupings.  You can see the new "lightweight IE cert management
UI" in IE5 beta 2.  Go to Tools->Internet Options, Content tab, Certificates
button; that launches the UI.  We present four tabs of certs:

Personal:               certs in the MY store
Other People:   filtered union of the CA and AddressBook stores
Intermediate CAs:       filtered portion of the CA store
Trusted Root CAs:       ROOT store

The Personal and Trusted Root tabs simply display the contents of the MY and
ROOT stores, respectively.  The "Other People" tab displays the union of the
AddressBook store and any certs in the CA store that we can definitely
identify as being end-entity via basicConstraints.  The "Intermediate CAs"
tab displays everything else in the CA store: certs with a basicConstraints
extension that says "CA=TRUE" as well as certs without any basicConstraints
extension.

Given that you know about the underlying cert store structure the
lightweight UI presentation may seem a little non-intuitive.  However, it's
easier for users in general to use when dealing with their pile of certs.
And if you want to browse the stores themselves you can do that on NT5 via
the Certificate Management MMC snap-in (the "heavyweight" UI).

>2) Re: Status of basicConstraits in PKIX. The current PKIX draft states
>that if the subject is NOT a CA then the basicConstraints extension
>should be omitted. In order words, if there is not a basicConstraints
>extension marked cA, the treat it as an end-entity cert. There is
>a current debate raging on the PKIX list about this. Will Microsoft
>expect to see a basicConstraints extension encoded as above in order
>to treat the cert as an end-entity cert?

You've probably seen my post to the PKIX list by now on this topic.  For
those who haven't, basically what I said was that I thought the PKIX
statement that EE certs SHOULD NOT contain a BC extension was wrong, and
that in fact PKIX should encourage use of BC extensions in all certs.
Nevertheless, because certs exist today that do not have a BC extension,
applications that rely on certs have to be able to deal with that fact.  At
the system level, we do so by allowing for the possibility that a cert w/o a
BC extension could be a CA cert, meaning that it may appear as a parent in a
cert chain.  Individual applications may choose to have tighter
restrictions, of course, as ultimately this is a local policy issue.

>3) Are the SP4 MS CSP's updated and if so, do they fix the problem of
>the Enhanced provider NOT being fully compatible with the Base
>provider? If they are updated, if there a way to patch them into
>non SP4 environments (SP3, Win95/98)?

The CSPs have been updated.  This update was mainly bug fixes and the
addition of support for PKCS #1 version 2 (CRYPT_OAEP flag to be used with
importing and exporting SIMPLEBLOBs).  The Enhanced provider is not set as
the default.  The patched CSPs are also in IE5 Beta 2 (and will be in IE5
final), so installing IE5B2 or IE5 final on those platforms will update the
CSPs.

>4) What revocation checking does the SP4 version of CAPI support?
>Local CRLs? What support is there/will there be for remote CRL
>retrieval? OCDP? OCSP? Does or will the Microsoft e-mail clients
>support revocation (status) checking on the cert chain?

SP4 supports automatic CRL-based revocation checking and retrieval as part
of the overall chain-building process.  Application request revocation
checking by setting appropriate flag values in the chain-building calls.
For example, if you look at CertGetCertificateChain there are three flag
values related to CRL-checking:

CERT_CHAIN_REVOCATION_CHECK_END_CERT--Revocation checking is done on the end
certificate and only the end certificate.

CERT_CHAIN_REVOCATION_CHECK_CHAIN--Revocation checking is done on all of the
certificates in every chain.

CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT--Revocation checking in done
on all certificates in all of the chains except the root certificate.

Revocation checking keys off the contents of the CRL Distribution Point
(CDP) extension within a certificate.  We use the URLs contained with the
CDP extension as location hints for finding a valid CRL.  We try them in
order until we're able to retrieve a currently-valid CRL.  Retrieved CRLs
get cached so the cost of the retrieval can be amortized over requests
against that CRL.

>5) Can you confirm for me the following behavior of Outlook Express
>and Outlook 98 vis-a-vis cert stores:
>
>OE v4 and v5 - certs for address book entries are stored in the registry
>on the local computer in the "Other People" Store.

Correct.  "Other People" is the display name for the AddressBook store
mentioned above.  It's a registry-based store and it does not inherit or
share information with any other store.

>OL98 - In Internet configuration certs are stored for Outlook Contacts
>as per above. In Exchange configuration, certs are stored on the Exchange
>Server.

Certificates that are associated with an Outlook Contacts address book entry
are stored in the "Other People"/AddressBook store just like OE4 and OE5 do.
Certs associated with Exchange directory entries are themselves stored in
the directory.

                                        --Brian LaMacchia
                                          Program Manager, Core Cryptography
                                          bal@microsoft.com

----------------------------------------------------------------
Users Guide http://www.microsoft.com/workshop/essentials/mail.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://discuss.microsoft.com/archives/index.html

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