powerpoint presentation - public key infrastructure tools for the

Public Key InfrastructurePublic Key InfrastructureTools for trusting electronic records

Russ Savage Mike [email protected] [email protected]

Public Key Infrastructure• What is it and What does it do for us?

– Not a new concept– Means to control electronic access– Evolved as networking evolved from

the dumb terminal, to networks to the internet traffic of today…

What we mean by securing the electronic community -

• Minimize threats:– Interception– Impersonation– Alteration– Unauthorized access– Denial of Service

Conceptually, how do we do this?

• Draw a perimeter• Identify those that can enter • Keep others out• To Protect the contents within the perimeter

– control who can change (update) the contents within the perimeter

Electronic “community” evolution• Access control lists• Network domains• Universal Naming Convention• X.500

– Novell Directory Services– X.509 certificates– Microsoft Active Directory– LDAP

The electronic community

• Establishes the identity of the elements of the community – Identification– Authentication– Authorization

Enter the electronic signature• Laws now recognize electronic signature

– E-Sign– Uniform electronic Transactions Act (state level)

• The twist…– Now e-signatures become part of (or related to) the document– Creates an inter-relation of digital identity and record lifecycle– Beyond electronic community, It’s also the product of the community– Electronic records!

Expectations of PKI:• electronic identity• electronic locations & devices within the e-community• ensuring integrity in documents• Access, authorization and control

Building trust for the electronic community

• Define the Trust in the community– Only authorized access to the system (community)?– Do I trust the documents stored in the system

(community)?– Don’t allow unauthorized access to my stuff– Don’t allow unauthorized change to my stuff– Don’t let them do it and say they didn’t– Don’t let them stop my work

• Create a hierarchal chain of trust that ensures validation of the product and verifies my records

Elements of Public Key Infrastructure

• The Key– Asymmetric cryptographic keys

• The Infrastructure– Roles, relationships and responsibility

• The Public– Open design and accessibility– Interactions with

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)

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)

Encrypt Decrypt

Encrypt

Encrypt

PlaintextCiphertext

Plaintext

Plaintext

Plaintext

Ciphertext

Ciphertext

Sam'sPrivate

Key

Sam'sPublicKey

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)

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

Encrypt DecryptCiphertext

Plaintext

Ciphertext

Ciphertext

Decrypt

Decrypt

Plaintext

Plaintext

Plaintext

Sam'sPrivate

Key

Sam'sPublic

Key

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

Light bulb -

Signature

plaintextplaintext

document

Sign

plaintextdocument

VerifyVerifies?(yes/no)

Sam(Originator/Signer)

Betty(Recepient/Relying Party)

Sam'sPrivate

Key

Sam'sPublicKey

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.

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

Message

Signature

Digest

Encrypt

Hash Function

ActualDigest

Message

ExpectedDigest

Decrypt

Hash Function

If these are the same,the signature is verified

SignatureMessage

PrivateKey

PublicKey

Viola – an electronic signature on an electronic record… unique to the person using it, capable of reliable verification and linked to the record in a manner so that if the record is changed the electronic signature is invalidated.

(Arizona Statute 41-132 B)

Message

Signature

Digest

Encrypt

Hash Function

ActualDigest

Message

ExpectedDigest

Decrypt

Hash Function


SignatureMessage

PrivateKey

PublicKey

The “infrastructure” in PKI– “Guidelines for Public Key

Infrastructure” by the American Bar Association • Defines Roles• Defines Responsibilities• Defines Relationships• Defines Liability

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:

• Policy Authority establishing the planning and zoning for the infrastructure

• Certification Authority registering the subscriber & issuing digital certificates

• Community, or sub-communities, contracting with the CA for services.

• Subscriber getting a certificate to have a digital signature.

•(Citizen of the electronic community)

• Relying Party verifies the digital signature received from the subscriber.** Depending on the policy of the community to which you belong

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

(Sec State)

PKI Roles & Responsibilities• Subscriber

– “subject”/holder of the signature– Subscriber Agreement (policy, contract)– keep signature private (sole control)

• Relying Party– party whose application requires

signature validation– Relying Party agreement (policy,

contract)

PKI Roles & Responsibilities• Certification Authority

– Operates mechanisms of PKI– Registration Authority

• Verify identity of applicants to become subscribers (in-person)– Issuance

• Manufacture and issue electronic signatures• Ensure subscriber possession of electronic signature

– Frequent Compliance Audits– Liability / Contract intensive function

• Repository– Maintain electronic signatures integrity– secure facilities, with public access

Certificate Policy is the zoning for construction

• Outlines the roles• Describes the responsibilities and liabilities• Limits the scope of application• Determines location within Infrastructure• Establishes the trust amongst the community

Certificate Policy is the zoning planZoning for Infrastructure is Summarized in CPPolicyIssuance of TechnologySubscriber PartyRepository Control for access & maintenanceRelying Party

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

E-mail or otherElectronically Signed

DocumentSubscriberRelying

Party

Subscribe forElectronicSignature

(and receivePrivate Key)

DepositSubscriber's PublicKey for Validation

Requestvalidation of

Certificate. Valid?Yes/No

Policy Authority(Secretary of

State)

Repository

$

VISIO CORPORATION

CertificationAuthority

Agency PKIProject Certificate Policy:

“SigningProcess”

The Structure is formulated into Policy

Public Key Infrastructure• Description of a trust through Certificate Policies

& Certificate Practice Statements– hierarchy of organizational units and end nodes– uses x.509v3 certificates as protocol specification– responsibilities and liabilities of the members of the

network– governs the operational aspect (tech and process) of

Infrastructure• uses a public / private key for unique identifiers

– Identity– Hierarchy– Encryption

PKI Certificate Policies• Depict the communities structure - Authority

PKI cliff notes

CP BX

CPS

CP XY

CPS

Bob’s Cert

Bob’s Cert

Who’s Bob

CERTIFICATE AUTHORITY

CA Z Cert

CP YZ

CPS

Bob’s Cert

Corp Y Cert

Business X

Cert

Issuer=CA ZO=Corp YOU=Business XDN=Bob

Repository

White Pages

Two Infrastructure pilots using the same CP

ESI for CP “A”

ESI for CP “B”

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

One size does not fit all

The “public” in PKI

• PKI meant to be open infrastructure• Distinguished Names and Object

Identifiers• External LDAP (Lightweight Directory

Access Protocol) interfaces• Little infrastructures connected are

big infrastructures

DN (distinguished names) and OID (object identifiers)

• OID uniquely defines Distinguished Names and Object Identifiers.• Under the joint-iso-ccitt arc in the registration tree,

the US-JRA has registered sub-authorities, including states.• Arizona’s schema builds on the US arc of the registration tree

established according to CCITT X.660 Recommendation and ISO/IEC 9834-1 Standard.

• The state arcs are defined by FIPS PUB 5-2. • The registration sub-authority for Arizona is the Secretary of State• The root Arizona arc is 2-16-840-3-04• The first numeric assignment after 2-16-840-3-04 identifies

the type of entity within the state.

OID Schema for the State of Arizona

(16)[org-type=country]

(2)[ISO-CCITT root]

(840)US

(3)[org-type=State]

(04)AZ [Arizona]

(nn)[org-type=intraStateType]

(nnn)intraStateOrg

[division, object]

01 = (EB) exec branch02 = (LB) legislative branch03 = (JB) judicial branch04 = (CO) county05 = (CI) city [and similar subdivisions]06 = (OP) other public entities07 = (NP) non-profit entities08 = (PB) private business (corp., LLC, etc)09 = (PC) private citizen10 = (EE) exec branch - educational (college, university)00 = (SO) state object

(nn)[SubOrg-type=division,

object]

(nnn)SubOrg [division,

object]

(nn)[SubOrg-type=section,

object]

(nnn)SubOrg [section,

object]

(nn)[SubOrg-type=unit, object]

(nnn)SubOrg [unit,

object]

2.16.840.3.04[state OID]

OID Schema for the State of Arizona

(001)Office of the

Governor

(01)[org-type=EB

(exec branch)]

(02)[org-type=LB

(legislative branch)]

(03)[org-type=JB

(judicial branch)]

(04)[org-type=CO

(county)]

(08)[org-type=PB

(private business)]

(07)[org-type=NP

(non-profit entity)]

(05)[org-type=CI

(city)]

(06)[org-type=OP(other public

entity)]

(09)[org-type=PC

(private citizen)]

(00)[org-type=SO(state object)]

(002)Secretary of State

(nnn)other Exec Branch

entity

(000)Exec Branch object

(001)Elections

(002)Business Division

(999)Policy Authority

(01)[org-type=EP

(person)]

(00)[org-type=OO

(object)]

(00[org-type=OO

(object)]

(000)Policy Authority

Practices

(001)Certificate Policy -

Fundamental

(002)Certificate Policy -

Basic

(000)SecState Object

(02)[org-type=DO

(division)]

(01)[org-type=EP

(person)]

(01)State Seal

(02)Web server

2.16.840.3.04.01.002.02.999.00.0022.16.840.3.04.01.002.02.999.00.001

(01)[org-type=EP

(person)]

(02)[org-type=DO

(division)]

(001)the

Governor

(001)the

Secretary of State

(10)[org-type=EE(educational)]

OID Schema Reads like an Org Chart

Lightweight Directory Access ProtocolLDAP 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:

(LDAP element = OID element)• cn=CommonName• sn=Surname• l=LocalityName• st=StateName• o=OrganizationName• ou=OrganizationUnitName• c=CountryName• street=StreetAddress• uid=UserIdentifier

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

Arizona a piece of global picture

Arizona

Basic

Medium

High

Communities of Interest• Based on interest, not jurisdiction• Need within community for electronic signing

– Reduce time constraints– Reduce location restraints– Automate the operation of the Community

• Jurisdictions serving community – Must be interested in participation– Resources for participation– Willing to collaborate with other jurisdictions– Agree to level of assurance required for community

enrollment

Arizona Communities Grow

Basic

Medium

High

Reliance (Community Evidence)• Within the community

– agreement of community enrollment– agreement of jurisdictions governing community– common understanding of evidence

• Outside the community– What are you missing?

• Who else relies upon evidence created in community• What other jurisdictions must the evidence be presented• How will the evidence be communicated

– Tool set / application “exportable”• How will evidence be proven

– Self evidencing documentation– Jurisdiction (perhaps community wide) system security

Communities Cross Jurisdictions

(Global) Public Infrastructure takes Shape

So what does this do for e-records?

• Just network domains and access control?• Fancy encryption to determine source of

document?• Policy overwhelming, community

complicated.

• Put the pieces together

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.

http://www.legalxml.org/

How do we assure accessibility by all parties? Interoperability requires common document and signing standards

across different communities

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.

Example of System Documented Records

What does it take for system documented records?

• Breaches• Vulnerability• Integrity

• System documentation:– Audit logs, user authorization, trustworthiness tested– From creation of to present of document in question

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!

Original Paper Document

Paper Copy

Digital Copy (Image)

Original Digital Document


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

The validity of a digital document depends on thetests it can pass - includingwhether it has been altered.

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

Original Paper Document

Paper Copy

Digital Copy (Image)


Digital Document

Parent

Parent

Clone

Child

Child

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

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.

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!


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

• Electronic signature records need to be retained based on their operational needs and perceptions of risk. • If an electronically signed record needs to be preserved, whether for a finite period of time or permanently, then its trustworthiness over time needs to be assured. • Use of a records retention schedule needs to include

• designating the disposition authority to dispose of records• the means to dispose of records at the end of the scheduled retention

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

Message

Signature

Digest

Encrypt

Hash Function

ActualDigest

Message

ExpectedDigest

Decrypt

Hash Function


SignatureMessage

PrivateKey

PublicKey

CP

TrustChain

System Documented RecordDocumenting 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.

• protect record against alteration without appropriate permission. • records management policies and procedures should specify

• what, if any, additions or annotations may be made to a record after it is created, • under what circumstances additions or annotations may be authorized, and• who is authorized to make them.

• Any authorized annotation or addition to a record made after it is complete should be explicitly indicated as annotations or additions.

• structural integrity of a record - the structure of a record should remain physically or logically intact - its physical and logical format and the relationships between the data elements comprising the record. Failure to maintain the record’s structural integrity may impair its reliability and authenticity.

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


Content*

• The electronic signature or signatures in a record are part of the content.

• They indicate who signed a record and whether that person approved the content of the record.

• Multiple signatures can indicate initial approval and subsequent concurrency.

• Signatures are often accompanied by dates and other identifiers such as organization or title.

• All of this is part of the content of the record and needs to be preserved.

• Lack of this information seriously affects a document’s reliability and authenticity.

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


Context*• Some electronic signature technologies rely on individual identifiers that are not embedded in the content of the record, trust paths, and other means to create and verify the validity of an electronic signature. This information is outside of the content of the record, but is nevertheless important to the context of the record as it provides additional evidence to support the reliability and authenticity of the record.

• Lack of these contextual records seriously affects one’s ability to verify the validity of the signed content.




Structure*• Preserving the structure of a record means its physical and logical format and the relationships between the data elements comprising the record remain physically and logically intact.

• It may be necessary to maintain the structure of the electronic signature. In that case it is necessary to retain the hardware and software that created the signature (e.g., chips or encryption algorithms) so that the complete record could be revalidated at a later time as needed.


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:• Evidence of the origin of the message• Evidence of sent• Evidence of receipt• Timestamp as needed of origin, sent, receipt• Long-term storage of evidence• Designated adjudicator of prospective disputes

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

ExternalE-Records Users

DetermineAgency

E-RecordsPolicy per

Statute, Regs& Rules

Non-BusinessE-communications

Inactive & Archive E-record Vault

Active E-recordRepository

discard non-businesscommunications

capture businesscommunicationsaccording toAgency & Statepolicy, standards& procedures(GITA, SLAPR,SoS, GAO)

Identify BusinessCommunications

(by agency protocol)

Provide Access toBusiness Records according toAgency Protocol



(electronic record/document management systems)E-records technology refresh as needed

destruction of persistent e-recordsat end of retention period

Electronic Records Life CycleSimplified Business Process View

Working Files

ElectronicCommunications

(Internal & ExternalSources)

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

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

For a record/document, we often need to: • identify & authenticate the source/originator• identify & authenticate requester – increasingly we need to manage access to records (or parts of records) based on the requester’s role (identity, purpose, etc)

• authorized access management• encryption and electronic “redacting” for confidentiality (e.g. HIPPA – Health Information Privacy & Portability Act)

• identify & authenticate signer(s)• affirm the integrity of record/document• copy certify – “this is a true and accurate copy of….”

Some of the current national, international and state PKI efforts

• Federal PKI Bridge – link agencies’ PKI systems together

• Federal ACES – common PKI system for federal agencies

• Identrus (international banking industry effort)

• USPS (certified “e-mail”)

• Multi-state Electronic Signatures & Documents Reciprocity

• Electronic Notary (multi-state reciprocity)

Federal Bridge CA (FBCA)

• The Federal Bridge CA is operated by the FPMA.

• Its purpose is to be a bridge of trust that provides trust paths between the various trust domains of the Federal PKI, as well as between the Federal PKI and non-Federal trust domains.

• FPMA-approved trust domains designate a principal CA that is eligible to cross-certify with the Federal FBCA.

• The FBCA is not a root CA because it does not typically begin certification paths.

Federal PKI Policy Authority

• Voluntary interagency group (is not an agency itself) Six charter members – DOJ, DOD, OMB, GSA, Treasury and DOC

• Governing body for FBCA interoperability Responsible for Certificate Policy Agency FBCA certificate policy mappings

• Oversees operation of FBCA

• Operates under the Federal CIO Council

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.

Any Web-basedGovernmentApplication

Access FederalSystem with ACES

Return PersonalizedGovernment Benefits/Information Validate Digital

Signature Certificate

Citizen

Industry Partner

Authentication

Access Control

Data Integrity

Technical Non-Repudiation

(This an OMB slide)

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

Identrusan international banking trust initiative

via an interoperable PKI network

IDENTRUS

employees withcertificates

Corporate clients

Financial Institutions- Certificate Authority

authenticated eCommerce between banking customers

State Electronic Records and Signatures Reciprocity

PosteCS™ works with Secure Sockets Layer (SSL) enabled browsers.

How it works for the sender•You establish a PosteCS account before the first file can be sent. •Next, you simply select the email address to where the document will be sent. •You can also choose to add several security levels along with delivery confirmation before sending the document.

•When the document is sent it is uploaded to the PosteCS server, which generates an email notice to the recipient, containing a unique Web address (a patented technology) to access the PosteCS document.

How It works for the Recipient•Following the notification email, the Recipient clicks on the Web address.•The file is downloaded through the Web connection into a Web browser.

United States Postal Service (USPS) certified e-mail


NECCC E-SIGN Interoperability Workgroup andState Electronic Records and Signatures Reciprocity and

Interoperability Issues

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

• E-SIGN was passed and put into effect in 2000.

• UETA (Uniform Electronic Transactions Act) was also passed by about half the states.

• They establish a legal foundation for electronic signatures in commerce. An electronic signature is whatever the parties agree to.

•E-SIGN requires states to be “technology neutral.” State statutes that aren’t “technology neutral” are preempted.


Several States:• Were a “little concerned” about preemption.• They also recognized

the risk of having to receive any record format, the need for legal guidelines for agencies and for an interoperability framework for recognizing electronic signatures from other states.

• Met in August, 2000 to discuss the issues. (hosted by California’s Secretary of State)

• Then met in September to form workgroups Policy, Legal, Security, and Interoperability sponsored by National Governors’ Association coordinated by NECCC (National Electronic Commerce Coordination Council)

Work will be officially published at NECCC conference this December.

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)



The Interoperability work group asked

“how do we get from technology neutral e-signatures statutesto agreement about what are

sharable, trustworthy signed electronic documents (things that are reliable, usable, authentic, and having integrity)?”

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:

Unique to the person using it.

Capable of verification.

Under the sole control of the person using it. Linked to the electronic record to which it relates in such a manner that if the record were changed the electronic signature would be invalidated.


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.



Recognize NEC3definitions for Secure

Electronic Signatures andSecure Electronic Record

Proposed Process leading to Electronic Signature Reciprocity between States

Determine whether tocentralize electronic

signature policy

Determine Electronic SigningProcess(es) to be used

(and appropriate ElectronicSignature Policies)

Negotiate Reciprocitywith other states based

on the Framework

PKI Signing Process(with Certificate Policy

ala NEC3 Model PKI CP)

PGP signingprocess

(with appropriatepolicy)

Shared Secret signingprocess

(PIN/password)(with appropriate policy)

CentralizedElectronic Signature Policy

Management Authority (ESPMA)[NEC3 ESR Framework whitepaper]

Decentralized ElectronicSignature Practices[NEC3 ? whitepaper]

? Signing Process(with appropriate

policy)

Develop Electronic Signing processes conforming to theNEC3 Framework for Electronic Signature Reciprocity

(and appropriate policy)While the Electronic Signature PolicyManagement Authority (ESPMA)provides a general framework forcentralized electronic signaturemanagement, there may be particularadditions needed for specifctechnologies(e.g. a PKI based Policy ManagementAuthority (PKI PMA) might be formedwith a wider view of PKI use and theESPMA and the PKI PMA policies wouldneed to be harmonized).


Framework for Electronic Signature Reciprocity

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

• Signer is identified.• Signer is linked to the signature.• Signature is linked to the integrity of the record.

The trust levels are:• Basic - provides a basic level of assurance relevant to transactions where there are risks and consequences of data compromise, but they are not considered to be of major significance. This may include access to private information where the likelihood of malicious access is not high. It is assumed at this security level that users are not likely to be malicious.• Medium - is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial.• High - is appropriate for use where the threats to data are high, or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk.


Recognize NEC3definitions for Secure

Electronic Signatures andSecure Electronic Record

Proposed Process leading to Electronic Signature Reciprocity between States

Determine whether tocentralize electronic

signature policy

Determine Electronic SigningProcess(es) to be used

(and appropriate ElectronicSignature Policies)

Negotiate Reciprocitywith other states based

on the Framework

PKI Signing Process(with Certificate Policy

ala NEC3 Model PKI CP)

PGP signingprocess

(with appropriatepolicy)

Shared Secret signingprocess

(PIN/password)(with appropriate policy)

CentralizedElectronic Signature Policy

Management Authority (ESPMA)[NEC3 ESR Framework whitepaper]

Decentralized ElectronicSignature Practices[NEC3 ? whitepaper]

? Signing Process(with appropriate

policy)

Develop Electronic Signing processes conforming to theNEC3 Framework for Electronic Signature Reciprocity

(and appropriate policy)While the Electronic Signature PolicyManagement Authority (ESPMA)provides a general framework forcentralized electronic signaturemanagement, there may be particularadditions needed for specifctechnologies(e.g. a PKI based Policy ManagementAuthority (PKI PMA) might be formedwith a wider view of PKI use and theESPMA and the PKI PMA policies wouldneed to be harmonized).


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.

Interoperabilitygetting from here to over there


DetermineAgency

E-RecordsPolicy per















Working Files




DetermineAgency

E-RecordsPolicy per















Working Files



Thank you

• Please visit us on the web…

http://www.sos.state.az.us/pa

Russ Savage Mike [email protected] [email protected]

For those more interested

• Following slides contain examples of what a digital certificate looks like

Digital Signatures (PKI)• uses a certificate issued within a PKI

– here’s what a certificate looks like– elements of a certificate

• uses encryption algorithms– publicly known algorithms– very high levels of assurance

• Bits equates stronger protection, but encryption still decays with age

PKI signature example1. Policy Authority defines the Certificate Policy for trusted network description2. Department as a relying party defines community of interest

a. Decision: electronic signatures needed? - Digital Signatureb. Chooses Certificate Policyc. Chooses Vendor off Approved Certification Authority List i Department will act as RAii Department (or community?) will archive certificatesiii Vendor sells tool sets to subscribersd. Department creates application for community

3. Subscriber visits Registration Authority (potentially Gov through contract) to registera. Subscriber verifies identity to RA b. CA issues digital signature to Subscriberc. Subscriber gets training from Vendord. Subscriber installs tool set with Vendor support

4. CA publishes public digital signature in Repository5. Subscriber uses application to commit transaction

a. Signs document with issued digital signature6. Relying party receives document

a. Verify integrity of transactioni Verify signature against repositoryii Check Certificate Revocation List (CRL)b. Updates database and stores transactionI Information parsed and saved in dbii “document” stored for evidencec. Receipt sent to subscriberd. Relying party verifies receipt received

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

E-mail or otherElectronically Signed Document

SubscriberRelying Party

Subscribe forElectronicSignature

(and receivePrivate Key)

DepositSubscriber's PublicKey for Validation

Requestvalidation of

Certificate. Valid?Yes/No

Policy Authority(Secretary of State)

Repository

$

VISIO CORPORATION

CertificationAuthority

Agency PKI Project

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

CertificateIssued

Revoked(Compromised,

critical information changeor expired)

Apply toRenew

(about toexpire)

SubscriberUses

Acceptedby

Subscriber

Application

approved

Apply forDigital

Signature

Digital Certificate Life Cycle

NewApplicant Life Cycle

PKI Risk evaluation• Uniqueness

– In-person registration assures uniqueness• Verifiable

– provides non-refutable verification• Repudiation based on handling, not technology

• Sole control– Combination something person knows with have =

Medium– Smart card could be next to perfect (with biometric)

• depends on implementation

• Linked to the record– Implementation inherent by design

Electronic Document by DS

SAMPLE SIGNING BLOCK

[s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> [s02] <SignedInfo>[s03] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>[s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>[s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">[s06] <Transforms> [s07] <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>[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>

<document>

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

</document>

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

<SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> [s12] </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> <P>...</P><Q>...</Q><G>...</G><Y>...</Y> </DSAKeyValue> </KeyValue> </KeyInfo></Signature></xml>

Email Digital SignatureReceived: from femail18.sdc1.sfba.home.com ([24.0.95.145]) 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 -0700Received: from cx74747a ([24.1.194.228]) by femail18.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010428204109.YZEE937.femail18.sdc1.sfba.home.com@cx74747a> for <[email protected]>; Sat, 28 Apr 2001 13:41:09 -0700Message-ID: <[email protected]>From: "Michael Totherow" <[email protected]>To: "Michael Totherow" <[email protected]>Subject: This is a Signed EmailDate: Sat, 28 Apr 2001 13:38:20 -0700MIME-Version: 1.0Content-Type: multipart/signed;

protocol="application/x-pkcs7-signature";micalg=SHA1;boundary="----=_NextPart_000_005C_01C0CFE8.7DBBDD00"

X-Priority: 3X-MSMail-Priority: NormalX-Mailer: Microsoft Outlook Express 5.00.2615.200X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01C0CFE8.7DBBDD00Content-Type: text/plain;

charset="iso-8859-1"Content-Transfer-Encoding: 7bit

------=_NextPart_000_005C_01C0CFE8.7DBBDD00Content-Type: application/x-pkcs7-signature;

name="smime.p7s"Content-Transfer-Encoding: base64Content-Disposition: attachment;

filename="smime.p7s"

------=_NextPart_000_005C_01C0CFE8.7DBBDD00--

Enveloping<DOCUMENT>

<PARAGRAPH>BLAH BLAH BLAH</PARAGRAPH>

</DOCUMENT><SIGNATURE>

<SIGNATURE_BLOCK ID=1>SIGN HERE</SIGNATURE_BLOCK ID=1><SIGNATURE_BLOCK ID=2>SIGN HERE</SIGNATURE_BLOCK ID=2><SIGNATURE_BLOCK ID=3>SIGN HERE</SIGNATURE_BLOCK ID=3>

</SIGNATURE>