Contribution for the PKIX Working Group
Alan Lloyd(OpenDirectory)
Internet Draft Expires in six months August 24, 1998
Internet X.509 Public Key Infrastructure
DIRECTORY SUPPORTED CERTIFICATE STATUS OPTIONS
<draft-lloyd-dir-cert-stat-01.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract
This Internet Draft specifies some proposed enhancements to the X.500
information schema and matching rules to support Certificate path
processing, certificate status and CRL mechanisms. These
enhancements provide advantages over existing Certificate validation
and CRL mechanisms. In particular, the mechanisms proposed can:
(a) reduce the need for unnecessarily fetching CRLs;
(b) allow certificate status-CRL evaluation time to be improved;
(c) provide a directory supported certificate test and fetch
capability;
(d) better support use of certificates in multiple environments with
different CRL arrangements.
(e) simplify the client software in the areas of certificate path,
certificate validity and CRL processing.
(f) provide the client a range of trust options when validating
certificates.
(g) provide a range of implementation options so that gradual adoption
is possible.
This document is submitted for consideration as the basis of possible
future IETF/ITU standardization. Please send comments on this
document to the ietf-pkix@imc.com mail list.
Acknowledgments
This document has been developed in consideration of other documents
that have been circulated on the pkix list. These documents identify
issues associated with certificate validity processing and provide
possible solutions to these issues.
1. BACKGROUND
This draft (Dir-CertStat) (DCS) proposes a number of (X.500) directory
based features and objects that can assist in the processing of
certificate paths and testing the validity of certificates. However,
the proposal does rely on the CA's schema management policy and its
supporting processing utilities to provide such objects. It is deemed
that the way in which CAs (and multiple cross referenced CAs) manage
their certificate environment and indicate their certificate
validity, can have many variants in terms of information architectures.
It is important for client software development that such variants do
not have to be incorporated in the client software and in fact be
subject to ongoing software maintenance because of CA evolution.
The current models for client - CA - certificate validation, put the
onus on the client software design to comply to the many information
schema policy options that CAs might put forward. Ie. The current CA
directory data model is CA focussed, not client service focussed.
This former approach is seen as being an unworkable situation for
large scale systems. This proposal requests that CAs (and their
directory systems) provide a uniform client interface for certificate
validation, regardless of their information management policy.
In addition, some proposed validation models also permit information
to be returned to the client that indicate the time and reason that
the certificate was invalidated. This model has not incorporated such
information on the basis that the client can do very little re
invalidity. However, such features can be included if required.
2. PRINCIPLES
Where public key certificates are applied and these are supported via
directory services, a User/client that receives a signed message or
wishes to encrypt a message for another recipient is required to
verify the certificate of the public key material used. This includes
validation of the certificate path in conjunction with its associated
CRLS via the associated directory service.
In the certificate path validation process, the organisation and type
of the CRLs used by the CA (direct or indirect or CRL distribution
points) need to be "understood" or tracked/processed by the client.
Specifically, the client software needs to understand "the CRL
information management and policy" of the CA under which it operates.
This process may be possible where a limited number of CAs are
used by purpose built clients. However, it is important today that
standard client software is of a generic nature so that it can be
used under any CA. Also, where cross certification techniques are
applied it is also necessary that the client software remains
compatible.
The real solution to the client-CRL/validation problem is to have a
directory supported function that a client can use when following a
certificate path. Ie, the client can, in the same directory access,
request validation of the presented certificate material as well as
at the same time, retrieve the next certificate in the path.
Naturally failure to validate the certificate presented, will
terminate the access with an error without retrieving the next
certificate.
This client action can be achieved using a new directory matching
rule and new CA directory objects. With these items, the client is
not forced to understand the CRL management regimes of any particular
CA. The client just needs to know what a valid/invalid certificate
indication is.
This directory Search/Test feature is intended for "entry level" or
commercial grade clients and CAs. Naturally, where greater degrees of
trust are required, then the mechanisms and objects applied to CRL
validation can be more extensive (as per the standard CRLs).
There are four principles behind this proposal.
1. The CAs can use what ever CRL management approaches they chose,
but are responsible for indicating validity/invalidity in a common
way.
2.The User/client software is standard and efficient, regardless of
the CA(s) they operate under.
3. Each directory access (a search) to follow a certificate path is
accompanied with a matching rule that requests the nature of validity
testing required. And that the directory system handles the "CRL
evaluation".
4. That in the event of this feature not being available from the
CA's directory service, the client can fall back to standard CRL
processing - if required.
3. ELEMENTS OF THE PROPOSAL
There are two elements of the proposal:
(a) The Directory Access - Search/Validation Function;
(b) The Validation - Information Model of the CA.
4. THE DIRECTORY ACCESS - SEARCH/VALIDATION FUNCTION.
In the client's LDAP/DAP (Search) request to retrieve the Issuer's
certificate, the client presents the Subject's certificate attributes
it has for validation and the validation type required. Included in
these attributes is the DN of the Issuer. This is used to return the
Issuer's certificate if the Subject's certificate is deemed valid.
For the sake of simplicity, it is assumed that the client has
verified the signature integrity of the Subject's certificate and the
Validity time. In addition the client may also validate any extension
material (such as policy attributes) whose pre-configured values (if
used) can be held in local storage.
The certificate material presented to the directory system includes
the Issuer DN, the Serial Number, the Subject DN and where used, the
Subject and Issuer Unique Ids. Where extensions have been applied and
these are critical to validation, the client can also submit these.
4.1 The Directory (DAP) Search is constructed as follows:
SearchArgument ::= OPTIONALLY-PROTECTED { SET {
baseObject [0] Name, {set to the Certificate Issuer DN.
subset [1] INTEGER {set to wholeSubtree(2)}
filter [2] Filter {set to Validate Attrs -
Matching Rule},
searchAliases [3] BOOLEAN DEFAULT TRUE,
selection [4] {set to return Issuer certificate
and validation data} see below,
pagedResults [5] PagedResultsRequest OPTIONAL {not applied},
matchedValuesOnly [6] BOOLEAN DEFAULT FALSE {defaulted},
extendedFilter [7] Filter OPTIONAL {not used},
checkOverspecified [8] BOOLEAN DEFAULT FALSE {not used},
COMPONENTS OF CommonArguments {as required}},
DIRQOP.&dapSearchArg-QOP{@dirqop} }
4.1.1 Selection:
The Directory (DAP) Search EIS (selection)can be constructed as
follows:
Selection can be set to ALL attributes or:
attribute selection =
select [1] SET OF AttributeType
where types = (issuers)certificate and BasicValidationResponse
Where validation records are required, then these attribute types
should also be selected.
Where ALL attributes are selected and returned, the client is
responsible for processing the various entries. However, being non
selective, may cause CRLs, etc to be returned.
The Directory (DAP) Search Filter is constructed as follows:
a) A Filter Item specifying the extensibleMatch -
MatchingRuleAssertion as specified in the section below.
b) Where extensible matches are not fully supported by the client or
the directory service, a set of AND filter items can be used. The
first item containing the matching rule assertion OID, the
ValidationType and subsequent filter items containing the Subject
certificate component attributes to be tested as AVAs.
(Note this approach is not considered complete for this first draft.
However, it does simplify client and directory software for initial
implementation).
4.2 The Directory Response
The successful response to the validation request should be the CA's
certificate and depending on validation options, the CA's
BasicValidationResponse, the Subject's Validation Object with its
BasicValidationResponse. Additionally a Validation Record may also be
returned. (see below)
Where the matching rule is not supported by the directory service,
then Attribute Problem - InappropriateMatching (X.511 - Errors) MUST
be returned.
4.3 The Certificate Validation Matching Rule
The certificate validation matching rule compares a presented value
with an attribute value of type CertificateValid. It selects
validation material on the basis of various characteristics.
certificateValidMatch MATCHING-RULE ::= {
SYNTAX CertificateValidAssertion
ID id-TBA-certificateValidMatch }
CertificateValidAssertion ::= SEQUENCE {
serialNumber [0] CertificateSerialNumber, Subject SN
subject [1] Name, Subject DN
subjectKeyIdentifier [2] SubjectKeyIdentifier OPTIONAL,
authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL,
certificateValid [4] Time OPTIONAL,
privateKeyValid [5] GeneralizedTime OPTIONAL,
subjectPublicKeyAlgID [6] OBJECT IDENTIFIER OPTIONAL,
keyUsage [7] KeyUsage OPTIONAL,
subjectAltName [8] AltNameType OPTIONAL,
policy [9] CertPolicySet OPTIONAL,
pathToName [10] Name OPTIONAL,
validationRequestor [11] Name OPTIONAL,
validationType [12] ValidationType }
Note 1. Definitions are as per X.509 - 12.7.2.
Note 2. This matching rule is different from X.509 12.7.2
CertificateAssertion, in that that parameter [1] is the Subject's
(name - not the issuer, and that parameter [0] and [1]
are mandatory.
Note 3. The certificate Issuer DN is provided as the Base Object
parameter in the Search request.
Note 4. The validation Requestor is the DN (domain) of the client,
which if supplied and cross certificates are encountered, the cross
certificate of the requestors Domain is supplied in the response.
This area of operation requires study.
4.4 Validation Type
The Validation Type attribute is set to indicate what level of
validation requested and validation response type by the client from
the CA's directory service.
Note:This attribute must be provided by the client and not defaulted.
Simple:
This value requests that if the validation is successful that the
only response to the Search/Validate operation is the Issuer's
certificate. Clients and CA directory systems MUST support this
validation type.
Basic:
This value, requests that if the validation is successful that the
response to the Search/Validate operation is the Issuer's certificate
and a Validation Code.
Clients and CA directory systems MUST support this validation type.
Basic and Fail Code:
This value, requests that if the validation is successful that the
response to the Search/Validate operation is the Issuer's certificate
and a Validation Code. If the Search/Validate operation indicates a
validation failure, then the failure code is provided in the response.
Clients and CA directory systems MAY support this validation type.
Provide Record:
This value, requests that if the validation is successful that the
response to the Search/Validate operation is the Issuer's
certificate and a Validation Record.
Clients and CA directory systems MAY support this validation type.
Provide Signed Record:
This value, requests that if the validation is successful that the
response to the Search/Validate operation is the Issuer's certificate
and a Signed Validation Record. The signature key used is the
Subject's certificate signature (the issuer's) key.
Clients and CA directory systems MAY support this validation type.
Extended: For additional validation methods. TBD
validationType ATTRIBUTE ::= {
SYNTAX validationTypeSyntax
IDENTIFIED BY { <oid tbd> } }
validationTypeSyntax ::= INTEGER {simple (0), basic (1),
basicAndFailCode (2), provideRecord (3),provideSignedRecord (4),
extended (5)}
4.5 Basic Validation Response
The Basic Validation Response provides an indication (as well as the
requested Issuer's certificate, if the Subject's certificate validity
is true) in the Search/Validate response with value flags indicating
the nature of the validation encountered. If there is a validity
object present in the CA's directory, then the name of this object
can be returned. Clients and CA directory systems MUST support this
validation response.
BasicValidationResponse ::= SEQUENCE {
basicValidationFlags [0] BasicValidationFlags,
validationTime [1] Time,
validityObject [2] Name OPTIONAL,
reasons [3] ReasonFlags OPTIONAL }
certPairProcessed [4] INTEGER {fwd (0),rev (1)}OPTIONAL}}
BasicValidationFlagsATTRIBUTE ::= {
SYNTAX basicValidationFlagsSyntax
IDENTIFIED BY { <oid tbd> } }
basicValidationFlagsSyntax ::= INTEGER
{valid (0), validAndCRLsProcessed (1),validityObjectPresent (2),
certificate-invalid(255)}
4.6 Provide Record Responses
The Provide Record Responses is either an unsigned or signed
attribute (depending on the validation response requested)
indicating the nature of the validation. These response types are
provided as audit records by the CA for the client.
SignedValidationRecord ::= SEQUENCE {
tbsValidationRecord ValidationRecord,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
ValidationRecord ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
validatingCA Name,
time Time,
subject Name,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
basicValidationFlags [3] BasicValidationFlags,
keyUsageTested [4] keyUsage
policyIDsValidated [5] BOOLEAN OPTIONAL,
policyIdentifier [6] CertPolicyId OPTIONAL,
crlsProcessed [5] CRLsProcessed OPTIONAL,
reasons [7] ReasonFlags OPTIONAL }
CRLsProcesssed ::= SEQUENCE {
crlList [0] CRLList OPTIONAL,
cRLIssuer [1] GeneralNames OPTIONAL }
CRLList ::= SET {serialNumber}
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6)}
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6)}
Note the above processing does require that directory systems embrace
a comprehensive validation process, which may be open to
accreditation. However, if this level of validation and trust is
required in the client software, then a similar accreditation issue
exists.
It is a question of does the Client trust the CA and to what extent.
5. THE VALIDATION - INFORMATION MODEL OF THE CA.
The Information model of the CA at the overall level is naturally the
responsibility of the CA. From the level from a CA's Object Class in
the CA's directory and what it represents this is defined in X.500.
(Note: there may be more than one CA OC in the directory - depending
on the number of certificate domains administered by this overall
CA.) The CA(v2) OC is an Auxiliary OC and is added to a structural OC
such as an Organisational Unit or Role depending on the CA's
operational policy. This OC contains the CA Certificate(s) attribute
including any Certificate Pair attributes. This OC may also contain
any CRLs, ARLs or Delta CRLs.
In addition X.509 defines a CRL Distribution Point structural OC
which can contain the same items as the CA OC except for a CA
certificate.
For the purpose of this proposal, each OC which represents a CA or an
OC which represents a certificate status capability also contains the
BasicValidationFlags attribute.
5.1 CA's DIB Design
>From an operational perspective of CA's DIB design, it is required
that the CA system designer puts any CRL Distribution Point OCs in
the DIB as named subordinate entries of the CA entry to which they
relate. In addition, it will be normal practice for the CA to
organise any entries that deal with the management of User/Client
certificates (as issued), as named subordinate entries of the CA's
entry. These entries could in fact contain copies of the Subject's
certificate(s)as issued - for backup/archive reasons.
This proposal therefore demands two basic rules of operation for the
CA's DIB.
1. In order to assist certificate validation for clients, the CA must
have a disciplined directory information model and where
appropriate, generate validation objects. These objects must be
deemed as being useful for improved service levels or performance
reasons.
2. That where such validation objects (or related Distribution Points
containing CRLs, ARLs or Delta CRLs) are constructed, that they are
placed as entries subordinate to the CA entry concerned in order for
the Search/validation process to occur.
NOTE: In all cases where the client processes the CA's CRLs directly,
etc, or provides a Search/Validate test operation on the CAs
directory system. It is still the responsibility of the CA to make
sure that such information is organised sensibly, available, correct
and timely. This proposal does not alter this requirement.
5.2 Issued Certificate Details
A proposed Object Class that assists in the certificate validation
process is provided below. This object represents each certificate
issued by the CA. These objects when instantiated, are named relative
to the CA entry by either a common name, a unique Id or DN qualifier,
etc according to local policy. The matching rule used to validate the
Subject's certificate locates this entry in the Search by using the
Subjects DN value.
caIssuedCertDetails
The caIssuedCertDetails object class is used in defining entries and
act as enablers for the management and validation of issued
certificates. This object permits the CA to predefine validity flags.
cAIssuedCertDetails OBJECT-CLASS ::= {
SUBCLASS OF { top }
KIND structural
MUST CONTAIN {commonName |
subject |
serialNumber |
basicValidationFlags }
MAY CONTAIN {issuedCertificate |
subjectUniqueId }
ID id-oc-TBD }
5.3 Issued Certificate Group Details
This proposed Object Class also assists in the certificate
validation process by grouping valid certificates. This object
represents a group of certificates issued by the CA. These objects
when instantiated, are named relative to the CA entry by either a
common name, a unique Id or DN qualifier, etc according to local
policy.
The matching rule used to validate the Subject's certificate locates
this entry in the Search by using the Subject's certificate serial
number. Other validity attributes can be provided eg. Policy Ids.
caIssuedCertGroupDetails
The caIssuedCertGroupDetails object class is used in defining entries
which act enablers for management and validation of issued
certificates. This object permits the CA to predefine validity flags.
cAIssuedCertDetails OBJECT-CLASS ::= {
SUBCLASS OF { top }
KIND structural
MUST CONTAIN {commonName |
lowSerialNumber |
highSerialNumber|
basicValidationFlags }
MAY CONTAIN { issuedCertificate |
subjectUniqueId }
ID id-oc-TBD }
5.4 Other Validity Details
Additional Object Classes could also assist validation. These might
be Policy Objects indicating what policies are valid/invalid.
6. CROSS CERTIFICATION
This area requires additional study re the use of inter-working of CA
directory domains and how these shared DIBs are orchestrated.
7. EXAMPLES OF USE - Directory Process
The Search operation that has the validation matching rule applied
and the validation level set to simple or basic operates in the
following way.
a) If the proposed Matching Rule is not supported by the directory,
the Search is terminated in error - Inappropriate Matching.
b) If there is no subordinate entries to the Issuer's CA's entry,
and the entry does not contain the BasicValidationFlags attribute,
then the Search is terminated in error - Inappropriate Matching.
Otherwise the matching rule is processed on the CA's entry CRLs,
ARLs or DeltaCRLs and the BasicValidationFlags attribute value is
returned with the CA's certificate if the BasicValidationFlags value
is not set to certificate-invalid.
If the CA's entry has no CRL's, ARL's or DeltaCRL's present then
and the BasicValidationFlags attribute value is returned with the
CA's certificate if the BasicValidationFlags value is not set to
certificate-invalid.
c) If there are subordinate entries to the Issuer's CA's entry, and
the CA's entry does not contain the BasicValidationFlags attribute,
then the Search is terminated in error - Inappropriate Matching.
If there is a subordinate entry to the Issuer's CA's entry that
matches the Subject's DN and the certificate serial number, and the
CA's entry BasicValidationFlags attribute is not set to certificate-
invalid (blanket invalidation), then the subordinate entry's
BasicValidationFlags attribute value is returned with the CA's
certificate unless the subordinate entry's BasicValidationFlags
value is not set to certificate-invalid (the subject's certificate
isinvalid).
9. PERFORMANCE ISSUES
This proposal requires additional objects/entries within the CAs
directory system and therefore the CA process requires additional
capacity to manage such objects. In addition the directory system
must deal with the processing of the matching rules. Experience
with scaleable (eg. 20 million entry) distributed (LDAP accessed
X.500) RDBMS supported directory systems demonstrates that where
additional functionality is required, then a higher rated platforms
should be used. As this proposal is targeted at the larger CA -
infrastructure providers, then it is considered that larger
processing platforms, (that support millions of entries and 100's
to 1000's of searches a second) can be used. This approach is in
line with market forces and commercial service providers in offering
competitive and improved service levels.
10. SECURITY ISSUES
This proposal provides a range of certificate validation trust levels.
And no doubt many security issues can be postulated. Eg. An attacker
might provide replay or masquerading techniques to make a client
erroneously believe that a certificate was valid when it had in fact
been revoked. For this reason the validation level requested MUST be
used as appropriate.
In addition, trust eventually comes down to implementation features
and quality - and these are always constrained by cost. Any security
issues deemed with the above proposals should consider the
implementation issues. Where higher degrees of trust are needed,
then Signed/Confidential directory services can be used. In addition,
the CAs information management processes should be formally
accredited.
11. INTELLECTUAL PROPERTY STATEMENT
The author(s) have no knowledge of any pending or granted patents
covering the techniques described, except for the Entrust patent on
CDPs. The mechanisms described are not inherently dependent on CDPs,
and can be used in a way which may not require licensing of the
Entrust patent.
The mechanisms proposed are provided as a contribution to the
development of CAs and Directory systems.
11. REFERENCES
TBD
Expires in six months August 24, 1998
Author Address:
Alan lloyd
OpenDirectory Pty Ltd.
266 Maroondah Highway
Mooroolbark 3138
Australia
Alan.lloyd@opendirectory.com.au