Evolved as networking evolved from the dumb terminal, to networks to the internet traffic of today…
2
What we mean by securing the electronic community —
Minimize threats:
Interception
Impersonation
Alteration
Unauthorized access
Denial of Service
3
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
4
Electronic “community” evolution
Access control lists
Network domains
Universal Naming Convention
X.500
Novell Directory Services
X.509 certificates
Microsoft Active Directory
LDAP
5
The electronic community
Establishes the identity of the elements of the community
Identification
Authentication
Authorization
6
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!
7
Expectations of PKI:
electronic identity
electronic locations & devices within the e-community
ensuring integrity in documents
Access, authorization and control
8
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
9
Elements of Public Key Infrastructure
The Key
Asymmetric cryptographic keys
The Infrastructure
Roles, relationships and responsibility
The Public
Open design and accessibility
Interactions with
10
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)
11
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)
12
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).”
13
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.”
14
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)
15
The “infrastructure” in PKI
— “Guidelines for Public Key Infrastructure” by the American Bar Association
Defines Roles
Defines Responsibilities
Defines Relationships
Defines Liability
16
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
17
The Roles in Electronic Signature Use
(State of Arizona’s infrastructure model)
18
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)
19
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
20
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
21
The Structure is formulated into Policy
Certificate Policy is the zoning plan
Zoning for Infrastructure is Summarized in CP
Policy
Issuance of Technology
Subscriber Party
Repository Control for access & maintenance
Relying Party
The ‘Certificate Policy’ might be called the ‘Contract of Process’
22
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
23
PKI Certificate Policies
Depict the communities structure — Authority
24
PKI cliff notes
25
Two Infrastructure pilots using the same CP
26
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).
Little infrastructures connected are big infrastructures
28
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.
29
30
OID Schema Reads like an Org Chart
31
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:
(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 that the registered OID alphanumeric arc is the LDAP DN.
32
Arizona a piece of global picture
33
Arizona
34
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
35
Arizona Communities Grow
36
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
37
Communities Cross Jurisdictions
38
(Global) Public Infrastructure takes Shape
39
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
40
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.
http://www.legalxml.org/
41
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.
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.
43
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
44
What is inspected?
45
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!
46
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.
47
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.
48
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.
49
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
50
If an electronically signed record needs to be preserved, then its trustworthiness over time needs to be assured.
51
Self Documenting record
Documenting integrity over time
52
System Documented Record
Documenting integrity over time
53
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.
54
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.
55
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).
56
Preserving Trustworthy Records
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
57
Preserving Trustworthy Records
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.
* text largely from “Records Management Guidance for Agencies Implementing Electronic Signature Technologies” National Archives and Records Administration, Oct. 18, 2000
58
Preserving Trustworthy Records
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.
* text largely from “Records Management Guidance for Agencies Implementing Electronic Signature Technologies” National Archives and Records Administration, Oct. 18, 2000
59
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:
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.
60
Intentionally blank
61
It’s important to remember that you’re not alone, others need access to those documents & records.
62
Current Movements to address the inter-relationship of digital 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….”
63
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
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.
65
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
66
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.
67
ACES
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.
68
Identrus
an international banking trust initiative via an interoperable PKI network
69
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
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.
70
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
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.
71
State Electronic Records and Signatures Reciprocity
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.
72
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)
73
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)?”
74
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:
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.
75
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.
76
State Electronic Records and Signatures Reciprocity
Proposed Process leading to Electronic Signature Reciprocity between States
77
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:
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.
78
State Electronic Records and Signatures Reciprocity
Proposed Process leading to Electronic Signature Reciprocity between States
79
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.
Following slides contain examples of what a digital certificate looks like
82
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
83
PKI signature example
Policy Authority defines the Certificate Policy for trusted network description
Department as a relying party defines community of interest
Decision: electronic signatures needed? - Digital Signature
Chooses Certificate Policy
Chooses Vendor off Approved Certification Authority List
Department will act as RA
Department (or community?) will archive certificates
iVendor sells tool sets to subscribers
Department creates application for community
Subscriber visits Registration Authority (potentially Gov through contract) to register
Subscriber verifies identity to RA
CA issues digital signature to Subscriber
Subscriber gets training from Vendor
Subscriber installs tool set with Vendor support
CA publishes public digital signature in Repository
Subscriber uses application to commit transaction
Signs document with issued digital signature
Relying party receives document
Verify integrity of transaction
Verify signature against repository
Check Certificate Revocation List (CRL)
Updates database and stores transaction
Information parsed and saved in db
“document” stored for evidence
Receipt sent to subscriber
Relying party verifies receipt received
84
The Roles in Electronic Signature Use
(State of Arizona’s infrastructure model)
85
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
86
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)
<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>
Received: 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 -0700
Received: 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 <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;
protocol="application/x-pkcs7-signature";
micalg=SHA1;
boundary="----=_NextPart_000_005C_01C0CFE8.7DBBDD00"
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
