Side - Effects of Cross-Certific

Document Sample
Side - Effects of Cross-Certific Powered By Docstoc
					                       Side-Effects of Cross-Certification
                                        James L. Fisher, Ph.D.
                                  Mitretek Systems, Falls Church VA

While many organizations lean towards                 automatically grants that peace of mind, but
cross-certification with bridge certification         rather that it is standard practice for each
authorities     (BCAs)      for   wider     PKI       party considering cross-certification to
interoperability, there are many hidden               scrutinize the other party’s pre-issuance
details that can affect operating capabilities        identity    vetting    policies,   private-key
as well as legal standings. The purpose of            protection policies, CA and directory
this paper is to share lessons learned to             infrastructure operational policies, etc. Thus,
help the reader to understand implications            an issued cross-certificate represents a
of choosing a cross-certificate based trust           thorough background check with acceptable
model.          Topics     covered     include:       findings.
X.500/LDAP          certificate       directory
                                                      Issued cross-certificates can be used to
implementation        and       interoperability
                                                      dynamically assemble a chain of certificates
requirements; transitive and asymmetrical
                                                      called a trust path which spans the gap
trust; choosing the proper trust anchor;
                                                      between the certificate issuer and the
cross-certificate policy mappings; and
                                                      relying party.      The complete set of
Certification & Accreditation requirements.
                                                      certificates comprising the certificate trust
This paper does not examine the trust path            path (including supporting time-specific
discovery process—it focuses on the                   validity statements) forms a tangible record
necessary,        enabling     configuration          of trust that can be stored for future
components that enable path discovery and             evidence of due diligence. This might be
path validation to be automated.                      necessary for institutional archival purposes
                                                      or to satisfy National Archive and Records
There are technical solutions to the issues
                                                      Administration (NARA) requirements.
presented herein. However, due to their
inherent complexity, a discussion of
alternative solutions is beyond the scope of          Directory Interoperability
this paper.                                           The operating authority of a BCA typically
                                                      provides a publicly available X.500 or LDAP
Benefits of Certificate Bridges                       directory for publishing issued CA
                                                      certificates, cross-certificates, and often
One of the primary advertised benefits of a
                                                      certificate revocation lists (CRLs). Equally
certificate bridge is that it allows the relying
                                                      important, these X.500/LDAP directories are
party to enjoy the benefits of a larger trust
                                                      configured to facilitate trust path discovery
domain while not being required to be an
                                                      and validation by providing chaining to, or
integral part of the certificate hierarchy of
                                                      referrals to, all other CA directories to which
that other trust domain, all while trusting
                                                      cross-certificates have been issued. The
only one trust anchor—a public key which is
                                                      intent is to provide a one-stop-shop virtual
within its own trust domain.
                                                      directory from which all relevant certificates
The other benefit is that the relying party           and CRLs can be retrieved during the path
can also be relatively sure of the certificate        discovery and validation processes.
holder’s identity, based on the trust placed
                                                      In    practice,     each     cross-certifying
in others to validate an organization's
                                                      organization    typically   has   its    own
identity.   It’s not that cross-certification
X.500/LDAP directory to which its own           The following list describes the cross-
users (certificate issuees and/or employees)    certifications that have occurred between
point the LDAP clients in their local           the above fictitious entities, and the
validation engines, and if the requested        resulting trust mesh appears in Figure 1:
certificate or CRL does not fall under that
                                                   •   The Government Bridge—GBA—
local directory's base distinguished name
                                                       (with base DN ou=GBA, o=Upper
(DN), a superior reference chains
(transparently to the user) to the master              Government, c=US) has cross-
BCA for retrieval. No matter where the                 certified with only:
certificate or CRL resides, it is returned to              • GI (with base DN ou=GI,
the LDAP client. Without such chaining,                       o=Upper Government,
there is currently no way for a desktop                       c=US)
LDAP client to discover what directory to                 •   UBA (with base DN o=edu,
connect to for retrieval of a certificate or                  c=US)
CRL.       This necessary processing has                  •    Neighboring Nation (with
interesting implementation implications.                       base DN c=NN)
                                                   •   The University Bridge (UBA) has
First, the BCA directory must be able to
                                                       also cross-certified with:
resolve any base DN that could ever form a
trust path through that BCA. An illustration               • The original Enormous State
will help in understanding the details.                        University infrastructure,
                                                               ESU1 (with base DN o=ESU
In the examples we use in this paper,                          Provosts, c=us)
assume the existence of the following                      • The new Enormous State
fictitious PKI participants:                                   University infrastructure,
   •   A Government (Certification) Bridge                     ESU2 (with base DN o=ESU
       Authority/Architecture (GBA)                           Provosts, c=us, dc=esu,
   •   A Government Institution (GI)                          dc=edu)
   •   A Neighboring Nation Bridge                 •   The Neighboring Nation has also
       Authority/Architecture (NNBA)                   cross-certified with:
   •   A University Bridge                                 • The World Wide Council
       Authority/Architecture (UBA)                             (with base DN dc=int)
   •   An older, legacy PKI system at the          •   The World Wide Council cross-
       Enormous State University (ESU1)                certifies with:
   •   A newer PKI system at the same                      • The Random Transoceanic
       university (ESU2)                                        Nation (with base DN c=RTN)
   •   A World Wide Council (WWC)
   •   A random transoceanic nation (RTN)
       GI                       GBA                     NNBA                        WWC

                                 UBA                                                 RTN

                      ESU1                ESU2

                    Figure 1: Cross-Certification Between Trusting Partners

Figure 1 allows us to see more clearly the             •   Name context: a subtree of a
many and varied trust paths that can be                    directory, and is identified by the DN
formed. For instance, through certificate                  of the topmost entry (the "base DN");
bridges      and    cross-certificates,    the             in many commercial databases, a
Government Institution should be able to                   DSA's database can contain more
trust digitally signed messages from the                   than one name context
Enormous State University, regardless of               •   Cross-reference: specifies a name
whether the signer’s certificate was issued                context (usually within a remote
from ESU’s old or new PKI infrastructures.                 DSA) that is not a child of this DSA's
Additionally, cross-certificates would also                name context; a cross-reference
allow the Government Institution to trust                  typically points directly to the entry in
digitally signed messages from the Random                  the name context hierarchy
Transoceanic Nation—this trust path may or             •   Subordinate reference: specifies a
may not be intentional or desired, as we will              name context (usually within a
discuss later. Let us now look at the                      remote DSA) that is a child of this
certificate/CRL    directory    configurations             DSA's name context
required to enable a relying party to easily           •   Superior reference: specifies the
discover and validate a trust path.                        parent DSA that holds entries
                                                           outside this DSA; only one superior
Before discussing the supporting certificate               reference per DSA is permitted
directories, it will be helpful to review the
definition of key X.500 directory knowledge        For complete directory chaining, the
references and concepts:                           (fictitious) US-based certificate directories
                                                   are configured as follows, with Figure 2
   •   Directory Server Agent (DSA): the           representing     the   same       information
       software providing the X.500                pictorially:
       directory service for a particular
       hierarchal directory information base           •   The GI directory DSA is rooted at
       (DIB)                                               ou=GI, O=Upper Government,
                                                           c=US, and has one superior
                                                           reference to the GBA directory
•   The ESU directory has:                           •   A subordinate reference from
       • One DSA rooted at o=ESU                         the DN o=ESU Provosts,
           Provosts, c=us                                c=us to the original ESU
       •   A second DSA (or a second                     directory
           naming context under the                  •   A cross-reference from the
           first DSA) rooted at o=ESU                    DN c=NN to Neighboring
           Provosts, c=us, dc=esu,                       Nation's border directory
                                                     •   A cross-reference from the
       •  One superior reference to the                  DN dc=edu to UBA's second
          UBA directory                                  DSA
•   The UBA directory has:                           •   A cross-reference from the
       • One DSA rooted at o=edu,                        DN dc=int to the WWC’s
           c=US                                          border directory
       •  A cross-reference from the                 •   A cross-reference from the
          DN o=ESU Provosts, c=us                        DN c=RTN to the RTN’s
          to the original ESU directory                  border directory
       • A second DSA (or a second                   •   (no superior references)
          naming context under the
          first DSA) rooted at dc=edu     (We leave it as an exercise to the reader to
       • A subordinate reference          consider the cross-references needed at the
          under the second DSA from       WWC and RTN border directories.)
          the DN o=ESU Provosts,          Notice this very important fact: in order to be
          c=us, dc=esu, dc=edu to         able to retrieve (via chaining) certificates
          the new ESU directory           issued by RTN’s CA, the GBA directory
       • A superior reference to the      must include a knowledge reference for the
          GBA directory                   c=RTN DN (pointing to the RTN directory)
•   The GBA directory has:                even though the GBA did not directly cross-
       • One DSA rooted at c=US           certify with the RTN. This requirement has
       • A subordinate reference from     potentially serious implications on how
          the DN ou=GI, o=Upper           easily a BCA can dynamically expand to
          Government, c=US to the GI      accommodate indirect trust agreements.
       • A subordinate reference from
          the DN ou=UBA, o=edu,
          c=US to the UBA directory
                 c=US                 cref(c=NN)       cref(dc=int)       cref(c=RTN)       cref(dc=edu)

       subref(ESU Prov)            o=Upr Govt                   o=edu

                                 subref(ou=GI)            subref(ou=UBA)

 GI                                                                                                UBA
       ou=GI, o=Upr Govt, c=US                   o=edu, c=US             dc=edu         cref(o=ESU Prov, c=US)

                                                   ou=UBA               subref(ou=ESU Prov, c=us, dc=esu)


  o=ESU Prov, c=US                    ou=ESU Prov, c=us, dc=esu, dc=edu

             Figure 2: Directory Chaining Agreements, and Subordinate and Superior References

Notice that because of DN naming                                  •     cross-references
conventions chosen, and how each DSA is                           •     subordinate references
rooted, both GBA and UBA directories need                         •     superior references
a cross-reference from the DN o=ESU                            Fortunately, these capabilities are found in a
Provosts, c=us to the original ESU                             number of commercial X.500 directories,
directory.                                                     such as: i500 by PeerLogic; eTrust by
One can easily see how quickly border                          Computer Associates; M-Vault by ISODE.
directory      configuration      becomes                      However, Microsoft Active Directory does
complicated when multiple BCAs cross-                          not support superior references, non-local
certify. Each BCA must be configured with                      cross-references, or non-local subordinate
knowledge of all possible directories                          references.        Therefore, organizations
traversed along a trust path, even if the                      wishing to provide a publicly accessible
BCA did not cross-certify directly with the                    certificate directory (often called a border
corresponding CA.                                              directory) to their relying parties suitable for
                                                               use in automated path discovery should
As seen, each border directory needs the                       export all necessary certificates and CRLs
capability of supporting:                                      from their Microsoft Active Directory and
   •     multiple root DSAs or multiple name                   import into a directory supporting the
         contexts within a single DSA                          aforementioned types of references.
Alternatives:                                      regulations, let us assume that GI directors
                                                   would prefer that there be no valid
The BCA directory was required to provide          certificate   trust   path  from    GI    to
a multitude of cross-references and                Forbiddenstan.
subordinate references because directory
chaining was desired.          One design          To prevent the formation of such a trust
alternative is to have the BCA directory           path, cross-certificates must be re-issued to
simply return referrals to only those              specify new name constraints or path length
directories with which it is directly cross-       constraints. There are two logical places in
certified. But this presents two problems in       the trust chain where such a filter could be
today's environments:                              positioned. Since this is a federal law, the
                                                   GBA’s cross-certificate issued to the NNBA
   •   Many LDAP clients still can not             could contain a name constraint to filter out
       process directory referrals                 Forbiddenstan’s c=FB DN. However, since
   •   Trust paths traversing more than            other     domestic      humanitarian-oriented
       one bridge would not be discovered          government agencies might have legitimate
       if the pertinent certificate fields         needs to trust Forbiddenstan-signed
       contained only DN-formatted                 documents, a nationwide filter might not be
       information and not URI-formatted           appropriate. Therefore, a GI itself might
       information                                 need to insert name constraints into the
Directory chaining would not be necessary if       cross-cert it issues to the GBA. Additionally,
all certificates had properly formatted AIA        all other relying parties would similarly need
fields, and the local validation client could      to be aware of this political situation and
understand all AIA formats. However, one           place appropriate name constraints in their
missing or improperly formatted AIA field          cross-certificates.
would destroy the ability to discover a trust      While this method works, it is very difficult to
path.                                              envision all necessary path constraint
                                                   needs—expressed either as path permitting
Transitive Trust                                   or path inhibiting rules—before cross-
When CAs cross-certify, the phenomenon of          certificate issuance. And, re-issuance of a
transitive trust comes into play.          Such    cross-certificate is not without its labor costs.
indirect trust may or may not be intended or       Revoking       previously     issued      cross-
welcomed.         An internationally oriented      certificates will also be necessary to force
illustration will make the side-effects clearer.   validation engines that pre-cache the
                                                   validation paths to refresh themselves.
Let us extend the example of the previous          More importantly, the need to restrict certain
section to include one additional cross-           trust paths is typically not realized until after
certificate pair.   Assume that the very           an “inappropriate” trust path is formed.
recently formed country of Forbiddenstan
has also cross-certified with the World Wide       Choosing the Proper Trust
Council for the purpose of discussing
commercial trade. Consequently, there is           Anchor
now a new trust path from the GI, through          Another challenge of a multiple cross-
the GBA, through a Neighboring Nation,             certificate environment is choosing the
through the World Wide Council, to                 correct trust anchor and certificate policies
Forbiddenstan. Let us also assume that             on which to filter. Complicating factors
"the United States maintains a broad               include:
embargo against trading with Forbiddenstan,
and most commercial imports from                       •   Asymmetrical policy mappings
Forbiddenstan are prohibited by law.” And              •   The possibility of multiple trust paths
finally, to ensure compliance with federal
    •   Unidirectional cross-certification          mappings found in the cross-certificate
        (e.g., a GBA may issue a cross-             issued by Algonk to the GBA, the State of
        certificate to a military to facilitate     Algonk views GBA Medium as mapping to
        GBA-centric trust path discovery, but       Algonk Level B.
        the military BCA may choose to not          Typically, the trust anchor of choice is a
        issue a cross-certificate to that GBA)      public key within one’s own issuing
Policy mappings are often placed in cross-          hierarchy. However, let us consider the
certificates for the purpose of declaring how       case were a centralized, organization-
the levels of assurances (LOAs) in the              independent validation service (employed
subject’s domain translate to the LOAs in           by a GBA) is being established to validate
the issuer’s domain. In order to make use           only certificates that are GBA Medium or
of these policy mappings, RFC3280                   equivalent. Let us examine two trust anchor
indicates that path discovery and validation        options and their implications.
algorithms must specify a trust anchor and a        If the trust anchor is a GBA root public key,
set of acceptable certificate policies (in the      then the certificate policy OIDs on which to
trust anchor’s domain). Additionally, if the        filter should be GBA Medium. In this case
initial set of acceptable certificate policies is   policy-filtered trust paths can be found from
a subset of those mapped, then the effect is        the GBA to (a) Algonk Level C certificates,
to filter out any trust paths involving             but not to other Algonk LOAs, and (b) any
certificates with LOAs that do not map to           other issuers' certificates that GBA maps to
that initial set.                                   GBA Medium LOA.
Consider the following example.          The        Alternatively, the validation service operator
(fictitious) State of Algonk has one CA (with       could reason that since Algonk certificates
one private key) issuing end-entity                 are validated so often, the dynamically
certificates with one of four levels of             discovered trust path for Algonk certificates
assurance (LOAs): Level A, Level B,                 should be made as short as possible for
Level C, and Level D. Independently, GSA            reasons of efficiency. To shorten the trust
has three LOAs: Small, Medium, and Large.           path, the trust anchor is chosen to be the
But when the State of Algonk cross-certified        State of Algonk’s root public key. Since the
with      the    GBA,     Algonk    submitted       GBA views only Algonk Level C certificates
documentation describing only their Level C         as equivalent to GBA Medium LOA, the
LOA, therefore the cross-certificate issued         initial set of acceptable certificate policy
by GBA to Algonk contains only one policy           OIDs is just the policy OID representing
mapping: Algonk Level C maps to GBA                 Algonk Level C. Obviously, trust paths will
Medium.                                             be found to Algonk Level C certificates.
Furthermore, the cross-certificate pair             However, the policy mapping in the Algonk-
between the GBA and the Algonk contains             issued cross-certificate (i.e., the cross-
asymmetrical policy mappings.           Why?        certificate going in the opposite direction)
Because each party’s Policy Authority (PA)          states that GBA Medium maps to Algonk
could independently evaluate the other              Level B. Since Algonk’s Level B certificate
party’s    Certificate    Policy/Certification      policy OID is not in the initial set of
Practice Statement (CP/CPS), and there is           acceptable certificate policies, no other
no guarantee the parties will view each             issuer's      certificates     mapping      to
other’s policies equally.     Consequently,         GBA Medium (as determined GBA’s point of
according to the policy mappings found in           view) will be accepted (i.e., no valid trust
the cross-certificate issued by the GBA to          path will be discovered for those
Algonk, the GBA views Algonk Level C LOA            certificates). And the configuration decision
as mapping to the GBA Medium LOA.                   complications increase as more BCAs
Conversely, according to the policy                 become involved.            It is therefore
recommended to explicitly state the                    browsers.
validation service’s acceptable certificate
                                                       For proper policy OID representation, one of
policy set—and not include the phrase “or
                                                       following two items must occur:
equivalent”—and       use     only      the
corresponding trust anchor.                                •   The new CR must assert all policy
                                                               OIDs of all subordinated CAs, or
In practice, such asymmetrical mappings
can be easily avoided. Both parties should                 •   The end-entity certificates of the
explicitly state and agree on how each of                      subordinated CAs must be re-issued
the applicant’s LOAs relates to the issuing                    to include the new CR policy OID
party’s LOAs. Continuing with our example,             Figure 3 depicts one phase of the proposed
when applying for cross-certification, the             hierarchy. Assume the GBA has previously
State of Algonk should explicitly request that         cross-certified with one of the commercial
the GBA PA map Algonk’s Level C LOA to                 vendor’s CAs (CVCA). The root CVCA has
GBA’s Medium LOA.                                      issued a proper subordinate CA A1, and A1
                                                       issues only special-audience end-entity
Post-Issuance CA                                       certificates. These end-entity certificates,
Subordination                                          when processed through the certificate
                                                       mappings in the GBA/CVCA cross-
One technique for reducing the number of               certificate, map to a GBA Medium LOA.
certificate bridges is to establish one root           Assume the common root, CR, was
under which all other certificates are issued.         subsequently cross-certified with the GBA.
Recently, there have been discussions of
establishing such a common root (CR) that              Then, in the final phase, the proposed
would subordinate existing commercial CAs              technique for demonstrating that A1
that meet government requirements.                     qualifies as a Scrutinized Provider is for the
                                                       CR to subordinate the CA A1. In practice,
A common root would also offer the                     this would result in a new subordinate CA
advantage of needing to distribute only one            A1*. A1 and A1* have the same public key
self-signed public key in popular web                  and subject DN (to validate the already-

                          CR                     GBA                   CVCA

                                                         A1*           A1

                               Figure 3: Subordinating Operational CA A1
existing end-entity certificates issued by A1),   A popular misconception in writing system
but different issuer DNs. This results in two     security plans (SSPs) is that when a BCA is
possible trust paths from the CR root to the      cross-certified with the root CA of a
A1-issued certificate:                            certificate issuer hierarchy, the BCA PMO is
                                                  required to see only the C&A report
   •   One directly from the CR through the
                                                  corresponding to the remote organization's
       subordinated A1* CA certificate, and
                                                  root CA, and that organization can be
   •   The second from the CR through the         trusted to silently perform C&As on their
       CR/GBA cross-certificate, through          internal hierarchy.      However, a careful
       the GBA/CVCA cross-certificate, and        review of NIST Special Publication (SP)
       finally through A1                         800-37, "Guide for the Security Certification
When processed through the second trust           and Accreditation of Federal Information
path, the policy mappings in the cross-           Systems,"       reveals     more     stringent
certificates will ensure the end-entity           requirements.
policies are properly mapped into the CR's        SP 800-37 defines a certification agent as
certificate policy OID space. However, in         "an individual, group, or organization
direct trust hierarchies, such as from CR         responsible for conducting a security
through A1* to the end-entity certificate, no     certification, or comprehensive assessment
policy mappings can take place. Therefore,        of the management, operational, and
A1-issued certificates must include two sets      technical security controls in an information
of certificate policy OIDs—one set for the        system to determine the extent to which the
CR policy name space, and the other set for       controls     are    implemented     correctly,
the CVCA policy OID space—thus reflecting         operating as intended, and producing the
A1's two superiors.                               desired outcome with respect to meeting the
Interestingly enough, if a relying party were     security requirements for the system."
given just the CR root, the subordinated A1*      (p.15) Additionally, SP 800-37 states that
CA certificate issued by the CR root, and an      since the certification agent "provides an
end-entity certificate issued by CA A1, the       independent assessment of the system
relying party would find a perfectly valid        security plan to ensure the plan provides a
hierarchical issuance path from the CR to         set of security controls for the information
the end-entity cert. However, if CVCA             system that is adequate to meet all
revoked A1 (say, due to a compromise of           applicable security requirements," the
A1's private key), and the organization           certification agent needs to be independent
behind CVCA did not notify the GBA                from:
Program Management Office (PMO), then
                                                     •   "persons directly responsible for the
the above direct trust path through A1*
                                                         development of the information
would still appear valid when, in reality, it
                                                         system and the day-to-day operation
should be declared as “revoked.”
                                                         of the system"
Therefore, extreme caution should be used            •   "individuals responsible for
if such a "two master" topology is used.                 correcting security deficiencies
                                                         identified during the security
Operations Policies                                      certification"
Typically, one focuses on technical and           Given a certification agent's independence
policy issues within one's own security           from the managerial and operational chains
domain.     In this section we consider           of a CA, the resulting report cannot remain
operations policies requirements such as          solely within the organizations chain of
Security Certification and Accreditation          command—the report must be delivered
(C&A).                                            externally.      The organization most
                                                  interested in and most impacted by such a
report is the BCA PMO, and therefore
should be the recipient of the certification
Therefore, the PMO of each BCA should
regularly see the C&As of every issuing CA
to which the BCA can form a trust chain.

As we have discussed, "bridging" for PKI
interoperability is not the panacea that many
thought it to be. It is extremely complex and
requires careful attention to detail. It is easy
to structure unintended and difficult-to-
detect consequences.         Such complexity
often results in significant opportunities for
undetected errors that the security
community often points out as exploitable
vulnerabilities.     We also implore each
organization to consider these inherent
issues when performing security C&A and
Certificate    Policy/Certification    Practice
Statement (CP/CPS) Compliance Audits.

NIST Special Publication (SP) 800-37,
“Guide for the Security Certification and
Accreditation       of     Federal      Information
RFC3280: “Internet X.509 Public Key
Infrastructure Certificate and Certificate
Revocation          List       (CRL)  Profile”