CONCLUSIONES

This protocol will make use of X.509 version 3 certificates[22] with the addition of a specialized subject alternative name extension that will be used to help identify the client, route messages, and provide a means of separating different types of messages. Each user will have a certificate that will verify their ownership of a private key and contain its associated public key. This key pair will be created by the client when setting up their account. After the key pair is created, the certificate will be acquired automatically. This will require that a user either verifies their identity at this time or that the user has already verified their identity to a certificate provider. Certificates will also be required for the mail servers and certificate servers. Appendix E below shows an example of a certificate created for a user of this system.

5.2.1 Subject Alternative Name Extension

The subject alternative name extension is a X.509 certificate extension that was created in order to allow for additional identities to be bound to a subject of a certificate. According to the X.509 version 3 standard, the contents of the subject alternative name

extension are considered definitively bound to the public key and must be verified by the CA. For this system, the subject alternative name extension will contain the following information: a version number, the name of the owner of the certificate, the alias of the owner of the certificate, and the certificate type. User certificates will also contain a mail server entry which will point to the fully qualified DNS address of the user’s mail server. Also for user certificates, the issuer may elect to include affiliation or title information. Certificate server certificates must also have a signer authentication value. Appendix F below shows the ASN.1 definition of the subject alternative name extension used in this system. Additionally, a sample of this extension can be seen at the end of the certificate in Appendix E.

For certificates that use the system described in this document, the version number should be 1. The name of the owner would be the user’s full legal name in the case of a user certificate, or the name of the owning organization in the case of a server certificate. Aliases, which are the same as mail addresses, will be discussed in Section 5.3. Certificate types and signer authentication values will be discussed in 5.2.1.1. The affiliation and title values would be used, for example, by a company that issues certificates to its employees. The affiliation would allow the company to indicate that the user certificates they are created are for their employees. The title value would allow the company to give each user a specific title. This allows users to more easily identify who they are communicating with, and adds another layer of protection against identity spoofing.

5.2.1.1 Certificate Types

associated with a given certificate. For users, certificate types will make it easy to tell what type of sender has sent each of their received messages and will prevent users from spoofing their affiliation or associations. In other words certificate types are concerned with how entities are portraying themselves when they send mail messages, encrypt data, or sign data. Each certificate type may require a different level of identification validation depending on the security level of the certificate type. This system contains the eight certificate types listed in Table 1.

Certificate Type Intended Use

Personal Messages from an ordinary user.

Business (General) Messages from a business. No financial information/transactions. E-Business Messages from a business. May be used for financial transactions. Financial Institution Messages from a financial institution (such as banks).

Government Messages from a government entity (such as the IRS). Mail Server Used by a mail server for TLS communication.

Root certificate server Used by root certificate server to sign subordinate certificate server certificates and TLS.

Subordinate certificate server

Used by subordinate certificate servers to sign user and mail server certificates and TLS.

Table 1. Certificate Types

Each of these eight certificate types has its own possible uses. Personal certificates could be used for sending secure personal communications between any two people (for example between family members or friends). A personal certificate would not be tied to any business or organization. A personal certificate could also be used by a customer sending a message to a business. A general business certificate could be used for a business that wants to communicate with customers or other businesses through secure messages but would not be used for anything financial (for example, soliciting account or payment information, sending e-bills, etc). An e-business certificate would have the same purposes as a general business certificate but would also allow the business to perform secure financial business. As the name suggests, financial institution certificates would be for identifying messages coming

from financial institutions such as bank, credit unions, brokerages, etc. The government certificate type could be used by a government in order to communicate official messages. For example, in the United States, the Internal Revenue Service (IRS) may want to deliver tax related information to its citizens via internet mail. This type of a message would be signed with a government certificate in order to verify that the sender was actually part of the indicated government entity. The last three types of certificates are used as described in the table above.

It is important to note that while the certificate type dictates the type of messages a user is allowed to send, it does not impact the type of messages the user can receive. So, while a personal user cannot send messages and appear to be a business user, that personal user could receive e-mail from users with any of the other types of certificates (for example, a personal user could receive a message from a user with a government certificate). Also, the type of certificate does not affect the confidentiality, integrity, or authentication aspect of the message. In other words, messages sent by someone possessing a personal certificate would be encrypted and signed using the same method and key type of someone possessing a government certificate. It is not the intent of the certificate type to be used for securing data in different ways but rather to help a user determine exactly who a message is coming from and if the information contained within a message is valid coming from a specific sender.

As mentioned before, certificate servers will only be allowed to issue certificates of certain types. This will allow users to easily ensure the message content they are receiving is valid coming from the type of user indicated by the certificate type. For example, if a user receives an e-mail requesting that he update his bank account information from a mail address linked to a personal certificate, clearly this is likely a fraudulent request. By using

Figure 5 on page 19 as an example, you can imagine what this may look like. Above the message it would clearly indicate the sender had used a personal certificate, instead of a financial institution certificate. There would also be no bank name or title shown. Similarly, if a user receives a message signed by a government certificate, but the certificate server that has signed the certificate is only authorized to sign personal certificates, the message and the certificate is likely fraudulent. In this case, the client should automatically detect this, and would not display the message. A subordinate certificate server that is signing certificates that it is not authorized to sign would need to have its certificate revoked by the root certificate server as it would not be acting in accordance to the rules of the protocol. These certificate types will be an integral part of the secure mail system. By having this information readily available, it will make it much easier for the user to determine when an e-mail is likely not from a legitimate sender.

An additional related piece of the subject alternative name extension is the SigningAuth value. This value is used to specify which types of certificates a given certificate server is allowed to create. Each of the certificate types is given a value as shown in Table 2 below. The values that a given server is allowed to sign are added up and inserted in to the subject alternative extension as an integer. This allows users to verify that the signing certificate was indeed allowed to sign certificates of a given type.

SigningAuth Value Certificate Type

1 Personal 2 Business (General) 4 E-Business 8 Financial Institution 16 Government 32 Mail Server

64 Subordinate Certificate Server