Authority Information Access extension is used to publish in a given certificate:
- where a copy of the issuer's certificate may be downloaded;
- at which address / URL an OCSP server may be found, which will yield fresh revocation information on the certificate which contains the AIA.
See section 18.104.22.168 of RFC 5280.
Both usages make sense only in a certificate which is meant to have an issuer, i.e. a certificate which is not the first certificate in a validation path. The first certificate in a path is the "trust anchor", aka "the root CA": this is the name+key in which you trust "by definition", not because of a delegation from some issuer. As such, trust anchors have no issuer and no revocation status (they cannot be revoked by some upper CA; at best, you manually decide to cease to trust them). Trust anchors (root CA) are represented as certificates out of tradition but extensions in a root CA make little sense (when such extensions are used, this is often with a semantic which is quite distinct from what the extension usually embodies).
There is a possible confusion which you must learn to avoid: a CA is not the same thing as a CA certificate. A Certification Authority is an entity which has a name (an X.500 Distinguished Name) and a key. That name and that public key can be copied into several distinct certificates. This is common in the situation where two hierarchical PKI decide to "trust each other". Consider two PKI, called (unimaginatively) "A" and "B". Each PKI consists in:
- a root CA (called "root_A" and "root_B", respectively), which we can imagine as an offline system with a Hardware Security Module;
- a subordinate CA (called "sub_A" and "sub_B", respectively), which is an online system, possibly also with a HSM, and which issues the end-entity certificates;
- end-entity certificates.
Each CA, be it online or offline, must publish revocation information on a regular basis, so we must assume that even for the offline CA, there is an online server somewhere, where an adequate CRL is pushed through some manual procedure (or possibly automatically if there is a one-way network link from the root to the online server -- the one-wayness of the link allowing to maintain the offlineness of the CA).
Before PKI A and B decide to trust each other, some certificates exist, with the following characteristics:
- The name and key of root_A are published as a self-signed certificate, and a copy of that certificate is available on:
- The name and key of sub_A are published as a certificate, signed by root_A, with an AIA which points at the URL where
root_A.cer is made available. A copy of the certificate for sub_A is available on:
- In each end-entity certificate published by sub_A is an AIA which contains the URL on which
- Similarly for PKI B.
Thus, a verifier who wants to validate an end-entity certificate from PKI A follows the AIA extensions to download all required certificates, i.e.
sub_A.cer. The verifier may also download
root_A.cer but this is hardly necessary, since, for validation to succeed, the verifier must already have a copy of this self-signed certificate. Pointers to OCSP servers (also in the AIA) and to CRL (as CRL Distribution Points extensions) follow the same pattern, although, in that case, the pointer to the CRL/OCSP from root_A is not superfluous (verifiers must check that sub_A is not revoked).
Now comes the covenant by which A and B decide to bind their fates, mingle their blood, and generally be best friends forever. To that effect, PKI A and B will "merge", or at least be linked with what is usually known as a "bridge CA". The point is to allow people who trust root_A to automatically accept the end-entity certificates from PKI B as valid. There are mostly four ways to achieve this:
Root_A issues a new certificate for root_B: the certificate contains the name and key of root_B, but this certificate is not self-signed; instead, it is signed by root_A. Let's call
bridge_AB.cer this new certificate. Being issued by root_A, this certificate contains an AIA which points at
root_A.cer and the OCSP server which maintains revocation status of certificates issued by root_A.
Since no existing certificate has been altered or revoked or deprecated in any way, people who trust root_B (as a trust anchor) can keep on validating EE certificates from PKI B, as before. For such an EE certificate, the path to validate will be root_B->sub_B.cer->EE for people who have root_B as a trust anchor; for people who have only root_A as a trust anchor, the path will be root_A->bridge_AB.cer->sub_B.cer->EE.
For this process to work automatically, involved certificates should contain AIA extensions which allow the reconstruction of both chains. In that case, it suffices to replace the
root_B.cer (on the
serverB.com server) with a copy of
bridge_AB.cer, but under the name
root_B.cer. Thus, the AIA in
sub_B.cer now points to
bridge_AB.cer, without needing to change any single bit of
sub_B.cer. People who trust root_B can use it directly, they don't even look at the AIA in
sub_B.cer (at least for path reconstruction); people who trust root_A only follow the AIA and rebuild the path which begins with root_A. Everything is fine.
root_B.cer with the bridge certificate works only as long as there are only two PKI. If a third PKI C joins them in a ménage-à-trois, a more generic method must be employed: a new certificate is issued for sub_B: that certificate will contain an AIA which points at all the certificates for root_B: the old self-signed certificate,
bridge_CB.cer, and so on. The AIA format allows for containing several URI. That new certificate for sub_B can be published as
sub_B.cer, replacing the previous one.
Root_A issues a new certificate for sub_B. Since this new certificate is issued by root_A, it contains an AIA which points to
root_A.cer. Let's call
sub_AB.cer this new certificate.
At that point, we have an issue with regards to path building. An EE certificate from PKI B still contains an AIA which points to
sub_B.cer on server
serverB.com. If we replace
sub_B.cer with the new certificate issued by root_A (
sub_AB.cer), then path building finishes on root_A with no possibility to plug back to root_B: validation for people who trust root_B only is now broken. The generic solution would be to reissue all EE certificates, with a new AIA which points at both certificates for sub_B (the one issued by root_B, and the one issued by root_A). However, mass reissuing is expensive. An alternative way is to "make available"
sub_AB.cer to people who want to verify certificates. There is a certificate store in Windows meant for that (called "Intermediate CA"). Even though this certificate will not be referenced in AIA, software should be smart enough to use it where necessary. Since an intermediate CA is not a priori trusted, mass deployment of such a certificate is less problematic than deploying a new trust anchor.
Sub_A issues a certificate for root_B. Treatment is similar to the case 1.
Sub_A issues a certificate for sub_B. Treatment is similar to the case 2.
These four methods are for delegation of trust from PKI A to PKI B, allowing people who trust in root_A to validate EE certificates from PKI B. For a full bridge, the other direction must also be done (people who trust in root_B should be able to validate EE certificates from PKI A). It is not necessary for both bridges to follow the same topology (but the fancier you get, the more confusing the whole thing becomes).
The salient points are that:
Any CA can have several certificates, which contain the same name and key. A given certificate (EE or CA) has a single issuer (the entity which signed the certificate) but any certificate containing the name and key of that issuer can be plugged at that point in the path. Correspondingly, certificate paths may merge (X.509 explicitly prohibits full loops).
The AIA extensions are used to help in path building, by pointing to potential certificates for the issuer. Use of these certificate is not mandatory; mass deployment of intermediate CA certificates is a viable alternative (at least in organized networks which offer facilities for that, e.g. Active Directory servers).
None of this is impacted by policy mappings. It is the other way round: if PKI A and B use certificate policies, and both have their own distinct OID, then the bridge will have to include a mapping, so that verifiers can follow the policies through all paths that the may build.