[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
A few additional comments.
>> Neither X.509 nor extant
>>PKIX standards define protocols for the management of trust anchors.
RFC 3125 (issued in september 2001), which is an S-MIME document, defines
a signature policy, which includes components for a validation policy.
So there exists material, that could be re-used to address the narrower scope
of a validation policy.
Some relevant text from RFC 3125 is copied below :
3.6.1 Certificate Requirements
The certificateTrustTrees identifies a set of self signed
certificates for the trust points used to start (or end) certificate
path processing and the initial conditions for certificate path
validation as defined RFC 2459 [7] section 4. This ASN1 structure is
used to define policy for validating the signing certificate, the
TSA's certificate and attribute certificates.
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
The trustPoint field gives the self signed certificate for the CA
that is used as the trust point for the start of certificate path
processing.
The pathLenConstraint field gives the maximum number of CA
certificates that may be in a certification path following the
trustpoint. A value of zero indicates that only the given trustpoint
certificate and an end-entity certificate may be used. If present,
the pathLenConstraint field must be greater than or equal to zero.
Where pathLenConstraint is not present, there is no limit to the
allowed length of the certification path.
PathLenConstraint ::= INTEGER (0..MAX)
The acceptablePolicySet field identifies the initial set of
certificate policies, any of which are acceptable under the signature
policy. AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
The nameConstraints field indicates a name space within which all
subject names in subsequent certificates in a certification path must
be located. Restrictions may apply to the subject distinguished name
or subject alternative names. Restrictions apply only when the
specified name form is present. If no name of the type is in the
certificate, the certificate is acceptable.
Restrictions are defined in terms of permitted or excluded name
subtrees. Any name matching a restriction in the excludedSubtrees
field is invalid regardless of information appearing in the
permittedSubtrees.
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
The policyConstraints extension constrains path processing in two
ways. It can be used to prohibit policy mapping or require that each
certificate in a path contain an acceptable policy identifier.
The policyConstraints field, if present specifies requirement for
explicit indication of the certificate policy and/or the constraints
on policy mapping.
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
If the inhibitPolicyMapping field is present, the value indicates the
number of additional certificates that may appear in the path
(including the trustpoint's self certificate) before policy mapping
is no longer permitted. For example, a value of one indicates that
policy mapping may be processed in certificates issued by the subject
of this certificate, but not in additional certificates in the path.
If the requireExplicitPolicy field is present, subsequent
certificates must include an acceptable policy identifier. The value
of requireExplicitPolicy indicates the number of additional
certificates that may appear in the path (including the trustpoint's
self certificate) before an explicit policy is required. An
acceptable policy identifier is the identifier of a policy required
by the user of the certification path or the identifier of a policy
which has been declared equivalent through policy mapping.
3.6.2 Revocation Requirements
The RevocRequirements field specifies minimum requirements for
revocation information, obtained through CRLs and/or OCSP responses,
to be used in checking the revocation status of certificates. This
ASN1 structure is used to define policy for validating the signing
certificate, the TSA's certificate and attribute certificates.
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
Certificate revocation requirements are specified in terms of checks
required on:
* endCertRevReq: end certificates (i.e., the signers certificate,
the attribute certificate or the time-stamping authority
certificate).
* caCerts: CA certificates.
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
An authority certificate is certificate issued to an authority (e.g.,
either to a certification authority or to an attribute authority
(AA)).
A Time-Stamping Authority (TSA) is a trusted third party that creates
time-stamp tokens in order to indicate that a datum existed at a
particular point in time. See [TSP].
EnuRevReq ::= ENUMERATED {
clrCheck (0),
--Checks must be made against current CRLs
-- (or authority revocation lists (ARL))
ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol
-- (OCSP),RFC 2450.
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be
-- carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature policy
-- extension
}
Revocation requirements are specified in terms of:
* clrCheck: Checks must be made against current CRLs (or
authority revocation lists);
* ocspCheck: The revocation status must be checked using the
Online Certificate Status Protocol (RFC 2450);
* bothCheck: Both OCSP and CRL checks must be carried out;
* eitherCheck: Either OCSP or CRL checks must be carried out;
* noCheck: No check is mandated.
Denis