NIH-Educause PKI Pilot: Phase Two Electronic Grant Application With Multiple Digital Signatures Peter Alterman, Ph.D. Director of Operations Office of Extramural Research

The Problem NIH receives over 40,000 applications for new grants annually. Each application averages over 40 pages long; 20 copies of each are often required; each application must be duplicated and sent to over a dozen reviewers. Do the math. While NIH has been developing strategies to convert paper to electronic processes, good solutions to the problem of electronic signature implementation have been lacking; Institutions are busy deploying PKIs and issuing digital certificates to their faculties and staffs.

Phase One Conceptual Design Create electronic versions of grant application form; Distribute TrustID digital certificates; Distribute E-Lock Assured Office to affix verify two different certificates to dummy electronic applications (business process requirement); signed applications to NIH.

Phase One Completed Successfully Multiple MS Word templates signed with two different digital certificates received from UW-Madison, UA- Birmingham and Dartmouth College; ACES Certificate Arbitration Module (CAM) installed and configured at NIH; E-Lock Assured Office, CAM-aware, installed and configured at NIH and at Institutions; All certificates verified and validated two ways by NIH: directly to the DST OCSP Responder and indirectly through the CAM.

Phase Two Goal Receive application in electronic form signed with two different, validated, digital certificates each digital certificates issued by Institution several different vendors represented

Participating Institutions University of Texas - Houston

What’s Different About Phase Two? Institutions use certificates they issue; Verify and validate digital signatures through ACES Certificate Arbitration Module (CAM); Trust path discovery uses Federal Bridge CA cross-certified with Higher Education Bridge CA, creating an Internet-based trust infrastructure; Use of multiple certificate providers tests interoperability within standards.

Phase Two Target Outcome 1.P.I. logs on to Internet at his/her workstation; 2.P.I. links to NIH website and downloads electronic application form (PHS 398) – grants.nih.gov/grants/oer.htm; 3.P.I. fills out 398 at workstation; 4.P.I. forwards signed 398 to AOR; 5.AOR completes and signs it using his/her Institution-issued digital certificate; 6.P.I. Signs completed 398 with his/her Institution-issued digital certificate; 7.P.I. Mails the signed 398 to NIH as an attachment (encryption to be tested at a future date); 8.NIH receives signed 398, downloads it, verifies and validates signatures, and initiates internal processing.

The Methodology Build upon the results of Phase 1 Create a controlled environment for proof of concept –Definition: Performed in a test laboratory environment to prove that the concepts and technologies to be utilized can be implemented Transition the controlled environment of the proof of concept into a controlled pilot –Definition: Performed outside of the test laboratory to better simulate real-world situations

Intermediate Requirements (NIH cross-certifies “its” CA with the FBCA) Stand up a Higher Education Bridge Certification Authority (HEBCA); Cross-certify the Federal Bridge CA with the Higher Education Bridge CA; Institutions configure directories, cross- certify their CAs with the HEBCA

Phase Two Concept of Operations (CONOPS) NIH OER Recipient E-Lock Assured Office Digital Signed Grant Appl E-Lock Assured Office CAM-enabled NIH CAM Server FBCA HEBCA Cert Status Cert Status Certificate Validation University B Certificate Validation University A Certificate Validation University C

Proof of Concept Architecture NIH User NIH Trust Domain NIH Test CA Directory Higher Education Trust Domain Directory DST ARP Test CA Firewall Prototype Federal Bridge Certificate Authority Cross Certified CAs Directory System Agent Cross certificates CRL FIP L3 Crypto Cross certificates CRL Cross certificates ARL RSA CA Entrust CA iPlanet CA Alabama RSA CA i500 Directory California Verisign CA Wisconsin Texas Dartmouth

Proof of Concept CA Interoperability Configuration Entrust CARSA CA Prototype Federal Bridge Certification Authority NIH NIH Test CA Client Wisconsin Client Higher Education Bridge Certification Authority RSA CA Texas VeriSign CA Client Alabama DST ARP Test CA Client iPlanet CA Dartmouth Client California VeriSign CA Client Entrust CA

Proof of Concept Directory Interoperability Configuration c=US; o=U.S. Government;ou=FBCA IP address: DSP port:102 LDAP port:389 TSEL: TCP/IP Prototype FBCA (Peerlogic) cn=FBCA_Directory NIH c=US; o=U.S. Government; ou=NIH IP address: DSP port:102 LDAP port: 389 TSEL:TCP/IP cn=nihstandin Chaining c=US; o=edu; ou=HEBCA IP address: DSP port:102 LDAP port:389 TSEL:TCP/IP HEBCA (Critical Path) cn=HEBCA Alabama cn= ARP Test Client CA California, Texas cn= Wisconsin, Dartmouth cn= Chaining c=US; o=Digital Signature Trust Co; ou=ARP Testing IP address: DAP/DSP port:102 LDAP port:389 c= ; o= ; ou= IP address: DAP/DSP port: LDAP port: c= ; o= ; ou= IP address: DAP/DSP port: LDAP port:

NIH ca trust anchor “DAVE” (Discovery and Validation Engine) sender (UA) receiver (NIH) NIH directory FBCA dir cross cert cross cert DAVECAME-Lock software ca directory HEBCA dir cross cert UA ca UA dir issued get Cert,CRL via directory chaining

DAVE Components CML Libraries [Getronics] ASN1 parsing (SNACC) S/MIME parsing (SFL) Cryptographic engine LDAP and local directory retrieval (SFL) Path discovery engine (CPL) DAVE Functions Perform proper sequential calling of CML functions (i.e., the business logic) Provide call-back functions needed by CML functions Provide all CAM communications and protocol transformations Wraps CML functions into an NT service (multithreaded, failure and recovery modes, logging, etc.)

Verification & Validation Details CAM Server Certificate Authority/ Validation Request CAM/CA OCSP Msg Data Discovery and Validation Engine (DAVE) Agency App/ CAM Search for issuer to validate CRL OSCP Responder If chained, path reverses If not chained, LDAP queries Agency App = E-Lock Assured Office CAM-enabled Passing Certificate E-Lock Assured Office verifies the signature Verifies the document has not been changed Verifies the validity period of the certificate Once verified, the certificate is sent to the CAM for certificate validation to ensure that it has not been revoked

CAM Log – Startup and Status Request 1.CAM Sees the Request from the Agency Application, e.g. E-Lock Assured Office 2.If the request is not an ACES request, it is sent to the Discovery and Validation Engine (DAVE) 3.DAVE responds by listing the nodes in the trust path 4.If the node in the cert path is found, a status of “0” (valid) is returned to the application

Proof of Concept - CAM Log LOG STARTED: 10:12:19 > 10:12:19: CAM server startup 10:12:20: listener: holding to receive request #0 10:14:45: listener: holding to receive request #1 10:14:45: [0] validation request from AA: installed agency application (user should change this upon install) 10:14:46: [0] validate: serial: serial_number:01 10:14:46: [0]: validate: using default validation method 10:14:46: [0]: validate: CA found: link:localhost:123 10:14:46: [0] verification deferred to linked CAM 10:14:47: CA MESSAGE: path node: stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US path node: stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US path node: stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US path node: stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US path node: stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=US Validation: usage=74e058, usageCrit=0 10:14:47: [0] validate: status: 0, aces code: 0x1600) 10:14:47: [0]: periodic memory tracking : memory usage is: :22:19: timer: running recurring save-state and ICL clean-up

DAVE Server Startup Verification

DAVE Server – Path Discovery and Status Return 1.Path discovery – this is the validation phase as CRLs are retrieved 2.If the CRL is retrieved, a status of “0” (valid) is returned to the CAM

Proof of Concept – DAVE Log LOG STARTED: 10:11:59 > 10:11:59: startup... 10:12:00: Trust anchor subject DN: stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US 10:12:00: listening on port :14:46: [0] saw request; aa_id=installed agency application (user should change this upon install) 10:14:46: Initial cert subject: stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=US 10:14:46: dave-get-request: stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US [tm=7, lm=8] 10:14:46: dave-get-answer: retrieved CA cert from LDAP database 10:14:46: dave-get-request: stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US [tm=7, lm=8] 10:14:46: dave-get-answer: retrieved CA cert from LDAP database 10:14:46: dave-get-request: stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US [tm=7, lm=8] 10:14:46: dave-get-answer: retrieved CA cert from LDAP database 10:14:46: dave-get-request: stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US [tm=7, lm=f]

Proof of Concept – DAVE Log (cont’d) 10:14:46: dave-get-answer: retrieved CA cert from LDAP database 10:14:47: successfully build trust path 10:14:47: node: stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US 10:14:47: node: stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US 10:14:47: node: stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US 10:14:47: node: stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US 10:14:47: node: stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=US 10:14:47: dave-get-request: stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US [tm=18, lm=f] 10:14:47: dave-get-answer: retrieved CRL from LDAP database 10:14:47: dave-get-request: stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US [tm=18, lm=f] 10:14:47: dave-get-answer: retrieved CRL from LDAP database 10:14:47: dave-get-request: stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US [tm=7, lm=f] 10:14:47: dave-get-answer: retrieved user cert from client database

Proof of Concept – DAVE Log (cont’d) 10:14:47: dave-get-request: stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US [tm=7, lm=f] 10:14:47: dave-get-answer: retrieved user cert from client database 10:14:47: dave-get-request: stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US [tm=18, lm=f] 10:14:47: dave-get-answer: retrieved {special type} from client database 10:14:47: dave-get-request: stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US [tm=18, lm=f] 10:14:47: dave-get-answer: retrieved CRL from LDAP database 10:14:47: dave-get-request: stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US [tm=18, lm=f] 10:14:47: dave-get-answer: retrieved CRL from LDAP database 10:14:47: validation successful 10:14:47: Validation: usage=74e058, usageCrit=0 10:14:47: [0] answered with status: 0

Development Status (as of Friday, 10/26/2001) Representative Directory Structures; –Cross-certs issued: NIH-stand-in*  FBCA, FBCA  HEBCA, HEBCA  ARP Test (DST) Also have fully working test environment with temporary stand-ins for all 4 CAs –Corresponding directory chaining and cross references –NIH-stand-in is DAVE’s trust anchor, and is only directory DAVE speaks to directly –Directory clock synchronization Correct CA cert retrieval, directory traversal, and cross-cert retrieval; Correct communications with CAM.

End-to-end Directory Chaining In Place:DITS for all 4 Directories Appear On One PC - NIH, HEBCA, FBCA, and DST

Issues and Resolutions Directory Structures and Services –Issue: No underscores in DNs (CML altered) –Issue: Some directories change binary data upon import and upon return via chaining agreements!!! Resolution: Some certs changed to indefinite length ASN1 encoding. Temporarily solved via another version of the I.500 directory. Resolution: PKCS7 cross-cert pairs stripped of certain ASN1 sets. Temporarily solved via same directory and by loading each individual cross-cert pair element in cACertificate attribute (not combined in the crossCertificatePair attributes)

Observation DST Business Model Common elements in PKI domains negate need to traverse bridges –CML goes up issuing chain, finds cross-cert with FBCA, correctly recognizes UAB end- entity cert and NIH trust anchor in same PKI domain, bypasses HEBCA bridge –This is correct PKI functionality, not a problem Self-Signed Root Non-issuing CA Issuing CA cross-certifies with HEBCA cross-certifies with FBCA (as NIH trust anchor) UAB end-entity certs NIH end-entity certs

Current Development Focus To move from Proof of Concept to Pilot: –Path traversal and discovery always works! However, the CPL occasionally does not recognize that it has discovered the complete path (works with test CAs and test certs). –Some CRLs are not parsed correctly by the CML –The CML may or may not be able to parse a true cross-cert pair (not yet attempted) –Expansion of the interface from the CAM to the Agency Application to utilize OCSP extensions

Next Steps Complete Development and Test of DAVE and CAM and have all working bits talking to each other in recognizable language; Replace Stand-in CAs and Directories with Institutions’ CAs and Directories; Verify and Validate Institution-issued digital signatures on electronic grant applications; Go out and celebrate!

Want More? Peter Alterman: Deb Blanchard: Monette Respress: