Background
One of the items we want to better understand is the operation of the PKI Bridge Path Validation logic built into Windows XP. Given the growing number of Windows XP users, designing support for how XP does path validation into the Higher Education Bridge Certification Authority (HEBCA) is likely to be important to its success. Windows XP support would immediately increase the number of bridge-enabled applications available and ease the difficulties of integrating the HEBCA into campus environments. Of particular interest is the S/MIME functionality in Outlook and Outlook Express and the digital signature functions integrated into Office XP.

We have been unable to locate reference information on the Microsoft web site that specifically details how the path validation logic functions. There are some articles on their web site that provide some of the detailed information. However, these articles also raise nearly as many questions as they answer with regard to the detailed behavior of the bridge functionality. Of particular interest is how Windows XP uses the URIs in the Authority Information Access (AIA) field of the certificates in the chain being validated. Does it simply accept a single certificate for the immediately superior Certification Authority (CA) for each AIA URI found in a certificate? Will XP accept an object containing multiple certificates? Can more information be provided using LDAP URLs instead of HTTP? The answers to these questions will likely impact our certificate profile recommendations and possibly alter how we architect the Higher Education Bridge Certification Authority (HEBCA).

The Test Environment
Given the sketchy information available on the Microsoft Web site, some experimentation appeared to be the quickest way to understand the behavior of Windows XP's path validation logic. The easiest way to proceed was to create a test bridge replicating the general environment of Figure 16 of the Windows TechNet article. This includes three hierarchical Certification Authorities (OrgCA, CorpCA, and RootCA) along with a Bridge CA, several End Entity user certificates, the supporting cross-certificates, some digitally signed documents from Office XP, and the general supporting infrastructure.

The testing done to date needs to be validated by other testers and the results compared. There are many details that have to be correct for the tests to yield meaningful answers. Furthermore, Windows XP caches the certificates downloaded via AIA lookups in some yet to be determined location. The only way known so far to run a full test has been to reload XP on a test machine. This is a rather time consuming and tedious process after the first couple of times and a frustrating way to run a test.

How to test
All testing is done using the Download Block Diagram of the test environment. Every item in blue on the drawing is a clickable link that can be used to obtain certificates and other items needed for testing. Note: since you will be testing using Internet Explorer, please use the DER encoded versions of the certificates.
Important: before running any of these tests, be sure that your operating system is configured to not check for certificate revocation. There are not yet any CRLs or CRL pointers in the any of the certificates in the test environment. Go to Control Panel, Internet Options, and select the Advanced tab. Scroll down to Security and ensure that the two check boxes that talk about certificate revocation checking are both unchecked. If you had to unselect either of these check boxes, reboot before starting the tests. Windows says that only one of the settings requires a restart but this does not appear to be the case.

1. Select and become one of the users
   Select between either User2, User12, or User22. The other existing users were made using certificate profiles that Windows XP does not support or we have other unresolved problems (more later). There have already been several User2 tests, so trying either User12 or User22 is appropriate. First download the appropriate root certificate (OrgCA, CorpCA, or RootCA using the proper cert.der link. Next download the certificate for the matching intermediate CA (SubCA, IssuingCA, or DeptCA). Finally download the PKCS-12 object for your user and install the certificate and private key. The password for the PKCS-12 import is the same as the name of your user (e.g. User2, User12, or User22).
   At this point in the test, you will be a user on one of the hierarchical CAs but your machine will have no knowledge of the other two hierarchical CAs or of the Bridge.
   

2. Optional, check the digital signature on a document in your hierarchical CA
   Right-click on the blue name of the intermediate CA in your hierarchy to download a Word XP document that was signed by your user. Note: it appears that if you want to verify an Office XP document signature that you need to download the document to your machine instead of reading it inside of Internet Explorer. Verify the signature by double-clicking on the small red certificate icon at the bottom of the Word window. Press the View Certificate button and select the Certification Path to verify the signature and configuration.

3. Check the digital signature documents signed by users from other CAs
   Download the Word XP documents signed by the other two users and verify the signatures via the method described in B. above. Verify that the signatures are valid even though you have not installed the root certificates for the other user's CAs and that the certification path now flows through the bridge certificate to your hierarchical CA's root certificate.

Functionality noted to date

1. Authority Information Access (AIA) URI lookups
   Windows XP reads a single object using HTTP URLs in the AIA field of the certificate. XP will try all of the URLs in the AIA field in order but will stop after it reads and caches the first entry found. For example, you can not simply add a URL for each object needed and expect Windows to read and cache all of the certificates. It will stop after downloading the first one. Windows appears to assume that the multiple URLs in the certificate all point to the same information so further lookups after the first successful download are not needed.
   Windows 2000 reads objects using AIA pointers the same way as Windows XP. The caching strategy appears to be a little different but the overall functionality is similar.

2. Download of simple certificates
   When referenced via an HTTP URL in the AIA field in a certificate, Windows XP will download and cache a single certificate. The certificate should be in DER format.

3. Download of PKCS-7 objects
   When referenced via an HTTP URL in the AIA field of a certificate, Windows XP will accept a PKCS-7 object containing multiple certificates. XP does load all of the certificates in the PKCS-7 object into its cache and uses these certificates for path construction and validation. Thus, it is possible to enable bridge functionality by simply adding AIA pointers into EE certificates and populating the referenced PKCS-7 objects with with the needed cross-certificates.

4. LDAP AIA URL Testing
   Windows XP also supports LDAP URLs in the AIA field of EE certs. See the certificates for User13 and User23 on the Download Block Diagram for details. Hopefully it will also support AIA LDAP URLs at higher levels in the bridge. Testing has been less successful with LDAP than it was using HTTP and PKCS-7 objects in that we haven't yet been able to get Word XP to find the cross-certs via LDAP when verifying a signature. However, if you download just the EE cert that was used to sign the document and view the cert in the XP cert viewer (in Control Panel/Inet Options), then XP will correctly go to the LDAP server, download all of the cross certs, and create and validate the correct trust path through the bridge. Word XP does not even generate an access attempt entry in the LDAP server log.

   So, early indications are that not 100% of the PKI functionality in Microsoft applications comes directlty from operating system libraries. Testing bridge functionality will need to be done with each application. We are hoping that a few other people will try to reproduce some of these results.

5. CRL Checking
   If CRL checking is enabled in the operating system, Office XP appears to want to check CRLs while performing document signature verification even if there are not any CRL distribution points present in the certificates.
   

A probably incomplete list of remaining work

1. Cross-certifying some campus test CAs into the test bridge
2. Testing Windows XP behavior using LDAP URLs in the certificate AIA field
3. Testing with CRLs in the certificates
4. Adding Outlook and Outlook Express (S/MIME) applications to the testing
5. Checking Windows 2000 behavior with Outlook and Outlook Express