The X.509 Specification
Digital certificates are taken from the X.509 specification. As mentioned before, the X.509 specification is an integrated extension to the X.500 specification. X.500 builds a directory structure in the shape of a tree based on the organization name , common names, distinguished names , and organizational unit. The X.509 was built to store the keying information. Using a tree that hides the keys and transports them through the Internet helps in this task. The LDAP serviceThe transfer of public keys should happen without the fear that whoever accesses them can break the private key or change the digital certificate information. The directory structure can interface with a set of distributed servers, or a single server, for maintaining a data structure of information for an organization. The LDAP service (X.500 service before LDAP) assists an organization in keeping records of the users inside the organization in a tree-like directory structure similar to the one just described. The information defined in the directory structure could be certificates, users, or keys, just to name a few. An LDAP service could be used as a repository to store the digital certificates following the directory structure from the X.500 entries in the digital certificate. When an organization starts working with certificates, the architecture should establish a plan for managing and distributing the X.509 certificates using either a Java keytool utility or extending the utility to interface with the LDAP service. The architect can start by understanding the keytool utility concepts.
You can find the reference used to understand the X.509 specification in the RFC 2459 at http://www.ietf.org/rfc/rfc2459.txt "Internet x.509 Public Key Infrastructure Certificate and CRL Profile." This is my main reference besides the code used in the JDK 1.4 distributions for this chapter. To understand the capabilities of the X.509 use and specification, you must have an in-depth understanding of the elements of the X.509. Each field in the X.509 specification has a specific use for transfer and use of the digital certificate. One of the elements of the X.509 is the signature. The signature of the certificate is a one-way hash function, such as MD5 or SHA-1, which is used for validating the fields in the X.509 certificate. The signature field is used to validate the information of the digital certificate. The signature field is just one example of why understanding the fields in the X.509 digital certificate is important. The elements inside a digital certificate are used to generate a digital signature. After receiving the digital certificate, the organization validates the elements by validating the digital signature. This ensures that no elements were tampered with. When studying certificates, it is important to note that a developer can generate certificates using the Java utility keytool .
This chapter goes into detail with some of the Java code used to generate the X.509 fields. You could accomplish the extension of all X.509 protocols using Java with a combination of the information presented on key storage and transference in Chapter 7, this chapter (Chapter 24), and Chapter 8. A self-signed certificateWhen you generate a digital certificate using the keytool utility, the certificate is a self-signed certificate. A self-signed certificate is a root certificate, meaning that the certificate was not passed through a CA or even multiple CAs. After the certificate information is signed, it is encrypted with the issuer's private key. Only the issuer's public key can decrypt the signature to verify the validity of the certificate. The public key is also included in the digital certificate. The certificate is considered to be from a trusted location. Sometimes a certificate will go through several trusted locations, each trusting and validating each other. If there is any question as to the authenticity of the digital certificate, the certificate will be added to the Certificate Revocation List (CRL) to be revoked for subsequent uses. The digital certificate can be questioned and verified through multiple trusted sources. The combination of these trusted sources for a specific certificate is known as the certificate's chain. The certificate chain is a chain of responsibility asking if the certificate can be trusted until the subject reaches a trusted source that is unquestionable to the subject. The certificate chain does not exist for a self-signed certificate, because the certificate is at its originating source. When a certificate is generated with the keytool , it has originated locally and has not been requested through a CA.
X.509 also defines alternative authentication protocols based on the use of public key certificates. The importance of X.509 is that it defines the structure of digital certificates and the related protocols, such as TLS, which are used in PKI. The X.509 specification was originally created in 1988, the second version was updated in 1993, and the current version, (the third) was drafted in 1995. There are many algorithms for encrypting and for public key exchange. Standard algorithms are recommended, however, very much like the ones specified for TLS. The digital signatures require a one-way hash algorithm such as SHA-1 or MD5. Some of the certificate entries were first developed in version 1 of the X.509, such as version number and signature. Version 2 of the certificate included the Unique Identifier of both the issuer and the subject. Version 3 included extensions that follow a name/value pair like Key Usage. Version 2 and version 3 entries will be discussed in detail later in this chapter. Version 1 entries are discussed in detail first. Many of the methods used to retrieve the certificate entries are displayed in Figure 24-2 along with the basic form of the X.509 certificate.  Figure 24-2: Certificate basic structure Let's start by printing out the version 1 entries using code. Listing 24-1 provides the code for importing a version 1 certificate. This code imports the file, basically by opening a certification file and initializing the X509Certificate class with the contents of the file. Using the version 1 methods from the X509Certificate class, the code retrieves the data and prints it out to the screens. The CertificateFactory initializes the type of certificate that is created in the program. The CertificateFactory is an engine class described in Chapter 8. Listing 24-1: The RichCertificate class: Importing X509Certificate version 1 in Java
package com.richware.chap24; import java.security.PublicKey; import java.security.Principal; import java.security.cert.X509Certificate; import java.security.cert.CertificateException; import java.security.cert.CertificateFactory; import java.io.FileInputStream; import java.io.FileNotFoundException; /** * Class RichCertificate * Description: A custom demonstration of the certificate. * * Copyright: Copyright (c) 2002 Wiley Publishing, Inc. * @author Rich Helton <rhelton@richware.com> * @version 1.0 * DISCLAIMER: Please refer to the disclaimer at the beginning of this book. */ public class RichCertificate { /** * Method main * Description: The main driver to run the methods. * * * @param args (no arguments presently). * */ public static void main(String args[]) { try { System.out.println("Starting RichCertificate...."); /* * Pass in the argument of the keystore file * It will be opened in the same directory as the application */ if (args[0] == null) { System.out.println( "This application requires an input file for the location of the certificate"); } String localDirectory = System.getProperty("user.dir"); System.out.println("Changing directory to Chapter 24"); System.setProperty("user.dir", localDirectory + "\com\richware\chap24\"); localDirectory = System.getProperty("user.dir"); /* * Get the local keystore that contains a trusted certificate */ String localInputFile = localDirectory + args[0]; System.out.println( "Openining Chapter 24 plus the input file as an argument: " + localInputFile); /* * Import the certificate */ RichCertificate myCertificate = new RichCertificate(); X509Certificate newcertificate = myCertificate.importCertificate(localInputFile); myCertificate.printVersion1(newcertificate); /* * catches. */ } catch (Exception e) { e.printStackTrace(); } } /** * Method importCertificate * Description: Import the certificate. * * @param filename is the file to import. * * @return the certification. * */ public X509Certificate importCertificate(String filename) { X509Certificate cert = null; try { CertificateFactory cf = CertificateFactory.getInstance("X509"); /* * Get the File I/O of the Certificate */ FileInputStream fr = new FileInputStream(filename); /* * Construct the certificate based on the import */ cert = (X509Certificate) cf.generateCertificate(fr); /* * catches. */ } catch (CertificateException e) { e.printStackTrace(); } catch (FileNotFoundException e) { e.printStackTrace(); } return cert; } /** * Method printVersion1 * Description: Print version 1 information of the Certificate. * * * @param cert is the certification to read from. * */ public void printVersion1(X509Certificate cert) { try { /* * Get the information of the certificate. */ System.out.println( "Certificate->Version Number*****************"); System.out.println(cert.getVersion()); System.out.println( "Certificate->Serial Number******************"); System.out.println(cert.getSerialNumber()); System.out.println( "Certificate->Signature Algorithm Identifier*"); System.out.println(cert.getSigAlgName()); System.out.println( "Certificate->Issuer Name********************"); System.out.println(cert.getIssuerDN()); System.out.println( "Certificate->Not Before Validity************"); System.out.println(cert.getNotBefore()); System.out.println( "Certificate->Not After Validity*************"); System.out.println(cert.getNotAfter()); System.out.println( "Certificate->Subject Name*******************"); System.out.println(cert.getSubjectDN()); System.out.println( "Certificate->Subject Public Key Information*"); System.out.println(cert.getPublicKey()); System.out.println( "Certificate->Signature**********************"); System.out.println(cert.getSignature()); /* * catches. */ } catch (Exception e) { e.printStackTrace(); } } }
The output of Listing 24-1 is included in Listing 24-2. The output is totally dependent on how the digital certificate was generated. Listing 24-2: Output for Listing 24-1
>java com.richware.chap24.RichCertificate rich.cer Starting RichCertificate.... Changing directory to Chapter 24 Openining Chapter 24 plus the input file as an argument: C:\com\richware\chap24\rich.cer Certificate->Version Number***************** 1 Certificate->Serial Number****************** 1006541843 Certificate->Signature Algorithm Identifier* SHA1withDSA Certificate->Issuer Name******************** CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us Certificate->Not Before Validity************ Fri Nov 23 11:57:23 MST 2001 Certificate->Not After Validity************* Thu Feb 21 11:57:23 MST 2002 Certificate->Subject Name******************* CN=Rich Helton, OU=development, O=richware, L=denver, ST=co, C=us Certificate->Subject Public Key Information* Sun DSA Public Key Parameters:DSA p: fd7f5381 1d751229 52df4a9c 2eece4e7 f611b752 3cef4400 c31e3f80 b6 512669 455d4022 51fb593d 8d58fabf c5f5ba30 f6cb9b55 6cd7813b 801d346f f26660b7 6b9950a5 a49f9fe8 047b1022 c24fbba9 d7feb7c6 1bf83b57 e7c6a8a6 150f04fb 83f6d3c5 1ec30235 54135a16 9132f675 f3ae2b61 d72aeff2 2203199d d14801c7 q: 9760508f 15230bcc b292b982 a2eb840b f0581cf5 g: f7e1a085 d69b3dde cbbcab5c 36b857b9 7994afbb fa3aea82 f9574c0b 3d 078267 5159578e bad4594f e6710710 8180b449 167123e8 4c281613 b7cf0932 8cc8a6e1 3c167a8b 547c8d28 e0a3ae1e 2bb3a675 916ea37f 0bfa2135 62f1fb62 7a01243b cca4f1be a8519089 a883dfe1 5ae59f06 928b665e 807b5525 64014c3b fecf492a y: 11f605f8 7dee5f91 33631abb ec1ca443 6e41033a b25316ba bb44bb60 93c7828e 6272f95b 02b1e59d 90f6ad6e 3d81cab2 50b945d1 c7282980 0e10d34f 63708366 85c00fe3 679d1ce9 0e308f3c bb49838a 623be15a c9032274 4ce6fb19 0cc0b31a 7b6c9cf0 1965c01c 07d7c2c1 2ad4e3cf cdd9c40a dcbc10fe ee099966 043a7066 Certificate->Signature********************** [B@aaa14a
The certificate that was imported was generated and exported using the keytool . The generated certificate is shown in Listing 24-3. Listing 24-3: The generated certificate
-----BEGIN CERTIFICATE----- MIIDCDCCAsYCBDv+nBMwCwYHKoZIzjgEAwUAMGoxCzAJBgNVBAYMAnVzMQswCQYDVQQIDAJjbzEP MA0GA1UEBwwGZGVudmVyMREwDwYDVQQKDAhyaWNod2FyZTEUMBIGA1UECwwLZGV2ZWxvcG1lbnQx FDASBgNVBAMMC1JpY2ggSGVsdG9uMB4XDTAxMTEyMzE4NTcyM1oXDTAyMDIyMTE4NTcyM1owajEL MAkGA1UEBgwCdXMxCzAJBgNVBAgMAmNvMQ8wDQYDVQQHDAZkZW52ZXIxETAPBgNVBAoMCHJpY2h3 YXJlMRQwEgYDVQQLDAtkZXZlbG9wbWVudDEUMBIGA1UEAwwLUmljaCBIZWx0b24wggG3MIIBLAYH KoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y +r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYVDwT7g/bT xR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL8Fgc9QKBgQD3 4aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgWE7fP CTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8Gkotm XoB7VSVkAUw7/s9JKgOBhAACgYAR9gX4fe5fkTNjGrvsHKRDbkEDOrJTFrq7RLtgk8eCjmJy+VsC seWdkPatbj2ByrJQuUXRxygpgA4Q009jcINmhcAP42edHOkOMI88u0mDimI74VrJAyJ0TOb7GQzA sxp7bJzwGWXAHAfXwsEq1OPPzdnECty8EP7uCZlmBDpwZjALBgcqhkjOOAQDBQADLwAwLAIUSM9W zM/EKrP2r5D58cGNXJdiwYYCFDc1v72BB3E4kAEVUFnGzYguKodD -----END CERTIFICATE-----
Some of the X.500 features of the certificate can be seen in the Issuer Name and Subject Name sections that define the organization, location, state, common name, and organizational unit. Many protocols, such as LDAP and X.500, use this information for building a directory tree for storage of the certificate. Another form of tree structure is the Internet. The organization could be treated as a domain name, such as www.richware.com . The organizational unit (OU), common name (CN), location (L), state (ST), and country (C) are used to store the certificate by different organizations that need it for storage and transportation. You may want to refer to Figure 24-1 because it is discussed in more detail now. Other organizations will receive the certificate to get the public key. The issuer organization keeps the private key that is used to encrypt the certificate. The CA also manages and stores the certificates. The X.500 information is needed by all these organizations to define how to store the certificate. The X.500 information could also be used to map to the exact location from the issuer and to the receiver (the subject). Most certificates are generated by a CA and tracked by the CA in an X.509 directory structure. A copy could also be kept by the organization for additional verification. The X.500 directory structure provides access to the certificates. The version 1 certificate normally includes the following:
Version 2 unique identifier fieldsAs mentioned before, in 1993, the X509 certificate was updated for version 2. The reason for the new version was that some DNs were not being kept unique enough from the registration. For example, when generating the certificate, I might have entered the organization code in the certificate as richware instead of richware,LLC . There are at least two richware organizations. In version 1, there is no way to uniquely identify the two organizations. Version 2 suggested having a string of bits to keep the organizations separate. That way a CA may know to send to richware with a bit string of 00000010 to my organization instead of another. It was not long before version 3 offered other alternatives, and many organizations and CAs don't support unique identifiers; therefore, unique identifiers are not recommended. An alternative in X509 version 3 is to add the URIName of www.richware.com . This way users of the certificate know that it came from my RichWare,LLC and not another organization. The two main fields for identification are the subject and issuer, and the unique identifier fields support both the Issuer Unique Identifier and a Subject Unique Identifier. To retrieve the Issuer Unique Identifier, the getIssuerUniqueID ( ) method of the X509Certificate class is used to return an array of booleans . Each boolean entry represents a bit. To retrieve the Subject Unique Identifier, the getSubjectUniqueID ( ) method of the X509Certificate class is used to return an array of booleans as a bit string. These are optional fields. Not all applications check these fields and there is no way to keep them unique. So you should use the fields in version 3 if there is any ambiguity to the DN, or simply to ensure that the DN is unique. Version 3 key extensionsIn the earlier versions of X509, there were issues with the key information that required extensions. One of the questions asked was, "What if the private key has different validity dates than the public key?" Other questions were, "If there are multiple subject public keys, which one do I use?" and "What was the intended purpose of the public key: for the CA to verify the digital signature or the subject?" When the digital certificate became more common, the answer to those questions was to extend the format of the X.509 digital certificate. The extensions were to become version 3 of the X.509. Each field in the X.509 version 3 has three parts : the field type, field criticality, and value. The criticality field states whether the field is critical for the operation of the certificate. The certificate is invalid if the field is set to critical and the application does not recognize the information in the field. If the field is non-critical, the values in the field are used for information only and the validity of the certificate does not depend on the field. The field type is the description of the field, and the certificate uses the associated value. In some cases the X509Extension class is used to retrieve the extensions. Getting the extension is done with the getExtendedValue ( ) method. To retrieve the value through the getExtendedValue ( ) method , the OID of the extension must be passed in as a parameter. The OID is an object identifier that maps the field to a specific object. The OID of the matching field is registered as part of the specification. Figure 24-3 maps the certificate extensions for X.509 version 3 with the X509Certificate class.  Figure 24-3: Version 3 extensions The following certificate fields in X.509 version 3 are extended for the key use:
Some of the fields described in this section do not have a corresponding method to return the extended information in the X509Certificate class, such as the Subject Key Identifier field. The X509Certicate class is extended by the X509Extension class, so that any field may return a byte array by passing the OID of the extension in the getExtensionValue ( ) method. For instance, the OID for Subject Key Identifier is "2.5.29.14" . Passing the OID into the method as getExtensionValue("2.5.29.14") will return a byte array for the Subject Key Identifier. Version 3, Policy Mapping ExtensionsCertificates can be issued for many reasons and applications, such as e-mail and an HTTPS server. The certificate policy defines the reason for the issuing of the certificate, such as to facilitate an HTTPS server. The policy contains an OID that the issuer and subject have agreed upon. The OID defines the policy, or reason for the issuing of the certificate. A certificate can contain a list of policies for multiple purposes of the certificate. The OIDs are registered through a Policy Authority that is defined in standard ISO/IEC 9834-1. The Policy Authority issues a set of policies known as a policy domain . The issuer and subject access the policy domain to know which OIDs and matching policies are available. The policy domain provides the mapping of OIDs to defined policies. The policy mapping is as follows :
Version 3, Certificate Alternative Names ExtensionsYou've learned that the subject's and issuer's names are given in the form of a DN to resolve the issuer and subject. This proved to have issues because some applications and protocols required particular name formats that did not match the DN format. Version 3 had to extend the names and add formats to support different protocols that required some other form of naming besides the DN formats. Some of these formats were needed to support a World Wide Web name, IP addresses, e-mail naming conventions, and registered names in an Object Identifier (OID) format, to name a few. One of the reasons to note why other naming conventions were required is that other applications, such as e-mail, may also use digital certificates. There are two types of Alternative Names, the Subject Alternative Name to give different names for the subject of the certificate, and the Issuer Alternative Name to give different names to the issuer of the certificate. The Alternative Names are used when the names cannot be defined in the X.500 DN format. To retrieve the information from an X509Certificate object, the getIssuerAlternative ( ) method is used to retrieve the Issuer Alternative Name and the getSubjectAlternative ( ) method is used to retrieve the Subject Alternative Name. These two methods return a Collection data class type that contains List class entries. Each entry has two fields: an integer for the name type, and the name in the form of a string or byte array. The name type determines if the second field is in the form of a string or byte array. According to RFC 2459, the data type for defining the Alternative Names should be in the form of a GeneralName . Internally, the X509Certificate uses a GeneralName class in the sun.security.X509 package. Internally, there are many classes that can construct the GeneralName class through the GeneralNameInterface . Each name type has a corresponding class to build the name type in an appropriate format. For instance, in the sun.security.X509 package, the URIName class is the corresponding class. The URIName class is responsible for formatting and ensuring the naming convention of the Uniform Resource Identifier name type. Knowing this is important if the Alternative Names are ever created or formatted in a Java application. Following are the names that make up the GeneralName and their corresponding integers for the type values:
Version 3, Certificate Constraints X509CertificateThese version 3 extensions convey additional information when the subject is a CA. These fields can only be used when the subject is a CA.
 Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |
