[an error occurred while processing this directive]

Speaker Presentation
Preservation and Access for Electronic College and University Records
October 12 – 13, 2001

Public Key Infrastructure: Tools for trusting electronic records

Russ Savage

Mike Totherow


Public Key Infrastructure


What we mean by securing the electronic community —


Conceptually, how do we do this?


Electronic “community” evolution


The electronic community


Enter the electronic signature


Expectations of PKI:


Building trust for the electronic community


Elements of Public Key Infrastructure


Behind the “key” in public key infrastructure — the first idea of public/private key use was for encryption.
(eliminated the problems with shared secret encryption)

Several people can encrypt and send secure messages to Sam.
And only Sam can read them.
This is “Hi, only you can read this.”
(a.k.a. PKC - Public Key Cryptography)


Then it was noticed that switching the order of public/private key use led to identification.

Sam can encrypt and send unsecured messages to several people.
But they know it is from Sam.
This is “Hi, it’s really me.” (Internet Caller ID)


Light bulb —

Sam can send a message to Jean, who will know it is from Sam.
This is “Hi, I sent this (but somebody might have changed it).”


To solve the risk of a party between sender and receiver changing the message.

Sam can send a message to Jean. Jean will know it is from Sam and that the message has not been altered.
This is “Hi, I sent this and you know whether it was changed.”


Viola — an electronic signature on an electronic record…

(Arizona Statute 41-132 B)


The “infrastructure” in PKI

— “Guidelines for Public Key Infrastructure” by the American Bar Association


The Four Corner Model

How do you know the person is who he says he is?
     Verified by reputable source –
     Chain of trust (chain of reputable sources) –

Authenticating the person associated with a record is not the same as showing intent to sign or establishing integrity of a signing**

To build an electronic signature infrastructure, the community has:

** Depending on the policy of the community to which you belong


The Roles in Electronic Signature Use
(State of Arizona’s infrastructure model)


PKI Roles & Responsibilities


PKI Roles & Responsibilities


Certificate Policy is the zoning for construction


The Structure is formulated into Policy

Certificate Policy is the zoning plan

Zoning for Infrastructure is Summarized in CP

Issuance of Technology
Subscriber Party
Repository Control for access & maintenance
Relying Party

The ‘Certificate Policy’ might be called the ‘Contract of Process’


Public Key Infrastructure


PKI Certificate Policies


PKI cliff notes


Two Infrastructure pilots using the same CP


One size does not fit all

The Arizona Electronic Signature Infrastructure (AESI) consists of several collections of pilots (ESIs) organized around different Certificate Policies (CPs).


The “public” in PKI


DN (distinguished names) and OID (object identifiers)



OID Schema Reads like an Org Chart


Lightweight Directory Access Protocol

LDAP relies on DN and RDN (Relative Distinguished Name) to define unique entries in the directory schema.

The common elements for mapping between LDAP DN and OID alphanumeric assignments are:

The proposed policy in Arizona is that the registered OID alphanumeric arc is the LDAP DN.


Arizona a piece of global picture




Communities of Interest


Arizona Communities Grow


Reliance (Community Evidence)


Communities Cross Jurisdictions


(Global) Public Infrastructure takes Shape


So what does this do for e-records?


How do we assure accessibility by all parties?

Interoperability requires common document and signing standards across different communities

Documents may be “self-documenting” or “system documented records” — we’ll need a range of standards.

"This initial study led to a detailed description of the electronic record. We determined that an electronic record had to be a fully self-documenting object. We chose to describe these objects in eXtensible Markup Language (XML), a text based standard. We determined that an electronic record was made up of one or more documents, contextual information relating this record with other records, and evidential integrity checks."

Victorian Electronic Records Strategy Final Report

One Interoperability example is LegalXML which is establishing court document standards.


Example of System Documented Records

What is EDI?
Electronic Data Interchange (EDI) is the computer-to-computer exchange of business-related documents in a structured, machine process able format. These documents may be purchase orders, invoices, payment remittances and shipping notices between the State of Ohio and its "trading partners." A trading partner, in EDI parlance, is a supplier, customer, subsidiary or any other organization with which the state of Ohio does business. EDI differs from e-mail and fax. Although both of these methods of transferring documents are electronic, both are unstructured and free-form in the way they are presented. This means that information received via e-mail or fax must be re-keyed and reinterpreted before it can be processed by a computer application. EDI, on the other hand, requires that the information be organized in a structured format which can be easily interpreted and processed by a computer application.

Ohio — http://www.state.oh.us/ecedi/welcome.htm


Example of System Documented Records

How EDI Works — Briefly (Ohio continued)

EDI involves taking a standard computer flat file and reformatting the file into a structured EDI format. This format complies with specific industry standards. This reformatting process is performed by a specialized software program called an EDI translator.

Once the file has been put into a structured format, it is transmitted over telephone lines to a third party network. The third-party network called a Value Added Network (VAN) provides a service much like a post office. The VAN receives the transmitted documents and places these documents into an electronic mailbox for the receiving party to pick up. By dialing into the network, the receiving party can access its mailbox and retrieve the transmitted documents.

Once the electronic documents have been accessed by the receiving party, the documents once again can be processed through an EDI translator. The translator takes the documents, which are still in EDI format, and translates them into a standard computer flat file. This flat file then can be formatted into a report and printed out or sent directly into a company’s computer application for processing.


What does it take for system documented records?


What is inspected?


Paper is self documenting, so electronic self-documenting is the same. Right?
A copy of a paper document is a copy, whether it is another paper document or a digital image.

It is possible to send an original digital document to someone — while you keep the original of it.

There is no difference between them!


Self-Documenting Records

The validity of a copy of a paper document depends on the validity of the original (and that the copy hasn’t been altered).

The validity of a digital document depends on the tests it can pass — including whether it has been altered.

Since there is no copy, only a clone, those tests apply to the clone as well.


Self-Documenting Records

The validity of a copy of a signed paper document still depends on the validity of the original (and that the copy hasn’t been altered).

There is the extra complication that you could sign a copy which would add “legal standing” to the copy.
You could even make it a clone!

A digital signature wraps the document. The validity of the document depends on how you can test the wrapping such that its contents were not altered.


Self-Documenting Records

Keeping a “legal” digital image of a paper original usually requires an affidavit or oath that it is a true, unaltered copy.

Keeping a “legal” digital document requires being able, over time, to test the signature's validity and keeping the wrapped contents readable.


Records Management Guidance for Implementing Electronic Signature Technologies


If an electronically signed record needs to be preserved, then its trustworthiness over time needs to be assured.


Self Documenting record

Documenting integrity over time


System Documented Record

Documenting integrity over time


Trustworthy Records

Reliability — record content can be trusted as a full and accurate representation of the transactions, activities, or facts to which it attests and can be depended upon in the course of subsequent transactions or activities.

Authenticity — a record proven to be what it purports to be and to have been created or sent by the person who purports to have created and sent it.

Usability — a record that can be located, retrieved, presented, and interpreted. In any subsequent retrieval and use, the record should be capable of being directly connected to the business activity or transaction which produced it. It should be possible to identify a record within the context of broader business activities and functions. The links between records which document a sequence of activities should be maintained. These contextual linkages of records should carry the information needed for an understanding of the transaction that created and used them.


Trustworthy Records (cont.)

Integrity — a record being complete and unaltered.


Preserving Trustworthy Records

For a record to remain reliable, authentic, with its integrity maintained, and useable over the record life cycle, it is necessary to preserve its content, context, and sometimes its structure.

A trustworthy record preserves the actual content of the record itself and information about the record that relates to the context in which it was created and used (e.g. formatting of presentation).

Specific contextual information will vary depending upon the business, legal, and regulatory requirements of the business.

It also may be necessary to preserve the structure or arrangement of its parts. Failure to preserve the structure of the record will impair its structural integrity. That may undermine the record ’ s reliability and authenticity (e.g. Linking the parts of the record together — presentation organizational instructions such as what text with what graphic).


Preserving Trustworthy Records


* text largely from “Records Management Guidance for Agencies Implementing Electronic Signature Technologies” National Archives and Records Administration, Oct. 18, 2000


Preserving Trustworthy Records


* text largely from “Records Management Guidance for Agencies Implementing Electronic Signature Technologies” National Archives and Records Administration, Oct. 18, 2000


Preserving Trustworthy Records


* text largely from “Records Management Guidance for Agencies Implementing Electronic Signature Technologies” National Archives and Records Administration, Oct. 18, 2000


Preserving Trustworthy Records

All of the checks and balances (the evidentiary proof) in the paper world will need to be mimicked in the electronic world — the clerk stamps the filing on receipt, files a self-documenting, signed original paper record, and, when requested, a copy is stamped as a certified copy.

Some form of technical “non-repudiation” services must be implemented to protect reliability, authenticity, integrity and usability.

Essential elements:

Remember that you’re not alone, others need access to those documents and records. And they need assurance that you protected the reliability, authenticity, integrity and usability of those records.


Intentionally blank


It’s important to remember that you’re not alone, others need access to those documents & records.


Current Movements to address the inter-relationship of digital identity & electronic records lifecycle using PKI

For a record/document, we often need to:


Some of the current national, international and state PKI efforts


Federal Bridge CA (FBCA)


Federal PKI Policy Authority


What is ACES?

Access Certificates for Electronic Services (ACES) provides the American Public secure electronic access to privacy related Federal Government information and services through the use of public key technology.


Certificate Arbitrator Module (CAM)

What is CAM?

The Certificate Arbitrator Module (CAM) is an application-level router that efficiently and consistently routes certificates from relying party programs to the issuing certification authorities (CAs) for validation. By interfacing directly with the CAM, a relying party application will be able to interact seamlessly with multiple CAs.

Open Source (with some proprietary parts)

As of August 2001, the CAM source code is now available through our open source agreement. This web site will continue to be the sole distribution point for the official CAM used in the ACES program.


an international banking trust initiative via an interoperable PKI network


State Electronic Records and Signatures Reciprocity

United States Postal Service (USPS) certified e-mail

PosteCSTM works with Secure Sockets Layer (SSL) enabled browsers.

How it works for the sender

How It works for the Recipient


State Electronic Records and Signatures Reciprocity

NECCC E-SIGN Interoperability Workgroup and State Electronic Records and Signatures Reciprocity and Interoperability Issues

E-SIGN — Federal Electronic Signatures in Global and National Commerce Act


State Electronic Records and Signatures Reciprocity

Several States:

Work will be officially published at NECCC conference this December.


State Electronic Records and Signatures Reciprocity

Using an electronic signature means creating a signed electronic document.

The legality of an electronically signed record requires that it “remains accessible to all persons who are entitled to access by statute, regulation, or rule of law, for the period required by such statute, regulation, or rule of law, in a form that is capable of being accurately reproduced for later reference, whether by transmission, printing, or otherwise.” (emphasis added)

Federal Electronic Signatures in Global and National Commerce Act, Section101. (d)(1)(B)
(E-SIGN - interstate and international commerce)


State Electronic Records and Signatures Reciprocity

The Interoperability work group asked

“how do we get from technology neutral e-signatures statutes to agreement about what are sharable, trustworthy signed electronic documents (things that are reliable, usable, authentic, and having integrity)?”


State Electronic Records and Signatures Reciprocity

Secure electronic signatures

A signature is a secure electronic signature if, through the application of a security procedure, it can be demonstrated that the electronic signature at the time the signature was made was all of the following:


State Electronic Records and Signatures Reciprocity

Secure electronic records

If, through the ongoing application of a security procedure, it can be demonstrated that an electronic record signed by a secure electronic signature has remained unaltered since a specified time, the record is a secure electronic record from that time of signing forward.


State Electronic Records and Signatures Reciprocity

Proposed Process leading to Electronic Signature Reciprocity between States


State Electronic Records and Signatures Reciprocity

Framework for Electronic Signature Reciprocity

The Framework identifies appropriate implementations for basic, medium, and high trust levels as far as how the:

The trust levels are:


State Electronic Records and Signatures Reciprocity

Proposed Process leading to Electronic Signature Reciprocity between States


State Electronic Records and Signatures Reciprocity

Now some of mine can migrate to your place and some of yours can migrate to my place.

Still, they will need to be readable at both places.

Copy certification & electronic notary will evolve in the near future.


Thank you


Russ Savage

Mike Totherow


For those more interested


Digital Signatures (PKI)


PKI signature example

  1. Policy Authority defines the Certificate Policy for trusted network description
  2. Department as a relying party defines community of interest
    1. Decision: electronic signatures needed? - Digital Signature
    2. Chooses Certificate Policy
    3. Chooses Vendor off Approved Certification Authority List
      1. Department will act as RA
      2. Department (or community?) will archive certificates
      3. iVendor sells tool sets to subscribers
    4. Department creates application for community
  3. Subscriber visits Registration Authority (potentially Gov through contract) to register
    1. Subscriber verifies identity to RA
    2. CA issues digital signature to Subscriber
    3. Subscriber gets training from Vendor
    4. Subscriber installs tool set with Vendor support
  4. CA publishes public digital signature in Repository
  5. Subscriber uses application to commit transaction
    1. Signs document with issued digital signature
  6. Relying party receives document
    1. Verify integrity of transaction
      1. Verify signature against repository
      2. Check Certificate Revocation List (CRL)
    2. Updates database and stores transaction
      1. Information parsed and saved in db
      2. “document” stored for evidence
    3. Receipt sent to subscriber
    4. Relying party verifies receipt received


The Roles in Electronic Signature Use
(State of Arizona’s infrastructure model)


Life Cycle

While this describes PKI certificates, the need for application and renewal occurs for any identification process — you have to identify the applicant and periodically renew them


PKI Risk evaluation


Electronic Document by DS


[s01] <Signature Id="MyFirstSignature"
[s02] <SignedInfo>
[s03] <CanonicalizationMethod
[s04] <SignatureMethod
[s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06] <Transforms>
[s07] <Transform
[s08] </Transforms>
[s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[s11] </Reference> [s12] </SignedInfo>
[s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
[s14] <KeyInfo>
[s15a] <KeyValue>
[s15b] <DSAKeyValue>
[s15c] <P>...</P><Q>...</Q><G>...</G><Y>...</Y>
[s15d] </DSAKeyValue>
[s15e] </KeyValue>
[s16] </KeyInfo>
[s17] </Signature>

<xml version=1.0>


     <title>An Electronic Document</title>

     <Section style=paragraph>This is an example of a document.</Section>

     <Section style=paragrahp>Everything within the document tag is passed to the hash algorithm to create the hash. The hash is stored in the document under the signing block, and the digital signature certificate information is inserted to designate who "signed" the document.</Section>


<Signature Id="Mike Totherow" xmlns="http://repository.verisign.com/clm#1">


<Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
   <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
</Reference> [s12] </SignedInfo>


Email Digital Signature

Received: from femail18.sdc1.sfba.home.com ([]) by extra.sosaz.com with SMTP (Microsoft Exchange
Internet Mail Service Version 5.5.2650.21)
           id JFJH9NQG; Sat, 28 Apr 2001 13:39:06 -0700
Received: from cx74747a ([]) by femail18.sdc1.sfba.home.com
     (InterMail vM. 201-229-121-120-20010223) with SMTP
      id <20010428204109.yzee937.femail18.sdc1.sfba.home.com@cx74747a>
     for <mtotherow@sos.state.az.us>; Sat, 28 Apr 2001 13:41:09 -0700
Message-ID: <006101c0d023$2e530780$03019dc0@phnx3.az.home.com>
From: "Michael Totherow" <mtotherow@home.com>
To: "Michael Totherow" <mtotherow@sos.state.az.us>
Subject: This is a Signed Email
Date: Sat, 28 Apr 2001 13:38:20 -0700
MIME-Version: 1.0
Content-Type: multipart/signed;
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

This is a multi-part message in MIME format.

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit

Content-Type: application/x-pkcs7-signature;
Content-Transfer-Encoding: base64
Content-Disposition: attachment;