Method and apparatus for achieving nonconformant public key infrastructures
Claim Score by NHIP
Abstract
Method and apparatus are described wherein, in one example embodiment, a public key certificate issued by a certificate authority includes at least one characteristic that conforms to at least one rule established for the operation of a public key infrastructure. An attribute certificate is issued to be used to modify the public key certificate in accordance with information contained in the attribute certificate to create a modified public key certificate wherein the at least one characteristic is modified so as to be non-conformant with the at least one rule. According to one example embodiment, the attribute certificates may be distributed by a certificate authority, or embedded in an application that includes an engine that is used to modify the conforming public key certificate.

Term
0 yearsto projected expiry
Projected expiry 10 October 2026, counted from filing; an application has no term until it is granted.
- Priority
- Filed
- Published
- Today
- Projected expiry
21 claims: 4 independent, 17 dependent
- 1Broadest claimClaim Score 76, broad(NHIP)A method comprising:receiving a public key certificate that conforms to a rule of a public key infrastructure, the rule being applicable to process the public key certificate, the public key certificate including a compliant attribute that complies with the rule;receiving an attribute certificate issued by a certificate authority, the attribute certificate referencing the public key certificate and including a supplemental attribute usable to render the public key certificate non-conformant with the rule of the public key infrastructure;and modifying the public key certificate based on the supplemental attribute included in the attribute certificate, the modified public key certificate being non-conformant with the rule.
- 5A non-transitory machine-readable storage medium comprising instructions that, when executed by one or more processors of a machine, cause the machine to perform operations comprising:receiving a public key certificate that conforms to a rule of a public key infrastructure, the rule being applicable to process the public key certificate, the public key certificate including a compliant attribute that complies with the rule;receiving an attribute certificate issued by a certificate authority, the attribute certificate referencing the public key certificate and including a supplemental attribute usable to render the public key certificate non-conformant with the rule of the public key infrastructure;and modifying the public key certificate based on the supplemental attribute included in the attribute certificate, the modified public key certificate being non-conformant with the rule.
- 11A system comprising:a processor configured to access an attribute certificate issued by a certificate authority, the attribute certificate referencing a public key certificate that conforms to a rule of a public key infrastructure, the rule being applicable to process the public key certificate, the public key certificate including a compliant attribute that complies with the rule, the attribute certificate including a supplemental attribute usable to render the public key certificate non-conformant with the rule of the public key infrastructure;and a network interface device configured to provide the attribute certificate to another system that is configured to modify the public key certificate based on the supplemental attribute included in the attribute certificate, the modified public key certificate being non-conformant with the rule.
- 17A method comprising:receiving a public key certificate that is compatible with one or more rules established to govern an operation of a public key infrastructure, the public key certificate including a compliant attribute that complies with the one or more rules, the one or more rules being applicable to process the public key certificate;storing an attribute certificate issued by a certificate authority, the attribute certificate referencing the public key certificate and including a supplemental attribute usable to render the public key certificate non-conformant with the one or more rules;and modifying the public key certificate based on the supplemental attribute included in the attribute certificate, the modified public key certificate being non-conformant with the one or more rules.
Independent claims4
31 paragraphs in 6 sections, as filed
CLAIM OF PRIORITY
0001This application is a continuation of U.S. application Ser. No. 11/546,115, filed Oct. 10, 2006, which application is incorporated in its entirety herein by reference.
TECHNICAL FIELD
0002The subject matter relates generally to the field of computer security, and more particularly to public key infrastructures.
COPYRIGHT
0003A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings that form a part of this document: Copyright 2006, Adobe Systems Inc. All Rights Reserved.
BACKGROUND
0004In cryptography, a public key infrastructure (PKI) is an arrangement that provides for trusted third party vetting of, and vouching for, user identities. It also allows binding of public keys to users. This is usually carried out by software at a central location together with other coordinated software at distributed locations. The public keys are typically distributed in public key certificates (PKCs) that are usually distributed by a Certificate Authority (CA). PKI arrangements enable users to be authenticated to each other, and to use the information in identity certificates (e.g., each other's public keys) to encrypt and decrypt messages. In general, a PKI consists of client software, server software such as a Certificate Authority, hardware (e.g., smart cards), and operational procedures. A user may digitally sign messages using his private key, and another user can check that signature using the public key contained in that user's certificate issued by a Certificate Authority within the PKI. This enables two (or more) communicating parties to establish confidentiality, message integrity, and user authentication without having to exchange any secret information in advance.
0005Many enterprise-scale PKI systems rely on certificate chains to establish a party's identity, as a certificate may have been issued by the Certificate Authority computer whose ‘legitimacy’ is established for such purposes by a certificate issued by a higher-level Certificate Authority, and so on. This produces a certificate hierarchy composed of, at a minimum, several computers, often more than one organization, and often assorted interoperating software packages from several sources. For this purpose, a certification path validation algorithm may be used to verify that a given certificate path is valid under a given public key infrastructure. A path starts with the subject certificate and may proceed through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted Certification Authority.
0006Standards are critical to PKI operation, and public standards are critical to PKIs intended for extensive operation. Some of the standards for PKI infrastructures are provided by the IETF PKIX working group (PKIX-WG), for example as stated in RFC 3280 and related RFCs. However most of the PKIs do not follow exactly the RFC rule set. For example, RFC 3280 requires that all the PKCs that are CAs must have the Basic Constraint extension, and must assert the CA bit. If not, then the PKC can't be considered as a CA. Some of the intermediate CAs in Europe, for instance, may not follow this PKI rule and do not include any Basic Constraint extension within the PKC. Accordingly, such CAs may not be compatible with some RFC 3280 rules. Examples of other non-conformant PKC attributes may include Validity Dates, KeyUsage, Extended Key Usage, CRL Distribution Point, Authority Information Access, Subject Key Identifier, Authority Key Identifier, or Certificate Policy.
0007In order to accommodate non-compliant PKCs, some PKI engines may include configurability options for each capability where the PKIs can diverge from the RFCs. Users of such non-conformant PKI engines are then provided documentation explaining how to configure their application (manually) to accommodate or work around the non-conformant performance of the PKI engine. However, such manual configuration is undesirable for a variety of reasons.
BRIEF DESCRIPTION OF THE DRAWING
0008<figref idref="DRAWINGS">FIG. 1</figref> illustrates a system and uses thereof according to one example embodiment of the inventive subject matter disclosed herein;
0009<figref idref="DRAWINGS">FIGS. 2A and 2B</figref> illustrate attribute certificates and uses thereof according to one example embodiment of the inventive subject matter disclosed herein;
0010<figref idref="DRAWINGS">FIG. 3</figref> illustrates a method for modifying a public key certificate according to one example embodiment of the inventive subject matter disclosed herein;
0011<figref idref="DRAWINGS">FIG. 4</figref> illustrates a method for use of attribute certificates to modify the operation of a PKI according to one example embodiment of the inventive subject matter disclosed herein; and
0012<figref idref="DRAWINGS">FIG. 5</figref> illustrates a diagram of one example embodiment of a computing system architecture according to the inventive subject matter disclosed herein.
DETAILED DESCRIPTION
0013In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which are shown, by way of illustration, specific embodiments in which the inventive subject matter can be practiced. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the inventive subject matter. The leading digit(s) of reference numbers appearing in the Figures generally corresponds to the Figure number in which that component is first introduced, such that the same reference number is used throughout to refer to an identical component which appears in multiple Figures. Signals and connections may be referred to by the same reference number or label, and the actual meaning will be clear from its use in the context of the description.
0014According to one example embodiment, the inventive subject matter disclosed herein provides for the use of Attribute Certificates (ACs), as for example but not limited to, those of the type or kind defined in RFC 3281, to modify Public Key Certificates (PKCs) so that PKCs can be made conformant to one or more rules of a standard. Accordingly, an otherwise non-conformant PKI engine may process all PKCs in accordance with the applicable rules or the standard without encountering exceptions. Thus, the need for manual configuration of a PKI engine is avoided.
0015Referring now to <figref idref="DRAWINGS">FIG. 1</figref>, there is illustrated a simplified example PKI <b>100</b> according to one example embodiment of the inventive subject matter described herein. PKI <b>100</b> includes one or more Certificate Authority (CA) servers <b>102</b>. CA server <b>102</b>-<b>1</b> may distribute public key certificates (PKCs) <b>108</b> or <b>109</b>, issued by a CA authority <b>104</b>-<b>1</b> or <b>104</b>-<b>2</b>, to one or more intermediate CA servers <b>102</b>-<b>2</b>. A PKC <b>108</b> or <b>109</b> may be issued for an entity <b>121</b> that holds a private key <b>115</b> that is paired with a public key <b>106</b> in the PKC <b>108</b>. Server <b>102</b>-<b>2</b> may in turn distribute PKCs <b>108</b> to PKI client systems <b>110</b>, for example client system <b>110</b>-<b>2</b>. Alternatively, server <b>102</b>-<b>1</b> may distribute certificates directly to the client systems <b>110</b>-<b>1</b> or <b>100</b>-<b>2</b>. A PKC <b>108</b> may, in one example embodiment, include: i) a public key being signed; ii) a name, which can refer to a person, a computer, or an organization; iii) a validity period; iv) the location (URL) of a revocation center; and v) the digital signature of the certificate, produced by the CA's private key. The CA <b>104</b>-<b>1</b> or <b>104</b>-<b>2</b> hold a private key that may be used to sign PKCs <b>108</b> or <b>109</b>, which in turn may be validated using the paired public key <b>105</b> for the CA. In one example embodiment, a PKC <b>108</b> issued by CA entity <b>104</b>-<b>1</b> is compliant with or conforms to a standard governing the operation of the PKI <b>100</b>, such as the X509 standard. Another PKC <b>109</b> issued by CA entity <b>104</b>-<b>2</b> is not compliant or is non-conforming with the standard governing the PKI <b>100</b>, for example because it has one or more characteristics that do not conform to the standard. If such a non-conforming PKC <b>109</b> is received at a PKI engine <b>112</b>, the engine <b>112</b> may be unable to use it unless it is manually configured or reprogrammed to accommodate the non-conforming attributes of the PKC <b>109</b>.
0016The one or more client systems <b>110</b>, which include a hardware computing platform such as a workstation, personal computer, server system, or other computing system, include a client PKI engine <b>112</b>. In one embodiment, a PKC <b>108</b> or <b>109</b>, signed by the CA <b>104</b>, is distributed from a CA server, such as server <b>102</b>-<b>2</b>, to a client system <b>110</b>, for example <b>110</b>-<b>1</b>. Client system <b>110</b>-<b>1</b> may hold the private key <b>115</b> corresponding to the PKC <b>108</b> or <b>109</b>. In the event the PKC is a conforming PKC <b>108</b>, system <b>110</b>-<b>1</b> may use it, for example, in order to assist in establishing a secure communication or exchange of information between system <b>110</b>-<b>1</b> and system <b>110</b>-<b>2</b>, pursuant to one or more currently known or later developed PKI modes of operation, without encountering exceptions. For example, the PKC <b>108</b> may be sent to system <b>110</b>-<b>2</b>, and using the public key provided by the certificate authority <b>104</b>-<b>1</b>, be validated and opened to obtain public key <b>106</b> for user entity <b>121</b>.
0017In one example embodiment, the public key <b>105</b> for the CA entity <b>104</b> may be kept in a secure key list on the client system <b>110</b>. Once the public key <b>106</b> associated with the user entity <b>121</b> is verified by the trusted relationship with CA <b>104</b>, the public key <b>106</b> can be used in combination with the private key <b>115</b> also held by user entity <b>121</b> to establish secure communications or data exchange. The public key <b>106</b> may be used, for example, to authenticate and open a file signed with private key <b>115</b>. File <b>118</b> may use, for example, the portable document format (PDF) established by Adobe Systems, Inc. The public key <b>106</b> may also be used by system <b>110</b>-<b>2</b> to sign files or transmissions such that such files or transmissions may only be opened using the associated private key <b>115</b>. PKC <b>108</b> may further include additional information, policies or permissions associated with the public key <b>106</b> and entity <b>121</b>. This information may be used by a PKI engine <b>112</b> to control how the public key <b>106</b> is used or for other purposes.
0018According to one example embodiment, system <b>110</b>-<b>1</b> may also receive a non-conforming PKC <b>109</b> that, if used by the system <b>110</b>-<b>1</b> for signing, may be unverifiable by a receiving entity such as system <b>110</b>-<b>2</b> due to PKC <b>109</b>'s non-compliance with a standard. Accordingly, in one example embodiment, system <b>110</b>-<b>2</b> may use one or more ACs <b>130</b> to conform a PKC <b>109</b> received from a signor system <b>110</b>-<b>1</b>. Client system <b>110</b>-<b>2</b> may use the ACs <b>130</b> to conform the PKC <b>109</b> to one or more rules of the standard. For this purpose, engine <b>112</b> of client system <b>110</b>-<b>2</b> may retrieve one or more Attribute Certificates (ACs) <b>130</b> issued from a trusted CA. An AC <b>130</b>, in one example embodiment, may be issued by a CA server <b>134</b>. The CA server <b>134</b> may issue AC <b>130</b> with a pointer to the PKC <b>109</b>. Such pointer, for example, may be provided as described in a standard, such as but not limited to the standard defined in RFC 3281. According to one example embodiment, as described in more detail below, the AC <b>130</b> is used by the PKI engine <b>112</b> to modify the associated non-conforming PKC <b>109</b> to create a modified PKC <b>111</b> that conforms entirely or at least in part to a desired rule or standard. The conforming PKC <b>111</b> may then be used by the engine <b>112</b> of system <b>110</b>-<b>1</b> without modification and/or configuration of the engine <b>112</b>, allowing it to accommodate the non-conforming aspects of PKC <b>109</b>
0019According to still another example embodiment, the required ACs <b>130</b> may be embedded in the PKI engine <b>112</b> or an application containing the engine <b>112</b> in a local storage location in the client system <b>110</b>, so that they do not need to be distributed by a CA. Such an application may be a document reader or authoring client, such a client application may be, for example selected from Adobe Acrobat® line of programs, available from Adobe Systems, Inc. According to still another example embodiment, an AC <b>130</b> may be distributed or embedded by the publisher or distributor of an application, wherein the application includes a PKI engine that requires compliance with one, several, or all rules of a standard that PKCs within the PKI do not conform to. Accordingly, the publisher or distributor may enable or assure that their application will be capable of working properly in the PKI without requiring manual configuration of the application.
0020According to another example embodiment, the engine <b>112</b> of system <b>110</b>-<b>1</b> obtains, as part of the signing process, all the PKCs, for example PKC <b>109</b> and any other PKCs in the chain above PKC <b>109</b>, that are required to build a validation chain from the end entity certificate to a trusted CA. According to one example embodiment, some the other PKCs in the chain may be conforming PKCs and some may be non-conforming. These PKCs may be obtained, for example, using any acceptable process, for example using an Authority Information Access extension, or fetching them from an Address book for the PKI. In addition, the PKI engine <b>112</b> may also obtain all the associated ACs <b>130</b>, for example in the same way the PKCs are obtained. Or, as noted above, the ACs <b>130</b> may be embedded in a client application including the engine <b>112</b>, or in the engine <b>112</b> proper. As described further below, all of the source PKCs in the certificate chain and associated ACs used to conform the nonconforming PKC <b>109</b>, may be embedded in any file signed by the engine <b>112</b> using the PKC <b>109</b>, allowing the any system receiving the signed document to validate the PKCs and any associated ACs. Once verified, the compliant PKC <b>111</b> created by the engine <b>112</b> in system <b>110</b>-<b>2</b> may be used, or example in order to establish secure exchange of information with a system <b>110</b>-<b>1</b>.
0021According to one example embodiment, system <b>110</b>-<b>1</b> may also first conform PKC <b>109</b> to one or more rules of a standard using one or more ACs <b>130</b>, prior to using the PKC <b>109</b> or any modified PKC <b>111</b> it may produce using the ACs <b>130</b>. In one example embodiment, the conforming PKC <b>111</b> may then be used by system <b>110</b>-<b>1</b> for signing.
0022Referring now to <figref idref="DRAWINGS">FIGS. 2A and 2B</figref>, there is illustrated one example embodiment of a schema <b>200</b> for an AC <b>130</b>. AC <b>130</b> includes a pointer <b>201</b> to a PKC, such as PKC <b>109</b>. Each attribute <b>202</b> in schema <b>200</b> of AC <b>130</b> includes an indicator <b>204</b> that specifies whether it adds to or replaces the corresponding attribute <b>210</b> in a PKC, such as PKC <b>109</b>. According to this example embodiment, for example but not by way of limitation, this allows the AC <b>130</b> to add to the attribute <b>210</b> already present in a PKC <b>109</b>, allowing multiple ACs to be chained. Accordingly, in one example embodiment, a first AC <b>130</b>-<b>1</b> is provided to modify or add to a first attribute <b>210</b>-<b>1</b> of a PKC <b>109</b>, and a second AC <b>130</b>-<b>2</b> is provided to modify the same or another attribute <b>210</b>-<b>2</b> of the same PKC <b>109</b>, so that more than one AC <b>130</b> may be used to modify the PKC <b>109</b> and therefore the operation of the corresponding PKI.
0023Referring now to <figref idref="DRAWINGS">FIG. 3</figref>, there is illustrated a method for modifying a PKC using ACs according to one example embodiment <b>300</b> of the inventive subject matter. As illustrated, during evaluation of a PKC, for example a non-compliant PKC <b>109</b>, the PKI engine <b>112</b> inspects <b>302</b> the PKC and then inspects <b>304</b> all the associated ACs that have been obtained by the engine <b>112</b>. Then, within the memory data structure of the system executing engine <b>112</b>, all the PKC attributes or extensions (as for example defined in RFC 3280) are modified <b>306</b> as dictated by the associated ACs, to generate <b>308</b> a modified PKC, such as PKC <b>111</b>, for example but not by way of limitation. According to one example embodiment, before an AC is allowed to modify a PKC attribute, all the AC validation checks described in a standard, such as but not limited to RFC 3281, are carried out by the PKI engine <b>112</b>. In this embodiment, an AC may be used only if the validation checks are successful. If the validation checks are not successful, the changes attempted by the AC are rejected. According to one example embodiment, if ACs <b>130</b> are accepted and applied to modify a PKC <b>109</b> to create a modified PKC <b>111</b>, the engine <b>112</b> may then evaluate the PKC <b>111</b> in the system memory against a standard, for example as defined in a RFC rule set, to determine if the modified PKC <b>111</b> is compliant with the standard.
0024According to one example embodiment, if a PKC <b>111</b> meets all the applicable rules for validation a system <b>110</b> may use <b>310</b> the PKC <b>111</b>. In one embodiment, system <b>110</b> may sign <b>312</b> a file <b>118</b> using PKC <b>111</b> and the associated private or public key, depending on the situation. In one embodiment, all the PKCs in the validation chain and associated ACs may be embedded in the signature and in turn embedded in the data or file <b>118</b>. The file <b>118</b> may be sent <b>314</b>, received <b>316</b> by another system signed with the PKC <b>111</b>. The other system thereafter obtains the PKCs packaged with the file <b>118</b> or if not packaged retrieves them, and performs <b>318</b> verification steps against the modified PKC <b>111</b>, for example checking the signature of the PKCs, including PKC <b>109</b> against a list of trusted CAs, and/or by checking for a valid certificate chain of PKCs between the PKC <b>109</b> and the root PKC. In addition, the validity of all ACs <b>130</b> may be checked, or retrieved from the local application or engine <b>112</b> they may be embedded in. If all the checks are successful, the signature is considered valid <b>320</b>.
0025According to still another example embodiment, an AC <b>130</b> may be used by an engine <b>112</b> not to conform a non-conforming PKC, but instead to modify a conforming PKC <b>108</b> to provide a non-conforming PKC that may include characteristics to provide a mode of operation that is different than a standard. As such, the AC <b>130</b> is used to create a non-standard PKI mode of operation or data structure. Thus, a standard-compliant PKC may be deliberately made non-compliant using an AC <b>130</b> as described herein. Further, according to another example embodiment, the CA <b>132</b> issuing an AC <b>130</b> may be the same as or different from the CA <b>104</b> that issues the PKC <b>109</b>. According to still another example embodiment, the issuing authority for the AC <b>130</b> is or must be, by way of example but not by way of limitation, trusted by the PKI engine <b>112</b> to issue ACs <b>130</b>. According to another example embodiment, the AC <b>130</b> may take the form of a PKC or a CA.
0026According to one example embodiment, the inventive subject matter disclosed herein may be employed as illustrated in <figref idref="DRAWINGS">FIG. 4</figref>. An enterprise <b>402</b> that wishes to evaluate PKCs <b>108</b> as per their internal digital signature policies <b>406</b>, may issue an AC <b>130</b> for a PKC <b>108</b> and have the AC issuer <b>410</b> trusted by its agents or employees <b>412</b>. In one example embodiment, a department in a corporation may have special rules, for example more stringent rules, on what a PKC <b>108</b> should contain, and such rules may mean that the normal corporate PKCs and PKIs are not sufficient for use by the department. Accordingly, the department may use the system and method of the inventive subject matter to establish the special rules of their desired PKI, as opposed to establishing a separate PKI that conforms to their desired rules. In this example, accordingly, the AC <b>130</b> may specify all the PKC attributes that the department wishes to modify for their special requirements. Of course, according to another example embodiment, any entity wishing to create a special set of rules may modify an existing PKI using the above-described system and method.
0027<figref idref="DRAWINGS">FIG. 5</figref> shows a diagrammatic representation of a machine in the example form of a computer system <b>500</b> within which a set of instructions <b>524</b>, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
0028The example computer system <b>500</b> includes a processor <b>502</b> (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory <b>504</b>, and a static memory <b>506</b>, which communicate with each other via a bus <b>508</b>. The computer system <b>500</b> may further include a video display unit <b>510</b> (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system <b>500</b> also includes an alphanumeric input device <b>512</b> (e.g., a keyboard), a cursor control device <b>514</b> (e.g., a mouse), a disk drive unit <b>516</b>, a signal generation device <b>518</b> (e.g., a speaker) and a network interface device <b>520</b>. The disk drive unit <b>516</b> includes a machine-readable medium <b>522</b> on which is stored one or more sets of instructions and data structures (e.g., software) <b>524</b> embodying or utilized by any one or more of the methodologies or functions described herein. The instructions <b>524</b> may also reside, completely or at least partially, within the main memory <b>504</b> and/or within the processor <b>502</b> during execution thereof by the computer system <b>500</b>, the main memory <b>504</b> and the processor <b>502</b> also constituting machine-readable media. The instructions <b>524</b> may further be transmitted or received over a network <b>526</b> via the network interface device <b>520</b> utilizing any one of a number of well-known transfer protocols, for example the hyper text transfer protocol (HTTP).
0029While the machine-readable medium <b>522</b> is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by, or associated with, such a set of instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
0030According to one example embodiment, the systems and methods described herein may use any form of public key certificate (such as PKC <b>108</b>, <b>109</b>) so long as it uses a digital signature to bind together a public key with an identity and is used to establish a trust relationship in a PKI. Similarly, any form of certificate can be used for the Attribute Certificate so long as it also uses a digital signature to bind together a public key with an identity and is used to establish a trust relationship in a PKI, and provides information that may be used to modify a characteristic of a public key certificate. Accordingly, these terms should not be interpreted to require any specific characteristics dictated by a standard unless explicitly enumerated. Further, the rules of a standard for a PKI, which may be set for the purpose of guaranteeing interoperability, may be public or proprietary, and may be established by either a private or public body. According to one example embodiment, the rules of the standard for a PKI may be set by the X509 specifications, or by rules established by the ITEF PKIX-WG.
0031In this description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, software, structures, and techniques have not been shown in detail in order not to obscure the understanding of this description. Note that in this description, references to “one embodiment” or “an embodiment” mean that the feature being referred to is included in at least one embodiment of the invention. Further, separate references to “one embodiment” in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually exclusive, unless so stated and except as will be readily apparent to those of ordinary skill in the art. Thus, the inventive subject matter can include any variety of combinations and/or integrations of the embodiments described herein. Each claim, as may be amended, constitutes an embodiment of the invention, incorporated by reference into the detailed description. Moreover, in this description, the phrase “exemplary embodiment” means that the embodiment being referred to serves as an example or illustration. Further, block diagrams illustrate exemplary embodiments of the invention. Also herein, flow diagrams illustrate operations of the exemplary embodiments of the invention. The operations of the flow diagrams are described with reference to the exemplary embodiments shown in the block diagrams. However, it should be understood that the operations of the flow diagrams could be performed by embodiments of the invention other than those discussed with reference to the block diagrams, and embodiments discussed with reference to the block diagrams could perform operations different than those discussed with reference to the flow diagrams. Additionally, some embodiments may not perform all the operations shown in a flow diagram. Moreover, it should be understood that although the flow diagrams depict serial operations, certain embodiments could perform certain of those operations in parallel.
Contents6
7 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| WO2018057599A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US10567355B2 | Cited by | United States of America | Applicant |
| WO2017147337A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2018083936A1 | Cited by | United States of America | Search report |
| US11063980B2 | Cited by | United States of America | Applicant |
| US10560440B2 | Cited by | United States of America | Applicant |
| AU2017222580B2 | Cited by | Australia | Search report |
| US10965459B2 | Cited by | United States of America | Applicant |
| US11537195B2 | Cited by | United States of America | Applicant |
| US2018083936A1 | Cited by | United States of America | Search report |
| US10917239B2 | Cited by | United States of America | Applicant |
| US11115397B2 | Cited by | United States of America | Search report |
| US10880281B2 | Cited by | United States of America | Applicant |
| US10931653B2 | Cited by | United States of America | Applicant |
| US11470086B2 | Cited by | United States of America | Applicant |
| AU2017222580B2 | Cited by | Australia | Search report |
| US9967289B2 | Cited by | United States of America | Applicant |
| US10630686B2 | Cited by | United States of America | Applicant |
| US11361312B2 | Cited by | United States of America | Applicant |
| US10860086B2 | Cited by | United States of America | Applicant |
| US11700244B2 | Cited by | United States of America | Applicant |
| US11178115B2 | Cited by | United States of America | Applicant |
| WO2018057592A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US11924345B2 | Cited by | United States of America | Applicant |
| US10348485B2 | Cited by | United States of America | Applicant |
| US2003018890A1 | Cites | United States of America | Pre-grant |
| US2005160476A1 | Cites | United States of America | Pre-grant |
6 members in 2 offices
Priority claims1
| Document | Office | Kind | Date |
|---|---|---|---|
| 54611506 | United States of America | A |
Members6
| Document | Office | Kind | |
|---|---|---|---|
| US2008086635A1 | United States of America | A1 | |
| WO2008045870A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2008045870A3 | World Intellectual Property Organization (WIPO) | A3 | |
| US8010784B2 | United States of America | B2 | |
| US2011296173A1 | United States of America | A1 | |
| US8341400B2 | United States of America | B2 |
44 transactions on the USPTO file
Allowed after 1 non-final rejection.
- Non-final rejections
- 1
- Final rejections
- 0
- RCEs
- 0
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Payment of Maintenance Fee, 12th Year, Large EntityM1553 | M1553 | |
| Payment of Maintenance Fee, 8th Year, Large EntityM1552 | M1552 | |
| Correspondence Address ChangeC.ADB | C.ADB | |
| Post Issue Communication - Certificate of CorrectionN423 | N423 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Reasons for AllowanceEX.R | EX.R | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Paralegal or electronic terminal disclaimer approvedP574 | P574 | |
| Miscellaneous Incoming LetterLET. | LET. | |
| Response after Non-Final ActionA... | A... | |
| Terminal Disclaimer FiledDIST | DIST | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Email NotificationEML_NTR | EML_NTR | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Application Is Now CompleteCOMP | COMP | |
| Email NotificationEML_NTR | EML_NTR | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Sent to Classification ContractorPGPC | PGPC | |
| Cleared by OIPE CSRL194 | L194 | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Initial Exam Team nnIEXX | IEXX |
6 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| AssignmentAS | AS | |
| Fee paymentFPAY | FPAY | |
| Certificate of correctionCC | CC | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| Fee payment procedurePAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP |
Numbers
- Publication
- 20110296173
- Application
- 13206668
Titles
- English
- METHOD AND APPARATUS FOR ACHIEVING NONCONFORMANT PUBLIC KEY INFRASTRUCTURES
Patent term adjustment
- Net adjustment
- 0 days
Classification
- CPC, 2
- H04L9/006
- H04L9/3265
- IPC, 1
- H04L9 30