Method and system for presentation and manipulation of PKCS signed-data objects

[0002] The present invention is related to the following applications entitled “METHOD AND SYSTEM FOR PRESENTATION AND MANIPULATION OF PKCS CERTIFICATION REQUESTS”, U.S. application Ser. No. 09/460,837, “METHOD AND SYSTEM FOR PRESENTATION AND MANIPULATION OF PKCS ENVELOPED-DATA OBJECTS”, U.S. application Ser. No. 09/460,839, “METHOD AND SYSTEM FOR PRESENTATION AND MANIPULATION OF PKCS AUTHENTICATED-DATA OBJECTS”; U.S. application Ser. No. 09/460,840, and all of which are assigned to the same assignee.

[0003] 1. Technical Field

[0004] The present invention relates generally to an improved data processing system and, in particular, to a method and apparatus for processing cryptographic data objects formatted according to interoperable standards.

[0005] 2. Description of Related Art

[0006] Public-key cryptography is the technology in which encryption and decryption involve different keys. The two keys are the public key and the private key, and either can encrypt or decrypt data. A user gives his or her public key to other users, keeping the private key to himself or herself. Data encrypted with a public key can be decrypted only with the corresponding private key, and vice versa.

[0007] As public-key cryptography has gained acceptance, standards have become necessary so that software at two different sites could work together even when the software is developed by different vendors. In particular, standards have been developed to allow agreement on digital signatures, digital enveloping, digital certification, and key agreement. However, interoperability requires strict adherence to communicable formats, and PKCS, or “Public Key Cryptography Standard,” provides a basis for interoperable standards in heterogeneous environments.

[0008] PKCS is a set of documents published by RSA Laboratories that serves to define data types and algorithms used in public-key cryptography. The first set of ten PKCS standards was released in 1991. In the 1993 release PKCS #2 and #4 were incorporated into PKCS #1, so the set of standards included:

[0009] PKCS #1: RSA Encryption Standard;

[0010] PKCS #3: Diffie-Hellman Key Agreement Standard;

[0011] PKCS #5: Password-Based Encryption Standard;

[0012] PKCS #6: Extended-Certificate Syntax Standard;

[0013] PKCS #7: Cryptographic Message Syntax Standard;

[0014] PKCS #8: Private-Key Information Syntax Standard;

[0015] PKCS #9: Selected Attribute Types; and

[0016] PKCS #10: Certification Request Syntax Standard.

[0017] PKCS continues to evolve and the following standards have been added since 1993:

[0018] PKCS #11: Cryptographic Token Interface Standard;

[0019] PKCS #12: Personal Information Exchange Syntax Standard;

[0020] PKCS #13: Elliptic Curve Cryptography Standard; and

[0021] PKCS #15: Cryptographic Token Information Format Standard.

[0022] Two independent levels of abstraction have been provided by these standards. The first level is message syntax, and the second level is specific algorithms. The intention has been that message syntax and specific algorithms should be orthogonal. In other words, a standard for the syntax of digitally signed messages should be able to work with any public-key algorithm, not just RSA, the public-key algorithm invented by Rivest, Shamir, and Adleman involving exponentiation modulo the product of two large prime numbers; and a standard for RSA should be applicable to many different message syntax standards.

[0023] One of these standard documents, PKCS #9, defines a set of attributes that can be used in other PKCS standards. In particular, PKCS #9 defines selected attribute types for use in PKCS #6 extended certificates, PKCS #7 digitally signed messages, PKCS #8 private-key information, PKCS #12 personal information, and PKCS #15 cryptographic token information.

[0024] PKCS 190 7 describes a general syntax for data that may have cryptography applied to it. In other words, PKCS #7 defines the syntax for several cryptographically protected messages, including encrypted messages and messages with digital signatures. The syntax admits recursion, so that one envelope can be nested inside another or one party can sign previously enveloped digital data. PKCS 190 7 also allows arbitrary attributes, such as signing time, to be authenticated along with the content of a message, and it also provides for other attributes, such as countersignatures, to be associated with a signature. A degenerate case of the syntax provides a means for disseminating certificates and certificate-revocation lists. PKCS 190 7 can also support a variety of architectures for certificate-based key management.

[0025] Originally an outgrowth of Internet Privacy-Enhanced Mail, PKCS 190 7 has become the basis for the widely implemented Secure/Multipurpose Internet Mail Extensions (S/MIME) secure electronic mail specification, an Internet e-mail security standard that employs public key encryption. PKCS 190 7 has become a basis for message security in systems as diverse as the Secure Electronic Transaction (SET) specification for bank systems.

[0026] PKCS 190 7 is compatible with Privacy-Enhanced Mail (PEM) in that signed-data and signed-and-enveloped data content, constructed in a PEM-compatible mode, can be converted into PEM messages without any cryptographic operations. A PEM message can similarly be converted into the signed-data and signed-and-enveloped data content types, i.e. a form that can be processed by applications including or implementations including PKCS #7 without any cryptographic operations. The conversion process is “flat” in the sense that the encapsulated text of the PEM message becomes the “inner” content of the PKCS 190 7 data. If the encapsulated text happens to contain privacy-enhanced messages, those messages are not implemented in the conversion process. PEM can effectively be viewed as a set of encoding rules analogous to the Basic Encoding Rules for ASN.1, abbreviated BER, for PKCS 190 7 data with these restrictions. Conversion from PKCS 190 7 to PEM may involve omission of attributes from PKCS #6 extended certificates, which is acceptable since the attributes are not essential to PEM.

[0027] The values produced according to PKCS 190 7 are intended to be BER-encoded. Abstract Syntax Notation One, abbreviated ASN.1, is a notation for describing abstract types and values. The Basic Encoding Rules for ASN.1 give one or more ways to represent any ASN.1 value as an octet string. The Distinguished Encoding Rules for ASN.1, abbreviated DER, are a subset of BER, and give exactly one way to represent any ASN.1 value as an octet string. DER is intended for applications in which a unique octet string encoding is needed, as is the case when a digital signature is computed on an ASN.1 value. ASN.1 and DER encoding are general purpose methods that can be applied to many domains in addition to PKCS.

[0028] A PKCS #7 SignedData object and the objects that may be contained within a SignedData object are defined in RFC 2630, “Cryptographic Message Syntax,” June 1999. Within this standard, the attribute definition includes the object version number, a set of message digest algorithms, the content that is signed, a set of certificates, a set of Certificate Revocation Lists (CRLs), and a set of SignerInfo objects that, among other attributes, each contain the signature of the contents for a given certificate.

[0029] SignedData objects were designed for a heterogeneous environment in which the SignedData object and the objects within it can be DER-encoded into a stream of bytes. The DER encoding can be transferred from one system to a completely different system and decoded to reform the SignedData object.

[0030] With all the attributes that are part of a SignedData object, administrators, applications developers, and other users can easily be lost in details. They may have access to all the integral objects used in creating a SignedData object, such as the text file to be signed, a certificate file, and a private key file, but they may lack the application or means to merge the objects together to create a SignedData object. In other situations, users may receive a SignedData object as an external file or as part of an S/MIME object for which they do not have a targeted application or that they do not wish to be automatically included in a targeted application.

[0031] Therefore, it would be advantageous to have an improved method and system for presenting and manipulating secure data objects using interoperable standards within heterogeneous environments, such as using PKCS within a distributed computing environment. It would be still more advantageous to provide users with a method and system to graphically construct a PKCS SignedData object as well as view and manipulate a SignedData object that has been stored or received.

[0032] A method and system for processing signed data objects in a data processing system is presented. The signed data object may be formatted, i.e. maintain a syntax, as defined by PKCS (Public Key Cryptography Standard) standards. A signed data object utility allows a user to view and edit the contents of data objects embedded within a signed data object via a graphical user interface. Graphical objects represent the data objects embedded within a signed data object. A user may drag and drop objects onto other objects within the signed data object, and the signed data object utility automatically performs the necessary signing operations. Logical associations between data objects contained within the signed data object, such as between certificates and signer information objects, are determined or created, and the logical associations are displayed using visual indicators, such arrows or other links, between graphical objects representing the associated data objects. As data objects are added or deleted through user actions on the graphical objects, the visual indicators are updated to reflect any updates to the logical associations between the data objects. The user may direct other operations on the signed data object through the graphical user interface.

[0033] The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

[0034] FIG. 1 is a pictorial representation of a distributed data processing system in which the present invention may be implemented;

[0035] FIG. 2A is a block diagram depicting a data processing system that may be implemented as a server;

[0036] FIG. 2B is a block diagram illustrating the relationship of software components operating within a computer system that may implement the present invention;

[0037] FIG. 3 depicts a dialog window for presenting and manipulating PKCS SignedData objects;

[0038] FIGS. 4A-4D depict a flowchart depicting the processing of user actions within a dialog window of a SignedData interface utility for viewing and manipulating SignedData objects, such as the SignedData object shown in FIG. 3;

[0039] FIG. 5A depicts a dialog window for presenting SignerInfo object information for a SignerInfo object selected by a user within a SignedData interface utility dialog window;

[0040] FIG. 5B is the format of a SignerInfo object data type;

[0041] FIG. 6 depicts a dialog window for presenting certificate information for certificates selected by a user within a SignedData interface utility dialog window; and

[0042] FIG. 7 depicts a dialog window for presenting certificate revocation list (CRL) information for a CRL selected by a user within a SignedData interface utility dialog window in accordance with a preferred embodiment of the present invention.

[0043] With reference now to the figures, FIG. 1 depicts a pictorial representation of a distributed data processing system in which the present invention may be implemented. Distributed data processing system 100 is a network of computers in which the present invention may be implemented. Distributed data processing system 100 contains a network 102, which is the medium used to provide communications links between various devices and computers connected together within distributed data processing system 100. Network 102 may include permanent connections, such as wire or fiber optic cables, or temporary connections made through telephone connections.

[0044] In the depicted example, a server 104 and server 106 is connected to network 102 along with storage unit 108. In addition, clients 110, 112, and 114 also are connected to network 102. These clients 110, 112, and 114 may be, for example, personal computers or network computers. For purposes of this application, a network computer is any computer, coupled to a network, which receives a program or other application from another computer coupled to the network. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 110-114.

[0045] Clients 110, 112, and 114 are clients to server 104. Additionally, clients 110-114 also may be clients to server 106 in these examples. Distributed data processing system 100 may include additional servers, clients, and other devices not shown. In the depicted example, distributed data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the TCP/IP suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational, and other computer systems that route data and messages. Of course, distributed data processing system 100 also may be implemented as a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN). FIG. 1 is intended as an example of a heterogeneous computing environment and not as an architectural limitation for the present invention.

[0046] With reference now to FIG. 2A, a block diagram depicting a data processing system that may be implemented as a server, such as server 104 or server 106 in FIG. 1. Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors 202 and 204 connected to system bus 206. Alternatively, a single processor system may be employed. Also connected to system bus 206 is memory controller/cache 208, which provides an interface to local memory 209. I/O bus bridge 210 is connected to system bus 206 and provides an interface to I/O bus 212. Memory controller/cache 208 and I/O bus bridge 210 may be integrated as depicted.

[0047] Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to network computers 108-112 in FIG. 1 may be provided through modem 218 and network adapter 220 connected to PCI local bus 216 through add-in boards.

[0048] Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, data processing system 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.

[0049] Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 2A may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention. The data processing system depicted in FIG. 2A may be, for example, an IBM RISC/System 6000 system, a product of International Business Machines Corporation in Armonk, N.Y. running the Advanced Interactive Executive (AIX) operating system. Alternatively, the operating system may be another commercially available operating system such as JavaOS For Business™ or OS/2™, which are also available from IBM. JavaOS is loaded from a server on a network to a network client and supports Java programs and applets. An object oriented programming system such as Java may run in conjunction with the operating system and may provide calls to the operating system from Java programs or applications executing on the data processing system.

[0050] The present invention provides a method, a system or apparatus, and computer-implemented instructions for processing signed data objects on a variety of computer platforms and operating systems. Although the present invention could be implemented in most computer languages, it is preferably implemented in Java due to the ability to run Java code in a distributed, heterogeneous environment. Hence, the present invention may operate within a Java runtime environment and operate in conjunction with a Java virtual machine (JVM) yet within the boundaries of a JVM as defined by Java standard specifications. In order to provide a context for the present invention, portions of the operation of a JVM according to Java specifications are herein described.

[0051] With reference now to FIG. 2B, a block diagram illustrates the relationship of software components operating within a computer system that may implement the present invention. Java-based system 250 contains platform specific operating system 252 that provides hardware and system support to software executing on a specific hardware platform. JVM 254 is one software application that may execute in conjunction with the operating system. JVM 254 provides a Java runtime environment with the ability to execute Java application or applet 256, which is a program, servlet, or software component written in the Java programming language. The computer system in which JVM 254 operates may be similar to data processing system 200 described above. However, JVM 254 may be implemented in dedicated hardware on a so-called Java chip, Java-on-silicon, or Java processor with an embedded picoJava core.

[0052] At the center of a Java runtime environment is the JVM, which supports all aspects of Java's environment, including its architecture, security features, mobility across networks, and platform independence. The JVM is a virtual computer, i.e. a computer that is specified abstractly. The Java specifications define certain features that every JVM must implement, with some range of design choices that may depend upon the platform on which the JVM is designed to execute. For example, all JVMs must execute Java bytecodes and may use a range of techniques to execute the instructions represented by the bytecodes. A JVM may be implemented completely in software or somewhat in hardware. This flexibility allows different JVMs to be designed for hardware platforms, such as mainframe computers and PDAs.

[0053] The JVM is the name of a virtual computer component that actually executes Java programs. Java programs are not run directly by the central processor but instead by the JVM, which is itself a piece of software running on the processor. The JVM allows Java programs to be executed on a different platform as opposed to only the one platform for which the code was compiled. Java programs are compiled for the JVM. In this manner, Java is able to support applications for many types of data processing systems, which may contain a variety of central processing units and operating systems architectures.

[0054] The data processing systems described above with respect to FIGS. 1-2B may be used to create, modify, transmit, store, and receive signed data objects formatted according to interoperably defined cryptography standards, and in particular, PKCS 190 7 SignedData objects. The following discussion provides background information on the utility of certificates, signatures, etc.

[0055] A certificate is a digital document that vouches for the identity and key ownership of an individual, a computer system, a specific server running on that system, or an organization. For example, a user's certificate verifies that the user owns a particular public key. Certificates are issued by certificate authorities. These authorities are responsible for verifying the identity and key ownership of the individual before issuing the certificate. An identity certificate is a digitally signed statement from one entity, saying that the public key of some other entity has some particular value.

[0056] Public keys are byte arrays associated with a particular entity, and are intended to be known to everyone who needs to have trusted interactions with that entity. An entity is a person, organization, program, computer, business, bank, etc. If some data is digitally signed, it has been stored with the “identity” of an entity and a signature that proves that entity originated the data. A signature is computed from some data and the private key of an entity.

[0057] Private keys are byte arrays that are supposed to be known only to a particular entity, i.e. kept secret. In a typical public key cryptographic system, a private key corresponds to exactly one public key.

[0058] Certificates rely on public key cryptographic systems in which (a) private and public keys are paired, (b) private keys are used to sign, and (c) public keys are used to verify signatures. A certificate authority (CA) is an entity (e.g., a business) that is trusted to sign (issue) certificates for other people (entities). It usually has some kind of legal responsibilities for its vouching of the binding between a public key and its owner that allow one to trust the entity that signed a certificate.

[0059] There are two basic techniques used to get certificates: (1) create a self-signed certificate oneself using the proper software, or (2) ask someone else, such as a certificate authority, to issue one. There are two main inputs to the certificate creation process. The first input is a pair of matched public and private keys generated using some special software. Only the public key is ever shown to anyone else. One usage of a private key is to sign data; if someone improperly knows or acquires a private key, they can forge legal documents attributed to a third party. The second input is information about the entity being certified, such as an individual. This normally includes information such as a name and organization address. If a certificate authority issues a certificate, one will normally need to provide proof of identity.

[0060] If a certificate authority issues a certificate for an individual, the individual must provide a public key and some information about himself. A tool, such as Netscape Navigator, may digitally sign this information and send it to the certificate authority. The certificate authority might be a company that provides trusted third-party certificate authority services. The certificate authority will then generate the certificate and return it. The certificate may contain other information, such as dates during which the certificate is valid and a serial number. One part of the value provided by a certificate authority is to serve as a neutral and trusted introduction service, based in part on their verification requirements, which are openly published in their Certification Service Practices (CSP).

[0061] The X.509 standard is one of many standards that defines what information can go into a certificate and describes the data format of that information. The “version” field indicates the X.509 version of the certificate format (1, 2, or 3), with provision for future versions of the standard. This identifies which version of the X.509 standard applies to this certificate, which affects what information can be specified in it. Thus far, three versions are defined. Version 1 of the X.509 standard for public key certificates was ratified in 1988. The version 2 standard, ratified in 1993, contained only minor enhancements to the version 1 standard. Version 3, defined in 1996, allows for flexible extensions to certificates in which certificates can be “extended” in a standardized and generic fashion to include additional information. In addition to the traditional fields in public key certificates (i.e. those defined in versions 1 and 2 of X.509), version 3 comprises extensions referred to as “standard extensions”. The term “standard extensions” refers to the fact that the version 3 X.509 standard defines some broadly applicable extensions to the version 2 certificate. However, certificates are not constrained to only the standard extensions and anyone can register an extension with the appropriate authorities (e.g., ISO). The extension mechanism itself is completely generic.

[0062] The “serial number” field specifies the unique, numerical identifier of the certificate in the domain of all public key certificates issued by a particular certificate authority (CA) in order to distinguish one certificate from another. When a certificate is revoked, it is actually the certificate serial number that is posted in a certificate revocation list signed by the certificate authority since posting the entire certificate would be wasteful and completely unnecessary. It is for this reason that the serial number for each certificate in the domain must be unique. The “signature algorithm” field identifies the algorithm used by the certificate authority to sign the certificate. The algorithm identifier, which is a number registered with an internationally-recognized standards organization (e.g., ISO), specifies both the public-key algorithm and the hashing algorithm used by the certificate authority to sign certificates.

[0063] The “issuer name” field specifies the X.500 Distinguished Name (DN) of the certificate authority that issued the certificate. For example, the Distinguished Name “c=US, o=ACME Corporation” might be used as the Distinguished Name for the certificate authority issuing certificates to the employees of the ACME Corporation in the United States. In some cases, such as root or top-level certificate authority certificates, the issuer signs its own certificates. The “validity period” field specifies the dates and times for the start date and the expiration date of the certificate. Every time a certificate is used, the software should examine the certificate to ensure it is still within its validity period. Each certificate is valid only for a limited amount of time, but this period can be as short as a few seconds or almost as long as a century. The validity period depends on a number of factors, such as the strength of the private key used to sign the certificate or the amount one is willing to pay for a certificate.

[0064] The “subject name” field specifies the X.500 Distinguished Name of the entity holding the private key corresponding to the public key identified in the certificate; for example, the Distinguished Name “c=US, o=ACME Corporation, cn=John M. Smith” might be the Distinguished Name for employee John M. Smith of the ACME corporation, where “cn” stands for “common name”, “o” is “organization”, and “c” is “country”.

[0065] The “public key” field is the public key of the entity being named or identified by the certificate. The “subject public key information” field identifies two important pieces of information: a) the value of the public key owned by the subject, and b) the algorithm identifier specifying the algorithm with which the public key is to be used. The algorithm identifier specifies both the public-key algorithm and the hashing algorithm.

[0066] The “issuer unique identifier” field was added to the X.509 certificate definition as part of the version 2 standard. The field, which is optional, provides a location to specify a bit string to uniquely identify the issuer X.500 name, in the event that the same X.500 name has been assigned to more than one certificate authority over time.

[0067] The “subject unique identifier” field was added to the X.509 certificate definition as part of the version 2 standard. The field, which is optional, provides a location to specify a bit string to uniquely identify the subject X.500 name, in the event that the same X.500 name has been assigned to more than one subject over time (e.g., one John M. Smith leaves ACME Corporation and a second John M. Smith joins ACME Corporation two months later). This field is not used by most certificate authorities for various reasons primarily because there are more convenient ways to uniquely identify a subject. Specifically, most certificate authorities use the serialNumber attribute. Such a scheme fits well within an organization's administrative and directory management procedures because employees require a unique identifier in their X.500 common names anyway (e.g., to handle the case where there are two John M. Smith's in the organization at the same time).

[0068] X.509 Version 1 has been available since 1988, is widely deployed, and is the most generic. X.509 Version 2 introduced the concept of subject and issuer unique identifiers to handle the possibility of reuse of subject and/or issuer names over time. Most certificate profile documents strongly recommend that names not be reused, and that certificates should not make use of unique identifiers. Version 2 certificates are not widely used.

[0069] X.509 Version 3 is the most recent (1996) and supports the notion of extensions, whereby anyone can define an extension and include it in the certificate. Some common extensions in use today are: KeyUsage, which limits the use of the keys for particular purposes such as “signing-only”; and AltNames, which allows other identities to also be associated with this public key, e.g., DNS names, e-mail addresses, IP addresses. Extensions can be marked critical to indicate that the extension should be checked and enforced/used. So, for example, if a certificate has the KeyUsage extension marked critical and set to “keyCertSign” then if this certificate is presented during SSL Communication, it should be rejected, as the certificate extension indicates that the associated private key should only be used for signing certificates and not for SSL.

[0070] The keys used to interact with various parties need to be hung in a “key chain.” In the physical world, a key ring holds keys, and a wallet hold)multiple identification and credit cards. In the digital world, a directory service provides storage for digital keys and certificates. The X.500 and LDAP (Lightweight Directory Access Protocol) standards are two main contenders for directory services. Each entry in the directory service is globally and uniquely identified by a Distinguished Name. For example, John M. Smith, who belongs in the Executive Office department at Acme Corporation, might have the following Distinguished Name: “cn=John M. Smith, ou=Executive Office, o=ACME Corporation, c=US”, where “cn” stands for “common name”, “ou” is “organizational unit”, “o” is “organization”, and “c” is “country”.

[0071] Second-generation directory services store entries in proprietary file formats, hash, B-tree, or Relational Database Management System. Although RDBMS is not necessarily optimized for X.500 Distinguished Names, the maturity, scalability and additional utilities in RDBMS make it an attractive alternative as a directory service repository. X.509v3 certificates and public keys can also be stored and protected in an X.500- or LDAP-based directory service. If a user's secret key is compromised, the certificate associated with the public key must be revoked and added to the appropriate certificate authority's Certificate Revocation List (CRL).

[0072] As noted previously, with all the attributes that are part of a SignedData object, administrators, applications developers, and other users can easily be lost in details. Such users may have access to all the integral objects used in creating a SignedData object, such as the text file to be signed, a certificate file, and a private key file, but they may lack the application or means to merge the objects together to create a SignedData object. The present invention provides a graphical user interface methodology for presenting and manipulating, in particular, PKCS 190 7 SignedData objects. However, the present invention may be used to view and manipulate signed data objects other than PKCS #7 SignedData objects, assuming that the signed data objects are formatted according to interoperably defined cryptography standards with some functional similarity to the PKCS family of standards, such as encapsulated content, certificates, certificate revocation lists, etc. Preferably, the graphical user interface and other functionality described in the following figures may be readily implemented in Java to provide the methodology of the present invention in various interoperable, heterogeneous environments.

[0073] With reference now to FIG. 3, a dialog window for presenting and manipulating PKCS SignedData objects is shown in accordance with a preferred embodiment of the present invention. The dialog window provides a visual work area where SignedData objects can be created, changed, etc. The dialog window and associated functions in FIG. 3 and the subsequent figures may be implemented as a stand-alone utility or application, or the dialog window and associated functions may be implemented as an applet within a browser-type application or as a portion of some other type of application.

[0074] In the descriptions of the following figures, several common user interface events or actions are mentioned, and it should be noted that equivalent user actions may also be employed, as would be apparent to one of ordinary skill in the art. For example, when a drag and drop operation is mentioned, alternative user actions could be employed, such as selecting the file or data object from a file list box or some other import means. Double clicking on an object would be equivalent to executing a default action on the object. This action could also be accomplished after right clicking on the object and selecting the default action, which is usually highlighted in a graphically significant way, or via some other means. In general, users can forgo using menus for most operations.

[0075] Although areas of the visual display are used to associate similar objects, other manners of visually indicating associated objects may be employed. For example, objects of similar type may have similar colors or shapes that differ from the colors or shapes of other objects of a different type. Additionally, although arrows are shown as visual indicators for relational links between objects, other visual indicators may be employed. For example, similar shape modifications may be made to objects that have a particular relationship. As another alternative, if the objects shown in the dialog are too numerous to clearly show their relationships, the user may optionally remove the relationship indicators, or the user may be required to perform some type of user action to request to see the relationships, e.g. by selecting a button or menu, in which case another window is generated to show relationships. Alternatively, the interface utility could automatically expand the interface utility window in order to obtain the visual area necessary to display relationships between objects.

[0076] In order to exploit all of the features of the SignedData interface utility shown in FIG. 3, users typically need to know about certificates and CRLs and, in some cases, the encryption and signing algorithms. However, the interface can pick up most of the values automatically by traversing the objects according to the accepted format or syntax provided the PKCS standards. For example, the private key can be matched to its certificate via a token or PKCS #12 file, and encryption and signing algorithms can be stored and retrieved from previous e-mails or user interface actions. It should be noted that files in PKCS #12 format typically store a certificate and its associated private key. The contents of the PKCS #12 file are generally protected by a password or other key mechanism.

[0077] Dialog 300 in FIG. 3 is a graphical user interface window for a SignedData interface utility application that allows a user to view and manipulate signed data objects formatted according to interoperably defined cryptography standards, and in particular, PKCS 190 7 SignedData objects. The user may optionally be provided with functionality to configure the SignedData interface utility with user preferences as to default actions, default methods of displaying certain objects, etc., in a manner known to those skilled in the art of graphical user interfaces.

[0078] In summary, the signed-data content type consists of a content of any type and zero or more signature values. Any number of signers in parallel can sign any type of content. The typical application of the signed-data content type represents one signer's digital signature on content of the data content type. Another typical application disseminates certificates and certificate revocation lists (CRLs).

[0079] The process by which signed-data is constructed generally involves the following steps:

[0080] 1. For each signer, a message digest, or hash value, is computed on the content with a signer-specific message-digest algorithm. If the signer is signing any information other than the content, the message digest of the content and the other information are digested with the signer's message digest algorithm, and the result becomes the “message digest.”

[0081] 2. For each signer, the message digest is digitally signed using the signer's private key. If there are signed attributes with the message digest, the explicit set of the DER encoding of the signed attributes are signed.

[0082] 3. For each signer, the signature value and other signer-specific information are collected into a SignerInfo value. Certificates and CRLs for each signer, and those not corresponding to any signer, are collected in this step.

[0083] 4. The message digest algorithms for all the signers and the SignerInfo values for all the signers are collected together with the content into a SignedData value.

[0084] A recipient independently computes the message digest. This message digest or the DER encoding of the signed attributes and the signer's public key are used to verify the signature value. The signer's public key is referenced to a corresponding certificate either by an issuer distinguished name (issuerDN) along with an issuer-specific serial number or by a subject key identifier that uniquely identifies the certificate containing the public key. The signer's certificate may be included in the SignedData certificates field.

[0085] SignedData 301 provides the name of the SignedData object that is currently being viewed within dialog 300.

[0086] Version 302 is the syntax version number for the SignedData object being displayed within dialog 300. As the standards for signed data objects changes over time, various applications may create signed data objects in accordance with different versions of the standard. The version number is stored within the SignedData object so that an application may know by which version of the standard the SignedData object should be parsed, interpreted, or decoded.

[0087] Digest Algorithm 304 is a list of message digest algorithm identifiers, and the list may be implemented within dialog 300 as a drop-down list that only appears when the user selects the list, e.g. by right-clicking a mouse, so as to minimize the amount of screen space occupied by the list.

[0088] EncapsulatedContentInfo area 306 displays the name or identifier content object that is contained within the SignedData object.

[0089] The SignedData interface utility automatically updates the version and algorithm list as elements of the SignedData object are updated. Elements of a SignedData object are grouped by type into areas of the dialog window so that the user may visually grasp associated elements and their relationships. The user can drag and drop an object, such as a text file, onto the contents area of the dialog to update the contents with a new value. If optionally configured by the user, the interface utility will remove SignerInfo objects that were created off the old encapsulated contents when new content is added.

[0090] SignerInfo objects 310-311 are shown grouped within an area of dialog 300. These signer information objects would have been created when the previously specified contents were encapsulated into the SignedData object. The user can select a SignerInfo object and open a separate visual interface or dialog window to view and manipulate the objects contained within a selected SignerInfo object, e.g. by double-clicking on a SignerInfo object.

[0091] Certificate objects 321-324 are shown grouped within an area of dialog 300. This set of certificates are used to help the recipient of the SignedData object to identify the public key that will be needed to verify the signed contents of the SignedData object. The certificates will typically be in a certificate chain order. Arrows between certificates represent certificate chains that exist within the SignedData object, and arrows 325-326 between the certificate objects show the order from the entry level to the root certificate authority. More than one chain can be present, and not all certificates in the chain need to be present.

[0092] Arrows 327-328 between the SignerInfo objects and the certificates indicate which certificate is related to a particular SignerInfo object, i.e. the arrows indicate that the private key associated with a certificate was used to sign the contents.

[0093] To create a SignerInfo object, the user would need to have added, at a minimum, the encapsulated contents and a public certificate to the visual area. Next, the user would need to drag and drop a private key object, such as one wrapped in a PKCS #12 file object, into the visual area. The interface utility would then automatically create a SignerInfo object which contains the message digest of the contents along with the signature of the contents that was created from the dropped private key.

[0094] The user can add certificates to the SignedData object by dragging and dropping the certificate object or a PKCS #12 file containing the certificate on the visual area. The interface utility will add the certificate to the certificate list. If desired by the user, the interface utility can automatically import the certificates from the configured certificate database to construct the certificate chain for the user after a certificate has been added. The user can select a certificate object and open a separate visual interface or dialog window to view and manipulate the attributes contained within the selected certificate object, e.g., by double-clicking on a certificate.

[0095] Certificate Revocation List (CRL) 330 is shown within an area of dialog 300 that is reserved for CRLs. The set of CRLs shown in dialog 300 are used to help the recipient of the SignedData object to identify which certificates should be flagged as revoked. Arrows between a CRL and a certificate object indicate which certificate has been revoked by a particular CRL, and arrow 331 indicates that certificate 322 has been revoked as indicated within CRL 330. If optionally configured by the user, the interface utility will consult a Lightweight Directory Access Protocol (LDAP) database and use the X.509 names in the certificate and CRL objects to determine which certificates should be revoked. The user can add CRLs to the SignedData object by dragging and dropping the CRL object on the CRL visual area. The interface utility will add the CRL to the CRL set. The user can also select a CRL object and open a separate visual interface or dialog window to view and manipulate the attributes contained within the selected CRL object, e.g. by double-clicking on a CRL object.

[0096] Existing SignedData objects could be dragged and dropped onto the interface to view a preconstructed SignedData object. The interface could also export a SignedData object that passes validation to a file or other transfer mechanism, such as the clipboard, in a DER-encoded format. Before the SignedData object is exported or stored, the interface will run the defined elements through a set of verification rules, presenting errors to the user if present. The same validation checks will also occur when a SignedData object is imported into the interface. Send button 341 allows the user to send the SignedData object to previously specified e-mail addresses. Import button 342 allows the user to import a SignedData object from a specified DER-encoded file and populate the display objects. Export button 343 allows the user to store the SignedData object in a DER-encoded file.

[0097] With reference now to FIGS. 4A-4D, a flowchart depicts the processing of user actions within a dialog window of a SignedData interface utility for viewing and manipulating SignedData objects, such as the SignedData object shown in FIG. 3, in accordance with a preferred embodiment of the present invention. The process begins by waiting for a user action (step 401). In essence, the flowchart shows a main event loop for processing events within a graphical user interface. The process sits in the event loop monitoring for a user action, processing the user action, and then returning to monitor for additional user actions.

[0098] A determination is then made as to whether the user has dropped a file object into the EncapsulatedContentInfo section (step 402). If so, then the SignedData interface utility wraps the file content into an EncapsulatedContentInfo object (step 403). The new content is then displayed in the EncapsulatedContentInfo section (step 404). The process then loops through the SignerInfo objects to remove SignerInfo objects that were created off the old encapsulated contents (step 405). A determination is made as to whether a particular SignerInfo object has a stored associated private key (step 406). If not, then the SignerInfo object is deleted (step 407). A determination is then made as to whether there are other SignerInfo objects to be processed (step 408). If so, then the process branches back to step 405 to select another SignerInfo object to be processed. If not, then the processing of the operation of the file object is complete, and the process branches back to step 401. If the SignerInfo object that is currently being processed in the loop has an associated private key, then a recalculation is made for the signature on the contents using the private key, and the SignerInfo object is then updated (step 409). The process then continues looping through the SignerInfo objects if appropriate.

[0099] If the user action that has been detected is not an operation to add a file object to the EncapsulatedContentInfo section, then a determination is made as to whether a user has selected contents within the EncapsulatedContentInfo section and requested to delete the selected contents, such as by pressing the Delete key (step 410). If so, then the content is removed from the EncapsulatedContentInfo section and the display is updated (step 411). The process then branches back to step 401 to await another user action.

[0100] If the user has not requested to delete contents, then a determination is made as to whether the user has requested to add a certificate by dragging and dropping a certificate or PKCS #12 file object into the certificate list section (step 412). If so, then a determination is made as to whether a certificate already exists in the certificate list (step 413). If so, then the processing for the certificate is complete, and the process branches back to step 401 to await another user action.

[0101] If the certificate does not exist, then the certificate is added to the certificate list (step 414). A determination is then made as to whether each certificate in the certificate list has a subjectDN that matches the issuerDN for another certificate (step 415). If not, then processing is complete. If so, then a link is drawn between the two certificates, i.e., the two certificates which have a matching issuerDN and subjectDN pair (step 416), and the processing of the user action is then complete. If the user has not requested to add a certificate, then a determination is made as to whether the user has requested to delete a certificate, e.g., by selecting a certificate and pressing the delete key (step 417). If so, then a determination is made as to whether the certificate has an associated SignerInfo object (step 418). If so, then the SignerInfo object is deleted and the associated link on the display is removed (step 419). The certificate is then deleted (step 420) and links to other certificates removed (if necessary), and the processing of the user action is complete. If the certificate is not linked to a SignerInfo object, then the certificate is simply deleted at step 420 and links to other certificates removed (if necessary), and the process loops back to step 401 to await another user action.

[0102] If the user has not requested to delete a certificate, a determination is made as to whether a user has requested to add a certificate revocation list (CRL), e.g., by dragging and dropping a CRL or PKCS #12 file object into the CRL list section of the dialog window (step 421). If so, then a determination is made as to whether the same CRL already exists (step 422). If so, then no further action is required, and the process branches back to step 401. If the CRL does not already exist, then the CRL is added to the list of CRLs (step 423). The process then checks each certificate in the certificate list to see if the issuerDN and serialNumber for a certificate matches the issuerDN and a serialNumber in the CRL (step 424). If not, then the processing of the CRL is complete. If so, then a relational link or links are drawn between the CRL and the matching certificate or certificates (step 425). The processing of the added CRL is then complete, and the process then branches back to step 401 to await another user action.

[0103] If the user action was not an operation to add a CRL, then a determination is made as to whether the user has requested to delete a CRL, e.g., by selecting a CRL and pressing the delete key (step 426). If so, then a determination is made as to whether the selected CRL is linked to one or more certificates (step 427). If so, then the associated links or links are removed from the display (step 428), and the CRL is deleted (step 429). The processing of the CRL deletion is then complete. If the CRL is not linked to any certificates, then the CRL is simply deleted and removed from the display at step 429, and the process branches back to step 401 to await another user.

[0104] If the requested operation was not a CRL deletion, then a determination is made as to whether the user has dragged and dropped a private key object via a PKCS #12 file or other token onto a certificate object in the certificate list (step 430). If so, then a determination is made as to whether a SignerInfo object already exists for the certificate (step 431). If so, then the processing of the user action is complete. If not, then a determination is made as to whether content exists in the EncapsulatedContentInfo section (step 432). If no content exists, then the processing of the user action is complete. If content does exists, then a new SignerInfo object is created for the certificate using the private key of the user action (step 433). The process then updates the message digest list, i.e. the message digest list of the SignedData object shown in the interface dialog, with the message digest of the signature if the message digest does not already exist in the list (step 434). The process then associatively stores the private key with the associated SignerInfo object (step 435), and the process branches back to step 401 to await another user action.

[0105] If the user action was not the dropping of a private key, then a determination is made as to whether the user has requested to delete a SignerInfo object, e.g., by selecting a SignerInfo object and pressing the delete key (step 436). If so, then the SignerInfo object is deleted and removed from the display (step 437). The processing of this user action is then complete, and the process branches back to step 401 to await another user action.

[0106] If the user has not requested to delete a SignerInfo object, then a determination is made as to whether the user has requested to view the contents of a certificate, e.g., by double clicking upon a certificate object (step 438). If so, then the certificate is displayed in a certificate dialog window (step 439). The processing of the user action is then complete, and the process branches back to step 401 to await another user action.

[0107] If the user has not requested to view the contents of a certificate, then a determination is made as to whether the user has requested to view the contents of a CRL object, e.g., by double clicking upon a CRL object (step 440). If so, then the contents of the CRL are displayed in a CRL dialog window (step 441) and the process branches back to step 401 to await another user action.

[0108] If the user has not requested to view a CRL, then a determination is made as to whether the user has requested to view a SignerInfo object, e.g., by double clicking on a SignerInfo object (step 442). If so, then the contents of the SignerInfo object are displayed in a SignerInfo dialog (step 443) and the process then branches back to step 401 to await another user action.

[0109] If the user has not requested to view a SignerInfo object, then a determination is made as to whether the user has requested to view the contents of the SignedData object, e.g., by double clicking on the EncapsulatedContentInfo object (step 444). If so, then the contents are displayed in the manner which is appropriate for the content type (step 445). For example, if the contents have an associated type of “text”, then the contents may be displayed in the default text editor of the computer system. The process then branches back to step 401 to await another user action.

[0110] If the user has not requested to display the contents of a SignedData object, then a determination is made as to whether the user has pressed the Send button (step 446). If so, then the user is prompted for an e-mail address list, i.e., e-mail addresses to which the S/MIME messages should be sent (step 447). A determination is made as to whether there are any SignerInfo objects (steps 448). If not, then a determination is made as to whether there are any certificate objects present in the SignedData objects (step 449). If not, then no further action is necessary and the processing of the user request is complete. If there are certificate objects, then an S/MIME message containing the certificate objects is sent to the e-mail addresses via SMTP provided by the user (step 450), and the processing of the user request is complete. If there were SignerInfo objects present at step 448, then an S/MIME message containing the SignedData object is sent to the e-mail addresses via SMTP (step 451), and the processing of the user send request is complete. The process then branches back to step 401 to await another user action.

[0111] If the user has not pressed the Send button, then a determination is made as to whether the user has pressed the Export button (step 452). If so, then the user is prompted for a file name (step 453), and the SignedData object is stored in the specified file name in DER-encoded format (step 454). The processing of the user Export request is then complete, and the process branches back to step 401 to await another user action.

[0112] If the user has not pressed the Export button, then a determination is made as to whether the user has pressed the Import button (step 455). If so, then the user is prompted for a file name (step 456), and the SignedData object is imported from the specified DER-encoded file, and the objects are displayed within the SignedData interface dialog (step 457). The processing of the user is then complete, and the process branches back to step 401 to await another user action.

[0113] If the user has not pressed the Import button, then an unknown user action has been detected (step 458). The unknown user action is then ignored, and the process branches back to step 401 to await another user action.

[0114] With reference now to FIG. 5A, a dialog window for presenting SignerInfo object information is shown for viewing a SignerInfo object selected by a user within a SignedData interface utility dialog window in accordance with a preferred embodiment of the present invention. Dialog 500 contains Close button 501 for allowing a user to close dialog 500 when the user has finished viewing the SignerInfo object information. Content value fields 510-515 display the values of various content elements within a SignerInfo object, which are obtained from the selected certificate by parsing the elements of the SignerInfo object according to a known, standard format, such as that shown in FIG. 5B.

[0115] With reference now to FIG. 5B, the format of a PKCS SignerInfo object data type is shown. A SignerInfo object may be placed into a SignedData object on a per-signer basis. As is apparent by a simple inspection of both FIG. 5A and FIG. 5B, each element within a SignerInfo object may appear as a content value field within a dialog window for viewing SignerInfo objects, such as dialog 500. In a similar manner, the certificate and certificate revocation list information may also be shown within a dialog window when these objects are selected by the user, as shown in FIG. 6 and FIG. 7.

[0116] With reference now to FIG. 6, a dialog window for presenting certificate information is shown for viewing certificates selected by a user within a SignedData interface utility dialog window in accordance with a preferred embodiment of the present invention. Dialog 600 contains Close button 601 for allowing a user to close dialog 600 when the user has finished viewing the certificate information. Content value fields 610-619 display the values of various content elements within a certificate, which are obtained from the selected certificate by parsing the elements of the certificate according to a known, standard format. Private key symbol 620 shows if the interface has internally associated a private key with the certificate. The private key was derived from the previous SignedData interface. This private key is automatically used by the interface to perform such actions as signing data for SignedData objects. If the interface did not associate a private key with the certificate, the dialog would display a private key icon with a slash symbol through it. The interface will associate the private key with a certificate (the public key in the certificate), if the user dropped a PKCS #12 file on the interface that contained a private key and certificate, for example.

[0117] With reference now to FIG. 7, a dialog window for presenting certificate revocation list (CRL) information is shown for viewing a CRL selected by a user within a SignedData interface utility dialog window in accordance with a preferred embodiment of the present invention. Dialog 700 contains Close button 701 for allowing a user to close dialog 700 when the user has finished viewing the CRL information. Content value fields 710-718 display the values of various content elements within a CRL, which are obtained from the selected CRL by parsing the elements of the CRL according to a known, standard format.

[0118] The advantages of the present invention are apparent in view of the detailed description of the invention provided above. The present invention provides a graphical user interface methodology for presenting and manipulating PKCS 190 7 SignedData objects. The system automatically decomposes a SignedData object and displays relationships between contained objects for rapid visual comprehension and ease of manipulation by various types of users, including system administrators, network administrators, and application developers. Users have a comprehensive, visual view of the SignedData object and its contents. A user may then easily change and refresh the contents of the SignedData object. Objects can be added via drag and drop operations or through conventional file or socket imports. The present invention is operable in a heterogeneous environment since the methodology can encode and decode DER-encoded objects that may be transmitted to and received from various types of computer systems. As concerns over data security and data integrity become more prevalent with the increasing amounts of e-commerce, the use of signed objects will also grow as they become a desired requirement between merchants that commercially interact.

[0119] It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in a form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media such a floppy disc, a hard disk drive, a RAM, and CD-ROMs and transmission-type media such as digital and analog communications links.

[0120] The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention the practical application and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.