NIH-Educause PKI Pilot: Phase Two

NIH-Educause PKI Pilot:NIH-Educause PKI Pilot:Phase TwoPhase Two

Electronic Grant Application With Electronic Grant Application With Multiple Digital SignaturesMultiple Digital Signatures

Peter Alterman, Ph.D.Peter Alterman, Ph.D.Director of OperationsDirector of OperationsOffice of Extramural ResearchOffice of Extramural Research

The ProblemThe 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 DesignPhase 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.

Phase One Completed SuccessfullyPhase 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 GoalPhase 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 InstitutionsParticipating Institutions

University of Texas - Houston 

What’s Different About Phase Two? 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 OutcomePhase 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.

The MethodologyThe 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 RequirementsIntermediate 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)Phase Two Concept of Operations (CONOPS)

NIH OER Mail ServerUniversity A

University B

University C

Internet

E-LockAssured OfficeDigital Signed

Grant Appl

E-LockAssured OfficeDigital Signed

Grant Appl

E-LockAssured OfficeDigital Signed

Grant Appl

NIH OER Recipient

E-LockAssured OfficeDigital Signed

Grant Appl

E-LockAssured OfficeCAM-enabled

NIH CAM Server

FBCA

HEBCA

CertStatus

CertStatus

Certificate ValidationUniversity B

Certificate ValidationUniversity A

Certificate ValidationUniversity C

Proof of Concept ArchitectureProof of Concept Architecture

NIH User

NIH Trust Domain

NIH TestCA

Directory

Higher Education Trust Domain

DirectoryDST ARP Test CA

Firewall

Prototype Federal Bridge Certificate Authority

Cross CertifiedCAs

Directory System Agent

• Cross certificates• CRL

FIP 140-1 L3 Crypto

FIP 140-1 L3 Crypto

• Cross certificates• CRL

• Cross certificates• ARL

RSA CA Entrust CA

iPlanet CA

Alabama

RSA CA

i500Directory

California

Verisign CA

Wisconsin

Texas

Dartmouth

Proof of Concept CA Interoperability Proof of Concept CA Interoperability ConfigurationConfiguration

Entrust CA RSA 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 Proof of Concept Directory Interoperability ConfigurationInteroperability Configuration

c=US; o=U.S. Government;ou=FBCAIP address: 198.76.35.155DSP port: 102LDAP port: 389TSEL: TCP/IP

Prototype FBCA(Peerlogic)

cn=FBCA_Directory

NIH

c=US; o=U.S. Government; ou=NIH IP address: 207.123.140.5DSP port: 102LDAP port: 389TSEL: TCP/IP

cn=nihstandin

Chaining

c=US; o=edu; ou=HEBCAIP address: 207.123.140.5 DSP port: 102LDAP port: 389TSEL: TCP/IP

HEBCA(Critical

Path)

cn=HEBCA

Alabama

cn=ARP Test Client CA

California, Texas

cn=

Wisconsin, Dartmouth

cn=

Chaining

Chaining

c=US; o=Digital Signature Trust Co; ou=ARP Testing IP address: 208.30.65.30DAP/DSP port: 102LDAP port:389

c= ; o= ; ou= IP address:DAP/DSP port:LDAP port:

c= ; o= ; ou= IP address:DAP/DSP port:LDAP port:

NIHca

trustanchor

““DAVE” DAVE” (Discovery and Validation Engine)(Discovery and Validation Engine)

sender(UA)

receiver(NIH)

NIHdirectory

FBCA

FBCAdir

crosscert

crosscert

DAVECAM

E-Lock

software

ca

directory

HEBCA HEBCAdir

crosscert

UAca

UAdir

issued

get Cert,CRLvia directory chaining

DAVE ComponentsDAVE 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 DetailsVerification & Validation Details

CAM Server Certificate Authority/Validation Request

CAM/CA

OCSP

MsgData

Discovery andValidation

Engine(DAVE)

Agency App/CAM

Search for issuer to validate• CRL• OSCP Responder

If chained, path reversesIf not chained, LDAP queries

Agency App =E-Lock

Assured OfficeCAM-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 RequestCAM Log – Startup and Status Request

1. CAM Sees the Request from the Agency Application, e.g. E-Lock Assured Office2. 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 path4. If the node in the cert path is found, a status of “0” (valid) is returned to the application

Proof of Concept - CAM LogProof of Concept - CAM Log------------------------------------LOG STARTED: 10:12:19<< DATE: 10/26/2001 >>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: [email protected],CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=USpath node: [email protected],CN=Mtek stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=USpath node: [email protected],CN=Mtek stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=USpath node: [email protected],CN=Mtek stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=USpath node: [email protected],CN=Mtek stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=USValidation: 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

DAVE Server Startup VerificationDAVE Server Startup Verification

DAVE Server – Path DAVE Server – Path Discovery and Status ReturnDiscovery and Status Return

1. Path discovery – this is the validation phase as CRLs are retrieved2. If the CRL is retrieved, a status of “0” (valid) is returned to the CAM

Proof of Concept – DAVE LogProof of Concept – DAVE Log------------------------------------LOG STARTED: 10:11:59<< DATE: 10/26/2001 >>10:11:59: startup... 10:12:00: Trust anchor subject DN: [email protected],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: [email protected],CN=Mtek stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=US 10:14:46: dave-get-request: [email protected],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: [email protected],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-answer: retrieved CA cert from LDAP database 10:14:46: dave-get-request: [email protected],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-answer: retrieved CA cert from LDAP database 10:14:46: dave-get-request: [email protected],CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US [tm=7, lm=f]

Proof of Concept – DAVE Log Proof of Concept – DAVE Log (cont’d)(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: [email protected],CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US 10:14:47: node: [email protected],CN=Mtek stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US 10:14:47: node: [email protected],CN=Mtek stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US 10:14:47: node: [email protected],CN=Mtek stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US 10:14:47: node: [email protected],CN=Mtek stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=US 10:14:47: dave-get-request: [email protected],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: [email protected],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: [email protected],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 10:14:47: dave-get-answer: retrieved user cert from client database

Proof of Concept – DAVE Log Proof of Concept – DAVE Log (cont’d)(cont’d)

10:14:47: dave-get-request: [email protected],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: [email protected],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: [email protected],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: [email protected],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

Development Status Development Status (as of Friday, (as of Friday,

10/26/2001)10/26/2001)

• Representative Directory Structures;– Cross-certs issued: NIH-stand-in*FBCA,

FBCAHEBCA, HEBCAARP 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 End-to-end Directory Chaining In Place:DITS for all 4 Directories Appear On One PC - NIH, HEBCA, FBCA, Directories Appear On One PC - NIH, HEBCA, FBCA, and DSTand DST

Issues and ResolutionsIssues 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)

ObservationObservation

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 Issuing CAcross-certifies with HEBCA

cross-certifies with FBCA (as

NIH trust anchor)

UAB end-entity certs

NIH end-entity certs

Current Development FocusCurrent 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 StepsNext 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?Want More?

• Peter Alterman: [email protected]

• Deb Blanchard: [email protected]

• Monette Respress: [email protected]