Digital Certificates and Digital Signatures: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
| ⚫ | |||
'''Introduction/motivation''' |
'''Introduction/motivation''' |
||
Users of a public key shall be confident that the associated private |
Users of a public key shall be confident that the associated private |
||
| Line 33: | Line 33: | ||
'''X.509v3''' |
'''X.509v3''' |
||
| ⚫ | |||
The v3 format extends the v2 format by |
The v3 format extends the v2 format by |
||
| Line 50: | Line 52: | ||
'''Certification path processing''' |
'''Certification path processing''' |
||
[[path processing algorithm]] |
|||
verifies the binding between the subject distinguished name and/or |
verifies the binding between the subject distinguished name and/or |
||
subject alternative name and subject public key. The binding is |
subject alternative name and subject public key. The binding is |
||
| Line 63: | Line 67: | ||
trusted CA." |
trusted CA." |
||
The path processing actions to be performed are: |
|||
(a) Verify the basic certificate information, including: |
|||
(1) the certificate was signed using the subject public key |
|||
from certificate i-1 (in the special case i=1, this step may be |
|||
omitted; if not, use the subject public key from the same |
|||
certificate), |
|||
(2) the certificate validity period includes time T, |
|||
(3) the certificate had not been revoked at time T and is not |
|||
currently on hold status that commenced before time T, (this |
|||
may be determined by obtaining the appropriate CRL or status |
|||
information, or by out-of-band mechanisms), and |
|||
(4) the subject and issuer names chain correctly (that is, the |
|||
issuer of this certificate was the subject of the previous |
|||
certificate.) |
|||
(b) Verify that the subject name and subjectAltName extension |
|||
(critical or noncritical) is consistent with the constrained |
|||
subtrees state variables. |
|||
(c) Verify that the subject name and subjectAltName extension |
|||
(critical or noncritical) is consistent with the excluded subtrees |
|||
state variables. |
|||
(d) Verify that policy information is consistent with the initial |
|||
policy set: |
|||
(1) if the explicit policy state variable is less than or equal |
|||
to i, a policy identifier in the certificate shall be in the |
|||
initial policy set; and |
|||
(2) if the policy mapping variable is less than or equal to i, |
|||
the policy identifier may not be mapped. |
|||
(e) Verify that policy information is consistent with the |
|||
acceptable policy set: |
|||
(1) if the certificate policies extension is marked critical, |
|||
the intersection of the policies extension and the acceptable |
|||
policy set shall be non-null; |
|||
(2) the acceptable policy set is assigned the resulting |
|||
intersection as its new value. |
|||
(g) Verify that the intersection of the acceptable policy set and |
|||
the initial policy set is non-null. |
|||
(h) Recognize and process any other critical extension present in |
|||
the certificate. |
|||
(i) Verify that the certificate is a CA certificate (as specified |
|||
in a basicConstraints extension or as verified out-of-band). |
|||
(j) If permittedSubtrees is present in the certificate, set the |
|||
constrained subtrees state variable to the intersection of its |
|||
previous value and the value indicated in the extension field. |
|||
(k) If excludedSubtrees is present in the certificate, set the |
|||
excluded subtrees state variable to the union of its previous |
|||
value and the value indicated in the extension field. |
|||
(l) If a policy constraints extension is included in the |
|||
certificate, modify the explicit policy and policy mapping state |
|||
variables as follows: |
|||
(1) If requireExplicitPolicy is present and has value r, the |
|||
explicit policy state variable is set to the minimum of its |
|||
current value and the sum of r and i (the current certificate |
|||
in the sequence). |
|||
(2) If inhibitPolicyMapping is present and has value q, the |
|||
policy mapping state variable is set to the minimum of its |
|||
current value and the sum of q and i (the current certificate |
|||
in the sequence). |
|||
(m) If a key usage extension is marked critical, ensure the |
|||
keyCertSign bit is set. |
|||
If any one of the above checks fail, the procedure terminates, |
|||
returning a failure indication and an appropriate reason. If none of |
|||
the above checks fail on the end-entity certificate, the procedure |
|||
terminates, returning a success indication together with the set of |
|||
all policy qualifier values encountered in the set of certificates. |
|||
''' |
''' |
||
Revocation''' |
Revocation''' |
||
Revision as of 14:58, 16 December 2004
PKIv3 architectual model and datastructures conforming to ITU-T X.509
Introduction/motivation
Users of a public key shall be confident that the associated private key is owned by the correct remote subject (person or system) with which an encryption or digital signature mechanism will be used. This confidence is obtained through the use of public key certificates, which are data structures that bind public key values to subjects.
assertion
The binding is asserted by having a trusted CA digitally sign each certificate. The CA may base this assertion upon technical means (a.k.a., proof of posession through a challenge- response protocol), presentation of the private key, or on an assertion by the subject. A certificate has a limited valid lifetime which is indicated in its signed contents. Because a certificate's signature and timeliness can be independently checked by a certificate-using client, certificates can be distributed via untrusted communications and server systems, and can be cached in unsecured storage in certificate-using systems.
ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was first published in 1988 as part of the X.500 Directory recommendations, defines a standard certificate format [X.509]. The certificate format in the 1988 standard is called the version 1 (v1) format. When X.500 was revised in 1993, two more fields were added, resulting in the version 2 (v2) format. These two fields may be used to support directory access control.
X.509v3
The v3 format extends the v2 format by adding provision for additional extension fields. Particular extension field types may be specified in standards or may be defined and registered by any organization or community. In June 1996, standardization of the basic v3 format was completed [X.509].
ISO/IEC/ITU and ANSI X9 have also developed standard extensions for use in the v3 extensions field [X.509][X9.55]. These extensions can convey such data as additional subject identification information, key attribute information, policy information, and certification path constraints.
Certification path processing
verifies the binding between the subject distinguished name and/or subject alternative name and subject public key. The binding is limited by constraints which are specified in the certificates which comprise the path. The basic constraints and policy constraints extensions allow the certification path processing logic to automate the decision making process.
The "most-trusted CA" is a matter of policy: it could be a root CA in a hierarchical PKI; the CA that issued the verifier's own certificate(s); or any other CA in a network PKI. The path validation procedure is the same regardless of the choice of "most- trusted CA."
Revocation
X.509 defines one method of certificate revocation. This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). A CRL is a time stamped list identifying revoked certificates which is signed by a CA and made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number.