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

3. 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.

4. 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); Email signed applications to NIH.

5. 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.

6. 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

7. Participating Institutions University of Texas - Houston

8. 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.

9. 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 e-mail attachment (encryption to be tested at a future date); 8.NIH receives signed 398, downloads it, verifies and validates signatures, and initiates internal processing.

10. 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

11. 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

12. 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

13. 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 140-1 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

14. 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

15. Proof of Concept Directory Interoperability Configuration c=US; o=U.S. Government;ou=FBCA IP address:198.76.35.155 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: 207.123.140.5 DSP port:102 LDAP port: 389 TSEL:TCP/IP cn=nihstandin Chaining c=US; o=edu; ou=HEBCA IP address: 207.123.140.5 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: 208.30.65.30 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:

16. 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

17. 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.)

18. 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

19. 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

20. 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: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US path node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US path node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US path node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US path node: emailAddress=stillson@mitretek.org,CN=Mtek 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: 154368 10:22:19: timer: running recurring save-state and ICL clean-up

21. DAVE Server Startup Verification

22. 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

23. Proof of Concept – DAVE Log ------------------------------------ LOG STARTED: 10:11:59 > 10:11:59: startup... 10:12:00: Trust anchor subject DN: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US 10:12:00: listening on port 123 10:14:46: [0] saw request; aa_id=installed agency application (user should change this upon install) 10:14:46: Initial cert subject: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=US 10:14:46: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek 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: emailAddress=stillson@mitretek.org,CN=Mtek 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: emailAddress=stillson@mitretek.org,CN=Mtek 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: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US [tm=7, lm=f]

24. 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: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US 10:14:47: node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US 10:14:47: node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US 10:14:47: node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US 10:14:47: node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=US 10:14:47: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek 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: emailAddress=stillson@mitretek.org,CN=Mtek 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: emailAddress=stillson@mitretek.org,CN=Mtek 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

25. Proof of Concept – DAVE Log (cont’d) 10:14:47: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek 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: emailAddress=stillson@mitretek.org,CN=Mtek 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: emailAddress=stillson@mitretek.org,CN=Mtek 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: emailAddress=stillson@mitretek.org,CN=Mtek 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

26. 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.

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

28. 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)

29. 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

30. 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

31. 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!

32. Want More? Peter Alterman: peter.alterman@nih.govpeter.alterman@nih.gov Deb Blanchard: dblanchard@trustdst.comdblanchard@trustdst.com Monette Respress: mrespres@mitretek.orgmrespres@mitretek.org