Possible Approaches to Certification Authority Implementation

MASARYK UNIVERSITY

FACULTY OF INFORMATICS

¦¨§

! "

¤ ¥

# $

¢ £

F G H

% &

D E

')(+*

? @ACB

,.-0/132 46587:9<;>=

Possible approaches to certiﬁcation authority implementation

DIPLOMA THESIS

Jan´ Lieskovsky´

Brno, 2007 Declaration

Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

I would like to express thanks to prof. RNDr. Jozef Gruska, DrSc., Doc. RNDr. Vaclav´ Matya´s,ˇ Ms.C Ph.D and Ing. Mgr. Zdenekˇ Rˇ ´ıha, Ph.D for their explanatory, exhaustive and interesting courses and materials related to the topic of cryptography that brought me round to the complex, mathematical and beautiful world of computer security.

My special thanks to my adviser Doc. RNDr. Vaclav´ Matya´s,ˇ Ms.C Ph.D for his perceptive leadership, showing me the direction, this work should follow, in times of doubt and for his patience during my study of this complex topic.

ii Keywords certificate, certificate authority, certificate request, extensions, PKI, QCA, registration authority, signature algorithm, subject of the certificate, X.509

iii Abstract

The presented work covers the subject of certification authorities and related topics. First, we discuss the relevant cryptography areas, like public- key cryptography, hash functions and digital signatures which are used in the digital certificates. Then we analyze the particular parts of the public- key infrastructure (PKI) to be able to determine the CA position in it and to separate the function, it should perform. Further we discuss in more detail the structure of the digital certificate request and digital certificate. We fo- cus on the extensions, in order to exactly describe the meaning of particular extension and relations between them (like allowed combinations of bits in the “KeyUsage” extension).

In the second part of our work, we analyze current approaches to a CA implementation. We discuss them in order to select our own approach. In the end, we describe library used and tools and talk about gained experiences and insights.

This diploma thesis should also provide information needed for CA implementation – introductory describing basic principles, CA functions and methods, structure of issued electronic documents, as well as description of currently used CA implementation techniques. A result of this investiga- tion should be a fully functional CA, implemented by us.

iv To Vierka Contents

1 Introduction ...... 4 1.1 Overview and structure of this diploma thesis ...... 4 2 Cryptography and certification authorities ...... 6 2.1 Important cryptographic properties ...... 6 2.2 Symmetric-key cryptography ...... 7 2.3 Public-key cryptography ...... 8 2.4 Hash functions ...... 10 2.5 Digital signatures ...... 12 2.5.1 Features of digital signatures ...... 14 3 Internet public-key infrastructure (PKI) ...... 15 3.1 Public-key infrastructure (PKI) ...... 15 3.1.1 E-commerce scenario ...... 16 3.1.2 Registration Authority (RA) ...... 17 3.1.3 Certification Authority (CA) ...... 19 3.1.4 Subject of the certificate – End entity ...... 20 3.1.5 Receiver of the certificate – Relying party ...... 20 3.1.6 The Repository ...... 21 3.1.7 X.509 (RFC 3280) [8] ...... 21 3.1.8 Certificate revocation lists (CRL) and Online certificate status protocol (OCSP) ...... 22 4 From certificate request to digital certificate ...... 26 4.1 Digital certificate request (DCR) ...... 26 4.2 Types of extensions used in digital certificate requests and digital certificates ...... 30 4.2.1 Authority Key Identifier ...... 30 4.2.2 Subject Key Idenfitier ...... 31 4.2.3 Key Usage ...... 31 4.2.4 Subject Alternative Name ...... 34 4.2.5 Basic Constraints ...... 36 4.2.6 Extended Key Usage ...... 36 4.2.7 Inhibit Any Policy ...... 38 4.3 Digital certificate (DC) ...... 39

2 4.3.1 Self-Signed and CA certificates ...... 42 5 Possible approaches to the certification authority implementation 43 5.1 OpenCA (OpenPKIX) ...... 44 5.2 Java Cryptographic Architecture (JCA) [15] ...... 47 5.3 What features we need to realize CA via the “library” approach 48 6 Qt Cryptographic Architecture (QCA) ...... 51 6.1 Description ...... 51 7 Qintca – CA implemented in QCA ...... 53 8 Conclusions ...... 60 A Examples of digital certificate request and digital certificate . . . 66 A.1 Example of digital certificate request ...... 67 A.2 Example of digital certificate ...... 68 B Digital certificate request and digital certificate creation . . . . . 69 B.1 Using the OpenSSL suite ...... 69 C Sample related QCA class ...... 71 C.1 Look and methods of the QCA::CertificateRequest class . . . 71 D Qintca screenshots ...... 75

3 Chapter 1 Introduction

“How is an error possible in mathematics?”

Jules H. Poincare

Nowadays, communication over the Internet and the possibility to use various Internet services is gradually becoming available to a wider part of the population. We can benefit from usage of electronic mail, chat, file- sharing and file transport. We can watch movies or lectures, listen to mu- sic and play games. Besides this ”amusement” part, there is also the far more visible “official part” of Internet. Many government organizations have their electronic equivalents. We can reserve and buy tickets and watch the meteorological progress or stock options on-line. So the “electronic life” is becoming more and more a part of our ordinary life. This fact is bringing as well as new challenges and responsibilities for us. We should take more care about topics like cryptography, digital signatures, computer security, subject authentication and authorization. We want the benefit of these new Internet possibilities while simultaneously protecting our property, identity or other things important for us like our medical records and bank account numbers etc. To achieve this goal we need to be more and more interested in modern computer security and the techniques it can provide.

1.1 Overview and structure of this diploma thesis

The aim of the second chapter is to pinpoint and explain cryptographic terms, that may be needed for CA implementation. It is an attempt to collect and deﬁne such terms.

In the third chapter we are describing the infrastructure that is needed to be able to meet four security goals.1 We are focusing on particular items

1. The list will be provided in section 2.3.

4 1. INTRODUCTION of Public-Key Infrastructure (PKI) and explaining what it consist, of, the function of its speciﬁc parts, what they can be used for and where we can ﬁnd its representatives.

In the fourth chapter we continue in developing the image of the PKI by describing the exact structure of digital certificate request (DCR) and digital certificate (DC). Some portion is also dedicated to the description of the process of creating the digital certificates from DCRs.

In the ﬁfth chapter we are trying to describe and analyze current approaches to certiﬁcation authority implementation. We describe the char- acteristics of representatives in each category by comparing these various ways. Then we select one to implement our CA.

The content of the sixth chapter is dedicated to the description of the structure and function of the Qt cryptographic architecture (QCA) – the library we have chosen for our CA implementation. We are discussing its parts, describing the selection proces and focusing on details of its classes.

The seventh chapter is a summarized overview of insights and impres- sions experienced by the creation and implementation of our CA. We present a description of tools used, applications and algorithms. We also provide a TO-DO list (list of desired future possible enhancements and features).

The conclusions is dedicated to the summarizing of goals, we have successfully reached and speciﬁcation of the meaning of this diploma thesis.

In the attachment one can find an overview of the usage of OpenSSL suite for the creation of digital certificate requests, end user and self signed CA certificates.

5 Chapter 2 Cryptography and certiﬁcation authorities

“The enchanting charms of this sublime science reveal only to those who have the courage to go deeply into it.”

Carl Friedrich Gauss

2.1 Important cryptographic properties

Let us suppose, we want to design, develop and maintain an e-commerce shop to be able to distribute our products over the Internet. One of the things we need to do, 1, is to make a list of all security goals, we would like to achieve. This is one of the tasks of modern cryptography, we will describe. But let us begin with a short classiﬁcation of the cryptography.

The modern cryptography is usually divided into two categories: • The classical cryptography and • the quantum cryptography.

Functions, principles, methods and algorithms of classical cryptography came out of laws of classical physics – the smallest unit of information is a bit. Octets of bits are combined into bytes (B). Sequences of bits are input into many arithmetical and logical operations, and many classical cryptosystems can be viewed on, as processing such streams of bits.

In contrast, methods used in quantum cryptography, are organized in a different way. The source of this difference is formed within the laws of microcosms and modern quantum physics. Thus, quantum cryptography

1. We will forget the need to organize and ensure the economic related tasks of our business at this moment and take into account only the informatics related part.

6 2. CRYPTOGRAPHY AND CERTIFICATION AUTHORITIES can beneﬁt not only from the mathematical complexity of known cryptographic problems, 2 but also from the combination of these features with unexpected and inconvenient laws of quantum physics, to develop even better and more secure cryptographic algorithms and protocols.

It is a good practice to divide classical cryptography into two groups:

• Symmetric-key cryptography.

• Public-key cryptography [10].

2.2 Symmetric-key cryptography

Kerchhoff’s 3 principle claims: “ The security of transmitted message should not rely on secrecy of mechanism of used encryption algorithm, but on the protection of the shared secret – so called key”. In symmetric cryptography both parts of communication share the same secret key, which is used for message encryption (on the sender side) and decryption (on the receiver side). Today there are a couple of symmetric-key algorithms available. [12] 4 Symmetric- key cryptosystems to encrypt and decrypt messages require the possession of the shared key. This shared key has to be distributed in a secure way (via a secure channel or by face-to-face contact) to both parties, before the start of the communication. But in some cases, prior distribution of the key, is hard to achieve. One suggestion for this problem was made by Whitﬁeld Difﬁe and Martin Hellman, when in 1976 they published the paper “New Directions of Cryptography”. This introduced a radically new method for distributing cryptographic keys, which went far toward solving one of the fundamen-

th 2. As example we can introduce the RSA problem [11] – it is the task of finding e roots modulo a composite number N whose factors are not known. In another words, the problem is to perform the RSA private-key operation given only the public key. A fast means of solving the RSA problem would require to break all RSA-based public-key encryption and signing systems. 3. Auguste Kerchhoff, one of the important scholars from Netherlands, who among others, based the grounds of modern cryptography. In his book from 1883, he has described cryptosystem, which is nowadays known as the Vernam cipher. 4. It is custom to divide symmetric-key algorithms into two groups based on the way the algorithm processes the data, that needs to be encrypted. The algorithm may handle the data like a stream – we call such an algorithms a “stream ciphers”, or it can divide the data into smaller blocks and handle each block separately – “block ciphers”. Examples of the stream ciphers are: FISH, Grain, ISAAC, Pike, RC4, SEAL, SOBER, VEST, WAKE. Block ciphers are represented by: AES, Anubis, Blowfish, CAST, DES, GOST, IDEA, KASUMI, Lucifer, M6, MARS, Q, RC2, RC5, RC6, Serpent, SHACAL, TEA, Triple DES, Twofish, Zodiac.

7 2. CRYPTOGRAPHY AND CERTIFICATION AUTHORITIES tal problems of cryptography and has become known as Difﬁe-Hellman key exchange.

2.3 Public-key cryptography

In public-key cryptography, the problem of distribution the key to the every user is solved by using a pair of keys – the public and the private one. Secure (encrypted) communication between two users in this cryptosystems is performed by following this scenario: User A encrypts the message, that needs to be sent, ﬁrst with his private key and then re-encrypts the result with the public key of user B. This double encrypted message is sent over the network to the recipient – user B. First he uses his private key for the message decryption, and only after that, he re-decrypts the message with the public key of user A, to get the plain-text message – the original message, created and sent by user A. In such case, there is no need for initial shared key distribution, as it is the case of symmetric-key cryptosystems. Effec- tiveness of public-key algorithms 5 rely on a special class of mathematical functions – called “one-way” functions. One-way functions are easy to compute in one way (i.e. to compute the multiplication of large prime numbers), but are almost incomputable (or require too much effort and computational power) the other way (i.e. to factor the multiplication back to prime numbers). Unfortunately only a small portion of generated keys are mathemat- ically secure enough to be used as keys in public-key cryptosystems. These are in most cases much longer than “correspondingly secure” symmetric keys. For this reasons, public-key cryptography is heavy on computational power and time, needed for key generation, compared to the symmetric one. A frequently used solution is to combine both approaches. The slower public-key algorithm securely sends a symmetric session key and then the faster symmetric algorithm takes over the rest of the communication.

Talking about cryptographic algorithms, used by certification authorities, we have to mention both, the symmetric-key and the public-key. Symmetric- key algorithms (typically DES-3) are used for the encryption of the private key of the certification authority.6 This key is of high importance, and needs to be kept safely. It will be used for signing all the certificates, issued by this CA, and in case, it was compromised, all certificates signed by this CA

5. Representatives of public-key algorithms: DH, DSA, ECDH, ECDSA, EKE, ElGamal, GMR, IES, MQV, Rabin, RSA, Schnorr, SPEKE, SRP, XTR. 6. CA as a part of the PKI will be discussed in section 3.1.3.

8 2. CRYPTOGRAPHY AND CERTIFICATION AUTHORITIES would also be compromised. The public-key cryptography is used by DCRs and DCs.7 Once the Registration Authority 8 generates the key pair, the private key is securely transferred to the end user and the public key is used for various purposes (specified in the certificate request – like “KeyAgree- ment”, “CertificateSign”, “CRLSign” etc.) as a part of DCR.

So now we can return back to the basic goals of modern cryptography, introduced in the e-commerce scenario section [20]: • Data conﬁdentiality – means, that no one else, except for the message sender and the receiver, should be able to read the plain-text (unencrypted message). This feature is needed to transfer user sensitive information (like passwords, credit card numbers or medical records) over the insecure Internet link. • Data integrity – each attempt to alter a message during its transmission, should be determine easily. Suppose someone wants us to compromise. What he could do, is to take the encrypted message, we just sent over the network (like the password), change it, (he will not be able to read it, but could add some extra information to it), so that the result would differ from the original message. If such message (password) was not accepted by the authentication interface the repetitive attempts could lead to disabling our account at this interface. • Authentication – this feature can be used in two ways – user authentication and data authentication. Suppose, we have discovered some business solution, we want known only to our business partners (and not to our opponents). – User authentication – in the moment of sending the message, we have to be sure about the identity of the receiver. To achieve this we can beneﬁt from the fact, that our message is encrypted with the public key of our intended recipient and he (she) is the only person, that can use its private key to decrypt it. Similarly, our recipient, by receiving this encrypted message, can be sure, that this message was sent by us. – Data authentication – when we sign a business solution document, it should be easy to identify, whether it was signed by us. Furthermore, it should be impossible to:

7. DCR stands for digital certiﬁcate request. See section 4.1 for more details. DC is abbreviation for digital certiﬁcate. We will talk about DCs in section 4.3. 8. RA is part of the PKI that will be described later in section 3.1.2. 9 2. CRYPTOGRAPHY AND CERTIFICATION AUTHORITIES

1. Falsify both, our identity and the information contained in the document. 2. Later modify document related information without detec- tion.

• Non-repudiation – this feature introduces “one wayness” to the communication and makes time the important part of it. Once you send the message, you can not longer claim, you did not do so (in case your private key was not compromised, of course).

2.4 Hash functions

Suppose the following – data origin determination problem: We want to distribute data over an insecure Internet. How can we ensure, that each later attempt to alter the data will be detectable? How can the data recipient be sure, that he has got, what we sent? The natural way for to solve this problem is to publish the data on our web-server, so that the recipient would have the possibility to compare the received copy with the original. But this approach has the following shortcuts:

• It is vulnerable to impersonation attack – the attacker could create the exact copy of our web-server, 9 and change the DNS infrastructure to point to his web-server instead of ours. It may happen, that our longterm customers would not notice anything suspicious. This malicious scenario includes two possible attacks:

1. The attacker could provide its own, completely different copy of “our” data – full of dangerous software, like viruses, or to retrieve customer sensitive information. 2. We could be easily compromised if the attacker modiﬁed the sensitive information during the transmission.

• It is slow – even, if the previous scenario did not occur and the data was successfully transmitted to recipients, the customers would have to manually compare the copies. This could be hard (for large ﬁles) or even impossible to perform (for large packs of installation binaries.)

9. Including the introductory page on the one side, and the exact name copies of all provided ﬁles, on the other side. The look of such a server would be the same, but the content would differ.

10 2. CRYPTOGRAPHY AND CERTIFICATION AUTHORITIES

So, it would be great, if we could to verify the data correctness, by “ex- tracting” some properties from received data. Cryptographic hash functions (“one-way” functions) provide us with a way to do it. The ﬁrst look at the solution of this problem is the following – we represent the data as number – input of the function. This data (number) is delivered to our customers. Our customers compute the value of this function and compare the result with the value, we publish at our web-server, in the column, corresponding to the initial number. When these two values are the same, the customers can be sure, they got, what we have sent.10 We will now introduce the hash functions more formally.

Cryptographic hash functions are functions, with input of variable length (up to 264 bits for SHA-1 and SHA-256 algorithms and up to 2128 bits for SHA-384 and SHA-512 functions), generate output of constant length (from 160 bits for SHA-1 algorithm up to 512 bits, for the corresponding SHA- 512 algorithm). Of course, the space of input messages is much larger 11, than the space of output messagesThere is a maximum of 10512 output messages.. It is possible that two different input messages (numbers) are projected to the same output message – we say, that a “collision” occurs. Cryptographic hash functions should have the following properties [22]:

• It should be possible to compute the function value – “the message digest”, “hash” or “hash-sum”.

• It should be almost uncomputable to retrieve the initial data (number) back from the “message digest”, i.e. perform the inverse operation – so called “one-wayness” of the hash functions.

• It should be computationally infeasible to ﬁnd another data (number), that if forwarded to the hash function would provide the same result, as the initial data (number). In other words, the probability, − that the collision occurs, should be small enough (smaller than 2 128).

Using hash functions, satisfying previously mentioned requirements, we can easily ﬁnd a solution to the data origin determination problem. Today,

10. Of course, there is also possible to have impersonation attack – this one can be pre- vented, when the server posseses the digital certiﬁcate, electronic document, that will be described in more detail in section 4.3. 128 127 0 11. There is a maximum of 2 + 2 + ... + 2 input messages.

11 2. CRYPTOGRAPHY AND CERTIFICATION AUTHORITIES there are a lot of hash functions available.[1] 12 For purposes of digital signatures, the following functions were used: MD2, MD4 and MD5.13 But there appeared in the recent past a couple of papers discussing the insufﬁcient length of the hash created with the MD5 hash function. 14. The MD2, MD4 and MD5 hash functions are potentially vulnerable to the birthday attack. 15 Thus NIST, in his FIPS 180-2 draft [14], recommends hash functions with longer (160 bits and more) output16, which should withstand this kind of cryptographic attack.

2.5 Digital signatures

A signature is not a part of the substance of a transaction, but rather of its representation or form. There are two types of signatures [16]: 1. Traditional handwritten signature – created with pen on a paper or other material in order to prove the identity of the signer and con- ﬁrm some transaction.

2. Electronic signature – document in an electronic form (digitized image of a handwritten signature or electronic mail headers). It is custom to classify this type of signature into the following categories:

• Basic electronic signature – is an electronic document containing any mark made with the intention of authenticating documents. Examples of this could be digitized images of paper signatures, typed notations like “John Doe” or electronic mail origination headers. These documents can not be considered to be digital signatures – they can easily be copied, attached to any other document and/or even changed after having been created.

12. Examples of well-known hash functions: Gost-Hash, HAS-160, HAS-V, MDC-2, MD2, MD4, MD5, N-Hash, RadioGatun,´ RIPEMD, SHA family of hash functions: SHA-0, .., SHA- 512, Snefru, Tiger, VEST, WHIRLPOOL. 13. These are exactly deﬁned in the FIPS 180-1 [3] standard. 14. For overview of possible attacks on the MD5 hash function see [25, 23] and [24]. 15. There are more than six billion people on Earth. Each of these people has a birthday in one of 366 possible days. Given a particular person A how big group,that there would be probability of at least 50 % , that this group will contain at least two people with their birthday on the same day. This problem is called birthday attack and it has been shown, that a group of 23 people is enough to satisfy this condition. In terms of cryptographic functions this means, that with the current level of technology it would take only hours, to break the output of hashing functions that is only 100 bits long. 16. The SHA-1, SHA-256, SHA-384 and SHA-512 functions belong to these type of hashing functions.

12 2. CRYPTOGRAPHY AND CERTIFICATION AUTHORITIES

• Advanced electronic signature (or digital signature) – is a type of electronic document, that is able with to overcome the three previously mentioned shortcuts.

There are four basic properties of digital signature: (a) It is uniquely linked to the signatory. (b) Capable of identifying the signatory. (c) Created using means that the signatory can maintain under his sole control. (d) Linked to the data to which it relates in such a manner, that any subsequent change of that data is detectable.

So the forementioned implies, that there is a difference between basic electronic and advanced electronic (digital) signatures.[2] A basic electronic signature can include a printed name, e-mail address or scanned signature. On the other hand, the digital signature itself is a unique numerical value based on the entire written document that is being signed.

The digital signature or digital signature scheme is a type of public-key cryptography, used to simulate the security properties of a signature in its digital form, rather than in its written form. The user in this scheme uses his private key to digitally sign the message and the receivers of the signature can then use the sender’s public key for message veriﬁcation. The result of the digital signature process is called “digital signature”.

Signing of documents should serve for the following purposes [16]:

• Evidence – signature binds the signer with the signed document. Signer speciﬁc and not easy to reproduce, and thus proves his identity and excludes the later possibility, that such a signature will be misused by someone else for signing other documents.

• Ceremony – by requesting a signature for some products (like life in- surance), it is intended, that the signer should take into account the importance of this step.

• Approval – by signing the document the signer also approves with the written document or gives authorization to perform something.

13 2. CRYPTOGRAPHY AND CERTIFICATION AUTHORITIES

• Efficiency and logistics – signature declares, that the signer is aware and understands the transaction. It is often used to finalize the transaction and to initiate the subsequent activities17, specified in the document.

2.5.1 Features of digital signatures Advantages: • The non-repudiation feature can be used to deal with imposters – persons, who are trying to escape their responsibility by claiming to have been impersonated. • Data integrity – each alternation of the digitally signed hash will invalidate the digital signature. This can help get rid of undetected message tampering and forgery and false claims, that a message was altered, after it was sent. • Formal legal requirements – digital signatures owns features, that are attributable to traditional handwritten signatures. This way, they can be considered, from the point of law, as an alternative to handwritten signatures. • Open systems – they can be used together with other areas of modern cryptography to overcome shortcuts of open, interconnected insecure computer systems and underlying communication.

Disadvantages: • (Loss of) non repudiation - the case when the user’s private key gets compromised (e.g. it is stolen) means, that all signatures made before this will become suspect. In case of digital signatures, this would mean, that all certificates issued to this user, need to be revoked. • Institutional overhead – there are additional resources and costs for establishing certification authorities, repositories and other related services. • Subscriber and relying party costs – these include costs for required software, hardware, for providing certification authority services and for the possibility to check the status of the received certificates.

17. We can start using services of our bank account after conﬁrmation of the bank account creation agreement.

14 Chapter 3 Internet public-key infrastructure (PKI)

“It is a good thing to proceed in order and to estab- lish propositions. This is the way to gain ground and to progress with certainty.”

Gottfried Wilhelm Leibniz

3.1 Public-key infrastructure (PKI)

a The purpose of the PKI is to authomaticaly identify and satisfy all of the requirements, needed for authentication, authorization and access control services. One of the first attempts to provide overview of such requirements was the NIST 1 MISPCv1 specification. This recommendation is the result of the research, made on various commercial PKI vendor products. The aim of this specification was to define particular parts of the PKI in such a way,that so the interoperation of various implementations would be easily achieved. There are three different types of PKI [19]:

• Trust-list PKI: provides only one level of trust.

• Hierarchical PKI: the particular items of the PKI are hierarchically separated and divided into levels, for simplifying the management of PKI services.

• Networked (mesh) PKI: decentralized, no concrete root is speciﬁed, with items interconnected via the network.

A PKI [21] is a set of hardware, software, people, policies and procedures, needed to create, manage, store, distribute and revoke DCs based on public- key cryptography. It consist of the following components:

1. NIST is the abbreviation for National Institute of Standards and Technology, part of the U.S. Department of Commerce

15 3. INTERNET PUBLIC-KEY INFRASTRUCTURE (PKI)

• Registration Authority (RA) – its purpose is to guarantee binding between public key and the identity of the subject requesting the DC.

• Certiﬁcation Authority (CA) – is responsible for issuing DCs and revoking DCs via the CRLs.

• Subject of the certiﬁcate – the entity which is trying to prove its identity.

• Receivers of the certificate – relying party. Various end entities, which want to communicate with the subject of the certificate and no one else. By verifying the validity of the certificate, they can be sure, that the second part of the communication is really the one, which it proclaims to be.

• Repository – its primary task is, to a safely and efﬁciently store newly created DCRs2, DCs3 and CRLs4 and, if needed, make them quickly available.

3.1.1 E-commerce scenario Suppose, our goal is to create an e-commerce web shop, i.e. we want to sell and deliver our products to the customers via the Internet. One of the things, we need to ensure (forget all the administrative tasks for the moment), is to connect the DNS name of our web server, with some level of trust – to prove, that our server http://www.my.successful.e-shop.com is really the one, which it proclaims to be. Why should the customers require such thing from us? Because they need to be sure, that each time they pay, for a product they ordered, this money will be deducted from the correct bank account. So what we need to do, is to obtain a digital certiﬁcate.5.

So we will contact one of the certification authorities in the world or in the Czech Republic, in order to create one for us. The concrete details about creation of the digital certificate will be discussed later, for the moment, creation of the digital certificate will be enough for us. So our request will be (in mostly cases), delivered to a registration authority.

2. See section 4.1 for more details. 3. See section 4.3. 4. See section 3.1.8. 5. Receiving of the certiﬁcate is only one and not sufﬁcient step for ensuring security of our web server. For more information about this complex topic see [17]

16 3. INTERNET PUBLIC-KEY INFRASTRUCTURE (PKI)

Figure 3.1: The functionality and parts of the PKI infrastructure.

3.1.2 Registration Authority (RA)

Registration authority is an administrative interface of the certiﬁcation authority (CA). In some cases, it can be part of the CA, but nowadays its more and more common that the RA is completely physically separated. It allows to specify the functions and responsibilities better and the mainte- nance and management better.

RA after registering our DC request is responsible for the following tasks:

• Performing authentication – it will use dedicated mechanisms to ﬁnd out our identity. The correct authentication is of critical importance. Malicious e-shop maintainer could claim to be us. RA, by not recog- nizing this fake and by conﬁrming the wrong binding (the malicious e-shop with our e-shop DNS name), could allow the attacker by legal means to impersonate us.

• Delivering the authorization codes – once we have authenticated ourselves against the RA, RA will assign some identiﬁer. We will

17 3. INTERNET PUBLIC-KEY INFRASTRUCTURE (PKI)

use this identifier for simplifying our later correspondence and other communication with the RA. • Notifying the CA about registering our DC request – the CA could be prepared to sign DCRs6 for us. • Assigning so called “Distinguished Name” – distinguished name is the name, that CA uses for binding the subject of the digital certificate with the key pair. Since there can be more than one company from the same region with the similar name, more than one e-shop with similar DNS names, RA has to ensure, that no name misunder- standing could occur. Thus policy, for specifying and assigning distinguished names, needs to be specified. Distinguished name is also one of the important criteria for storing the DC in the Repository and especially, for retrieving from the DC. • Generating and archiving key pairs – RA will create RSA or DSA key pair of a sufficient length (1024 and more bits) for us and safely store it for later usage. • Safely deliver the private key – the key pair, after creation, consists of two keys: the public one and the private one. The public one is included into the DC and will be used, after the creation of the DC, for the verification of the validity of the digital signatures, created by us. The private one needs to be safely transfered to us. This one will be used for signing messages, encrypting documents and for other purposes, we might request. • Initiating the revoking the DCs – once our identity got compromised, i.e. our private key was stolen and we are not the only holder of the key any more, DC has to be revoked – previously created DC has to be marked as invalid, and specified “Key Compromise”. When such a situation occurs, RA will help us to find a solution out of this situation. It will be responsible for initiating the CRL request.

From technical point of view, RA is usually represented by some web interface (possibly equipped with GUI). This web interface should also own resources for safe authentication validation (HTTPS protocol support), authentication codes delivery (MAC support) and safe and fast key pair generation (OpenSSL suite support).

6. See section 4.1 for more details.

18 3. INTERNET PUBLIC-KEY INFRASTRUCTURE (PKI)

Let us recall our example with the e-shop. Now we have reached the phase, in which RA has confirmed our identity and received all the information needed, so that we can act as the subject of the digital certificate. Then, it has generated and delivered authorization codes to us. DN was assigned, pair of keys was generated and we have successfully received the private key. At this moment our original request can be forwarded to the other part of the PKI – to the certification authority.

3.1.3 Certiﬁcation Authority (CA) CA is the basic construct element of the PKI. It is responsible for performing the following tasks: • Creation and archiving digital certiﬁcate requests (DCRs) – CA uses the information about the subject collected by RA for binding it with its public key. Exact process will be described later.

• Signing the DCRs (i.e. creation of the DCs) – CA uses its safely stored private key to digitally sign the above mentioned DCR. The process of signing means, that CA, as a holder of trust confirms, that the public key attached to this certificate really belongs to the listed subject. The certificate will be created and valid for the particular period of time, specified in it. The only way, this certificate can become invalid, is by expiration its validity period or by issuing certificate revocation list (CRL), that would contain its serial number.7

• Issuing CRLs – this mechanism provides CA with the possibility to invalidate DCs, which subject or its private key, got compromised. The exact structure of the CRL is also described in RFC3280 [8] IETF draft. This recommendation also includes the reasons for DCs revocation.

• Cooperates with RA by publishing DCRs, DCs, CRLs8 and other objects (like certiﬁcate policies) to the Repository.

In hierarchical type of PKI its parts are separated and divided into levels (like the nameservers in the Domain Name System). The main certiﬁcation authority (so called Root CA) can delegate the trust to one of its descedant

7. Certiﬁcate revocation lists will be discussed in more detail in section 3.1.8. 8. For more information about DCRs, DCs and CRLs see sections 4.1, 4.3 or 3.1.8 respec- tively.

19 3. INTERNET PUBLIC-KEY INFRASTRUCTURE (PKI)

(so called Subordinate CA). This root CA signs its own certificate (so called “Self Signed certificate”) and the certificates of all subordinate CAs. In this case so called “chain of trust” is created. So when we send our DC request to one of the root CAs, this CA can forward the request to one of its subordinate CAs and this subordinate CA can either process the request or forward it further to another subordinate CA. This DC request forwarding means that there can be a chain of multiple certificates needed to obtain public key of the subject (one subject certificate plus zero or more additional CA certificates signed by other CA). The path from the root CA to the last CA, that is processing our certificate request, is called “certification path”. 9

CA may be represented by a private enterprise or operated by a trusted third party. There is a plenty of requirements, we have to satisfy (follow the X.509 standard, the issuing duty, the need to gain accreditation for our CA), to be allowed to act as a CA. Then CA, as a vendor of certification services, can offer various levels of trust, depending on number and character of the conditions, it has satisfied. From these varying levels of trust come different prices for certification services, that are provided by particular CAs.

3.1.4 Subject of the certiﬁcate – End entity

The person or organization (e-shop web site in our example), who wants to provide specific service or protect its property or resources. To achieve this, it is requesting the digital certificate. By possession of this certificate, it is able to prove its identity to the business partners and is able to benefit from satisfying all four previously mentioned properties of cryptographic communication.

3.1.5 Receiver of the certiﬁcate – Relying party

A customer or a business partner of our “digitally protected” company. By receiving our certificate (after it is signed by CA and published in the Repository), the relying party can obtain our public key, that can be used for the verification of digital documents signed by us, decryption of files and other purposes.

9. The RFC 3280 [8] IETF draft speciﬁes besides the structure of DCs and CRLs, the algorithm which is used for certiﬁcation path validation and also discuss the form of various management and operational protocols.

20 3. INTERNET PUBLIC-KEY INFRASTRUCTURE (PKI)

3.1.6 The Repository Serves as a database for newly created DCRs, DCs, CRLs and other related cryptographic properties (like certiﬁcation policies). It is used by all parties of the PKI: • By CAs and RAs for publishing DCs and CRLs. • By end PKI users: – The Repository uses management protocols to obtain all the information needed about the subject of the certiﬁcate (registration, initialization.. ) – Via the operational protocols (e.g. LDAP, HTTP or X.500), the Repository is able to deliver the DCs and CRLs to the end user.

To handle the distribution, DCs and CRLs are published in the Repos- itory. Since there can be many DC requests (that require user registration and initialization phases to be processed) and many requests for releasing the DC of end user, at the same time, it is very important the question to perform the search over the entries in the database as fast and efficient as possible. One of the approaches used for the record accessibility time speedup is the use of the so called Directory Services (DS) (typically LDAP) instead of the traditional relational databases. One advantage of this approach is, that DS can provide query results (the results of the search) faster than the databases in the environment, where the read operation is performed more frequently than the write operation. Another approach is the use of shadow directories for certificates storage. The certificates are published in several shadow directories and the transition from one name-space to another, can be easily performed by chaining directory names. So now, it is the time, to have the directory service specification, come on the scene.

3.1.7 X.509 (RFC 3280) [8] X.509 is a standard specifying structure of digital certificates and certificate revocation lists. It also provides the algorithm for certification path validation, methods for certificate revocation and describes operational and management protocols. It appeared for the first time in 1988 as ITU-T X.509 (or ISO/IEC 9594-8) document. 10 This document was originally part of the

10. The certiﬁcate format deﬁned in standard from 1988 is called the version v1 (0x0) format.

21 3. INTERNET PUBLIC-KEY INFRASTRUCTURE (PKI)

X.500 Directory recommendations. But X.500, as specification for Directory Services, is considered to be too complex and it has never been fully implemented. So the IETF X.509 (also known as PKIX) working group decided to modify the X.500 standard, so that it would reflect the requirements of digital certificates better. In 1993, X.500 was revised and two more fields were added. This resulted in version 2 (v2) of the format. But soon after applying v1 and v2, it was discovered, that these versions are insufficient (for example due the absence of the possibility to add extensions to the certificate). Thus in June 1996, ISO/IEC, ITU-T and ANSI X9 introduced a new (v3) certificate standard. ISO/IEC, ITU-T and ANSI X9 also presented standard possible extensions, that can be used in the v3 Extension field. Particular extensions can be defined by any organization or company in order to meet their specific needs.

3.1.8 Certificate revocation lists (CRL) and Online certificate status protocol (OCSP) These two mysterious abbreviations represent two possible methods, to determine current digital certificate status.

Certificate revocation list scheme is the older one. It is specified in RFC 3280 [?] profile together with the recommendations for digital certificates. When a digital certificate is issued, it is expected to be in use for its entire validity11 period. Some circumstances (change of the subject name, change of association between subject and the CA, misuse of the private key) the certificate might need to be revoked12 prior to expiration of its validity period. Certificate revocation requires, that the CA periodically issue a signed data structure – a certificate revocation list (CRL). A CRL is a time stamped list of revoked certificates, which is signed by CA or CRL issuer and made freely available in public repository. Each revoked certificate can be found in the CRL by its serial number. So when the relying party wants to verify the remote user digital signature, it has to check not only the certificate serial number and the validity field, but also the latest released CRL, in order to find out, whether this certificate serial number was listed in actual CRL.

This approach has its advantages and disadvantages. An advantage may be presented the fact, that there is no special care needed for the CRL distri-

11. The exact structure and meaning of the Validity digital certificate field will be described in more detail later in section 4.3 in part dedicated to this field. 12. Under term revoked we understand, that the digital certificate is invalidated.

22 3. INTERNET PUBLIC-KEY INFRASTRUCTURE (PKI) bution. CRLs can be distributed in the same way as the digital certiﬁcates – published in the Repository and further transmitted via untrusted network. On the other hand, this approach has its limitations. One important problem this CRL issuing scheme is the frequency. When the key is compromised, the digital certiﬁcate, containing the corresponding public key, needs to be revoked as soon as possible. Even hourly frequency of issuing CRLs would provide the attacker enough time to abuse the secret information.

Online certificate status protocol provides us with another way, to determine the current status of digital certificates. It tries to set over the basic disadvantage of the CRL issuing scheme – the need to download the CRL list too often, by keeping the status of all certificates actualized. OCSP looks at the problem of determining the current certificate status from different point of view. It is protocol, in that two parts (server = CA and client = application, requesting current certificate status), encounter in the communication. The communication proceeds in following the steps: 1. An OCSP client (requesting application) send a status request to the OCSP server (CA). The OCSP request consists of the following parts:13 • Protocol version. • Service request. • Target certificate identifier. • Optional extensions.

During the time, the client waits for the response, it postpones the acceptance of the questioned certiﬁcate, until he gets the response from the server. OCSP server recognizes the status of the request and checks if: (a) The status of the request follows the requested structure. (b) The server is authorized to provide such kind of services. (c) The request contains all the information needed by the server. 2. If all the previous items are met, the server replies with the so called deﬁnitive response. Otherwise it produces an error message, which includes the reason, why the request was not handled correctly.

13. The exact structure of the OCSP request can be viewed on ﬁgure 3.2.

23 3. INTERNET PUBLIC-KEY INFRASTRUCTURE (PKI)

OCSPRequest ::= SEQUENCE { tbsRequest TBSRequest, optionalSignature [0] EXPLICIT Signature OPTIONAL }

TBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, requestList SEQUENCE OF Request, requestExtensions [2] EXPLICIT Extensions OPTIONAL }

Figure 3.2: The structure of the OCSP request.

A deﬁnitive response has also exactly speciﬁed requirements, it has to follow. It can consist of the following parts:

• Version of the response syntax. • Name of the responder. • Responses for every digital certiﬁcates in request. • Optional extensions. • Signature algorithm OID. • Signature computed from the hash of the response.

Certificate status value, together with target certificate identifier, response validity interval and optional extensions field is includen, in section “Responses for each of the digital certificates in request” of the definitive response. RFC 2560 [13] suggests, that the certificate status value should have one of the following values:

• “Good” – positive response. At the minimum, this response means, that the certificate was not revoked, but it can not specify, whether the certificate was ever issued or whether the time the response was sent, is within the certificate validity interval. • “Revoked” – response of this type says, whether the certificate was revoked.

24 3. INTERNET PUBLIC-KEY INFRASTRUCTURE (PKI)

ResponseBytes ::= SEQUENCE { responseType OBJECT IDENTIFIER, response OCTET STRING }

SingleResponse ::= SEQUENCE { certID CertID, certStatus CertStatus, thisUpdate GeneralizedTime, nextUpdate [0] EXPLICIT Generalized- Time OPTIONAL, singleExtensions [1] EXPLICIT Extensions OPTIONAL }

Figure 3.3: The shortened form of the OCSP response. Only ResponseBytes and SingleResponse items are displayed. To see all constituting parts of the OCSP response please refer to [13].

• “Unknown” – this response means, that the server does not know anything about this particular certiﬁcate.

Even, if the OCSP protocol was able to determine the certificate current status much faster, than by using the CRL issuing schema, it still has limitations. One of the major problems is the ambiguity , introduced by the current certificate status, in case, “Good” or “Unknown” responses are received. For this reason this technique mostly has to be combined with other methods, to find out the validity of particular digital certificate.

25 Chapter 4 From certiﬁcate request to digital certiﬁcate

“Mathematicians have tried in vain to this day to discover some order in the sequence of prime numbers, and we have reason to believe that it is a mystery into which the human mind will never penetrate.”

Leonhard Euler

4.1 Digital certiﬁcate request (DCR)

Digital certiﬁcate request1, as type of digitally signed message, consist of the following parts:

• Version – this field can contain values v1 (0x0), v2 (0x1) and v3 (0x2). Choosing the version number has consequences for the form of the resulting DCR. Version v1 can not contain fields issuerUniqueID and subjectUniqueID (these are available only in higher versions). Field extensions may be present, only if it is a version v3. The default value for this field is a value v1.

• Subject – content of this field specifies more information about the subject – End entity, the DCR is created for. Particular different end entities are recognized by its Distinguished Name (DN). DN acts as an unique identifier used for searching the Repository for DCR belonging to specified subject. In v1 and v2, DN is listed as one item in the subject field and is the only one way to recognize the subject. In v3 (by presence of extension field), the DN can be empty string, only if the subjectAltName extension is present and set to critical. When the DN is empty, at least one of the following items has to be specified:

1. The example of the digital certiﬁcate request created by the openssl req command is shown in Appendix A.1 on ﬁgure A.1.

26 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

– Subject email address – “rfc822Name” field – content of this field has to meet the requirements from RFC 822 about the form of the electronic mail address. – Subject host IP Address – “iPAddress” field – IPv4 address has to consist of exactly four octets (following the RFC 791) and IPv6 address of exactly sixteen octets (by RFC 1883). – Subject DN, in the form of Domain Name System (DNS) name – “dNSName” field – when used as the only item for DN recognition, this field can not be empty (“ ”) string. – Subject Uniform Resource Identifier (URI) – “uniformResourceI- dentifier” field – its value consist of two parts. The protocol name (e.g. “http”) and the scheme specific part (e.g. fully qualified domain name or IP address). – Subject Directory Name – “directoryName” field – this has to be unique for each end entity, certified by one CA.

In case, the Distinguished Name is not empty (by absence of subjec- tAltName extension), RFC 3280 [8] recommends, the ﬁeld should be able to store the following basic standard attribute types:

– country, – organization, – organizational-unit, – distinguished name qualiﬁer, – state or province name, – common name and – serial number.

Content of almost all previous items is intuitive. Obviously serial number has to be unique, for each issued DCR or DC. In most cases, it is the only unique attribute, that binds concrete public key with user – subject of the DCR or DC. Imagine, that the user has multiple public keys generated (and multiple DCRs issued) in one day – each of them for various desired purpose (one for KeyAgreement, other for web client authentication and one for IPSecEndUser protection). Without the serial number ﬁeld, we would not be able to determine the purpose of these issued DCRs. The serial number ﬁeld is also

27 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:da:c5:25:42:2b:fe:db:08:26:29:a2:cb:a4:4b: 34:49:c9:0d:0a:b4:62:fb:72:c8:43:4a:78:20:98: 86:3d:7e:b7:d7:e7:00:28:c2:b7:ad:55:5a:51:cc: 75:6c:f4:fa:1d:70:91:61:5a:b4:50:d5:28:95:53: ae:66:16:af:f0:14:a5:50:85:d6:b8:fb:4a:ee:98: 63:8e:42:61:75:cd:d3:6c:66:5c:63:cd:a1:77:d3: 49:20:eb:30:58:5e:dc:87:73:99:9c:29:80:f8:1a: d4:63:8b:bb:ea:1c:82:d0:54:02:3d:b7:ef:24:a3: ec:1c:3f:62:41:a9:03:d7:f3 Exponent: 65537 (0x10001)

Figure 4.1: Possible form of the “SubjectPublicKeyInfo” ﬁeld: It can be seen, that RSA algorithm was used for key pair generation, the key and modulus are 1024 bit long (modulus is displayed in hexadecimal form), exponent is 65537 and it is also followed by its hexadecimal representation.

used in certiﬁcate the revocation lists (CRLs) for revocation of concrete DC (in most cases CRL contains serial numbers for more than one DC). By listing these serial numbers on CRL, the DCs users – relying party is informed about the fact, that DC became invalid.

Together with these basic standard attribute types, some additional standard attribute types should be supported in the subject ﬁeld:

– locality, – title, – surname, – given name, – initials, – pseudonym, generation qualiﬁer (e.g. “Jr.”, “3rd”).

If the subject of DCR (DC) is a CA (the value of “cA” attribute in “basicConstraints” extension ﬁeld is “TRUE”), then the Distinguished

28 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

Name must not be empty string and has to match the DN in the issuer ﬁeld.

If the subject of DCR (DC) is a CRL issuer, then the Distinguished name must not be empty string and has to have the form of DN published in the issuer ﬁeld.

• SubjectPublicKeyInfo – this ﬁeld contains the information about the type of algorithm (RSA, DSA) used for subject key pair generation and some additional information, specifying other features of the public key (e.g. key length, exponent and modulus – its length and hexadecimal value). See attached ﬁgure 4.1 for better illustration.

• Issuer/Subject Unique Identifier – this optional field may appear, only if the version of certificate request is v2 or v3. The identifiers were introduced to allow the reuse of subject and/or issuer names in a course of time. RFC 3280 [8] recommends, not to generate certificates with unique identifiers. The CA should be also capable of parsing the unique identifiers.

• Extensions – optional, can appear, only if the version is set to v3. The reason for introducing extensions was to specify better the intended purpose of use. IETF specifies basic set of extensions, but each company may define its own extensions, that would suite their specific needs better.2 Extensions are presented in a sequence and each one can appear only once. Every extension can carry optional parameter (among others) – its classification: either “critical” or “non-critical”. CAs should reject the certificate requests with critical extension, if not recognized. On the other hand if certificate request has unrecog- nized non-critical extension it is considered to be valid (if all other remaining needed requirements are met). So each of non-critical extension will have its “critical part” by default set to “FALSE”, and only critical extensions will have the value set to “TRUE”. The form of Extensions field is shown on Figure 4.2. 3

2. Mail server management company providing the mail services to the end users will be interested in extensions related to the S/MIME protocol. On the other hand, company maintaining its own virtual private network will be interested in possible IPSec extensions. 3. Particular types of extensions will be described in the following section 4.1.1, which is dedicated to this topic.

29 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING }

Figure 4.2: The form of Extension digital certiﬁcate request ﬁeld.

AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerial- Number OPTIONAL }

Figure 4.3: The form of Authority Key Identiﬁer extension ﬁeld.

4.2 Types of extensions used in digital certiﬁcate requests and digital certiﬁcates

4.2.1 Authority Key Identiﬁer

Using extension, the relying party of the certificate request, has the possibility to identify the private key, that was used for signing the certificate request. The need of private key recognition, can appear, when the issuer uses multiple signing keys simultaneously. 4 Then it has to be decided which private key was used for signing the corresponding certificate request. The identification is based either on the key identifier or on the issuer name and on the serial number. See figure for more details.

This extension field has to be included in all certificate requests and certificates to facilitate the certification path construction. In case, the CA dis- tributes its public key via the “Self-Signed” certificate, the authorityKeyI- dentifier may be omitted.5 6

4. Either because of multiple concurrent key pairs or changeover. 5. Because the signature on “Self-Signed” certificate was created with the private, key that is associated to the certificate subject public key. 6. “Self-Signed” certificate will be described in more detail later in section 4.3.1.

30 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

There are three methods recommended, to determine the content of the keyIdentifier field. First two methods derive this content from the public key, that was used to verify the certificate request signature: 1. The “keyIdentifier” is composed of the 160-bit SHA-1 hash of the bit string “subjectPublicKey” (excluding the tag, the length and the number of unused bits).

2. The “keyIdentifier” is composed of a four bit type field with the value 0100 followed by the least significant 60 bits of the SHA-1 hash of the bit string “subjectPublicKey” (excluding the tag, the length and the number of unused bit strings). The third method for generation “keyIdentifier” is to use unique values, created by monotonically increasing sequence of integers.

This extension could not be marked as “critical”.

4.2.2 Subject Key Idenfitier By specifying this extension, the CA can select all certificates, that contain public key belonging to particular subject, rather than the subject specified by the distinguished name. This extension has to be present in all certificate requests, where the “cA” attribute in the “basicConstraints” extension is set to “TRUE”. Similarly to the “Authority Key Identifier” extension, this extension also can not be marked as “critical” and should use one of the three methods presented above. .

4.2.3 Key Usage This extension defines the purpose of use of the public key contained in the certificate request. It shall be used in cases, when the end user public key is used in wider range of application purposes. For example in the situation7 where the RSA public key is supposed to be used only for verification of digital signatures the intended usage can be specified by setting the “KeyCertSign” 8 bit. This extension has to be present on certificate requests, which are intended to be used for the verification of digital signatures that are listed on other digital certificates or certificate revocation lists.

7. Suppose the public key presented in the certiﬁcate request is a RSA key. This could be used for multiple purposes including message encryption, decryption, signing or verifying. 8. Bit “cA” has also be set to “TRUE” in case, when bit “KeyCertSign” is set.

31 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

When this extension is present, the value of the “critical” attribute has to be set to “TRUE”. Key Usage extensions provides nine bits for speciﬁcation of the usage of the certiﬁcate request. Each of this bits has its own particular meaning and can be used only for the corresponding purpose. Some of these bits may be combined together, while others are mutually exclusive. List of possible Key Usage bits and the explanation of their purpose is the following:

• digitalSignature – this bit may be set in cases, when public-key shall be used for signing and verifying of digital signatures of the objects, that are not certificates (bit five) or certificate revocation lists (bit six). Thus this bit can not be combined with “KeyCertSign” and “cRLSign” bits. This bit is often set, when we have in mind to ensure user authentication and data integrity.

• nonRepudiation – when set and used together with the “digitalSig- nature” bit, it provides “non-repudiation” for public keys that are used for digital signatures veriﬁcation. In cases, the unreliable signer would claim, that he did not use the public-key for signing the message, the trusted third party can determine the authenticity of signed data. This bit can not be used together with “KeyCertSign” and “cRL- Sign” bits.

• keyEncipherment – the intended usage of this bit includes cases, when the subject public key is designed to safely transfer some other key (for example symmetric key). This way it is possible to handle situations, when “slower” public-key is used for initial session encryption, so that the “faster” symmetric key could be transfered and later used for the rest of the communication session. This bit is excluding itself with the “dataEncipherment” bit, but can be used in combination with the “keyAgreement” bit.

• dataEncipherment – this bit can be set, when the public key will be used for data encryption/decryption, but only in cases, where the nature of the transmitted data does not have a cryptographic basis (i.e. the data are not cryptographic keys). Such a use logically con- cludes, that this bit can not be set up together with the “keyEncipher- ment” bit.

• keyAgreement – is set in situations, when subject the public key will be used for initial symmetric key agreement (for example when Difﬁe-

32 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

Hellman key will be used for key management). This bit can be combined together with the “keyEncipherment” bit. • keyCertSign – the certificate request, whose public-key will be used for verification of the digital signature on other public-key certificates, will have this bit set up. This bit can not be used in cases, when the subject public-key shall be used for signature validation on certificate revocation lists and on other objects, that are not digital certificates (this means, that this bit can not be combined with the “digitalSignature” and “cRLSign” bits). It also can not be used together with the ”nonRepudiation” bit. 9 When this (“keyCertSign”) bit is set up, the “cA” bit of the “basicConstraints” extension has to be set to “TRUE”. • cRLSign – its intended usage areas are cases when the public key is used for certificate revocation list signature validation (CRL, deltaCRL or ARL). 10 It has to be set by similar types of certificate requests. This bit can not be combined with the “digitalSignature”, “keyCert- Sign” and “nonRepudiation” bits. • encipherOnly – the meaning of this bit is defined only when the “keyA- greement” is also set. In such cases (when both of them are specified), the intended purpose of the use is key encipherment by processing the key agreement phase. • decipherOnly – the meaning of this bit is analogous, to the previous one. It can be used only in conjunction with the “keyAgreement” bit set (otherwise its meaning is undefined). When both are specified, the intended purpose is the key decipherment during the key agreement phase.

All possible combinations of bits from the “Key Usage” extension are not deﬁned. Some of them can be used without any limitation, while the others exclude each other. Furthermore, various public-key algorithms also deﬁne different constraints on the form of possible “KeyUsage” bit combinations.

9. The root or subordinate CA is considered to act as trusted third party and can not con- tinually deny the fact if issued some particular certificate or certificate revocation list. 10. The CRL stands for certificate revocation list – will be discussed in more detail in section 3.1.8. The CA issues CRLs on a regular basis. When the certificate needs to be revoked outside the date of issuing the CRL, the CA issues so called “deltaCRL”. DeltaCRL contains serial numbers of certificates that were not yet listed on the CRL, but are already considered to be invalid. On the authority revocation list (ARL) there are issued certification authority certificates, that were revoked. 33 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

4.2.4 Subject Alternative Name This extension provides another ways, to specify the identity of the subject of the certiﬁcate request. The subject can present its identity either by supplying its distinguished name or by entering its Internet electronic mail address, DNS name, IP address or an uniform resource identiﬁer (URI).

The subject alternative name is considered to be deﬁnitely bound to the public key of the subject, so all parts of the subject alternative name extension have to be veriﬁed.

When the subject identity is included in the certiﬁcate request only in the form of the subject alternative name (i.e. the Subject Alternative Name extension is set), then the subject distinguished name must be empty (in this case the subjectAltName extension has to be marked as critical).

When the subject proves its identity by entering its electronic mail address in the subjectAltName extension, then the value of the “rfc822Name” string has to be a valid electronic mail address, that conforms to RFC 822.11

The user can enter two forms of IP address as in the subjectAltName extension field: • IPv4 address – then the value of the “iPAddress” string is expected to follow the form from RFC 791 (i.e it has to consist of exactly four octets, where the least significant bit of each octet is the least significant bit of corresponding byte in the network address. • IPv6 address – then the value of the “iPAddress” string has to consist of exactly sixteen octets (as specified in RFC 1883).

When the subject wishes to use its domain name as the identifier, the “dNSName” field has to follow the syntax from RFC 1034. There are some special notes: • No significance is attached to the DN case (i.e. google.com and GooGle.com are considered to be the same DNs). • The string “ ” must not be used as the “dNSName” value.

11. The addr-speciﬁer ﬁeld has form “local-part@domain”, has no phrase before it, no com- ment after it and is not surrounded by the “<” and “>” signs.

34 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

• The subject can not use its electronic mail address in the form of the domain name (i.e. [email protected] can not be trans- formed to kaspersky.security.company.com) – when the electronic mail should be used as the subject alternative name, then the “rfc822Name” ﬁeld should be used instead of the “dNSName” ﬁeld.

• DNS names in international character sets are not supported yet (This work is in progress, so only characters without accents should be used as DNS records).

In cases, when the subject provides a host IP address, as an identification method, the “uniformResourceIdentifier” field has to be used. This field can not have the form of a relative URL and has to follow the syntax specified in RFC 1738. It has to consist of two parts:

1. scheme – like http://, ftp:// and

2. scheme-speciﬁc part – this must contain only the fully qualiﬁed domain name or IP address of the host. 12

Other ways for subject identiﬁcation that may appear in the subject alternative name extension are:

• “directoryName” ﬁeld or

• “otherName” field. In the former case, the distinguished name must be unique for each subject entity certified by that specific CA, as defined in the issuer certificate field. In the later case, the form and semantics of the name are indicated through the OBJECT IDENTIFIER in the type-id field. For example, Kerberos RFC 1510 format names can be encoded into the “otherName”, using a Kerberos 5 principal name OID and a sequence of the Realm and the PrincipalName.

The values of the subjectAltName extension ﬁeld may be constrained in the same way, like the subject distinguished names using the “Name Con- straints” extension. When this extension is present, then at least one of the above speciﬁed forms of specifying the subject alternative name has to be used (the value of the subjectAltName can not be empty).

12. It is important to mention that the scheme part is considered to be case-insensitive (i.e. “http” == “HTTP”), but the scheme-speciﬁc part has to be validated in a case-sensitive way.

35 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

4.2.5 Basic Constraints

This extension allows the subject of the certificate request to declare, that it is certification authority – “cA” field set to “TRUE”, indicates this. If the “cA” field is not asserted, then the “keyCertSign” bit in the “Key Usage Ex- tension” must not be asserted.

The second item that can appear in the value of the “Basic Constrains” extension field, is the “pathLenConstraint” – this one can be used only if the “cA” field is set to “TRUE” and “keyCertSign” bit is asserted. In such cases, it presents the maximum number of non-self-signed intermediate certificates, that may follow this certificate on a valid certification path.13

If this extension field is used on the digital certificate for certification authority, it can be marked either as critical, (in all CA certificates, that contain public keys used to validate digital signatures on certificates) or non-critical (for purposes other than validation of digital signatures on certificates). If this extension is used on the certificate for the end user, it can be marked either as critical or non-critical.

4.2.6 Extended Key Usage

The extended key usage extension may be used for specification of the intended certificate request public key purpose of the use. Purposes listed in this extension may be enhancements (i.e. the more detailed description of those mentioned in the “Key Usage” extension), or can be completely new ones displayed in place of the basic purposes. This extension will appear only in the end entity certificates. It has the following form:

The intended key usage purposes may be defined by any organization or company and reflect its specific needs. The identifiers used to mark such purposes must be assigned with the ITU-T X.660 recommendation.

This extension may be set up either as critical or as non-critical. If set up, then the public key of such certiﬁcate can, and has to be used only for

13. The Self-Signed certificate is such type of certificate where the issuer and subject fields are the same and are not empty. For more information about the certificate types classification see section 4.3.1.

36 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF

KeyPurposeId

KeyPurposeId ::= OBJECT IDENTIFIER

Figure 4.4: The possible form of the “Extended Key Usage” extension field. the purpose listed in this extension. Cases might appear, when some applications accept only certificates with some specific public key usage purposes preset in the extension field. In such cases, the CAs in order to satisfy requirements of these applications, but not to restrict usage purposes of the public key too much, will include the special key purpose identifier (keyPurposeID) “anyExtendedKeyUsage” in the extension field. If this special keyPurposeID is present, then this extension should be marked as critical.

If the subject in the certificate request specifies both key usage purpose by “Key Usage” extension and extended key usage purpose by “Extended Key Usage” extension, then both types of extension have to be handled separately and the public key has to be used only for the resulting usage purpose. If there is no purpose consistent with both types of extensions, then the public key must not be used for any purpose. THe following intended key usage purposes may appear in the “Extended Key Usage” extension field:

• anyExtendedKeyUsage (id == 0): This usage purpose is set by the CA, when end the application ex- pects the presence of at least one or more extensions from the “Ex- tended Key Usage” extensions pool. In such cases, the CA uses this value, in order not to restrict the intended public key usage purpose too much.

• serverAuth (id == 1): THe set up for the certiﬁcate public key should be used for authentication of the web server, which supports the TLS protocol. This bit can be combined with the digitalSignature, keyAgreement and keyEnci- pherment bits from the “KeyUsage” extension.

37 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

• clientAuth (id == 2): Indicates that the public key will be used for client authentication in communication with the TLS protocol supporting the web server. Can be used together with the digitalSignature and/or keyAgreement bits from the “keyUsage” extension.

• codeSigning (id == 3): The set up, for the certiﬁcate public key should be used for the digital signatures of download-able executable binary applications. The DigitalSignature bit from the “KeyUsage” extension ﬁeld may be used together with this bit.

• emailProtection (id == 4): The public key of this certiﬁcate should be used for providing cryptographic features, like user/data authentication, data integrity or for electronic mail service. Allowed combinations of the “KeyUsage” bits include: digitalSignature, nonRepudiation and/or KeyAgreement or KeyEncipherment.

• timeStamping (id == 8): The certiﬁcate will be used for the creation of a binding – the object hash with a speciﬁc time. Such a binding can be used as one of the methods for reply attack prevention. This bit could be used together with the digitalSignature and/or nonRepudiation “KeyUsage” bits.

• OCSPSigning (id == 9): The public key will be used for signing, and thus for ensuring the authentication and data integrity, of the OCSP protocol responses. This intended purpose of the use may be combined with digitalSignature and/or nonRepudiation “KeyUsage” bits.

4.2.7 Inhibit Any Policy It is customare, to use this extension for certificates issued for other CAs. This extension must be marked as critical. When set up, it means, that the special “anyPolicy” identifier can not be used as a substitute value for other certificate policies. The integer value indicates the maximum number of additional certificates, in which the “anyPolicy” identifier may appear in the path, before it is no longer permitted. For example, the value of two means, that the “anyPolicy” identifier can appear and be processed only in certificates issued by the subject of the certificate plus one more CA in the path, but no more.

38 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

We have described the structure and meaning of particular parts that can appear in a digital certificate request. By including these values the subject of the request issues and proves its identity and can specify additional intended key usage purposes via the extension part. So to create the digital certificate request, the subject first fills in all the fields needed, digitally signs the result with its private key and encrypts it with the public key of the CA. The CA then applies its private key to the message in order to de- code it and then uses the subject public key to verify the signature on the certificate request.

4.3 Digital certiﬁcate (DC)

Now the subject owns the digital certificate request – it has securely transmitted all the requested data to the CA and it has proved its identity by possession of the private key. But, to create a trustworthy certificate from this request, the information about the CA – the certificate issuer has to be included. So now, the CA takes the request, adds two additional parts – the Issuer and Validity field, and then signs it with its private key. At that point, the digital certificate request has changed to the digital certificate.14 From this point, the relying party, can be sure, that the public key belongs to the subject, listed in the certificate.15

Now, we will discuss in more detail the structure of the two fields: Issuer and Validity, added by CA: • Issuer: This serves for identification of the particular CA, which has issued this digital certificate. This field has to contain a non-empty distinguished name (DN) and is defined as the X.501 type Name: 16.

The Name, as a representation of the Issuer field, is a hierarchical name composed of a set of AttributeTypeAndValue type. This type is a sequence of keys – AttributeType and possible values – AttributeValue, corresponding to them. The type of AttributeValue field is based on the type of the AttributeType field. In general, it will be the Directo- ryString.17 The RFC 3280 [8] recommends to use the utf8String, as a

14. The example of digital certificate is displayed in Appendix A.1 on figure A.2. 15. Creating the digital certificate is only one step on the way to the desired e-shop security. For an overview of things, see [17]. 16. See figure 4.5 to see the exact form 17. See figure 4.6 for an overview of types this field can contain.

39 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

Name ::= CHOICE { RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::= SET OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE { type AttributeType, value AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY DEFINED BY AttributeType

Figure 4.5: The prescribed structure of the X.501 Name ﬁeld, as a representation of the Issuer ﬁeld.

type for the AttributeValue items, from the DirectoryString types pool.

The RFC 3280 profile does not restrict the set of AttributeType and AttributeValue items, that can appear in the Issuer field. Basic and additional sets of attributes, that each digital certificate, has to recognize are defined. It is the same set of attributes that is defined for the Subject field (i.e. country, organization, organizational-unit etc.).18

Except for these two sets of attributes, the CA should also allow to enter the Issuer DN in the form of the DNS name. This DN is not required to be converted to the “dNSName” ﬁeld from the “Subject Alternative Name” extension.19

18. The complete set of possible basic and additional attributes can be found in section 4.1. 19. The DNS system of naming also represents a hierarchical form of name composition. The structure of this system is similar to the worldwide PKI organization – there are also root name-servers. The second level is represented by name-servers for each country – each particular country has its primary and secondary name-servers. Yet a higher level is represented by name-servers belonging to state organizations like universities, libraries, hos- pitals and business corporations. These provide naming services for their purposes. They can be divided into smaller sections to reﬂect, for example, the different faculty orienta-

40 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

DirectoryString ::= CHOICE { teletexString TeletexString (SIZE (1..MAX)), printableString PrintableString (SIZE (1..MAX)), universalString UniversalString (SIZE (1..MAX)), utf8String UTF8String (SIZE (1..MAX)), bmpString BMPString (SIZE (1..MAX)) }

Figure 4.6: The possible types of DirectoryString, that may appear in the AttributeValue ﬁeld.

• Validity: Content of this field represents time interval, during which CA claims, it will maintain the information about the status of this certificate. It consist of two date and time specification items:

1. NotBefore – date and time when the certificate period begins, including the day and time mentioned in this field. 2. NotAfter – date and time when the certificate period ends, including the mentioned day and time.

Both of the previously mentioned items should be represented in the UTC time.20 UTC time is ASN.1 standard type, which is able to carry information about the date and time. The year in this format is represented with only two digits21 while the time is speciﬁed up to the precision of seconds – so the resulting form is that of YYMMD- tion or different organizational unit application area. These units may also have their own name-servers to provide naming services to end users.

The “domainComponent” attribute in the Issuer field is capable of carrying organizational (sub)domain names and fulfills the requirement of the organization, which wishes to use its DN name to parallel its DNS name. 20. Digital certificates, with the validity period starting from the year 2050 and later, should use GeneralizedTime. 21. When the YY year field contains value less than 50, the year shall be interpreted as 20YY, otherwise as 19YY.

41 4. FROM CERTIFICATE REQUEST TO DIGITAL CERTIFICATE

DHHMMSSZ22 or form, when the time difference against the Green- wich Mean Time is speciﬁed.

4.3.1 Self-Signed and CA certificates Each CA, to be able to issue digital certificates, has to own a digital certificate and public-private key pair. The public key will appear as one of the parts in the CA certificate and can also be retrieved by the end users to encrypt the following underlying communication with the CA. The private key will be used by the CA for digital signing of issued certificates. The CA can retrieve the digital certificates, needed for its function, from another “higher level” CA. In this case, the CA requesting the certificate is called the “Subordinate” CA, and the one providing the desired certificate (in case it is on the highest level) is called the “Root” CA. This, previously mentioned method, represents one way, that the CA can retrieve the needed digital certificate. Another is to create and sign their own certificate. The CA first creates a certificate request, generates a public-private key pair for itself and then signs the request with the private key. So for the time being it behaves, as it were an end user. After retrieving this so called “Self-Signed” 23 certificate, the CA stores its private key and allows other users to retrieve its public key. From this moment on it starts to provide the CA services. The “self-signing” method for CA certificate creation is less trustworthy and should be used only in exceptional cases. The natural way to retrieve the digital CA certificate retrieving should be to get the certificate from some other, “higher-level” CA.

It can be seen from the previous section, that there are two types of digital certificates – one for CAs and one for the end users. The type of the certificate should be transparently marked. For CA certificates, this can be done be setting the “cA” bit in the Basic Constraints extension to “TRUE”. If this option is not set to “TRUE”, the certificate is considered to be the end user certificate.

22. Z stands for the Zulu or Greenwich Mean Time. 23. Please observe, that the Issuer and Subject ﬁelds on such “Self-Signed” certiﬁcate will be the same.

42 Chapter 5 Possible approaches to the certiﬁcation authority implementation

“Security, like correctness, is not an add-on feature.”

Andrew S. Tannenbaum

We will discuss two approaches to realization of the services provided by the CA and PKI:

1. Ensure the CA functionality via separated tools – different application programs. Each tool will provide couple of necessary functions and by mutual cooperation we can meet the target of fully fucntional CA.

2. The use cryptographic library which is providing functions like generation of the x bits long RSA or DSA private key is used to encrypt the message or to create signature. Then one can beneﬁt from the API of such a library and reach the whole desired CA functionality by combining functions from the library.

The mentioned approaches have their (dis) advantages. The advantage of the former is higher modularity – when it turns out that some tool does not fully suit our needs, we can easily replace it with some other more suitable application program. Unfortunately, this way of CA realization is too heterogeneous. It requires additional effort to make these various tools to work together as one component unit. We will need to write separated scripts, that will try to overcome this heterogeneity and add the places with miss- ing functionality. Of course, such scripts will be prone to errors and failures.

The “library” approach to CA realization seems to be more natural, as it provides independent functions needed in homogeneous environment. The

43 5. POSSIBLE APPROACHES TO THE CERTIFICATION AUTHORITY IMPLEMENTATION library of cryptographic functions is not so heterogeneous, as the conjunction of the independent application programs, even if it provides various functionality. These functions are relatively easy to combine into (higher) objects to meet the desired CA operations. On the other hand, from the library view, the need to replace some function with another would introduce another library dependency in our resulting application program. We can also try to rewrite such a (targeted) function on our own, but then we have to keep in mind, that we are handling with cryptographic functions. The security aspects of such kind of methods are of a high importance and even if we wrote computational more efﬁcient function, we must ensure the sufﬁcient level of security.

We will describe in more detail one representative for each mentioned approach.

5.1 OpenCA (OpenPKIX)

OpenCA [9, 18] represents ﬁrst approach to the CA implementation – the way via separated tools. The OpenCA PKI project aims to develop robust, fully-featured and Open-source based PKI implementation, that would support a set of related protocols like HTTP, HTTPS, LDAP and OCSP. It started in 1999. The design still attempts to follow the original principles:

• A Perl based web interface, for conﬁguring the whole tool.

• An OpenSSL backend, for performing cryptographic operations.

• A database, for storing all the related cryptographic objects.

The database should be able to store all four types of cryptographic objects:

1. Digital certiﬁcate requests – these are called Certiﬁcate Signing Re- quests (CSRs) in OpenCA terminology.

2. Digital certiﬁcates.

3. Certiﬁcate revocation requests (CRRs) - this represents means to re- vocate the end user certiﬁcate.

4. Certiﬁcate revocation lists (CRLs).

The OpenCA PKI project supports the following features:

44 5. POSSIBLE APPROACHES TO THE CERTIFICATION AUTHORITY IMPLEMENTATION

• IP-ﬁlters for interfaces.

• Pass-phrase based login.

• Certiﬁcate based login (including smart-cards).

• Role based access control.

• Flexible certiﬁcate subjects.

• Flexible certiﬁcate extensions.

• PKI based revocation.

• Digital signature based revocation.

• CRL issuing.

• Warning of the certiﬁcates expiring soon.

OpenCA PKI consists of six interfaces:1

1. Node – this interface handles the database initialization and man- ages all the export and import functions. Then the database will be used for all four previously mentioned cryptographic objects. Thats why this interface has a critical importance for the whole PKI design. Node is also able to perform basic backup and recovery functions. Here the operator can conﬁgure different rules of the synchroniza- tion with other Node interfaces which are active on different level of the hierarchy. It is not intended to be a primary storage area for the CA digital signatures and primary keys. For security reasons these should be backed up separately.

2. The CA interface supports all the functions needed for issuing certificates and CRLs. It also provides comfortable web based configuration interface and supports so called “batch processors”. This can be used for automatic creation of the digital certificate from databases of users like SAP, HIS, NIS systems or etcpasswd file.

3. RA interface from the OpenCA PKI is intended to handle the following: editing of requests, (dis)approving requests, creating of private keys with smart-cards, deletion of wrong requests and email users.

1. Each of these interfaces has their dedicated functionality. The design follows the recommendations of [21] on the structure of the PKI.

45 5. POSSIBLE APPROACHES TO THE CERTIFICATION AUTHORITY IMPLEMENTATION

4. LDAP interface should be used for LDAP service and support ad- ministration.

5. Pub interface handles all the remaining types of user requirements. It can:

• Generate client-dependent (Explorer, Mozilla) and client-independent digital certificate requests (CSRs) and private keys. • Receive PEM-formatted PKCS#10 requests from servers. • Enroll certificates and CRLs. • Support two forementioned methods of revocation – CRLs and OCSP protocol. • Search for the certificates. • Test user certificates in browsers.

OpenCA PKI is a professional, web-based, full-featured PKI implementation suitable for application in big corporations and organizations like universities and libraries. It is able to handle multiple CAs and manage the CA hierarchy three or more levels deep. It also supports multiple distribution protocols (HTTP, HTTPS, LDAP, OCSP), multiple CDPs2, both forementioned methods of certiﬁcate status retrieving etc.3 Using its interfaces it can be conﬁgured to work as a separated PKI. It is also possible that some of its parts cooperate with another higher level CA or CAs.

The guide to this tool covers the installation and configuration steps as well as other recommendations needed to install CA in a secure manner (like advices about hardware backups, data organization or network traf- fic notes). This guide describes all steps necessary to CA realization. Rather than describing the official recommendations it explains how to ensure phys- ical security of the PKI building, how to place the servers, that will in the most convenient way respond on user requests. It also deals with which protocols enable on these servers and in which order call them. Such recommendations would surely appreciate any potential PKI designer. They are based on hands-on experience and can be very helpful when setting the organization of the PKI.

2. CDP stands for CRL Distribution Point. It is interface or point where issued CRLs are distributed, i.e. can be accessed by end users. 3. Issuing CRLs and OCSP protocol. See section 3.1.8 for more details about these techniques.

46 5. POSSIBLE APPROACHES TO THE CERTIFICATION AUTHORITY IMPLEMENTATION

5.2 Java Cryptographic Architecture (JCA) [15]

Java Security API is a core API of the Java programming language. It is built around the java.security package and its sub packages. The ﬁrst time it appeared in JDK 1.1 and introduced the Java Cryptography Architecture. It was designed to serve as framework for encapsulating and providing the cryptographic functionality on the Java platform. JCA in JDK 1.1 covered topics like message digests and digital signatures. In Java 2 SDK, it has been enhanced to support also X.509v3 certiﬁcates and CRLs. Besides JCA there existed also JCE (Java Cryptography Extension)4. Starting from version 1.4 of the Java 2 SDK, JCE became part of this kit. So now we can refer only to JCA to be able to speak about all previously mentioned cryptography features.

Before we start to speak about JCA library, let us shortly discuss some of the terms this library uses for security feature handling: • Cryptography service: By this term JCA understands some feature from the cryptography – message encryption, message digests, digital signatures or X.509 certificates. • Cryptography service provider: JCA introduces a way to built cryptographic library on the concept of “provider” or “plug-in”. The provider is a way to implement cryptographic features (one provider may implement for example DSA algorithm more efficiently than the other. The application can choose freely any “provider” from the pool. It can pick the default one (with highest priority number) or any other (by specifying its priority number). Following this concept the replacement of inefficiently implemented cryptographic function by another (possibly) more efficient one, is as easy as possible. • Engine classes: Represents cryptographic services in an abstract fash- ion. This is possible via the Java “Interface” object type.5 The engine classes provide access to the functionality of a algorithm class. Then the realization of the cryptographic service usually performs in three steps:

4. In form of separate package – extension, that could be downloaded and added as a plugin to the Java 2 SDK kit. 5. “Interface” is a type of Java object, which allows to postpone the class implementation to the last possible moment. In the “Interface” class just declare the header of the function – its name, return value, names, count and types of its arguments, and each class which wants to implement this interface has to meet this speciﬁcation.

47 5. POSSIBLE APPROACHES TO THE CERTIFICATION AUTHORITY IMPLEMENTATION

1. Object initialization. 2. Object update – i.e. assigning data, that need to be processed by this service. 3. Cryptographic service execution.

JCA puts the accent on the following four principles:

1. Implementation independence – this can be easily ensured by following the “provider” concept. End applications just select the desired provider, the best suites their needs.

2. Algorithm independence – is achieved via the “provider” and “engine classes” mechanisms. Each application can choose between multiple providers (by specifying its number) and between multiple engine classes implementations.

3. Interoperability or compatibility – feature, that ensures, that all cryptographic services have to create key pairs, message digests etc. in format that will be acceptable by other algorithm implementations.

4. Extensibility – implemented properties should be easily extensible to provide another cryptographic operations.

The JCA library is fully featured cryptographic library6, which can satisfy any need for the CA implementation.7

5.3 What features we need to realize CA via the “library” approach

We will now discuss in more detail the features that cryptographic library must possess so that it could be used for the CA implementation. First it must provide the ability to handle big precision integer numbers. 8 9

6. Provides support for the message digest, digital signatures, key pair generation, key store representation, digital certificates and CRLs, certificate store representation, PKCS 12 and PKCS 7 key store format, base-64 encoded certificate format etc. 7. See the JCA MessageDigest, Signature, KeyPairGenerator, KeyFactory, CertificateFactory, Al- gorithmParameters, KeyStore and CertStore classes documentation to find more details about this interesting library. 8. Digital certificate serial number field is one example of the attributes that will be need. 9. The QCA – library we have chosen for the CA realization, described in section 4.1, uses class called QBigInteger for the high precision integer numbers calculations.

48 5. POSSIBLE APPROACHES TO THE CERTIFICATION AUTHORITY IMPLEMENTATION

This feature could be implemented by concatenation of a certain number of integer type objects, but it would be error prone and it would be a source of numerous buffer overﬂows, which could imply a number of security holes and risks.10

Further characteristic related to the previous one, is the ability to transform big integer numbers into their hexadecimal representation11 and back.

It is also must to handle the cryptography sensitive information securely. 12 The library has to ensure that the sensitive material can not be read by any unauthorized third party applications. These applications could get in a contact with our binary and could possibly be interested in stealing and later reusing the sensitive cryptographic information.

To dive deeper into the area of cryptographic functions, the potential cryptographic library, should provide functions for RSA and DSA key generation etc. It should also be capable to generate these keys with variable bit lengths and convert them into their private and/or public representation. Very important is also the question of secure loading and storing os keys from/to the ﬁle system or any other storage medium. 13

CA realization also requires functions which provide the digital signature service. Therefore the library should be able to digitally sign the data at least with the “SHA-1” signature algorithm14 and simultaneously recognize the digital signatures created with the “MD2”, “MD4” and “MD5”15 algorithms.

The potentially usable library should also include a support of various digital certificate storage formats. Digital certificate requests and certificates are usually saved in *.DER, *.PEM or in *.base64 encoded format. There- fore the library should also understand these formats and should be able

10. We are not saying that in this implementation security ﬂaws can not appear. 11. It is a custom to display the “modulus” part of the RSA public key in its hexadecimal form. 12. The QCA library ensures the secrecy of passwords via the QSecureArray class. 13. The QCA library enables this functionality with classes RSAPrivateKey, RSAPublicKey, DSAPrivateKey and DSAPublicKey and their particular methods. 14. Today this one is the preferred one that should be used in the digital certiﬁcates. 15. For overview and explanation of possible attacks on MD5 hash function see [25, 23] and [24].

49 5. POSSIBLE APPROACHES TO THE CERTIFICATION AUTHORITY IMPLEMENTATION to transform digital certificates into all supported formats. Of high importance, is also the question of secure, fast and easy loading and saving of digital certificates from/to these formats from/to the file system.

Another non-cryptographic features, that could be satisﬁed by programming language, include support of dynamic and complex data structures like lists, lists of lists, multi-maps or hashes. These could enable the processing of information in really effective manner.

50 Chapter 6 Qt Cryptographic Architecture (QCA)

“If you could prove that something was a one-way function, that was the most practical thing–that was purely cryptographic.”

Whitﬁeld Difﬁe

6.1 Description

For our CA implementation we have decided to use the second mentioned approach, i.e. the way of ensuring CA functionality via cryptographic library. We have chosen to apply the Qt Cryptographic Architecture (QCA) library. QCA (also known as QtCrypto) is one of the parts of the Qt library. It is analogous to the Java Cryptographic Architecture (JCA) library and was developed with the similar aim – to provide public-key, message digest and other cryptographic functions. As a programming language for this library was used the C++ language, so the desired functionality can be reached by the creation of necessary class instances and by calling their methods. It is a complex library, organized in couple of traditional C++ header ﬁles, that can serve not only for the CA implementation, but also can be used as a module for providing the following features: • Secure byte arrays (QSecureArray).

• Arbitrary precision integers (QBigInteger).

• Random number generation (QCA::Random).

• SSL/TLS protocol support (QCA::TLS).

• X509 Certiﬁcate revocation lists (QCA::CRL).

• Built-in support for operating system root storage (QCA::SystemStore).

• Simple Authentication and Security Layer (SASL) (QCA::SASL).

51 6. QT CRYPTOGRAPHIC ARCHITECTURE (QCA)

• Cryptographic Message Syntax (QCA::CMS).

• PGP messages (QCA::OpenPGP).

• Uniﬁed PGP/CMS API (QCA::SecureMessage).

• Subsystem for managing smart-cards and PGP keyrings (QCA::KeyStore).

• RSA (QCA::RSAPrivateKey and QCA::RSAPublicKey).

• DSA (QCA::DSAPrivateKey and QCA::DSAPublicKey).

• Difﬁe-Hellman (QCA::DHPrivateKey and QCA::DHPublicKey).

• Hashing (QCA::Hash):

– QCA::SHA0. – QCA::SHA1. – QCA::MD2. – QCA::MD4. – QCA::MD5. – QCA::RIPEMD160. – QCA::SHA224. – QCA::SHA256. – QCA::SHA384. – QCA::SHA512.

• Ciphers (QCA::Cipher):

– BlowFish (QCA::BlowFish). – Triple DES (QCA::TripleDES). – DES (QCA::DES). – AES (QCA::AES128, QCA::AES192 and QCA::QES256).

• Keyed Hash Message Authentication Code (QCA::HMAC) using SHA1, MD5, RIPEMD160, SHA224, SHA256, SHA384 and SHA512.

• Encoding and decoding of hexadecimal (QCA::Hex) and Base64 (QCA::Base64).

52 Chapter 7 Qintca – CA implemented in QCA

“Using current mathematics and technology it is impossible to even consider factoring a 1024–bit number. I’m not willing to make any hard predictions about tomorrow.” Bruce Schneier

All the previous inspection was inspired only with one aim – CA implementation. We have implemented the binary, called “Qintca” 1. It is written in the C++ language, using the Qt 2 library. It includes all cryptographic information and support is provided by the QCA3 library – the QtCrypto part of the Qt library. The Qt library was chosen for multiple reasons. One of them was the possibility to provide tasks like public-private key pair generation, subject or extension information specification via the graphical user interface (GUI). GUI is much more natural and illustrative for end users and by a suitable combination of features that are enabled or disabled, you can instruct them to a follow desired sequence of steps and so avoid ambiguous situations. Another advantage of the Qt library is, that it provides a couple types of dynamic data structures, like lists, maps, multi-maps and their combinations, that can be successfully applied.4 This library also provides numerous methods for various data type conversions. Features not present in other libraries and more time consuming, if needed to be implemented. Qt provides resources to benefit from properties and methods supplied with graphical items like buttons, line-edits or open/save file-dialogs.5 An-

1. The latest source code can be found at [6]. 2. The Qt library is available for various platforms. All the related information is described at [7]. 3. The main page of the Qt cryptographic architecture (QCA) library from the Delta Affinix project can be found at [5]. We have used the Beta2 version of this library, available at [4]. 4. For example, for representation of the Subject field we have used the multi-map data structure, which made certificate subject information procession much more easier. 5. Suppose we want to validate the input in the form of IPv4 or IPv6 address. This is only one example from a pool of similar problems, that can easily be resolved by using the

53 7. QINTCA – CA IMPLEMENTED IN QCA

Figure 7.1: The look of the main Qintca window while selecting the “Vali- date” option. For more Qintca screen-shots see Appendix D. other advantage of this design is, that possible future Qintca enhancements (like the CRLs issuing or OCSP protocol support) can be handled due to the universality of the Qt library. The requirement to add HTTP or HTTPS protocol support would, in this case, mean to modify the QHttp class, shipped as one class in the Qt suite. Also the need to change the repository format from the ﬁle system to the traditional database could be easily performed via the QtSql class and its particular methods.

From our experiences with the QCA library we can say, that it is an easy- to-use, multi-featured cryptographic library. It is properly documented and relatively intuitive to apply – once we knew the structure of of the CA issued electronic documents and the operations, the CA should perform. Then we could implement the desired functionality easily by calling corren- sponding QCA methods. One exception to this rule was the creation of the digital certificate request – in order to create an instance of QCA::CertificateRequest class, instances of QCA::CertificateOptions and QCA::PrivateKey classes are needed. Class QCA::CertificateOptions consists of the following classes and structure:

• QCA::Constraints – carries all the information related with the x509 v3 extension support.

• QCA::CertificateInfo – contains information about the subject of the certificate request, specification if it is or is not CA, details about the request validity period (notBefore and notAfter times) and other related information.

• QStringList Policies – speciﬁes information about applied requests and certiﬁcate policies.

QValidator item.

54 7. QINTCA – CA IMPLEMENTED IN QCA

Such a design for a certificate request implementation at first seemed to be much too complicated and hard to understand, but on the other hand, it allows that the function, that handles the certificate request creation, could have only two arguments – certificate options and the corresponding subject public key.

Next we should mention the disadvantages of the QCA library. The main one is the “feature”, if provided inproper (other than expected) input to some method, it does not display any suitable warning message, yet it causes the whole application to crash. Such behavior is acceptable in small- sized applications, where it is possible to manually investigate each line of code. However by the scope of our application (about 3500 LOC), it is much too time consuming. After several cases of spending a couple of hours in- vestigating the binary, until we finally found the source of the crash in the QCA library method. Thus every time we attempted to enhance the functionality of the whole binary, we first separated out the newly added QCA lines to a standalone procedure. Once we found, that this procedure was working as expected, we included it in the final Qintca code.

Following entity-relationship diagram (ERD) illustrates the scope of the Qintca project.

The current Qintca implementation is able to generate public-private key pairs, issue digital certificate requests, sign them with the SHA-1 algorithm, 6 i.e. to create digital certificates from them and store them in the file system.8 It also validates digital certificates. Qintca recognizes the following certificate statuses – certificate validation proces results: • The certificate is valid. • The root CA rejected the certificate purpose. • The certificate is not trusted. • The signature on certificate does not match. • The certification authority is invalid.

6. MD2, MD4 and MD57 message digest algorithms are supported only by reverse compatibility. Qintca is able to verify certificates signed with these algorithms, but uses only SHA-1 algorithm for certificate request signing (this behavior is recommended at the conclusion of the RFC 3280 [8] IETF profile). 8. In the *.PEM or *.DER file format.

55 7. QINTCA – CA IMPLEMENTED IN QCA

Figure 7.2: Entity-relationship diagram illustrating the Qintca structure – part 1. Class names marked with the * sign match class names in the QCA library. 56 7. QINTCA – CA IMPLEMENTED IN QCA

Figure 7.3: ER diagram illustrating the Qintca structure – part 2. Class names marked with the * sign match class names in the QCA library. 57 7. QINTCA – CA IMPLEMENTED IN QCA

Figure 7.4: Specifying Key Usage extension in Qintca. For more Qintca screen-shots see Attachment D.

• The purpose does not match the intended usage.

• The certiﬁcate is self-signed and was not found in the in the list of trusted certiﬁcates.

• The certiﬁcate has been revoked.

• The path length from the root CA to this certiﬁcate is too long.

• The certiﬁcate has expired.

• The certiﬁcate authority has expired.

• Validity is unknown.

It supports the following X.509 v3 extensions:

• Basic Constraints extension.

• Key Usage extension.

• Extended Key Usage extension.

58 7. QINTCA – CA IMPLEMENTED IN QCA

It should also permit to use only allowed combinations of Key Usage and Extended Key Usage extension bits, as speciﬁed in the RFC 3280 [8] IETF proﬁle.

Future releases of the Qintca binary should support:

• Remaining extensions from the minimal set of extensions specified in the RFC 3280 [8] IETF profile: Authority Key Identifier, Subject Key Identifier, Subject Alternative Name, Issuer Alternative Name, Name Con- straints, Policy Constraints and Inhibit Any Policy extension.

• The creation of digital certificates via the “batch processors” – the method of the creation the digital certificates in cases, when large databases of users are available, like those provided by the SAP, HIS or NIS systems or by the /etc/passwd file.

• Two methods for certiﬁcate revocation – the CRL issuing and OCSP protocal support.

• Another possible desired protocol, like HTTP, HTTPS or LDAP.

• The Repository is implemented as a relational database instead of ﬁle system storage.

In the future, there may be even more requirements for the desired enhancements.

59 Chapter 8 Conclusions

“Finally, two days ago, I succeeded – not on account of my hard efforts, but by the grace of the Lord. Like a sud- den ﬂash of lightning, the riddle was solved. I am unable to say what was the conducting thread that connected what I previously knew with what made my success possible.

Carl Friedrich Gauss

The aim of this diploma thesis was to implement a functional CA [6], based on Qt and QCA libraries, that would store generated key pairs and issued digital certificate requests and digital certificates to the file system. In order to realize this goal, we first focused on specific areas of modern cryptography – like public-key cryptography, hash functions and digital signatures. After understanding the basic underlying principles we contin- ued with the study of the structure of particular PKI constituting parts. This study allowed us to understand the functions of each PKI part and to specify the CA position and its expected functionality. We also described the structure of the electronic documents issued by the CA and focused on the extensions. Our presentation of this part should be looked at, as an attempt to summarize this complex topic in a simple and illustrative way, while simultaneously preserving the required level of accuracy. This work can be used as a source of insights and recommendations, since potential suc- cessors will have to overcome the same problems and difficulties we have encountered.

After discovering the expected CA features we could, then start with the implementation. We presented two possible ways, to do so. First we inves- tigated and discussed the example, provided by the OpenCA PKI project. This project represented an attempt to implement the functionality of the

60 8. CONCLUSIONS whole PKI. It is suitable for big enterprises and corporations, as it includes huge amounts of supported features (various authentication methods, multiple protocol support, techniques for handling fail-over and load balanc- ing). This environment provides multiple XML based conﬁguration interfaces and is modular enough in order to satisfy the requirement for case of ease development and replacement of every part. But from our point of view, it would be hard to implement only CA via the separated components. If functionally separated tools are combined to provide the PKI functions there is a risk that some functions would be redundant. On the other hand no single tool provide us with all the requested features.

We have also analyzed the JCA approach. This one seems to be more natural for us, as it provides the fully featured cryptographic library – pool of cryptographic algorithms and techniques and each binary, that implements this API, can select the desired components. This way it should be possible to implement the CA by selecting and using suitable functions. JCA provides an easy uniform way to perform CA public-key cryptography, hash and digital signatures functions (by following the three step schema – class initialization, class update and operation realization). This way all functions followed an uniﬁed simple mechanism. Modularity in this library is ensured via the provider approach. This way the resulting application can select another (more secure or fast) implementation of concrete algorithm or class. The provider approach also provides a method of how to handle the need of possible future feature development or replacement.

For implementation of our CA, we have chosen the QCA and Qt libraries, due to the fact that the QCA library was designed by following similar principles, (provider support, common schema of methods calling) like the JCA library. Another reason was that it is easy to cooperate with and easy to be included in the binary based on the Qt library. Qt is a complex, object- oriented graphical library, suitable for implementation of graphical applications, that makes it easy to handle every common application design problems – like retrieving input from the user, conversions between various data representations or displaying the results. All you need to do is create suitable classes and call their methods. This way we could beneﬁt from two fully featured libraries (each covering only the set of needed functions) and make the CA realization as efﬁcient as possible.

61 8. CONCLUSIONS

The presented CA should serve as a simple, graphical, Unix environment based tool, utilized by the end users in order to provide basic CA services, without the need to understand and be aware of related underlying cryptographic details. From the design and basic principles of used the QCA library we can conclude, that it is easy to replace the cryptographic algorithms implementation, with some future one that would be much faster or secure. The proposed CA [6] is by no means complete. A list of implemented features is available in the chapter, dedicated to the “Qintca” binary. But it is meant to be modular enough to allow future possible enhancements. We have also presented the features, we would like to see present in future releases.

The realization of this diploma thesis gave me the opportunity to dive deeper into the problematics of the desing of certiﬁcation authorities and the whole PKI. Now I am able to imagine its complexity not only from the theoretical point of view. It also provided me the possibility to discover the principles of work of the related cryptographic features. I spent time while searching for available cryptographic libraries to choose one of them. Thus I can beneﬁt from these knowledges as there can be expected that the need to ensure the security of the electronic communication will get much intensive in the future.

62 Bibliography

[1] Cryptographic hash function. http://en.wikipedia.org/wiki/Cryptographic_hash_function.

[2] Electronic Signatures FAQs. http://www.out-law.com/page-443.htm.

[3] Federal Information Processing Standards Publication 180-1. http://www.itl.nist.gov/fipspubs/fip180-1.htm.

[4] Home page of the beta 2 version of the QCA 2.0 library. http://www.delta.affinix.com/download/qca/2.0/beta2/.

[5] Home page of the Delta Afﬁnix Qt cryptographic architecture library project. http://www.delta.affinix.com/qca/.

[6] Home page of the Qintca project. http://www.fi.muni.cz/˜xlieskov/qintca/.

[7] Home page of the Trolltech Qt library. http://www.trolltech.com/developer/downloads/qt/index/.

[8] Internet X.509 Public Key Infrastructure Certificate and Certificate Re- vocation List (CRL) Profile. http://rfc.net/rfc3280.html.

[9] OpenCA PKI (v0.9). https://www.openca.org/projects/openca/downloads.shtml.

[10] Public-key cryptography. http://en.wikipedia.org/wiki/Public-key_cryptography.

[11] RSA problem. http://en.wikipedia.org/wiki/RSA_problem.htm.

[12] Symmetrick-key algorithm. http://en.wikipedia.org/wiki/Symmetric-key_algorithm.

63 8. CONCLUSIONS

[13] X.509 Internet Public Key Infrastructure Online Certiﬁcate Status Pro- tocol. http://rfc.net/rfc2560.html.

[14] Federal Information Processing Standards Publication 180-2, SECURE HASH STANDARD. Technical report, August 2002. http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf.

[15] JavaTM Cryptography Architecture API Speciﬁcation & Reference. August 2002. http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html.

[16] American Bar Association. Digital Signature Guidelines Tutorial. Section of Science and Technology Information Security Committee http://www.abanet.org/scitech/ec/isc/dsg-tutorial.html.

[17] Carl Ellison and Bruce Schneier. Ten Risks of PKI: What You’re Not Being Told about Public Key Infrastructure. Computer Security Jour- nal, Volume XVI(Number 1), 2000. http://www.schneier.com/paper-pki.pdf.

[18] OpenCA Group TM. OpenCA Guide for Versions 0.9.2+. https://www.openca.org/projects/openca/openca-guide.pdf.

[19] Peter Gutmann. Evertything you Never Wanted to Know about PKI but were Forced to Find Out. University of Auckland, http://www.cs.auckland.ac.nz/%7Epgut001/pubs/pkitutorial.pdf.

[20] Thomas Stockton Stacy Cannady. Easing the pain. February 2001. http://www-106.ibm.com/developerworks/library/s-pain.html.

[21] Symeon (Simos) Xenitellis. The Open-source PKI Book: A guide to PKIs and Open-source implementations. http://ospkibook.sourceforge.net/.

[22] Vesna Hassler. Security Fundamentals for E-Commerce. ARTECH HOUSE, INC., 2001. ISBN 1-58053-108-3.

[23] Vlastimil Klima. Tunnels in Hash Functions: MD5 Collisions Within a Minute. Prague, Czech Republic, Version 1, March 2006, Version 2, April 2006, http://cryptography.hyperlink.cz.

64 8. CONCLUSIONS

[24] Xiaoyun Wang and Hongbo Yu. How To Breake MD5 and Other Hash Functions. Shandong University, Jinan250100, China http://www.infosec.sdu.edu.cn/paper/md5-attack.pdf.

[25] Xiaoyun Wang1, Dengguo Feng2, Xueyia Lai3, and Hongbo Yu. Colli- sions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD. The School of Mathematics and System Science, Shandong Univer- sity, Jinan250100, China1, Institute of Software, Chinese Academy of Sciences, Beijing100080, China2, Dept. of Computer Science and Engi- neering, Shanghai Jiatong University, Shanghai, China3 revised on August 17, 2004 http://eprint.incr.org/2004/199.pdf.

65 Appendix A Examples of digital certiﬁcate request and digital cer- tiﬁcate

66 A. EXAMPLES OF DIGITAL CERTIFICATE REQUEST AND DIGITAL CERTIFICATE

A.1 Example of digital certiﬁcate request

Figure A.1: The example of the digital certiﬁcate request created by the openssl req command: openssl req -newkey rsa:1024 -keyout ibmkey.pem -out ibmreq.pem and using values: Country=US, State=New York, Locality=Poughkeepsie, Organization Name=IBM, Organizational Unit Name=TPF, Common Name=John Doe, Email [email protected], functionality it supports and features it implements. a challenge password=whoareyou67 and an optional company name=IBM. A. EXAMPLES OF DIGITAL CERTIFICATE REQUEST AND DIGITAL CERTIFICATE

A.2 Example of digital certiﬁcate

Figure A.2: The example of the digital certiﬁcate created by the Thawte company.

68 Appendix B Digital certiﬁcate request and digital certiﬁcate creation

B.1 Using the OpenSSL suite

• Specifying parameters for the DSA key – the length of 768 bits:

openssl dsaparam -out dsa.parameters 768

• Generation of 768 bit long DSA key encrypted with 3DES CBC mode:

openssl gendsa -des3 -out key.pem dsa.parameters

• Removing passphrase from the DSA key:

openssl dsa -in key.pem -out cakey.pem

• Generation of digital certiﬁcate request using the previously created DSA key:

openssl req -new -key cakey.pem -out careq.pem

• Signing of the above certificate request, i.e creation of X.509 CA digital certificate, using the private key from the file newkey.pem, SHA-1 signature algorithm, the validity period of 30 days, starting from today, with the serial number 2037874 and using X.509 v3 extensions from file /etc/pki/tls/openssl.cnf:

openssl x509 -req -in careq.pem -sha1 -days 30 -set serial 2037874 -extﬁle /etc/pki/tls/openssl.cnf -extensions v3 ca -signkey cakey.pem -out cacert.pem

• Generation of 1024 bit long RSA key, with the exponent of 65537 (the default), stored in ﬁle key.pem and encrypted with AES CBC mode:

openssl genrsa -out key.pem -f4 -aes192 1024

69 B. DIGITAL CERTIFICATE REQUEST AND DIGITAL CERTIFICATE CREATION

• Creation of end user certiﬁcate request for subject: Country=US, State=New York, Locality=Poughkeepsie, Organization Unit=TPF, Organization=IBM, Common Name=John Doe, which will use the previously created RSA key from the ﬁle key.pem and MD5 hash algorithm:

openssl req -new -md5 -subj ’/C=US/ST=New York/L=Poughkeepsie/OU=TPF/O=IBM/CN=John Doe’ -key key.pem -out endUserReq.pem

• CA sign of end user certificate request, stored in the file endUser- Req.pem, using CA certificate from the file cacert.pem, CA private key from the file cakey.pem and creating a new certificate serial number:

openssl x509 -req -in endUserReq.pem -CA cacert.pem -CAkey cakey.pem -CAcreateserial -out endUserCert.pem

70 Appendix C Sample related QCA class

C.1 Look and methods of the QCA::CertiﬁcateRequest class class QCA EXPORT CertificateRequest : public Algorithm { public: /** Create an empty certificate request */ CertificateRequest();

/** Create a certificate request based on the * contents of a file */ CertificateRequest(const QString &fileName);

/** Create a certificate request based on specified * options */ CertificateRequest(const CertificateOptions &opts, const PrivateKey &key, const QString &provider = QString());

/** Test if the certificate request is empty */ bool isNull() const;

/** Test if the certificate request can use * a specified format */ static bool canUseFormat(CertificateRequestFormat f, const QString &provider = QString());

/** The format that this certificate request is in */ CertificateRequestFormat format() const;

71 C. SAMPLE RELATED QCA CLASS

/** Information on the subject of the certificate * being requested */ // PKCS#10 format only CertificateInfo subjectInfo() const;

/** The constraints that apply to this certificate * request */ // PKCS#10 format only Constraints constraints() const;

/** The policies that apply to this certificate * request */ // PKCS#10 format only QStringList policies() const;

/** The public key belonging to the issuer */ PublicKey subjectPublicKey() const;

/** Test if this certificate request is for * a certificate authority certificate */ // PKCS#10 format only bool isCA() const;

/** The path limit for the certificate in this * certificate request */ // PKCS#10 format only int pathLimit() const;

/** The challenge associated with this * certificate request */ QString challenge() const;

/** The algorithm used to make the signature * on this certificate request */ SignatureAlgorithm signatureAlgorithm() const;

/** Test for equality of two certificate requests */ bool operator==(const CertificateRequest &csr) const;

/** Export the certificate request into a DER format */

72 C. SAMPLE RELATED QCA CLASS

// PKCS#10 format only QSecureArray toDER() const;

/** Export the certificate request into a PEM format */ // PKCS#10 format only QString toPEM() const;

/** Export the certificate into PEM format in a file */ // PKCS#10 format only bool toPEMFile(const QString &fileName) const;

/** Import the certificate request from DER */ // PKCS#10 format only static CertificateRequest fromDER( const QSecureArray &a, ConvertResult *result = 0, const QString &provider = QString());

/** Import the certificate request from PEM format */ // PKCS#10 format only static CertificateRequest fromPEM( const QString &s, ConvertResult *result = 0, const QString &provider = QString());

/** Import the certificate request from a file */ // PKCS#10 format only static CertificateRequest fromPEMFile( const QString &fileName, ConvertResult *result = 0, const QString &provider = QString());

/** Export the CertificateRequest to a string */ // SPKAC format only QString toString() const;

/** Import the CertificateRequest from a string */ // SPKAC format only static CertificateRequest fromString( const QString &s,

73 C. SAMPLE RELATED QCA CLASS

ConvertResult *result = 0, const QString &provider = QString()); };

74 Appendix D Qintca screenshots

75 D. QINTCA SCREENSHOTS

Figure D.1: Qintca key pair generation dialog.

Figure D.2: Specifying the subject information in Qintca by pressing the Use conﬁg ﬁle values button.

76 D. QINTCA SCREENSHOTS

Figure D.3: Specifying Extended Key Usage extension in Qintca.

Figure D.4: The certificate is valid and The certificate has expired – results of the Qintca certificate validation process.

77 D. QINTCA SCREENSHOTS

Figure D.5: Example certificate request created with the Qintca binary. Qintca allows you to dismiss the changes – by pressing the Close without saving button, or save this request to PEM encoded file – by pressing the Save as *.PEM file button or go to the “sign dialog” in order to create a digital certificate, by pressing the Go to sign dialog button. 78