YEAH! Etter all dem dagan her med skriving av essay kan æ jo skjønn at all dokker ut der bare sitt å hoppe på stolen etter å les ka æ har skreve. så, here goes.. Have phun

PKIX Management Functions in detail

This document describes the Public Key Infrastructure X.509 Management Functions in detail. At first, it will introduce the term Public Key Infrastructure. Before moving on to the Management Functions, it will define some important terms that are needed in understanding the properties of the management functions.

Public Key Infrastructure

Public Key Infrastructure, or PKI, is an arrangement that provides public-key encryption and digital signature services. The purpose of the arrangement is providing means for managing keys and certificates, and using them effectively. A certificate is really a binding of public key to the user that owns the public key. By the use of a PKI, a company can establish a trustworthy networking environment. This is done by authenticating users computers to each other, by the use of encryption, decryption, and digitally signing messages using private keys.

The X.509 is a ITU-T standard for public key infrastructure. It specifies standard formats for public key certificates and certification path validation algorithms. The PKIX Working Group was established the fall of 1995 with a goal of developing Internet standards needed to support an X.509 based PKI.

Definition of terms

An entity in PKI management refers to the entity to be named in the subject field of a certificate, or the certification authority, and may also include registration authority.

A Certification Authority, CA, refers to the entity named in the issuer field of a certificate. This is often called a third party, but from the end entities point of view, the CA actually quite often belong to the same organization as the entities it support. The term Root CA is used to indicate that a CA is directly trusted by an entity, and the term subordinate CA is used for a CA that is not a Root CA for the current entity.

The Registration Authority, RA, is in RFC2510 viewed as an optional component of the certificate management protocols. Functions of an RA may include personal authentication, token distribution, revocation reporting, name assignment, key generation, archival of key pairs etc. When the RA is not present, the CA will carry out it's functions so that the PKI management protocols are the same from the entities point of view.

The term out-of-band, in communications, refers to call control information being exchanged on a separate band of the data channel.

The Management Functions

The management functions of the PKI Certificate Management Protocols (defined in RFC2510) are functions that are mandatory for all end entity, CA/RA implementations, meaning that all these functions describe functionality that the implementations at least must be able to provide. The functions mentioned in RFC2510 which are mandatory include Root CA Initialization, Root CA key update, Subordinate CA initialization, CRL production, PKI information request, Cross Certification, End entity initialization, Certificate Request and Key update. A description of each functions follows.

Root CA Initialization
Newly created root CAs must produce a self-certificate with the profile for what is called newWithNew  certificate, followed by doing a root CA key update, which is described in the next section.

A self-certificate is a certificate which is signed by its own creator. A newWithNew certificate is a new certificate that contains the new public key of the CA signed with the private key. In other words, by signing the public key with the CAs own private key, one can verify that the CAs public key is correct. Other types of profiles for the self-signed certificates are newWithOld and oldWithNew, all of which are ment for entities that hold the current self-signed CA certificate (oldWithOld) to securely be able to transfer to the new self-signed CA certificate, and to serve new end entities that hold the newWithNew certificate to acquire oldWithOld securely for verification of already existing data - NewWithOld meaning the new public key signed with the old private key, and oldWithNew the old public key signed with the new private key.

Key Update
On a general basis keys have a finite lifetime, and when a key pair is about to expire, an entity may request a key update by sending the CA an update request message (kur). The CA returns the new certificate.

Key update refers to the process of creating completely new key pairs for the existing users – updating both public and private keys. The keys of a user are a complimentary key pair, consisting of one private key that is private to the user, and one public key that is shared with other users. The beauty of this system is that data encrypted with one of the keys have to be decrypted with the complimentary key. If you want to encrypt something for another user, you would encrypt the data using his public key. The data is then only decryptable using the private key, ensuring that he is the only one able to read the data.

Key updates should seem transparent for the user. Key update is different from certificate renewal. Certificate renewal is the process of extracting the existing public key from one certificate and putting it into a new certificate with a different lifetime. Certificate renewal is relatively simple compared to key update because it does not involve the management of a completely new key pair.

Updating the keys provides a mechanism for restricting the amount of data that is left vulnerable or open to the wrong people when a private key is compromised.

Root CA Key update
Root CA keys have to be updated on a periodic basis.
As already mentioned, keys have a finite lifetime, and as well as for other keys, the management functions require the CA keys to be updated on a periodic basis. The same key pairs should never be used forever.

End entity initialization
End entities requires initialization.

End entities, like the CAs, also requires initialization. This includes two steps: acquisition of the PKI information and an out-of-band verification of one of the root CA public key.

Subordinate CA initialization
For the initialization of a subordinate CA, this procedure is the same as for the initialization of an end entity, but the subordinate CA must also produce an empty CRL. CRLs are explained in the following section.

CRL production
Before a newly established CA can start issuing certificates, it must produce empty versions of what is called CRLs, Certificate Revocation Lists, which are to be periodically produced.

These lists are present for holding the ids of certificates that has been revoked and are available for all users. There may be several reasons for which a certificate may have to be revoked before its validity period has expired. For instance, a company can have a security policy saying that employees leaving the organization should not any longer be trusted. The id of the employee's certificate will then be added to the CRL list, and prior to the next use of the certificate, comparing the certificates id with the one of the CRL will claim the certificate revoked, and it may no longer be used.

As well as for an employee leaving the company, a CRL is also needed in the case of a user's private key being compromised. It is important that a mechanism is provided from which the users can verify the revocation lists and refuse to use a revoked certificate.

PKI information request
Information about the current status of a CA may at any times be requested by an end entity, CA or RA. The CA must respond with the information requested, or if the information at the moment is not available, the CA must respond with an error.

Cross Certification
Cross-certification allows CAs from different domains to establish trust. The CAs securely exchange verification keys, that are used to verify the CAs signature of the certificates. Each CA then signs the other CAs verification key in what is called a cross-certificate.

As an example, if a user is using your public key he has to trust the public key of the CA that signed it. If the CA that signed your certificate is not the CA that he trusts, he will have to rely on what is called a cross-certificate - certificates signed by CAs, for other CAs, establish a path down to the CA that signed your public key, and you thereby establish trust.

Certificate Request
The management functions specifies that, at any time, an initialized entity may request a certificate. This may be a part of an update procedure, of for any other mean. The request is sent by using a certification request message called cr. If the request is successful, the CA returns the certificate.

Further development

When Diffie and Hellman brought light to both secure key exchange over an insecure communications channel and asymmetric key algorithms back in 1976 it totally changed the meaning of secure communications. As the development of high speed digital data transfer and electronic communications continues showing its importance as of today, the need for securely being able to communicate with each other, and being sure of whom one is actually interacting with, is becoming more and more important.

In the USA, the National Institute of Standards and Technology in the US Department of Commerce have developed a test suit, to ensure that systems that are using certificates actually confirm to the standards, meaning they are doing the checks properly and verifying the digital signatures. This is going to help move things forward with PKI, making sure systems processing certificates are doing their job right. Earlier, software that did not confirm to the standards might have resulted in users trusting certificates that really were not trustworthy, jeopardizing the whole implementation of PKI

The use of PKI today is still increasing. Users are becoming aware of the importance of protecting their interests in encrypting and signing data, ensuring confidentiality of the information. Though the use of mechanisms for encrypting and signing data using public key systems are visible to the user today, we will experience these systems appearing more and more transparent to the users in the coming years. The systems mentioned in this text form a basis for security measures we will use without thinking about it or even knowing they are present. It is reasonable to believe that the use of public key cryptography even will become regulatory in certain areas.

References:

    [1]    William Stallings, Cryptography and Network Security Fourth Edition, Pearson Prentice         Hall 2006
    [2]    Svein J. Knapskog, Informasjonssikkerhet i internett, Tapir Akademisk Forlag 2005
    [3]    C. Adams, S. Farrell, Internet X.509 Public Key Infrastructure: Certificate Management         Protocols, RFC 2510, March 1999
        http://www.ietf.org/rfc/rfc2510.txt
    [4]    Symeon (Simos) Xenitellis, The Open–source PKI Book, OpenCA Team 1999                http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm
    [5]    IETF, Public-Key Infrastructure (X.509) (pkix) Charter, IETF Secretariat 2007
        http://www.ietf.org/html.charters/pkix-charter.html
    [6]    Housley, R., W. Ford, W. Polk and D. Solo, Internet X.509 Public Key Infrastructure             Certificate and Certificate Revocation List (CRL) Profil, RFC3280, April 2002
        http://tools.ietf.org/html/rfc2459
    [7]    Entrust, Securing Digital Identities & Information, Public-Key Infrastructure (PKI),             2007 http://www.entrust.com/pki/
    [8]    Steve Gibson and Leo Laporte, Security Now, 2007
        http://www.grc.com/securitynow.htm