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 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 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 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 { } } 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 { } } 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 is invalid). 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 Lloyd +Others TBD Page 2 submitted to "internet-drafts@ietf.org"