Bridge-to-Bridge Working Group (BBWG)

1. Bridge-to-Bridge Working Group (BBWG) Debb Blanchard, Cybertrust EDUCAUSE Federal and Higher Education PKI Coordination Meeting June 16, 2005 The Fairmont Hotel Washington, DC

2. Agenda • Purpose and Goals of BBWG • Bridge Certification Authority Participants • Issues and Status • Conclusion

3. Purpose and Goals Purpose • To provide a mechanism to gather input from the communities of interest, and identify, vet, resolve and document all technical and policy related issues associated with cross-certification of BCAs. Goals • Interoperability, collaboration and trust with other BCAs • Trust that the other BCA will manage and map its policies in strict accordance with the policy advertised by that BCA and will properly manage the cross-certified relationships between that BCA and the Participating CAs within that community of the BCA

4. Bridge Certification Authority Participants • Federal Bridge Certification Authority • PKI cross-certification and interoperability issues within the US Federal Government - specifically, between US Federal Government agencies deploying their own PKIs. • Will also cross-certify with commercial entities if a BCA is not available for that community • Is cross-certifying with foreign governments, e.g., UK MOD, Australia, Government of Canada • Higher Education Bridge Certification Authority • To facilitate trusted electronic communications within and between institutions of higher education as well as with federal and state governments to facilitate trusted electronic communications within and between institutions of higher education as well as with federal and state governments • Secure Access for Everyone (SAFE) • The BioPharmaceutical Industry standard and infrastructure services necessary to support unique electronic identity (eIdentity) credentials, enabling legally enforceable & regulatory compliant digital signatures, for business-to-business and business to regulator transactions • CertiPath • Design, implement, maintain and market a secure public key infrastructure communications bridge, initially focused on the aerospace and defense industry. • To enable the transfer of secured and authenticated information globally between subscribing companies; and between such companies and a number of domestic and foreign government agencies

5. Issues and Remedies Issues • Policy Mapping • Charter Disclosure Statements • Audit Requirements • Governance • Common lexicon • Compliance with open standards • Liability • Trusted Roles and Citizenship.

6. Policy Mapping • Involves the comparison of CA Certificate Policies to determine whether the assurance offered by the two policies is comparable • Other documentation that is needed: • Mapping methodology used by the policy authority of the BCA used to determine the requirements of the Participating CAs that comprise that BCA • The charter of rules or charter disclosure statement for a BCA determines the rules and business procedures and processes under which a BCA operates • Audit results of the BCA Status – on hold while waiting for the results of the Audit and Legal sub-working group and Citizenship results

7. Charter disclosure statements • Charter Disclosure Statement should declare the business of the BCA and should be audited • Need to identify: • Purpose of the BCA • Organizational structure of the BCA including separation of operational and policy responsibilities • Liability framework • Policy authority and governance structure • Contract infrastructure (e.g., relying party and subscriber agreements, insurance policies) • General operational environment (i.e., the communities of interest in which the applicant BCA participates either directly and indirectly).

8. Charter Disclosure Statements (contd) • Issues that need to be addressed in the charter are, but not limited to: • If a Participating CA leaves a BCA, identification of the process for notification of other BCAs and Participating CAs for the certificate path processing needs to be outlined. • The dispute procedure that is included in the MOA with specifics that address how a federation or BCA does business to notify others.. • The perceived need for entities to have visibility into the CPSs and audit results of specific PKIs beyond their BCA domain, including the potential for PKIs hanging off of inter-connected BCAs, e.g., DoD to have visibility into the CPS of HEBCA as well as the CPS of Duke University, assuming that HEBCA is fully cross-certified with the FBCA • Charter Disclosure Statement should be audited Status - on hold while waiting for the results of the Audit and Legal sub-working group and Citizenship results

9. Governance • BCAs are autonomous peers that agree to interoperate contractually within the context of laws of international commerce and the laws of the nation within which it operates • BCA approach uniquely brings policy and technical cohesion (or governance), as well as trust promulgation to otherwise autonomous and independent entities, without enforcing a strict hierarchy. Governance structures and the extent of the authority of a particular BCA could be vastly different and incompatible with that of another BCA. This is true in large part because the governance mechanism is a reflection of the interest and characteristics of the community. • The governance of the BCA should address how it does business and how it is governed Status - on hold while waiting for the results of the Audit and Legal sub-working group and Citizenship results

10. Audit Requirements • Standards do not exist for performing audits for a BCA • BBWG created a sub-committee to determine the standards for auditing a BCA. The work of that sub-committee is still on-going • Recommendations to include the following: • the requirements for the persons who will be performing the audit, • the documents that are needed to support the auditors, • the audit standards for a Bridge-to-Bridge environment • Auditing needs to be done at 2 levels: • first at the CP and CPS • second the actual steps for completing the annual audit of the BCA • Need to cover policy mapping • Audits and their results are not solely for Bridge-to-Bridge certification, but to also allow the participating CAs to review the operations of their bridges and to review the accreditations of external bridges with which their bridge will/may/have cross-certified Status - Work is still on-going in this area

11. Common Lexicon • Each community of interest tends to define its lexicon in a language that the community understands. • In a Bridge-to-Bridge environment, definitions and terminology should be included as part of the mapping methodology • Necessary to facilitate common terms of reference and to provide a common lexicon. • In an attempt to put together definitions for the Bridge-to-Bridge environment, members of the group synthesized definitions and terminology from a variety of sources Status • A couple of definitions need to be included. • For the most part, this list is complete as of 1/2005.

12. Compliance with Open Standards • Need for BCAs to insist on full compliance to open standards. • Too many vendors do not implement the full standards thereby causing a deterrent to interoperability. • Vendors also tend to “bend” standards to create rule-sets which create a closed community, thus, making interoperability difficult if not impossible. • Standards need to be identified from the National Institutes of Standards and Technology (NIST) as well as the IETF, ISO, and European Union to allow for Bridge-to-Bridge interoperability in a global environment. Status - Standards identified for PKI for the group and seem to be complete as of 1/2005

13. Liability • An important issue that would not necessarily show up when mapping Certificate Policies. Liability concerns do need to be addressed early in the formation of the BCA • Situations need to be compared for each of the BCAs, which include limits on liability and an appropriate indemnification clause where possible • Within the context of a BCA, liability does not exist with data management. Liability is addressed in the internal processes and may be a way of managing risk • Different liability issues exist depending upon the community - the Federal government versus the commercial private sector and the types of liability, such as contractual liability, negligence liability, and strict liability. The subtlety of these liabilities as they pertain to the Bridge-to-Bridge environment needs to be discussed further • The MOA between these entities should explicitly disallow waivers to the CP/CPS and to the MOA itself Status - Work is still on-going in this area.

14. Trusted Roles and Citizenship Status/Resolution Update (as of 6/3/2005) per FBCA • Creating two new policies, with OIDS, termed medium-cbp and medium hardware-cbp (for “commercial best practice”).  These two new policies will be identical to the existing medium and new medium hardware except for the absence of any mention of citizenship of trusted operators.  Medium-cbp and medium hardware-cbp are considered by the FPKI PA as identical in trustworthiness to the existing medium and new medium hardware. • All policies will include re-defined requirements for trustworthiness, loyalty and integrity, and all four medium policies will have the identical TLI requirement.  The current medium and new medium hardware will include language that addresses the citizenship requirements for CAs run in foreign countries and CAs run by multinational entities.  Note: this language will NOT be in medium-cbp or medium hardware-cbp, which are citizenship-blind policies. • FBCA will drop the citizenship requirement for trusted operators from Rudimentary and Basic Assurance levels

15. Trusted Roles and Citizenship (contd) Status/Resolution Update (as of 6/3/2005) per FBCA • FBCA has not at this time chosen to create a high-cbp policy since the government’s EAuthentication Initiative has defined medium hardware (and the proposed medium hardware-cbp) as satisfying the requirements for EAuthentication Level 4 (highest level) for all eGov applications.  This means that in practice no external entity will ever be required to have a high assurance certificate to do business with an eGov application. • Any PKI, or bridge, may run at high assurance without cross-certifying with the Federal Bridge at high assurance.  So, for example, if FBCA cross-certifies with HEBCA at medium hardware-cbp, any PKI cross-certified with HEBCA at that LOA or better would see its credentials accepted by any eGov application, all the way up to Level 4, the highest • FBCA will cross-certify at a High LOA with only other another government entity.  Therefore, HEBCA and FBCA both run at high but FBCA cross-certifies with HEBA at medium hardware-cbp.  FBCA is required to do this to avoid certain international trade policy problems Next steps – this is awaiting final confirmation by the FPKI CPWG and membership agencies

16. Conclusion • A lot of work has been completed to date on Bridge-to-Bridge interoperability, yet more needs to be done. • Technical issues, such as name constraints and certificate path validation, need to be considered. However, because these technical issues also impact other interoperability areas, such as applications and authorizations, they are not addressed by the BBWG. • At the core, foundation of all of this is: • the identity proofing and vetting of individuals by organizations • the impact of HSPD-12 and FIPS 201 across the entire infrastructure

17. Questions?

18. Debb Blanchard, Cybertrust Senior Program Specialist Former Chair, BBWG Deborah.Blanchard@cybertrust.com Office-1: 443-367-7011 Office-2: 410-871-0836 Cell: 410-259-0624 Dr. Peter Alterman, NIH Chair, FPKI PA Peter.Alterman@nih.gov Office: 301-496-7998 Cell: 301-252-8846 Mark Luker, EDUCAUSE Vice President mluker@educause.edu Office: 202-872-4200 Steve Worona, EDUCAUSE Director of Policy and Networking Programs sworona@educause.edu Office: 202-872-4200 For More Information