validation
Click on the red underlined text to get to the source
...
This specification also includes path validation procedures in
Section 6. These procedures are based upon the ISO/IEC/ITU ...
... constraints which shield the user from many malicious actions, and
applications which sensibly automate validation functions.
...
... on-line service will correctly reflect the
certificate validation impacts of the revocation. However, these
methods ...
... shall trust the on-line validation service while the repository does
not need to be trusted.
...
... distinguished name (see sec. 4.1.2.6)
fields to perform name chaining for certification path validation
(see section 6). Name chaining is performed by matching the issuer
...
... certificate to that list. If this extension is
critical, the path validation software MUST be able to interpret this
extension (including the optional qualifier), or MUST reject the
certificate ...
... to CAs. The policy constraints extension constrains path validation
in two ways. It can be used to prohibit policy mapping or require
that each certificate ...
... Public
Key Infrastructure. This extension may be used to direct
applications to identify an on-line validation service supporting the
issuing CA ...
... critical or non-
critical. A CRL validation MUST fail if it encounters a critical
extension which it does not know how to process. However, an
...
... CRL entry may be designated as critical or non-critical. A CRL
validation MUST fail if it encounters a critical CRL entry extension
...
... Certification Path Validation ...
...
In section 6.1, the text describes basic path validation. This text
assumes that all valid paths begin with certificates ...
... network PKI. The path
validation procedure is the same regardless of the choice of "most-
trusted CA."
...
...
section 6.2 describes extensions to the basic path validation
algorithm. Two specific cases are discussed: the case where paths may
...
... Basic Path Validation ...
... Extending Path Validation ...
...
The path validation algorithm presented in 6.1 is based on several
simplifying assumptions (e.g., a single trusted CA ...
... CAs by providing
a set of self-signed certificates to the validation module. In this
case, a valid path could begin with any one of the self-signed
certificates ...
... self-signed certificate's extensions. In
this way, the self-signed certificates permit the path validation
module to automatically incorporate local security policy and
...
... the assurance associated with the binding is clearly reduced.
Similarly, implementations of the Path Validation mechanism described
in section 6 that omit revocation checking provide less assurance
...
... trusted CA, the user will need to modify the information provided to
the path validation routine. Selection of too many trusted CAs will
make the trusted CA ...
... The quality of implementations that process certificates may also
affect the degree of assurance provided. The path validation
algorithm described in section 6 relies upon the integrity ...