In Exchange 2003 RTM, as part of the cached mode Outlook initiative, we found that the Offline Address Book stored on the client was taking 300 megabytes at Microsoft, a phenomenal amount of space and far too much to be reasonable. Other customers had also found that their OABs were very large and were looking for a way to reduce the size. Upon investigation we found that a substantial portion of the OAB was being taken up by user certificates. Although we had rolled out a public key infrastructure for e-mail at Microsoft, adoption wasn't high enough to warrant the size of the OAB files we were seeing. After digging deeper, we found that a large percentage of the certificates stored weren't even usable for e-mail; they were Encrypted File System certificates used by the Windows operating system. Another large percentage of the remaining certificates were usable for e-mail but had expired. To improve the situation, it was decided that we had better start filtering the certificates that are stored in the OAB.
Currently there are three attributes that ship with Windows 2003 and Exchange 2003 that can store user certificates: userCert, userCertificate, and userSMIMECertificate. UserCert is a single valued attribute that stores the old Nortel style certificates used long ago with Key Management Server for Exchange (KMS). Most companies don't use these anymore so filtering it would not reduce the OAB size much. At Microsoft this attribute only consumed 69k of space over the entire address book. UserSMIMECertificate is used only by Exchange and Outlook for PKCS-7 encoded e-mail certificates and all certificates stored here are supposed to be usable for e-mail. This attribute consumed 33 megabytes of space in the OAB. UserCertificate, however, is used by Exchange, Outlook, and Windows. Exchange and Outlook use it to store DER encoded X.509 e-mail certificates, and Windows uses it to store the public keys for logon, EFS and other such keys. This attribute consumed 155 megabytes of space in the OAB. Filtering this attribute would provide the greatest reduction in OAB size since we found that there were over 72,000 EFS certificates stored in this attribute at Microsoft at the time.
The filtering algorithm works as follows for all versions of the OAB except version 1 since version 1 OABs include neither the userCertificate attribute nor the userSMIMECertificate attribute. First, the OAB generation code attempts to open each certificate for each recipient using the Windows Crypto API. If Windows doesn't recognize it, the OAB generator will drop the certificate and set a flag that the recipient has had a certificate dropped. If the certificate can be successfully opened, the intended key usage is retrieved and checked to see if the CERT_DIGITAL_SIGNATURE_KEY_USAGE or CERT_NON_REPUDIATION_KEY_USAGE bits are set. If either is set, then the key can be used for signing e-mail. If CERT_KEY_ENCIPHERMENT_KEY_USAGE or CERT_KEY_AGREEMENT_KEY_USAGE are set, then the certificate can be used for e-mail encryption. If either case is true then the cert could be included in the OAB. If the certificate doesn't have an intended usage specifically set, it is assumed the key could be used for anything and needs to be included.
Next, the OAB generator checks the enhanced key usage field of the certificate. Again, if no enhanced usage is specified, it is assumed it can be used for anything and is included in the OAB. The OAB generator checks for the OID_PKIX_KP_EMAIL_PROTECTION object identifier to determine if it can be used for e-mail. EFS certificates will be dropped from the OAB because they only have the OID_PP_EFS object id set and not the other.
Finally after checking the above restrictions, the OAB generator reads the expiration date on the certificate. If it has expired, the certificate is dropped regardless of its usage. After performing all these operations, the remaining certificates for the current recipient are included in the OAB. A 9323 event is logged for the current recipient if OAL logging is set to medium and any invalid or expired certificates were discarded. When OAB generation has finished, a 9320 event will be logged at logging level NONE if any certificates were dropped at all. But note that a 9320 event can also indicate the details record for an entry went over 64 kilobytes and was dropped. Turning up event logging to medium for OAL generation during the next run will force the generation process to log specific messages for every entry affected.
As a fail-safe mechanism, the behavior of the OAB certificate filtering can be customized to a certain extent. If a customer is using a third party certificate add-on to Outlook that stores their own certificates in the UserCertificate attribute, or a new format of encoding certificates is used that the OAB server doesn't understand, we added a registry key to be set on the OABGen server. The registry key can turn off certificate filtering entirely, or only filter certificates that the OAB generator can read and leave other certificates in the OAB.
The DWORD registry key (note the Canadian spelling) "HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\OAL Invalid Cert Behaviour" has the following integer settings:
0: Discard invalid - Filter all certificates and discard any that can’t be decoded, any certificates that can be decoded but do not have any e-mail usage bits set, or any certificates that have expired. This is the default setting if the registry key is not set.
1: Include invalid - Same as above, but any certificates that couldn't be decoded for any reason will not be discarded.
2: Don’t filter - Leave the UserCertificate attribute alone and include all values in the OAB.
Note that changing this registry key can result in a full OAB download for everyone that uses the OAB due to the size of the differences file. If everyone has an EFS cert and you change the value so that no certificates are filtered, then this results in a modification to every recipient in the OAB and a full download results.
I haven't heard of any customer that has had to use this registry key, but it's there in case anyone runs into difficulty. This OAB change, when applied internally, reduced Microsoft's details OAB file by two thirds: reducing it from 289 megabytes down to 100 megabytes, a very large savings in file size. These changes shipped with Exchange 2003 RTM and has not been back-ported to any Exchange 2000 service packs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.