20: Difference between revisions
KarenSanders (talk | contribs) (minor updates) |
m (Reverted edits by KarenSanders (talk) to last revision by Mdpeters) |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
==Footnote 20== | ==Footnote 20== | ||
Of course, the holder of the private key may choose to divulge it, or may lose control of it (often called "compromise"), and thereby make forgery possible. The Guidelines seek to address this problem in two ways, (1) by requiring a subscriber, who holds the private key, to use a degree of care in its safekeeping, and (2) enabling the subscriber to disassociate himself from the key by temporarily suspending or permanently revoking his certificate and publishing these actions in a "certificate revocation list," or "CRL". A variety of methods are available for securing the private key. The safer methods store the private key in a "cryptographic token" (one example is a "smart card") which executes the signature program within an internal microprocessing chip, so that the private key is never divulged outside the token and does not pass into the main memory or processor of the signer's computer. The signer must typically present to the token some authenticating information, such as a password, pass phrase, or personal identification number, for the token to run a process requiring access to the private key. In addition, this token must be physically produced, and biometric authentication such as fingerprints or retinal scan can assure the physical presence of the token's authorized holder. There are also software-based schemes for protecting the security of the private key, generally less secure than hardware schemes, but providing adequate security for many types of applications. See generally Schneier, supra note 18, at § 2.7, 41-44. | Of course, the holder of the private key may choose to divulge it, or may lose control of it (often called "compromise"), and thereby make forgery possible. The Guidelines seek to address this problem in two ways, (1) by requiring a subscriber, who holds the private key, to use a degree of care in its safekeeping, and (2) enabling the subscriber to disassociate himself from the key by temporarily suspending or permanently revoking his certificate and publishing these actions in a "certificate revocation list," or "CRL". A variety of methods are available for securing the private key. The safer methods store the private key in a "cryptographic token" (one example is a "smart card") which executes the signature program within an internal microprocessing chip, so that the private key is never divulged outside the token and does not pass into the main memory or processor of the signer's computer. The signer must typically present to the token some authenticating information, such as a password, pass phrase, or personal identification number, for the token to run a process requiring access to the private key. In addition, this token must be physically produced, and biometric authentication such as fingerprints or retinal scan can assure the physical presence of the token's authorized holder. There are also software-based schemes for protecting the security of the private key, generally less secure than hardware schemes, but providing adequate security for many types of applications. See generally Schneier, supra note 18, at § 2.7, 41-44. | ||
Latest revision as of 12:37, 16 October 2014
Footnote 20
Of course, the holder of the private key may choose to divulge it, or may lose control of it (often called "compromise"), and thereby make forgery possible. The Guidelines seek to address this problem in two ways, (1) by requiring a subscriber, who holds the private key, to use a degree of care in its safekeeping, and (2) enabling the subscriber to disassociate himself from the key by temporarily suspending or permanently revoking his certificate and publishing these actions in a "certificate revocation list," or "CRL". A variety of methods are available for securing the private key. The safer methods store the private key in a "cryptographic token" (one example is a "smart card") which executes the signature program within an internal microprocessing chip, so that the private key is never divulged outside the token and does not pass into the main memory or processor of the signer's computer. The signer must typically present to the token some authenticating information, such as a password, pass phrase, or personal identification number, for the token to run a process requiring access to the private key. In addition, this token must be physically produced, and biometric authentication such as fingerprints or retinal scan can assure the physical presence of the token's authorized holder. There are also software-based schemes for protecting the security of the private key, generally less secure than hardware schemes, but providing adequate security for many types of applications. See generally Schneier, supra note 18, at § 2.7, 41-44.