Public key infrastructure: Difference between revisions
imported>Caesar Schinas m (Robot: Changing template: TOC-right) |
imported>Sandy Harris mNo edit summary |
||
Line 2: | Line 2: | ||
{{TOC|right}} | {{TOC|right}} | ||
A '''public key infrastructure | A '''public key infrastructure''' or '''PKI''' provides the supporting tools to make it practical to deploy and use [[public key cryptography]]. The first essential element of PKI is that the creators of public-private keys key pairs have a secure way to store the public key in an accessible repository, with the stored key autheticated as coming from the purported source. The second essential element is that users of the public key have a secure way to retrieve the public key for a given source of information. As with any security tool, there must be a reliable means of auditing changes to the system resources, such as the entry of new keys, with a log verifying that the change was authenticated. | ||
Public keys, in practice, will be delivered in a '''[[digital certificate]]'''.<ref name=RFC5280>{{citation | Public keys, in practice, will be delivered in a '''[[digital certificate]]'''.<ref name=RFC5280>{{citation |
Revision as of 02:00, 9 March 2010
A public key infrastructure or PKI provides the supporting tools to make it practical to deploy and use public key cryptography. The first essential element of PKI is that the creators of public-private keys key pairs have a secure way to store the public key in an accessible repository, with the stored key autheticated as coming from the purported source. The second essential element is that users of the public key have a secure way to retrieve the public key for a given source of information. As with any security tool, there must be a reliable means of auditing changes to the system resources, such as the entry of new keys, with a log verifying that the change was authenticated.
Public keys, in practice, will be delivered in a digital certificate.[1] While there are many details, think of a digital certificate as if it were a typical official document such as a passport:
- The passport holder is named
- There is some way of authenticating the holder's identity, such as a photograph
- The credential issuer can be verified (e.g., official seals and stamps)
- There is an understanding of the credentials granted by the certificate (i.e., the government of the issuing country asks the government of the country being visited to accept the passport holder)
- There are means of detecting forgeries (e.g., tamper resistant paper, biometrics)
- There is a way to verify if the certificate has been revoked (e.g., a traveler "hot list", or, in the case of digital certificates, a certificate revocation list (CRL))
In the Internet, the fundamental specification, RFC 5280, states that it may be necessary to add additional authorization, assurance, or operational requirements to accept a certificate. This specification, however, deals with common representations of frequently used attributes are defined so that application developers can obtain necessary information without regard to the issuer of a particular certificate or certificate revocation list (CRL)." In no way does the standard suggest any specific rights that apply to the holder of a certificate.
References
- ↑ D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk (May 2008.), Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC5280