| Security and Authentication |
| The Internet Document Authentication Server will be a
server application which stores the Public Keys of
individuals. It will be similar to Verisign, but instead
of a single company being at the top of a 'trust tree',
there will be a network of Authentication Servers. The
Authentication Server Application will be open source,
and be able to be run by anyone. Its purpose is to have a
publicly available store of public keys which you can
trust to be correct. This will allow Internet Documents to be protected by strong encryption, and it will allow Internet Documents to be signed by the sender to ensure authenticity. It means you will not need to pay a company such as verisign in order to achieve this security. |
| Home Next |
| B2B Resources |
| The following links are provided to other sites related to Business to Business communication. |
| Electronic Business XML (ebMXL) |
| Go To Electronic
Business XML Web Page ebXML Mission: To provide an open XML-based infrastructure enabling the global use of electronic business information in an interoperable, secure and consistent manner by all parties. About ebXML: The United Nations body for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS) have joined forces to initiate a worldwide project to standardize XML business specifications. UN/CEFACT and OASIS have established the Electronic Business XML initiative to develop a technical framework that will enable XML to be utilized in a consistent manner for the exchange of all electronic business data. Industry groups currently working on XML specifications have been invited to participate in the 18-month project. A primary objective of ebXML is to lower the barrier of entry to electronic business in order to facilitate trade, particularly with respect to small- and medium-sized enterprises (SMEs) and developing nations. We welcome your participation in this important effort. |
| BizTalk |
| Go To BizTalk.Org
Web Page BizTalk is an industry initiative started by Microsoft and supported by a wide range of organizations, from technology vendors like SAP and CommerceOne to technology users like Ariba and BASDA. BizTalk is not a standards body. Instead, we are a community of standards users, with the goal of driving the rapid, consistent adoption of XML to enable electronic commerce and application integration. |
| BASDA and eBIS-XML |
| Go To Basda.Com Web
Page Go To eBIS-XML.Com Web Page Following the successful launch of its eBIS-XML initiative earlier this year, BASDA (the Business & Accounting Software Developers’ Association) has now introduced its latest eBIS-XML Web Shopping Cart schema which enables companies to transmit orders generated on their websites, directly into their back office, order entry and financial systems. The BASDA eBIS-XML technology already allows direct exchange of purchase orders and invoices between different business software applications, via e-mail and the Internet. More than 150 national and international business application software developers are implementing the BASDA eBIS-XML interface, which will enable their software to generate and read the XML messages. A number of those companies have already had their software tested to ensure compliance to the BASDA eBIS-XML standard and have launched eBIS-XML enabled products which, in turn, are creating a growing network of users who are automating their supply chains. |
| Extensible Business Reporting Language (XBRL) |
| Go To Extensible
Business Reporting Language Web Page What are we doing? XBRL.ORG is developing the eXtensible Business Reporting Language (XBRL) for the preparation and exchange of business reports and data. The initial goal of XBRL is to provide an XML-based framework that the global business information supply chain will use to create, exchange, and analyze financial reporting information including, but not limited to, regulatory filings such as annual and quarterly financial statements, general ledger information, and audit schedules. XBRL is freely licensed and facilitates the automatic exchange and reliable extraction of financial information among various software applications anywhere in the world. The XBRL Specification and the first taxonomy for financial reporting of commercial and industrial companies under US GAAP was released on July 31, 2000. This was a major milestone for the XBRL framework. |
| MEC-EAGLE.ORG |
| Go To
MEC-EAGLE.ORG Web Page m-e-c eagle is the first open source, OS independent, Java, XML and XSL based B2B integration software, which give you the right tool for it. It has an high basic functionality with many components, which give you a set of integrated tools, which make it possible to create any business solutions for interating different systems with each other. |
| Open Business Objects for EDI |
| Go
To Open Business Objects for EDI Web Page OBOE is a EDI and EDI/XML Translator Package. EDI Document Rules Engine - Reads in a XML and DTD file to build/parse an EDI Document or EDI/XML file. Sample XML File. EDI Document Formatter and Browser - by utilizing the EDI Object classes with JAVA.AWT classes we've created a simple document browser. If you receive EDI documents in your mail then you can now look at them in a format that is easy to read. The mail program add-on is based on the RFC 1767 MIME Encapsulation of EDI Objects. For the latest proposed changes MIME-based Secure EDI EDI Translator - it parses an EDI document into Java objects. The objects are then used to interact with a GUI or database or some other process, e.g. a web page or batch program. EDI/XML Translator - it parses an EDI/XML file into Java objects. The objects are then used to interact with a GUI or database or some other process, e.g. a web page or batch program. Envelope builder - it takes the EDI Objects Java objects and builds an EDI document. The EDI document can then be sent via email, to a VAN for transmission, transmitted using a proprietary message delivering system, print out and faxed... etc. EDI Objects - each transaction set, table, segment data element is defined in a class. The classes defines business logic, relationship rules to other transaction sets, tables, segments and data elements, data element rules validation ... etc. |
| Electronic Publishing |
| Go To
Electronic Publishing Projects This page provides the starting point for information on El.pub concerned with the Interactive Electronic Publishing. It provides an on-going overview of the sector, and links to information about the projects being supported through the European Commission's IST and 5th Framework R&D programmes. The Interactive Electronic Publishing (IEP) sector of the European Commission's Information Society Technologies (IST) Programme is part of Multimedia Content and Tools, Key Action III of the IST Programme, which itself falls within the the 5th Framework RTD Programme. The reserch and development projects funded by the Interactive Electronic Publishing sector focus primarily on generating, managing, personalising creative digital content. |
| XML/EDI Group |
| Go To XML/EDI
Group XML and EDI Provide a standard framework to exchange different types of data -- for example, an invoice, healthcare claim, project status -- so that the information be it in a transaction, exchanged via an Application Program Interface (API), web automation, database portal, catalog, a workflow document or message can be searched, decoded, manipulated, and displayed consistently and correctly by first implementing EDI dictionaries and extending our vocabulary via on-line repositories to include our business language, rules and objects. Thus by combining XML and EDI we create a new powerful paradigm different from XML or EDI! |
| Home |
| IDTrans - A Business Case | ||||||||||||
| This project could have a far reaching positive effect on New Zealand business. It could enable a revolution in business communication similar to the effect email has had on personal communications. I have listed below some of the advantages this new technology will bring to companies. | ||||||||||||
| Advantages for Business | ||||||||||||
|
||||||||||||
| Advantages for Internet Service Providers | ||||||||||||
|
||||||||||||
| Advantages for Accounting System Companies | ||||||||||||
|
||||||||||||
| Advantages for Accountants | ||||||||||||
|
||||||||||||
| Advantages for Banks | ||||||||||||
|
||||||||||||
| Advantages for Government Departments | ||||||||||||
|
||||||||||||
| Home Next |
| Complex Catelogs |
| A Catalog is something supplied by a business to
advertise their wares, and possibly their prices and
specials. A Internet Catalog is pretty much the same
thing. It allows clients, business or consumer, to browse
a catalog and create orders offline. It will be based on
XML, and may contain HTML and Image files. Typically the
Internet Catalog will be compressed into a single file,
and downloaded or emailed between client and business. The advantage of the Internet Catalog is that you can build in logic into it, such as bulk discounts and other business logic specific to that supplier. The order can be created and the price calculated offline. Automatic price comparisions also may be possible. Businesses will be able to keep customers up to date with the latest catelogs automatically. |
| Home Next |
| Real Software |
| The Internet Documents Client will use the Internet
Document Transfer API to provide an application for
consumers and businesses. It will act as a client for
sending and receiving orders, invoices and statements. It
will also be a standard email client similar in
functionality to Outlook Express. It will be a free
product, and its purpose will be to get as many people,
business and consumers alike, using the new Internet
Document standards. In addition to protecting Internet Documents with strong public key encryption, it will protect emails as well between two Internet Document Clients. The protection will be automatic, not requiring complex manual processes to maintain your private and public keys. |
| Home Next |
| Secure Email Specification (version 1) Discussion |
This message document a discription of what I have so far as a specification for secure business document transmission. There is also a discussion about the proposed specification. Please feel free to email peterha@nothingbutnet if you have any comments to add. The points discussed will be written into version 2, which will be written in the next couple of weeks. I will also be talking with PGP experts to see if we can use a limited implementation of PGP. |
| SMTP / POP3 |
| Messages are transmitted via attachments within standard SMTP messages. The Message Bodies themselves are not encrypted, only the attachments. Each Attachment is a Encrypted File. Each attachment potentially can be separatly opened or saved to disk for later decryption. Attachments are via standard MIME. |
| Encrypted Attachments |
| Each Encrypted Attachment has a four blocks of
information in a fixed sequential order. These blocks
are: FileName Encrypted Session Key Signature Main Data |
| FileName |
| The FileName block consists of the filename of the
original file being sent. This is sent in order to ensure
it is to the correct name on receipt. It is possible that
the encrypted file is renamed or otherwise altered in the
transmission process, therefore including the filename
with the file is a good idea. The actual format of the
FileName is : 2 bytes - Short Integer representing
FileName Length (n) |
| Encrypted Session Key |
| The Encrypted Session Key is a random session key
used by the symetric AES algorithm to encrypt and decrypt
the main file data. By using RSA to encrypt the session
key only the recipient can decrypt the session, and
therefore decrypt the main file. The encrypted session
key is stored in the following format : 2 bytes - Short
Integer representing Encrypted Session Key Length (n) When encrypting a random session key is generated and encrypted with RSA using the public key of the recipient. The receiver uses his private key to decrypt the session key, which is then used for the main data. |
| Signature |
| The signature is a MD5 hash of the original data in
the file encrypted with RSA using the public key of the
sender. On decrypting the main data the recipient can
check the hash provided with one calculated from the
decrypted main data. If the hash match the recipient can
be sure that the file was encrypted by someone with
access to the private key that corresponds with the
public key on file for the sender. In other words, it
ensures the apparent sender of the file is the actual
sender of the file. The format of the signature block is
in the following format : 2 bytes - Short Integer
representing length of Signature (n) |
| Main Data |
| The Main Data is simply the data of the original file
encrypted with the Session Key using the AES algorithm.
Its format is simple : x bytes - All remaining bytes to the end of the file are encrypted data. |
| Discussion |
| There are a few design issues I have been thinking
about, which I wouldn't mind some input on: 1. Multiple Recipients. The above format sacrifices flexibility for ease of use. In the above format many of the features are not optional. For example, in PGP you can have multiple recipients by including more than one Encrypted Session Key. You can also elect to only sign, or only encrypt. My solution forces both encryption and signing to be used regardless, while limiting to a single recipient. The reasoning is that I don't want users to need to think about weather to encrypt or sign - it should be automatic and invisible. Also there may be limited application of sending multi-recipient business files? 2. Including Recipients and Senders Email Addresses. In my current implementation the Public Keys are distributed by a web server based on email address. The email address of the sender and recipient defined in each email allow the client to obtain the appropriate keys used for encryption etc. By having the email addresses imbedded into the file itself you could divorce the files totally from the email, so the files can be saved to disk, transmitted by means other than email (FTP?) and still be decrypted at a later date. 3. Compression. Currently there is no compression involved in this process. However, by encrypting data we make it uncompressable. This creates a problem for external systems, such as modems which perform internal compression to aid performance. Take Text for example. Usually text can compress by 90%. With encryption this compression reduces to 0%. It is therefor a good idea to compress files before encryption. Since we are compressing, we might like to compress multiple files - in which case I think the use of zip format would be the most sensible. |
| Mailing List Comments |
| from: Grant Black |
| I think this [encrypted
attachments] section needs to be clarified. I think you
are saying that you can attach multiple files but then
each file (or block) is actually a collection of 4 files.
If so how are the files tied together (by name/MIME ID)?
Do the files have a type (an extension under win32?). I
probably need to refresh my memory when I get home &
look at the MIME RFC. Might have to beware of UniCode and allow for 2 bytes per char filenames, (I have recieved documents from Asia that have unicode names). I think there is a good case for allowing the sending of multi-recipient files in business. When sending tender and other contract documents it is sometimes important that it is transparent that all parties received the same document at the same time. For instance when preparing bids for projects most companies would want to ensure that they received the same proposal details at the same time as competing companies. Does it [compression] matter for ID-Trans? I guess I saw the system as passing around business objects like invoices or receipts which tend to be small bits of text/XML - compression seems overkill in these cases. If large files or large groups of files are being exchanged, then that could be an extension of the system to allow for different file formats - after all you don't want to force zipping on a company that might be trading (legally!) MP3/MPeg or JPG's files. |
| from: Nicholas Hynes |
| RE: REPLY TO THE DEVCENTRE SECURE E-MAIL SPEC... had a look at the spec. As you know, I'm not an encryption expert, so I've focussed on some basic design decisions. Perhaps the standard would benefit from wider discussion. Have you invited comment from any international news groups? It's always interesting to get different points of view, and could lead to wider acceptance. Okay, my opinion... 1/ Is it wise to advocate the use of un-encrypted e-mail? I know that people CAN use PGP if they want, but are they likely to actually do that? You know what people in business are like, they'll think 'it conforms to the standard, that should be secure enough', and yet eavesdroppers will still have access to: the name of the companies involved, any name/reference number they give the transaction, subject & message body from the unencrypted message. If this is a must have requirement, then perhaps the standard needs to include rules about what can/must/can't be included in the main message. 2/ Filenames should be of a specified nature - makes it possible to save on multiple platforms, and can help track transactions without the receiver having access to the un-encrypted content. We don't want every attachment to be called 'attachment', because if it gets disassociated with information about how to decrypt it, then there will be no way of tracking it. On the other hand, if the filename gives away too much, it could be used by the evil people. 3/ Perhaps we should make the length indicators 4+ digits. It's a small, small overhead in modern times, and we don't want another Y2K meltdown. 3a/ Perhaps we should stardardize each block of the message (i.e. add a length indicator to the final block). This may make it easier to extend the protocol in the future??? What do other's think??? What about a block id??? 4/ How about a protocol version number somewhere. That
will allow people to continue using the existing
channels, if & when the specification is upgraded.
The version number should have, at least, two distinct
parts. One for the sent version, one to indicate which
versions can reliably decrypt the message. In reply to your questions... 1. Multiple Recipients. Can't think of a solution to this. You're right though, encryption & signing should be mandatory, there's no point in having a spec that is foiled by idiot users. Can think of uses for multiple recipients though, there are some business transactions that involve three or more separate legal entities. Each RECEIVING party will need some way of ensuring that all parties have been privy to the same agreement/correspondance. 2. Including Recipients and Senders Email Addresses. This is a really tricky one. You don't want people to know who is doing business with who. That info is valuable commercial information. Companies are VERY secretive about this sort of information. Even if the e-mail addresses aren't included in the message, the actual transfer medium (SMTP) requires it be included. Perhaps we need a trusted intermediary, which could recieve a message with two encrypted parts: firstly it has an encrypted header that indicates who the sender & receivers are, secondly it has the original data, encrypted with a different key, which is unknown to the intermediary. All transactions, from any company, can only be traced as far as 'from X to the intermediary', or 'from intermediary to Y'. Given both bits of information, a company could probably piece together who is talking to who. Perhaps the intermediaries need to bundle/unbundle multiple packets & distribute them accross an IP-tunnel style network... [phew! this is getting huge... sounds like a publicly owned VPN...] 3. Compression. Currently there is no compression
involved in this |
| Home |
email.htm 100744 765 764 4351 7240110776 11053 0 ustar html html
| Open Standards |
| Email is a great success. By using standard
protocols, and connected in a standard way to a huge
network, we are able to transfer information all over the
world between organizations and computer systems that are
very different in culture, location, and size. The
Internet email system is based on simple, standard
protocols. Email is a great model for developing further
protocols for communication. The one primary problem preventing communication of the basic business documents today is lack of a standard format for electronic data. Some standards, such as XML are being developed which may aid in developing some standard for transfer of invoices, but currently no specific standard has been implemented across a wide range of systems for basic business documents. I believe there needs to be an initiative to develop standard business document formats, based on XML. There should be standards for Invoices, Statements, and Orders etc. Several projects are currently developing such standards, and it is my intension to follow and implement the standards as far as practical. There is a list of other B2B XML standards projects on my B2B Resources Page. |
| Home Next |
| Secure Email Specification (version 1) Discussion |
This message document a discription of what I have so far as a specification for secure business document transmission. There is also a discussion about the proposed specification. Please feel free to email peterha@nothingbutnet if you have any comments to add. The points discussed will be written into version 2, which will be written in the next couple of weeks. I will also be talking with PGP experts to see if we can use a limited implementation of PGP. |
| SMTP / POP3 |
| Messages are transmitted via attachments within standard SMTP messages. The Message Bodies themselves are not encrypted, only the attachments. Each Attachment is a Encrypted File. Each attachment potentially can be separatly opened or saved to disk for later decryption. Attachments are via standard MIME. |
| Encrypted Attachments |
| Each Encrypted Attachment has a four blocks of
information in a fixed sequential order. These blocks
are: FileName Encrypted Session Key Signature Main Data |
| FileName |
| The FileName block consists of the filename of the
original file being sent. This is sent in order to ensure
it is to the correct name on receipt. It is possible that
the encrypted file is renamed or otherwise altered in the
transmission process, therefore including the filename
with the file is a good idea. The actual format of the
FileName is : 2 bytes - Short Integer representing
FileName Length (n) |
| Encrypted Session Key |
| The Encrypted Session Key is a random session key
used by the symetric AES algorithm to encrypt and decrypt
the main file data. By using RSA to encrypt the session
key only the recipient can decrypt the session, and
therefore decrypt the main file. The encrypted session
key is stored in the following format : 2 bytes - Short
Integer representing Encrypted Session Key Length (n) When encrypting a random session key is generated and encrypted with RSA using the public key of the recipient. The receiver uses his private key to decrypt the session key, which is then used for the main data. |
| Signature |
| The signature is a MD5 hash of the original data in
the file encrypted with RSA using the public key of the
sender. On decrypting the main data the recipient can
check the hash provided with one calculated from the
decrypted main data. If the hash match the recipient can
be sure that the file was encrypted by someone with
access to the private key that corresponds with the
public key on file for the sender. In other words, it
ensures the apparent sender of the file is the actual
sender of the file. The format of the signature block is
in the following format : 2 bytes - Short Integer
representing length of Signature (n) |
| Main Data |
| The Main Data is simply the data of the original file
encrypted with the Session Key using the AES algorithm.
Its format is simple : x bytes - All remaining bytes to the end of the file are encrypted data. |
| Discussion |
| There are a few design issues I have been thinking
about, which I wouldn't mind some input on: 1. Multiple Recipients. The above format sacrifices flexibility for ease of use. In the above format many of the features are not optional. For example, in PGP you can have multiple recipients by including more than one Encrypted Session Key. You can also elect to only sign, or only encrypt. My solution forces both encryption and signing to be used regardless, while limiting to a single recipient. The reasoning is that I don't want users to need to think about weather to encrypt or sign - it should be automatic and invisible. Also there may be limited application of sending multi-recipient business files? 2. Including Recipients and Senders Email Addresses. In my current implementation the Public Keys are distributed by a web server based on email address. The email address of the sender and recipient defined in each email allow the client to obtain the appropriate keys used for encryption etc. By having the email addresses imbedded into the file itself you could divorce the files totally from the email, so the files can be saved to disk, transmitted by means other than email (FTP?) and still be decrypted at a later date. 3. Compression. Currently there is no compression involved in this process. However, by encrypting data we make it uncompressable. This creates a problem for external systems, such as modems which perform internal compression to aid performance. Take Text for example. Usually text can compress by 90%. With encryption this compression reduces to 0%. It is therefor a good idea to compress files before encryption. Since we are compressing, we might like to compress multiple files - in which case I think the use of zip format would be the most sensible. |
| Mailing List Comments |
| from: Grant Black |
| I think this [encrypted
attachments] section needs to be clarified. I think you
are saying that you can attach multiple files but then
each file (or block) is actually a collection of 4 files.
If so how are the files tied together (by name/MIME ID)?
Do the files have a type (an extension under win32?). I
probably need to refresh my memory when I get home &
look at the MIME RFC. Might have to beware of UniCode and allow for 2 bytes per char filenames, (I have recieved documents from Asia that have unicode names). I think there is a good case for allowing the sending of multi-recipient files in business. When sending tender and other contract documents it is sometimes important that it is transparent that all parties received the same document at the same time. For instance when preparing bids for projects most companies would want to ensure that they received the same proposal details at the same time as competing companies. Does it [compression] matter for ID-Trans? I guess I saw the system as passing around business objects like invoices or receipts which tend to be small bits of text/XML - compression seems overkill in these cases. If large files or large groups of files are being exchanged, then that could be an extension of the system to allow for different file formats - after all you don't want to force zipping on a company that might be trading (legally!) MP3/MPeg or JPG's files. |
| from: Nicholas Hynes |
| RE: REPLY TO THE DEVCENTRE SECURE E-MAIL SPEC... had a look at the spec. As you know, I'm not an encryption expert, so I've focussed on some basic design decisions. Perhaps the standard would benefit from wider discussion. Have you invited comment from any international news groups? It's always interesting to get different points of view, and could lead to wider acceptance. Okay, my opinion... 1/ Is it wise to advocate the use of un-encrypted e-mail? I know that people CAN use PGP if they want, but are they likely to actually do that? You know what people in business are like, they'll think 'it conforms to the standard, that should be secure enough', and yet eavesdroppers will still have access to: the name of the companies involved, any name/reference number they give the transaction, subject & message body from the unencrypted message. If this is a must have requirement, then perhaps the standard needs to include rules about what can/must/can't be included in the main message. 2/ Filenames should be of a specified nature - makes it possible to save on multiple platforms, and can help track transactions without the receiver having access to the un-encrypted content. We don't want every attachment to be called 'attachment', because if it gets disassociated with information about how to decrypt it, then there will be no way of tracking it. On the other hand, if the filename gives away too much, it could be used by the evil people. 3/ Perhaps we should make the length indicators 4+ digits. It's a small, small overhead in modern times, and we don't want another Y2K meltdown. 3a/ Perhaps we should stardardize each block of the message (i.e. add a length indicator to the final block). This may make it easier to extend the protocol in the future??? What do other's think??? What about a block id??? 4/ How about a protocol version number somewhere. That
will allow people to continue using the existing
channels, if & when the specification is upgraded.
The version number should have, at least, two distinct
parts. One for the sent version, one to indicate which
versions can reliably decrypt the message. In reply to your questions... 1. Multiple Recipients. Can't think of a solution to this. You're right though, encryption & signing should be mandatory, there's no point in having a spec that is foiled by idiot users. Can think of uses for multiple recipients though, there are some business transactions that involve three or more separate legal entities. Each RECEIVING party will need some way of ensuring that all parties have been privy to the same agreement/correspondance. 2. Including Recipients and Senders Email Addresses. This is a really tricky one. You don't want people to know who is doing business with who. That info is valuable commercial information. Companies are VERY secretive about this sort of information. Even if the e-mail addresses aren't included in the message, the actual transfer medium (SMTP) requires it be included. Perhaps we need a trusted intermediary, which could recieve a message with two encrypted parts: firstly it has an encrypted header that indicates who the sender & receivers are, secondly it has the original data, encrypted with a different key, which is unknown to the intermediary. All transactions, from any company, can only be traced as far as 'from X to the intermediary', or 'from intermediary to Y'. Given both bits of information, a company could probably piece together who is talking to who. Perhaps the intermediaries need to bundle/unbundle multiple packets & distribute them accross an IP-tunnel style network... [phew! this is getting huge... sounds like a publicly owned VPN...] 3. Compression. Currently there is no compression
involved in this |
| Home |
email_spec2.htm 100744 765 764 17375 7247554560 12213 0 ustar html html
| Secure Email Specification (version 2) Discussion |
This message document a discription of what I have so far as a specification for secure business document transmission. There is also a discussion about the proposed specification. Please feel free to email peterha@nothingbutnet if you have any comments to add. Notes regarding PGP and S/MIME: I am looking at how I can be compatible with either PGP or S/MIME, while still being able to achieve the project objectives. |
| SMTP / POP3 |
| Messages are transmitted via attachments within standard SMTP messages. The Message Bodies themselves are not encrypted, only the attachments. Each Attachment is a Encrypted File. Each attachment potentially can be separatly opened or saved to disk for later decryption. Attachments are via standard MIME. Text Messages can still be sent however, by including a text file inside the attachment. |
| Encrypted Attachments |
| Each Encrypted Attachment has a five types of data
'block': Version Block Session Key Block Directory Block Signature Block Data Block |
| Version Block |
| The Version Block provides information about which
version of the software was used to create the encrypted
file. 1 byte - Literally 'V' to signify start of a
Version Block. |
| Session Key Block |
| The Encrypted Session Key is a random session key
used by the symetric AES algorithm to encrypt and decrypt
the main file data. By using RSA to encrypt the session
key only the recipient can decrypt the session, and
therefore decrypt the main file. The encrypted session
key is stored in the following format : 1 byte -
Literally 'K' to signify start of a Session Key Block. When encrypting a random session key is generated and encrypted with RSA using the public key of the recipient. The receiver uses his private key to decrypt the session key, which is then used for the main data. There can be multiple Session Key Blocks, one for each recipient. |
| Directory Block |
| The Directory Block consists of the filenames and
sizes of the data being sent.. 1 byte - Literally 'D'
to signify start of a Directory Block. (All data from this point is encrypted with the
session key) |
| Signature Block |
| The Signature Block is a MD5 hash of the original
data in the files, encrypted with RSA using the private
key of the sender. On decrypting the main data the
recipient can check the hash provided with one calculated
from the decrypted main data. If the hashes match the
recipient can be sure that the file was encrypted by
someone with access to the private key that corresponds
with the public key on file for the sender. In other
words, it ensures the apparent sender of the file is the
actual sender of the file. The format of the signature
block is in the following format : 1 byte - Literally
'S' to signify start of a Signature Block. |
| Data Block |
| The Data Block is simply the data of the original
files appended sequencially according to the Directory
Block compressed with the Zip algorithm, and encrypted
with the Session Key using the Rijndael algorithm. Its
format is simple : 1 byte - Literally 'M' to signify
start of a Main Data Block |
| Home |
id/ 40755 765 764 0 7256336160 7551 5 ustar html html id/xmlschemas.htm 100744 765 764 12324 7265024322 12541 0 ustar html html
| XML Document Schemas |
| It is clear that the Internet Documents will be XML. Currently there are a number of Business Document XML projects underway. My desire is to use industry standard XML schemas in order to maintain compatibility with existing implementations, and to ensure the widest possible utilization of this project. |
| XML Schema Projects |
| There are many projects developing XML schemas for
everything under the sun. However, there are some front
runners I believe which I have detailed in my Business to Business Resources. In addition IDTrans has developed its own XML source code. This is aimed at working with XML with a lightweight code base, rather than the heavyweight approach of Document Object Models. To date this approach has worked very well, although it will need continued work. While initially only available for Delphi, the XML code will be ported to Java and C. |
| The Role of XML within IDTrans |
| All Internet Documents will be XML documents.
Furthermore those documents will conform to standard
definitions that will be incorporated into the software
for invoices, statements, orders and other business
documents. There will be minimim requirements for various documents. For example, a invoice will need to contain the sender and receipeint data. It will need to include a Invoice Number, and Invoice Date etc. Every invoice will have common features. This will ensure that you do not need to obtain a schema from your receipient before you can send them a document. If you send an invoice you know the receipient will be able to parse the invoice. |
| Children Schemas |
| My plan is to incorporate inheritance into schemas. For example, I will distribute a standard Invoice, Statement, Order etc. People will be able to 'inherit' from the standard Invoice to add properties of their own, without redefining the whole invoice schema. If you write in Delphi or Java you will already be familar with the concept. The advantage of this is that you can send a invoice created from a special invoice schema (ie the schema adds properties to the invoice not normally present in the standard), and the receiver will still be able to make sence of the invoice. They have the option of downloading your inherited schema if they want to parse the additional fields, but they don't need to in order to find the basic invoice data. Furthermore, all the standard documents would inherit from a single top level document - and you would have a naming convension for people to add their own schemas.ie, |
| Home |
| Encryption Algorithms |
| Over the last few months the project has developed an
implementation of IDTrans which depends on two encryption
algorithms. Those are Rijndael (AES) and RSA. We may add
other algorithms as required, such as a signing
algorithm. The reason we currently use only two algorithms is simplicity. Adding further algorithms would make the system more complex, but not add anything to the security. Also included on this page is a Specification, now in draft number 2. This provides more detail about the specific implementation being used. This page also provides information about other algorithms under consideration. |
| Why do we need encryption? |
| Requirements |
| Secure Email Specification |
| The Secure Email Specification is the current incarnation of a description of the implementation we are currently working towards. It includes the use of Rijndael and RSA. |
| AES - Rijndael |
| In October 2000 the Advanced Encryption Standard was
announced in the US by the National Institute of
Standards and Technology. The winning encryption
algorithm was Rijndael. The Rijndael developers are
Belgian cryptographers Joan Daemen and Vincent Rijmen
(pronounced Rye'-mun) of Katholieke Universiteit Leuven. Rijndael does not have any patents against it or any of the optimized maths required to implement it. It stacks up well against other algorithms in performance, security and scaleability. It has implementations written in at least C, Java and Delphi, all of which are now public domain or shareware. |
| Blowfish / Twofish |
| Blowfish and Twofish are fast and it is not patented. It is also supported by Open Source libraries already, including Java, Delphi, C++, and C. It is not as old as some more well known systems however. Twofish is a more modern version of Blowfish. I have found free implementations of Blowfish in Java, C, C++, and Delphi. |
| MD5 |
| MD5 is one of the most common hash functions available. It is also very widly implemented in libraries, including Open Source Libraries. I have found implementations of MD5 in C, C++, Delphi and Java. |
| ElGamel |
| ElGamel is a Public Key Algorithm. It is not patented, which makes it attractive. It has been implemented in C++, Delphi and Java, but the Java code to this is still not stable. |
| Elliptic Curve |
| Elliptic Curve is a another Public Key Algorithm. Like Elgamel, it is not patented. There is an implementations available in C, C++, Delphi and Java. |
| RSA |
| RSA is currently the most popular form of public key cryptography. This algorithm was patented until September 2000 when it was released into the Public Domain. There are many implementations of RSA for most languages. |
| Home |
| Transport Protocols Specification |
| The form of Transport used by the Internet Document
API will be SMTP and POP3 compliant. In other words we
will be using email to transport our documents. This is
because there is no compelling reason to develop a
separate method of transport. However, SMTP and POP3 will probably not be the only protocol required to make the project fully functional. The one specific instance of another form of communication is Public Key Distribution. The Public Key Server will use its own protocol to transmit and verify Public Keys. (see Public Key Server) It is possible that the Open Source system called Jabber will be used for some functions. Jabber is an instant messaging system. It could be used to hold public keys, and to transmit XML Documents. Jabber has been developed around transmitting XML. Emailed Documents themselves will be MIME attachments inside Emails. This way, even if a non Internet Document mail reader receives an email, the attached file could be saved and later imported into a Internet Document Accounting System. Documents transmitted by Jabber will be encrypted and included inside an XML tag. |
| Catelogs |
| Catelogs are slightly different to other documents in that they are distributed to a wide number of users, rather than a single recipient. Also Catelogs will generally be large, containing not only text, but images and graphics that are displayed to the user when browsing. Catelogs will still be able to be sent by SMTP/POP3, but will also be able to be retrieved from a web site via HTTP protocol. |
| Home |
| Application Programmers Interface Specification |
| The Internet Document API will provide all the
services for sending and receiving Internet Documents.
The following page is just a draft of what it could look
like. It will be implemented in Java, C, and Delphi. The implementations may differ slightly, as the languages themselves all have different syntax. Suggestions about how the API should be implemented would be appreciated. Send any comments or ideas to Peter Harrison |
| Outline |
| The API is split into two functional areas, the Document Interface and the Transport Interface. The Document Interface will be able to manipulate, load, save and verify XML Documents. Essentially the Document Interface will be a implmentation of DOM. The Transport Interface will be used to transfer any kind of data over via email, taking care of issues such as encryption and signing. |
| Document Interface |
| The Document Interface is actually a lightweight XML
'Parser'. Its not a validating parser, it is just able to
read and write XML documents. Class: TIDXml Properties: XML Node Methods: GetValue( node : String ) : String GetCount( node : String ) : Integer AddNode( node, newnode : String ) AddElement( newnode, value : String ) EditValue( node, value : String ) |
| Transport Interface |
| The primary strength of the Transport Interface is
the way I plan to handle Public Keys. One of the biggest
problems I see currently is that people need to worry
about how to obtain public keys. With this API, the
details are more hidden. Once you generate your own Key
Pair, and you get the PKServer List, the sending an
receiving of encrypted emails is automatic. Any required
public keys are downloaded for you. GetPKServers(); PrivateKey GeneratePrivateKey(); PublicKey GeneratePublicKey( PrivateKey ); PKAddress SendPublicKey( Name, Email, PublicKey ); PublicKey GetPublicKey( PKAddress | emailAddress ); If an email address is supplied each PKServer is contacted in turn and queried. Naturally using email addresses for Public Key resolution is not the prefered means of obtaining a Public Key due to the huge comms overhead. PS : Any ideas on how we could make email public key resolution faster? PublicKey VerifyPublicKey( PKAddress | emailAddress
); If an email address is supplied each PKServer is contacted in turn and queried. Naturally using email addresses for Public Key resolution is not the prefered means of obtaining a Public Key due to the huge comms overhead. The Verification consists of a MD5 of the Public Key, instead of the Public Key itself. The MD5 is shorter than the Public Key. SetEmailSettings( emailaddress, pop3server,
smtpserver, pop3password ); SendEmailFile( emailaddress, PublicKey, FileName ); SendEmailStream( emailaddress, PublicKey, Stream ); GetEmailHeaders(); GetEMailtoFile( number, Filename ); GetEMailtoStream( number, Stream ); DeleteEmail( number ); |
| Odds and Ends |
| Further things to think about: |
| Home |
id/idclient.htm 100744 765 764 3343 7265672654 12172 0 ustar html html
| Client Application Specification - ODYSSEY |
| The client application currently in development is
called ODYSSEY. It is a modern email client, and in
addition can automatically handle encryption and
compression of email. It can also create and send
Business Documents, and browse Catalogs. It is currently being developed in Delphi, as this is what I know. The API is not language specific, so my decision to write the 'reference implementation' of the client in Delphi should not be a concern. By writing in Delphi and avoiding calls to the Windows API I should be able to have a Kylix port of the Client when Kylix is released. Kylix is the Linux port of Delphi, which promises to make a huge impact on the number of available applications on Linux. The first beta release of ODYSSEY should be available in early May 2001. |
| Home |
| The Trust Network - distribution of public keys |
| The Trust Network is an important part of the whole
system. Its purpose is to store public keys so that they
can be retrieved. The problem is that when you send an
email to somebody, and if you are using public key
crypto, you need to know their public key. Current client
software requires you to obtain the public key by some
means before encrypted communication can begin. By having your Public Key stored on a server people can obtain your public key at any time. And because you can also interrogate your public key yourself at any time you can ensure the public key has not been replaced. Once someone has your public key it is stored on their machine, and verified against the public key server when used. This increases the chance that a man in the middle attack is detected. An additional security feature may be signed keys. This is effectivly a certificate. It means that the public key has been signed by the server as geniune. This means that any attempt to replace the key in transit will break the certificate. |
| Receiving Keys |
| The Server will receive keys by having the client
connect to the server go through the following protocol : |
| Obtaining / Verifying a Public Key |
| The Server will distribute a public key to any client which requests one using the following protocol: Client sends a message requesting the public key of a specific email address in the clear. This is not encrypted as there is no secret information to be protected. Server looks up email address and sends the Public Key signed by the Private Key of the owner of the Public Key. This protocol is the same weather requesting or verifying a Public Key. |
| The Trust Network |
| Public keys are used for both Encryption and
Verification, so ensuring you have the correct public key
is vitally important, otherwise your encrypted
communications are vunrable, and you cannot be verify
where messages come from. The traditional way of ensuring distributing public keys was a trust tree, where some organization at the top of the tree signs certificates of organizations below. In turn those organizations might distribute certificates and so on down. The purpose of this is to provide some certainty that the public key you have obtained is really the public key of the intended receipient of a message, and not a spy in the middle. The Trust Network is a set of Public Key Servers. Each server on the network has a full list of the other servers.When a new public key is received it sends the public key via secure channel to two servers on the list at random. These two servers will then periodically query the original server to ensure the Public Key has not been tampered with. Should tampering be detected by a server, it will send out a message to all the servers on the server list to check the server under suspicion. Each server will then query the Public Keys it has stored against the suspect server. Any Public Keys that have been tampered with will generate an additional message to the suspect server informing them of the mismatch, and what the correct key should be. If a server gets corrections from two servers for a Public Key it will change the Public Key stored to the one supplied, assuming the Public Keys from the other servers match. If a suspect Public Key is not corrected even when these messages have been sent to a server, the entire server will be marked on the list as 'defective'. A new server will be chosen to host the keys that previously belonged to the defective server, and all Public Keys stored on other servers relating to the defective server will be transmitted to the new server. The new server will only accept Public Keys if it receives two copies from different servers. The result of all this is that servers which have been hacked or modified in such a way to allow false Public Keys to be distributed will be discovered, and if the problem is not resolved, will be eliminated from the 'Trust Network'. |
| Lightweight Directory Access Protocol |
| The LightWeight Directory Access Protocol is already being used in a system much like that described above. In all probability we will end up using this protocol and the open source implementations of it to deliver Public Key Distribution. PGP uses LDAP to distribute keys. Like many of the other standards and protocols I have already found, I am investergating how this can be incorporated into the project. |
| Home |
Document Signing Service Specification |
| Catalog Package Specification |
| The Catalog Package will typically be a compressed
archive of files. There will be a single XML file which
stores information about the products, prices, and will
have links to HTML pages from products. The HTML files
will then link to image files. This means generation of the HTML and images can be done with standard tools, and rendered on the client side using a standard web browser. The XML will be parsed by the Client internally. The initial version of the Catalog will have no business logic in it. However this is an open area, in that business may want to include some kind of business logic script in the catalog to perform bulk discounts and other calculations. |
| Home |
| Platforms |
| The project will attempt to be as inclusive as possible with supported platforms. The objective is to support the largest number of computer systems as possible with the available resources. |
| The Internet Document API |
| The Internet Document API will be available for every
major programming language. The following is a list of
languages which an API will be available for C, C++,
Delphi, Java and Visual Basic. The API will come in the form of libraries, which can be included in applications in any way the programmer wants, ie as a DLL, statically linked etc. In Java it will usually be implemented as a single jar file. In Delphi it will probably be a component set. To some extent they may have interfaces, however the primary methodology of using the API should be the same between language implementations. |
| Server Side Applications |
| I intend to write the first implementation of Server
Side Applications in Java. I don't believe there is much point in writing the Server Side Applications in several languages at the same time. My intention is to concentrate in writing the Server Side applications in one langauge that is currently common on the server side. This implementation can then become the reference implementation so other languages can be ported. |
| Client Side Applications |
| I intend to write the Client Side Applications in
Delphi. This is simply because I know Delphi, and I know
that a working product will be very quick to develop
compared to the alternatives. There will be API's for every language, so although I am writing the Client in Delphi I am not limiting anyone to Delphi. Delphi has the advantage of a large number of component developers who have released source code for free. This includes implementations of cryptography, compression, and TCP/IP communications. |
| Home |
| Open Source License |
|
After doing some evaluation I feel the following license has the best for for this project. The primary difficulty this license avoids is the difficulty of incorporating GPL source code into commercial products. My intension is to incorporate the source code to the Project into as many accounting systems as possible, and therefore a restrictive license is not desirable. The GNU Library General Public License allows a library to be incorporated into a commercial product, and is therefore more appropriate for this project. The full license is posted below. |
| GNU LIBRARY GENERAL PUBLIC LICENSE |
Version 2, June 1991
|
| Home |
The Internet Document ProjectThe following pages are the official planning and respository pages for the Internet Document Project
|
| News | Resources |
Odyssey Email - The ClientOdyssey Email is the name of the email client which is currently in development. The first release of a beta should be ready by May. Its primary feature improvements over Outlook Express will be 'invisible' encryption - so easy to use you don't know you are, and the ability to send and receive invoices and orders. The source code is already available via CVS, and the project is always looking for developers to aid in the development of this and other technologies in the project. IDTrans CVS Repository Lightweight XML SystemFrustration in finding a lightweight, easy to use XML parser over several months lead me to write my own 'paser', which is now part of the IDTrans project. The lightweight parser allows easy writing and access to XML documents without heavyweight object models such as DOM, but retaining the random access features of DOM. The source for this is currently in CVS. Source Released on SoureForge
Secure Email Specification DiscussionThanks to several helpfull emails I have made some modifications to my original specification for secure email. Secure Email Specification - version 2 Open Source License AvailableThe License that will be used for all source code developed for the project is now available. The license is not the GPL as this would have had implications for working with the commercial developers that the project intended to work with. Instead the license allows unrestricted copy and modification. ComputerWorld on the ProjectComputerWorld recently ran a story about the project. Feedback from the article has been very good, and I hope to build on this success. I am now talking with several companies about joining the project. Profax Accounting has already joined, and will no doubt be looking to incorporate the project code into Profax next year. ComputerWorld on the DevCentre Project |
SourceForge
- Summary Provides access to all IDTrans pages on SourceForge. SourceForge
- Forum SourceForge
- Downloads SourceForge
- Tracker Documents Objectives Business Case Open Standards Real API Real Software Security Catalogs This site hosted by: |
| Technical Documents | DevCentre.Org |
Platforms XML Schemas Encryption
Algorithms Transport
Protocols Application
Programmers Interface Internet
Document Client Public Key
Service Catalog
Packages |
DevCentre.Org is a resource for developers of Open Source projects. The site is primarily related to technologies for enabling Business Communication over the Internet. |
| License for IDTrans Source Code |
| Copyright (c) 2000, Internet Document Transport
Project (IDTrans) Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Note : This License covers source code written as part of the IDTrans Project only. Other source code used in the project, such as encryption and communication libraries have their own license. All source code included in the project is able to be copied and modified however, as any source code that excludes these terms is not used. |
| Home |
| Wouldn't it be great... |
| Wouldn't it be great if you could receive your phone
bill, electricity bill, bank statement, and any other
kind of invoice or statement, by email. Wouldn't it be
great if once you receive your invoice you could transfer
it to your accounting system. Wouldn't it be great if you
could send your customers your invoice, and they could
pay it electronically once they receive it. I see a
future where most paper documentation is replaced by
Internet Standard Documents, and we can all send business
documents as easily as we do with email today. With the rise of the Internet email has now become a required part of business. A vast majority of businesses, and a huge number of consumers have access to email and the Internet. What is surprising is that despite this revolution in communication a vast majority of companies still send physical invoices and bills to each other and to their customers. This projects primary goal is to introduce a method of transmitting business documents between different organizations without a requirement to coordinate the format of documents prior to transmission. In other words, you can send an invoice without the worry of the receipient not being able to import the invoice. |
| Project Objectives |
| The DevCentre Project has some very specific
objectives: The project as a whole has the following principles: |
| Home |
| Project Sponsors |
DevCentre thanks the following sponsors for their support of the project to date. Without the help of our sponsors this project would not be possible.
|
| Home |
| Summary |
| This brief discussion document is intended to provoke
thought about how we can make the most of the Internet in
business. By working together to create standards and
Open Source tools based on those standards we can all
intergrate our financial systems better than ever before. This document is simply a jumping off point. On this site you will find more detailed specifications and research. This includes Open Source resources which will make a major part of the project. Over the coming months you can also expect to see discussions, source code, and working product. The goal we have set is not an easy one. We need help to achieve the goals. Our aim is to approach accounting system companies, banks, and other organizations who would benefit from this project in order to fund the project. If you think you would benefit from this project, or would like to be involved in its development, please Register your interest by clicking Register Below. |
| Home Register |
