view Side-By-Side changes

Date: Tue, 09 Apr 2002 06:23:11 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 20 Mar 1997 13:25:00 GMT
ETag: "304c14-8613-33313aac"
Accept-Ranges: bytes
Content-Length: 34323
Connection: close
Content-Type: text/plain

Internet Draft





PKIX Working Group                                     
draft-ietf-pkix-ipki2opp-00.txt                           Sharon Boeyen (Entrust)
draft-ietf-pkix-ipki2opp-01.txt              Tim Howes (Netscape)
Expires in 6 months                                        March 1997

                                  S. Boeyen (Entrust Technologies)
                                  R. Housley (SPYRUS)
                                  T. Howes (Netscape)
                                  M. Myers (Verisign)
                                  P.                          Patrick Richard (Xcert)
                                             September 1997


                   Internet Public Key Infrastructure

                    Part 2:
                      Operational Protocols

                   <draft-ietf-pkix-ipki2opp-00.txt> - LDAP
                   <draft-ietf-pkix-ipki2opp-01.txt>



1.  Status of this Memo

This document is an Internet-Draft. Internet-Drafts  are  working 
documents  docu-
ments  of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working documents docu-
ments 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 learn the current status of  any  Internet-Draft,  please  check  the
"1id-abstracts.txt"  listing  contained  in  the  Internet-Drafts Shadow
Directories   on   ftp.is.co.za   (Africa),   nic.nordu.net    (Europe),
munnari.oz.au   (Pacific  Rim),  ds.internic.net  (US  East  Coast),  or
ftp.isi.edu (US West Coast).

2.  Abstract

This

The protocol described in this document is the first draft designed to satisfy  some  of
the  operational requirements within the Internet Public Key Infrastructure 
X.509 Operational Protocols. This Infrastruc-
ture (IPKI).  Specifically, this document identifies candidate 
protocols addresses requirements to pro-
vide access to Public Key Infrastructure (PKI) repositories for retrieval the pur-
poses of X.509 v3 certificates retrieving PKI information and v2 CRLs as 
well as a candidate protocol for online status checking of X.509 v3 
certificates. It is proposed managing that same  information.
The  mechanism  described  in  this document serve as is based on the basis Lightweight
Directory Access Protocol (LDAP) version 2, defined  in  RFC  1777,  and
defines  a  profile of that protocol for use within the IPKI. Additional
mechanisms addressing PKIX Part 2 standardization effort.  operational  requirements  are  specified  in
separate documents.

The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"  in
this document are to be interpreted as described in RFC 2119.

Please send comments on this document to the  ietf-pkix@tandem.com  mail
list.

1.



Boeyen, Howes & Richard                                         [Page 1]






INTERNET DRAFT                                            September 1997


3.  Introduction

This specification is Part 2 part of a multi-part standard for development of a
Public  Key  Infrastructure  (PKI)  for the Internet. This specification
addresses the requirements to provide retrieval of  X.509  PKI  information,
including  certificates  and  CRLs from an information a repository.  Two 
protocol profiles are provided This specification
also addresses requirements to satisfy this requirement. One is 

                               [Page 1]
Draft-ietf-pkix-ipki2opp-00.txt 		March 1997

based on the Lightweight Directory Access Protocol (LDAP) add, delete and the 
other on the File Transfer Protocol (FTP).  In addition, the 
requirement for modify PKI information in
a user to validate repository. A profile based on the status of a certificate 
online, directly from a CA is addressed and supporting LDAP version 2 protocol is 
specified.
 
1.1 provided
to satisfy these requirements.

4.  Model

The PKI components, as defined in PKIX Part 1,  which  are  involved  in
PKIX operational protocol interactions include:

   -  End Entities
   -  Certification Authorities (CA)
   -  Repository

End entities and CAs using LDAPv2, retrieve certificates and/or CRLs  PKI  information  from  the
repository using either the Lightweight Directory Access Protocol 
(LDAP) profile defined in section 2 or the File Transfer Protocol 
(FTP) profile defined in section 3 a subset of this specification.

Otherwise, entities validate the status of a certificate, by 
communicating directly LDAPv2 protocol.

CAs populate the repository with a CA, PKI information using the Online Certificate 
Status Protocol (OCSP) defined in section 4 a subset  of this specification.

2.  the
LDAPv2 protocol.

5.  Lightweight Directory Access Protocol (LDAP)

This section examines the retrieval

The following sections examine the retrieval of PKI information  from the 
certificate/CRL  a
repository  and defines management of PKI information in a subset repository. A profile
of the LDAPv2 protocol is defined for providing this retrieval mechanism. Two scenarios, 
satisfying different sets of requirements are provided in 2.1 and 
2.2 below. these services.

Section 2.1 6 satisfies the requirement to retrieve PKI information (a certificate,  cer-
tificate,  CRL,  or other information of interest)  from an entry in the
repository, where the retrieving entity (either an end entity or  a  CA)
has  knowledge  of  the  name  of  the entry. This is termed "repository
read".

Section 2.2 7 satisfies the same requirement as 2.1 6 for  the  situation  where
the  name  of the entry is not known, but some other related information
which can may optionally be used as a filter against  candidate  entries  in
the repository, is known.  This is termed "repository search".

Section 8 satisfies the requirement of CAs to add, delete and modify PKI
information  information  (a  certificate,  CRL, or other information of
interest)in the repository. This is termed "repository modify".

The subset of LDAPv2 needed  to  support  each  of  these  functions  is
described  below. Note that the repository search service  is a superset



Boeyen, Howes & Richard                                         [Page 2]






INTERNET DRAFT                                            September 1997


of the repository read service  in terms  of  the  LDAPv2  functionality
needed.

Note also  that all tags are implicit by default  in  the  ASN.1  definitions
that follow.

2.1

6.  LDAP Repository Read

To retrieve information from an entry corresponding to  the  subject  or
issuer  name  of a certificate, requires a subset of the following 

	[Page 2]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997 three
LDAP operations:

  BindRequest (and BindResponse)
  SearchRequest (and SearchResponse)
  UnbindRequest

The subset of each REQUIRED operation is given below.

2.1.1

6.1.  Bind

2.1.1.1

6.1.1.  Bind Request

The full LDAP v2 Bind Request is defined in RFC 1777.

An application providing a LDAP repository read service  MUST  implement
the following subset of this operation:

   BindRequest ::=
     [APPLICATION 0] SEQUENCE {
        version      INTEGER (2),
        name         LDAPDN, -- MUST accept NULL LDAPDN
        simpleauth [0] OCTET STRING  -- MUST accept NULL simple
        }

An application providing a LDAP repository read  service  MAY  implement
other aspects of the BindRequest as well.

Different services may have different security requirements.  Some 
services  ser-
vices  may  allow  anonymous  search, others may require authentication.
Those services allowing anonymous search may choose only to allow search
based on certain criteria and not others.

A LDAP repository read service SHOULD implement some level of  anonymous
search  access.  A Public-Key Search  LDAP repository read service MAY implement 
authenticated authenti-
cated search access. 

2.1.1.2 BindResponse






Boeyen, Howes & Richard                                         [Page 3]






INTERNET DRAFT                                            September 1997


6.1.2.  Bind Response

The full LDAPv2 BindResponse is described in RFC 1777.

An application providing a LDAP repository read service  MUST  implement
this  entire protocol element, though only the following 
errors error codes may
be returned from a Bind operation:

  success                      (0),
  operationsError              (1),
  protocolError                (2),
  authMethodNotSupported       (7),
  noSuchObject                 (32),
  invalidDNSyntax              (34),
  inappropriateAuthentication  (48),
  invalidCredentials           (49),
  busy                         (51),

	[Page 3]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997
  unavailable                  (52),
  unwillingToPerform           (53),
  other                        (80)

2.1.2

6.2.  Search

2.1.2.1 SearchRequest

6.2.1.  Search Request

The full LDAPv2 SearchRequest is defined in RFC 1777.

An application providing a LDAP repository read service  MUST  implement
the following subset of the SearchRequest.

   SearchRequest ::=
     [APPLICATION 3] SEQUENCE {
        baseObject     LDAPDN,
        scope             ENUMERATED {
                          baseObject   (0),
                                     },
        derefAliases   ENUMERATED {
                          neverDerefAliases   (0),
                                  },
        sizeLimit      INTEGER (0),
        timeLimit      INTEGER (0),
        attrsOnly      BOOLEAN, -- FALSE only
        filter         Filter,
        attributes     SEQUENCE OF AttributeType
                            }

   Filter ::=
     CHOICE {



Boeyen, Howes & Richard                                         [Page 4]






INTERNET DRAFT                                            September 1997


       present        [7] AttributeType, -- "objectclass" only
              }

This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read" 
operation:  opera-
tion:  a  base  object search with a filter testing for the existence of
the objectClass attribute.

An application providing a LDAP repository read  service  MAY  implement
other aspects of the SearchRequest as well.

2.1.2.2 SearchResponse

6.2.2.

The full LDAPv2 SearchResponse is defined in RFC 1777.

An application providing a LDAP repository read service over LDAPv2 MUST
implement the full SearchResponse.

2.1.3

6.3.  Unbind

The full LDAPv2 UnbindRequest is defined in RFC 1777.

An application providing a LDAP repository read service  MUST 

	[Page 4]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997  implement
the full UnbindResponse.

2.2 UnbindRequest.

7.  LDAP Repository Search

To search ,using arbitrary criteria, for an entry in a  repository containing  con-
taining a user's public 
key using arbitrary criteria certificate, CRL, or other information of interest, requires a
subset of the following three LDAP operations:

  BindRequest (and BindResponse)
  SearchRequest (and SearchResponse)
  UnbindRequest

The subset of each operation required REQUIRED is given below.

2.2.1

7.1.  Bind

The BindRequest and BindResponse subsets needed are the  same  as  those
described in Section 2.1.1. 6.1.

The full LDAP v2 Bind Request is defined in RFC 1777.

2.2.2

7.2.  Search

2.2.2.1 SearchRequest

7.2.1.  Search Request

The full LDAPv2 SearchRequest is defined in RFC 1777.



Boeyen, Howes & Richard                                         [Page 5]






INTERNET DRAFT                                            September 1997


An application providing a LDAP repository search service MUST implement
the following subset of the SearchRequest protocol unit.

   SearchRequest ::=
     [APPLICATION 3] SEQUENCE {
        baseObject     LDAPDN,
        scope          ENUMERATED {
                            baseObject     (0),
                            singleLevel    (1),
                            wholeSubtree   (2)
                                  },
        derefAliases   ENUMERATED {
                            neverDerefAliases     (0),
                                  },
        sizeLimit      INTEGER (0 .. maxInt),
        timeLimit      INTEGER (0 .. maxInt),
        attrsOnly      BOOLEAN,  -- FALSE only
        filter         Filter,
        attributes     SEQUENCE OF AttributeType
                             }

All aspects of the SearchRequest MUST be supported, except for the 
following:  fol-
lowing:

- Only the neverDerefAliases value of derefAliases needs
  to be 

	[Page 5]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997 supported

- Only the FALSE value for attrsOnly needs to be supported

This subset provides a more general search capability. It is a  superset
of the SearchRequest subset defined in Section 2.1.2.1. 6.2.1. The elements added
to this service are:

- singleLevel and wholeSubtree scope needs to be supported

- sizeLimit is included

- timeLimit is included

- Enhanced filter capability

An application providing a LDAP repository search service MAY  implement
other aspects of the SearchRequest as well.

2.2.2.2 SearchResponse

7.2.2.  Search Response

The full LDAPv2 SearchResponse is defined in RFC 1777.




Boeyen, Howes & Richard                                         [Page 6]






INTERNET DRAFT                                            September 1997


An application providing a LDAP repository search  service  over  LDAPv2
MUST implement the full SearchResponse.

2.2.3

7.3.  Unbind

An application providing a LDAP repository search service MUST implement
the full UnbindRequest.

2.3 Transport

8.  LDAP Repository Modify

To add, delete and modify PKI information in  a  repository  requires  a
subset of the following LDAP operations:

  BindRequest (and BindResponse)
  ModifyRequest (and ModifyResponse)
  AddRequest (and AddResponse)
  DelRequest (and DelResponse
  UnbindRequest

The subset of each operation REQUIRED is given below.

8.1.  Bind

The full LDAP v2 Bind Request is defined in RFC 1777.

An application providing a LDAP repository read modify service or a MUST implement
the following subset of this operation:

   BindRequest ::=
     [APPLICATION 0] SEQUENCE {
        version      INTEGER (2),
        name         LDAPDN,
        simpleauth [0] OCTET STRING
        }

A LDAP repository search modify service MUST support LDAPv2 transport over TCP, implement authenticated access.

The BindResponse subsets needed are the same as those described in  Sec-
tion 6.1.2.

8.2.  Modify

8.2.1.  Modify Request

The full LDAPv2 ModifyRequest is defined in Section 3.1 of RFC 1777.

An application providing a LDAP repository read service or a LDAP 
repository search modify service MAY support LDAPv2 transport over other 
reliable transports as well.

2.4 Security Considerations

For LDAP, since the elements of information which are key to the 
PKI service (certificates and CRLs) are both digitally signed 
pieces of information, no additional integrity service is required.  
As neither information element need be kept secret and anonymous 
access to such information is generally acceptable, no privacy 
service is required.  As CAs may have access to information 
elements in the repository which anonymous users will not, it is 
recommended that even though anonymous access can be provided to 
end entities, CAs should bind to the repository with a minimum of 

	[Page 6]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997

simple authentication.

3. File Transfer Protocol (FTP)

Some CAs mandate the use of on-line validation services, while 
others distribute CRLs to allow certificate users to perform 
certificate validation themselves.  In general, CAs make CRLs 
available to certificate users by posting them in the Directory.  
The Directory is also the normal distribution mechanism for 
certificates.  However, Directory Services are not available in 
many parts of the Internet today, and the File Transfer Protocol 
(FTP), defined in RFC 959,  offers an alternate method for 
certificate and CRL distribution.

Within certificate extensions and CRL extensions, URI form of 
GeneralName is used to specify the location where issuer 
certificates and CRL may be obtained.  For instance, a URI 
identifying the subject of a certificate can be carried in 
subjectAltName certificate extension. An IA5String describes the 
use of anonymous, or authenticated FTP to fetch certificate or CRL.  
For example:

   ftp://ftp.netcom.com/sp/spyrus/housley.cer 
   ftp://ftp.your.org/pki/id48.cer
   ftp://ftp.your.org/pki/id48.no42.crl

Internet users may publish the URI reference to a file that 
contains their certificate on their business card.  This practice 
is useful when there is no Directory entry for that user. FTP is 
widely deployed, and anonymous FTP is accommodated by many 
firewalls.  Thus, FTP is an attractive alternative to Directory 
access protocols for certificate and CRL distribution.

For convenience, the names of files that contain certificates 
should have a suffix of ".cer".  Likewise, the names of files that 
contain CRLs should have a suffix of ".crl".

Note that this service satisfies the the requirement to retrieve 
information related to a certificate which is already identified by 
a URI. It is not intended to satisfy the more general problem of 
finding a certificate for a user about whom some other information, 
such as their email address or corporate affiliation, is known.

4. Online Certificate Status Protocol (OCSP) 

There exists a requirement for CAs to provide an Online Certificate 
Status Protocol (OCSP) service characterized by a high degree of 
availability and a rapid response time.  Instances where this 
service would be used include those where:

- Application vendors may not implement the syntax and semantics
  required for standards-compliant certificate path validation.

	[Page 7]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997

- Application vendors who implement compliant certificate path
  validation logic may not implement the logic associated with
  periodic Certificate Revocation Lists (CRLs).

- Application vendors may find that while CRL processing is within
  their reach, implementing the protocols necessary to obtain CRLs
  from public repositories (e.g. an X.500 Directory System) is not.

- In lieu of or as a supplement to checking against a periodic CRL,
  it may be necessary to obtain immediate status regarding a
  certificate's revocation state (cf. PKIX Part 1, Section 3.3).
  Examples include high-value funds transfer or the compromise of a
  highly sensitive key.

Two meta-level requirements factor into the specification of OCSP.  
First, it should be significantly easier to implement than the 
corresponding local CRL processing it supplements.  This will 
enable the rapid integration of the protocol into emerging 
certificate-enabled applications.

Secondly, the specification of OCSP should enable rapid 
assimilation and deployment of the service among CA product and 
service vendors. Since the task of certificate management is 
largely unaffected by the mode of a certificate's use, it is 
optimal from the CA perspective that a single OCSP implementation 
would meet the needs of IPSEC, S/MIME, EDI and other diverse 
applications.  Recognizing that this goal may not be achievable, 
the semantics of the OCSP transaction model should remain invariant 
against the syntactic constraints of the transport protocol used to 
convey the OCSP.  For example, it's easily forseeable that use of 
SMTP as a transport model is the path of least resistance for e-
mail User Agents, while HTTP is an optimal choice for Web browsers.  
The OCSP syntax for each may differ according to each transport 
protocol's usage patterns; the semantic constructs should not.

4.1 Protocol Overview

The Online Certificate Status Protocol (OCSP) enables applications 
to efficiently and rapidly determine the validity and revocation 
state of an identified certificate.  An application issues a status 
request to the certificate issuer (CA) and suspends further 
certificate acceptance processing until the CA responds with a 
status indication.

4.1.1 Query

An OCSP query is semantically defined by the following three 
elements:

1  protocol version
2  service request

	[Page 8]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997

3  target certificate identifier

Upon receipt of a query, the CA first determines if: 1) the message 
is well formed, 2) the CA provides the requested service, and 3) 
the CA issued the subject certificate.  If any one of the prior 
conditions are not met, an error message is produced; otherwise, a 
definitive response is returned.

4.1.2 Response

All definitive response messages are authenticated with the 
responding CA's digital signature.  A definitive response message 
is composed of:

1  date and time of response
2  repeat of target certificate identifier
3  certificate status value
4  signature algorithm OID
5  signature computed across hash of previous four values

This specification defines the following "definitive" response 
values:

1  VALID
2   INVALID
3  REVOKED
4  NOT REVOKED
5  EXPIRED

Two error response semantics are defined. The first favors service 
availability at the expense of security.  This is a "minimal" error 
response.  The second option provides the converse balance:  
enhancing the authenticity of CA error responses through the use of 
a signed error message, although at the risk of denial of service.  
(The Performance Considerations and Security Considerations 
sections of this document provide amplifying discussions.)

The syntactic definition of a minimal error message is expected to 
vary by transport protocol.  For example, when using HTTP to convey 
OCSP, a minimal error response would be a single space character.  
This is viewed as sufficient to inform the requesting party that, 
with some degree of likelihood, the CA received the message but 
could not return an otherwise definitive response.
Signed error messages are semantically identical to definitive 
response messages, extending the set of definitive response values 
to include the previously identified error conditions:

1  ILLFORMED MESSAGE
2  SERVICE UNAVAILABLE
3  DID NOT ISSUE CERTIFICATE

In the case of an ill-formed message, it may not be possible for 

	[Page 9]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997

the receiving CA to parse the certificate identifier from the 
received message.  To regularize the implementation of response 
generation and response processing logic, a null certificate 
identifier is defined.

4.2 Requirements

For the purposes of requirements specification, abstract response 
values are indicated by UPPER CASE.  A syntactic-level 
interpretation of these abstract values per transport protocol is 
provided in Section 4.3.1 of this specification.

4.2.1 Definition of Services

Certificate status service information can be organized into three 
categories:  1) certificate path validation; 2) current revocation 
status; and 3) historical revocation status.  Path validation 
services enable applications to defer all processing associated 
with determining a certificate's validity state to a trusted third 
party. The current revocation status service provides the means to 
determine whether or not an otherwise valid certificate has been 
revoked within the interval of its validity period and maintains 
this state for some limited time thereafter.  The historical 
revocation status service extends the current revocation status 
service over an extended period of time beyond a certificate's 
expiration.

4.2.2 Error Responses

Upon receipt of a query which fails to parse against defined OCSP 
semantics, the receiving CA shall respond with an error message.  
If a CA provides signed error responses, a failure to parse an 
incoming query shall be indicated by an ILLFORMED MESSAGE response.  
The value of the certificate identifier of such a response shall be 
NULL_CERT_ID.

For service request categories not supported by a CA, the CA shall 
respond with an error message. If a CA provides signed error 
responses, non-availability of the requested service shall be 
indicated by a SERVICE UNAVAILABLE response.

For service request categories supported by a CA, if the receiving 
CA did not issue the subject certificate, the CA shall respond with 
an error message. If a CA provides signed error responses, this 
error situation shall be indicated by a DID NOT ISSUE CERTIFICATE 
response.

CAs shall produce a minimal error response as described in Section 
2.1.2.  They may provide signed error responses as described in 
Section 2.1.2.  They should provide the option to do both.  The 
means by which a CA signals to a relying party which error behavior 
is offered should be through certificate contents.

	[Page 10]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997

4.2.3 Required and Optional Services

CAs which offer online certificate status services shall at a 
minimum provide the current revocation status service defined in 
Section 3.1.

Upon receipt by a CA of a current revocation status request for a 
certificate issued by the recipient CA, the CA shall respond with 
either REVOKED or NOT_REVOKED, according to the certificate's 
status, throughout the duration of the certificate's validity 
interval and continuing for a given number days following the date 
of the subject certificate's expiration.  This latter interval is 
identified as the certificate's "inclusion interval".  
Specification of a certificate's inclusion interval is considered a 
matter of a CA's certification practices, and should be documented 
in the CA's Certification Practices Statement.

If a subject certificate was not revoked prior to the expiration of 
its validity period, but a current revocation status request is 
received by its issuer within the subject certificate's inclusion 
interval, the CA shall respond with a status indicating EXPIRED.

Thereafter, CAs may respond with an error message. If a CA provides 
signed error responses, this error situation shall be indicated by 
a DID NOT ISSUE CERTIFICATE response.  (That is, the CA is not 
required to maintain online records regarding issuance beyond some 
well-defined interval. The automatic mechanisms that produce OCSP 
responses may not therefore be able to differentiate between the 
expiration of a certificate previously issued and a certificate 
that was never issued. This requirement is not intended to 
establish the full extent of a CA's record-keeping obligations.  
The means by which CAs enable the resolution of such queries via 
other mechanisms and for other purposes are beyond the scope of 
this specification.)

CAs may extend a certificate's inclusion interval to some 
arbitrarily longer period of time, thereby providing historical 
revocation status service. This interval is identified as a 
certificate's "online status retention interval". Specification of 
a certificate's online status retention interval is considered a 
matter of a CA's certification practices, and should be documented 
in the CA's Certification Practices Statement.  (The same caveat 
applies here regarding online vs. off-line records access 
requirements.)

Queries on certificates beyond the online status retention interval 
are considered by this specification to be more properly addressed 
by CA Archive services.  Interactions with CA Archive services are 
beyond the scope of this specification.

CAs may provide online certificate path validation status services; 

	[Page 11]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997

they are not required to do so.  However, if a CA does provide this 
service, then upon receipt of a path validation request for a 
certificate issued by the recipient CA, the CA shall respond as 
follows:

If the subject certificate is:                  CA responds with:
------------------------------                  -----------------
within validity interval and valid:             VALID
within validity interval and invalid:           INVALID
within validity interval and revoked:           REVOKED
within inclusion interval and not revoked:      EXPIRED
within inclusion interval and revoked:          REVOKED

4.2.4 Use of PKIX AuthorityInfoAccess Extension

In order to convey to certificate-using systems a well-known point 
of information access, CAs that provide online certificate status 
services shall provide the capability to include the 
AuthorityInfoAccess extension (defined in PKIX Part 1, section 
4.2.2.2) in certificates intended to be applied to the service.

At a minimum this extension shall contain a value for certStatus 
field.

Conversely, certificate-using systems shall be capable of 
processing the AuthorityInfoAccess extension for the purposes of 
obtaining the AccessDescription value of the certStatus field.

4.2.5 Required and Optional Access Methods

CAs which provide certificate status services shall provide a value 
for a uniformResourceIndicator (URI) accessLocation and the OID 
value httpID for the accessMethod in the AccessDescription SEQUENCE 
of the certStatus field.  (The httpID OID value is defined in PKIX 
Part 1, Section 8: ASN.1 Structures and OIDs.)

CAs may provide additional values of AccessDescription in the 
certStatus field of AuthorityInfoAccess.

Certificate-using systems are not required to MUST implement mechanisms 
for all values of AccessDescription.

However, to ensure the development and deployment of a globally 
interoperable infrastructure with the minimum number of 
requirements, PKIX-compliant certificate-using systems shall be 
capable of recognizing
the httpID accessMethod and be capable following subset of 
using the corresponding URI accessLocation value in accordance with the ModifyRequest protocol syntax and semantics defined in Section 4.3.1 of this 
document.

The syntax, semantics and OIDs of each additional included 
AccessDescription syntax of certStatus shall conform to PKIX Part unit.



Boeyen, Howes & Richard                                         [Page 12]

Draft-ietf-pkix-ipki2opp-00.txt 		March 7]






INTERNET DRAFT                                            September 1997

1.

For each AccessDescription included in the certStatus


   ModifyRequest ::=
     [APPLICATION 6] SEQUENCE {
    object         LDAPDN,
    modification   SEQUENCE OF SEQUENCE {
                     operation     ENUMERATED {
                                     add     (0),
                                     delete  (1)
                                   },
                     modification  SEQUENCE {
                                   type   AttributeType,
                                   values SET OF
                                          AttributeValue
                                   }
                   }
     }

All aspects of a 
given certificate, the issuing CA shall ensure that: 1) all 
information required to obtain a certificate's status is included 
in the accessLocation value; and 2), the status response is 
invariant with respect to the use of any AccessDescription value 
included in the certStatus SEQUENCE.

4.2.6 Access Method Symmetry

For each AccessDescription for which a CA provides a certificate 
status service, the CA shall transmit responses using the access 
method used to receive the correspondingly prior query.  That is, 
queries transmitted using HTTP will result in HTTP responses; 
queries transmitted using SMTP will result in SMTP responses; and 
so forth.

Conversely, certificate-using system which initiate a query using a 
given access method shall be capable of receiving the corresponding 
response using that same access method.

4.3 Detailed Protocol

This section specifies ModifyRequest MUST be supported, except for the details of OCSP per access method.  At 
present, only  fol-
lowing:

- Only the HTTP access method is specified.  Specifications add and delete values of OCSP over other access methods will follow.

4.3.1 HTTP

4.3.1.1 Query Syntax

An HTTP-based OCSP query operation need to be supported

8.2.2.  Modify Response

The full LDAPv2 ModifyResponse is defined in RFC 1777.

An application providing a text-based message composed of a URL 
followed by a sequence of keyword-value pairs. The following loose 
grammar specifies the query portion of the protocol.  Quoted 
syntactic elements are terminal elements of LDAP repository modify service MUST implement
the grammar.

OCSP_query       :      url request version cert_id
url              :      protocol "://" domain_name "/"
protocol         :      "http"
request          :      service_class "/" action
service_class    :      "status"
action           :      "check"
cert_id          :      "ID" "/" hash
hash             :      hash_of(Issuer DN | cert serial number) full ModifyResponse.

8.3.  Add

8.3.1.  Add Request

The cert_id field could be full LDAPv2 AddRequest is defined in RFC 1777.

An application providing a straightforward reiteration of LDAP repository modify service MUST implement
the 
Issuer DN and certificate serial number.  However, OCSP should be 
responsive to bandwidth issues associated with high usage frequency 
(i.e millions of hits per day on a responding server).  Backend 
search efficiency should be full AddRequest.

8.3.2.  Add Response

The full LDAPv2 AddResponse is defined in RFC 1777.

An application providing a factor as well, for exactly LDAP repository modify service MUST implement
the same 
reason. full AddResponse.

8.4.  Delete






Boeyen, Howes & Richard                                         [Page 13]

Draft-ietf-pkix-ipki2opp-00.txt 		March 8]






INTERNET DRAFT                                            September 1997

A hash of issuer DN with certificate serial number meets these 
needs, both reducing the bits on the wire and also providing an 
unstructured index useful for high speed, random access to large 
data repositories.

There


8.4.1.  Delete Request

The full LDAPv2 DelRequest is no cryptographic relevance to the use of a hash defined in OCSP 
queries. RFC 1777.

An application providing a LDAP repository modify service MUST implement
the full DelRequest.

8.4.2.  Delete Response

The requirement full LDAPv2 DelResponse is production of defined in RFC 1777.

An application providing a compact, unique 
identification.  MD5 meets these needs and further yields fewer 
bits on LDAP repository modify service MUST implement
the wire than, for example, SHA-1. Support for other hashes 
will require inclusion of full DelResponse.

8.5.  Unbind

An application providing a hash algorithm identifier, further 
extending LDAP repository modify service MUST implement
the number full UnbindRequest.

9.  Non-standard attribute value encodings

When conveyed in LDAP requests and results, attributes defined in  X.500
are  to be encoded using string representations defined in RFC 1778, The
String Representation of bits  Standard  Attribute  Syntaxes.   These  string
encodings  were  based  on  the wire. Consequently,  attribute definitions from X.500(1988).
Thus, the string representations of the OCSP 
query hash value shall be PKI information elements are for
version  1  certificates  and  version  1  revocation lists.  Since this
specification uses version  3  certificates  and  version  2  revocation
lists,  as defined in X.509(1997), the base-64 representation RFC 1778 string encoding of a hash 
computed using MD5.
  
4.3.1.2 Response Syntax

An HTTP-based OCSP response these
attributes is composed of inappropriate.

For this reason, these attributes MUST be encoded using a sequence syntax similar
to the syntax  "Undefined" from section 2.1 of data 
fields separated by a "#" character.  Response codes RFC 1778: values of these
attributes are returned encoded as the ASCII encoding if they were values of a decimal number.  Values  type  "OCTET  STRING",
with a minus 
sign (ASCII encoding of "-") indicate definitive error values.

OCSP_response      :    definitive_rsp | error_rsp
definitive_rsp     :    base status_value signature_block
error_rsp          :    minimal_error | definitive_error

minimal_error      :    0x20                             // " " //
definitive_error   :    base error_value signature_block

base               :    time "#" prior_id "#"
time               :    YYYYMMDDHHMMSSZ
prior_id           :    // cert_id  the  string  value  of corresponding query //

error_value        :    illformed_msg | no_service | not_my_cert
illformed_msg      :    0x2d 0x31                       // "-1" //
no_service         :    0x2d 0x32                       // "-2" //
not_my_cert        :    0x2d 0x33                       // "-3" //

status_value       :    valid|invalid|revoked|not_revoked|expired 
not_revoked        :    0x31                            // "1"  //
revoked            :    0x32                            // "2"  //
invalid            :    0x33                            // "3"  //
valid              :    0x34                            // "4"  //
expired            :    0x35                            // "5"  //

signature_block    :    sig_alg_oid "#" signature
sig_alg_oid        :    // OID used to generate signature //
signature          :    // base-64 encoded value corresponding to  the result encoding being the DER-encoding of using sig-alg-oid //

To produce a signed response, the responder first calculates
value itself.  For example, when writing a hash 
across the to-be-transmitted sequence

	[Page 14]

Draft-ietf-pkix-ipki2opp-00.txt 		March 1997

            { time#prior_id#response_value#sign_alg_oid# },

signs the hash using the algorithm indicated by sig_alg_oid, base-
64 encodes the result and then concatenates it userCertificate to the prior fields. 

4.4 Performance Considerations

Performance considerations may motivate  repo-
sitory, the use of CA generates a cache on DER-encoding of the 
status server end to retain recently retrieved state information.  
When doing so, certificate and uses that
encoding as the effect value of cache refresh rates need to be 
considered.  It is possible when using such an approach to reduce  the timeliness of  userCertificate  attribute  in  the certificate status service to that 
approaching periodic CRL distribution.

4.5 Security Considerations

For this service to be effective, certificate using system must 
connect to  LDAP
Modify  request.This  encoding  style  is  consistent  with the certificate status service provider. In encoding
scheme proposed for LDAPv3, which is now being defined within the event 
such IETF.

10.  Transport

An application providing a connection cannot be obtained, certificate-using systems 
should implement CRL processing logic LDAP repository read service, LDAP repository
search  service,  or  LDAP repository modify service MUST support LDAPv2
transport over TCP, as a fall-back position.

A denial defined in Section 3.1 of service vulnerability is evident with respect to RFC 1777.

An application providing a 
flood LDAP repository read service, LDAP repository



Boeyen, Howes & Richard                                         [Page 9]






INTERNET DRAFT                                            September 1997


search  service,  or  LDAP  repository modify service MAY support LDAPv2
transport over other reliable transports as well.

11.  Security Considerations

Since the elements of queries constructed information which are key to produce error responses.  The 
production of a cryptographic signature significantly affects 
response generation cycle time, thereby exacerbating the situation. 
Performance studies on a preliminary implementation of OCSP capable 
of handling two million hits per day without degradation suggest 
this effect is of an orders of magnitude per response. Unsigned 
error responses provide a reasonable tradeoff against protection 
against this particular attack.

The use the PKI service (cer-
tificates  and CRLs) are both digitally signed pieces of unsigned error messages introduces a vulnerability to 
intermediation attacks. It information, no
additional integrity service is reasonable to ask for error messages 
to REQUIRED.  As neither  information  ele-
ment  need  be signed kept secret and anonymous access to address this vulnerability.  A request such information, for
retrieval purposes  is  generally  acceptable,  no  privacy  service  is
REQUIRED.  As CAs may have access to do so 
however must also consider the converse risk identified above-
namely that increasing the response cycle time of error messages 
through use of cryptographic signing increases information elements in the impact of 
flooding attacks.  CAs reposi-
tory which anonymous users will not, it is RECOMMENDED that wish even  though
anonymous  access  is  provided  to offer end entities, CAs should bind to their relying parties the benefit
repository with a minimum of signed error responses should strongly consider simple authentication.

For the 
use LDAP repository modify service, profiled in section 8, there are
some specific security considerations with respect to access control.

The CA MUST have access control permissions allowing it to:

  For CA entries:
    - add, modify and delete all PKI attributes for its
      own directory entry;
    - add, modify and delete all values of hardware-assisted cryptography.  Do so will reduce the 
threat these attributes.

  For CRL distribution point entries (if used):
    - create, modify and delete entries of flood attacks.

To mitigate the effects object class
      cRLDistributionPoint immediately subordinate to its own
      entry;
    - add, modify and delete all attributes, and all values of replay attacks (by using previously 
signed responses), applications should match
      these attributes for these entries.

  For subscriber (end-entity) entries:
    - add, modify and delete the certificate 
identifier attribute userCertificate and time field
      all values of the incoming response to the previous 
query before acting on the response.

Finally, the results delivered to the certificate acceptance 
decision function may be mediated that attribute, issued by one or more software 
components which provide no explicit means to establish or maintain 
a trusted path. Ultimately, this CA
      to/from these entries.

 The CA is the relying party (or, ONLY entity with these permissions.

An application providing LDAP repository read, LDAP  repository  search,
or  LDAP  repository  modify service as defined in the case of 

	[Page 15]

Draft-ietf-pkix-ipki2opp-00.txt this specification is
not REQUIRED to implement any additional security  features  other  than
those described herein, however an implementation MAY do so.

12.  References

[1]  Lightweight Directory Access  Protocol.  Y.  Yeong,  T.  Howes,  S.
     Kille, RFC 1777, March 1995.



Boeyen, Howes & Richard                                        [Page 10]






INTERNET DRAFT                                            September 1997

automated machine processing, the owner/operator


[2]   The String  Representation  of a router, Web 
Server, X.400 MTA, etc.) is responsible  Standard  Attribute  Syntaxes.  T.
     Howes, S. Kille, W. Yeong, C. Robbins, RFC 1778, March 1995.

[3]  Key Words for placing trust use  in the 
results.

Author Addresses:  RFCs  to  Indicate  Requirement  Levels,  S.
     Bradner, RFC 2119, March 1997.

13.  Author's Address

 
   Sharon Boeyen
   Entrust Technologies
2 Constellation Crescent, Nepean
P.O. Box 3511,Station C Limited
   750 Heron Road
   Ottawa, Ontario
   Canada K1Y 4H7 K1V 1A7
   boeyen@entrust.com

Russell Housley
SPYRUS
PO Box 1198
Herndon, VA 20172
USA
housley@spyrus.com

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA
   howes@netscape.com

Michael Myers
VeriSign Inc.
2593 Coast Avenue
Mountain View, CA 94043
USA
myers@psn.net

   Patrick Richard
   Xcert Software Inc.
   Suite 1001, 701 W. Georgia Street
   P.O. Box 10145
   Pacific Centre
   Vancouver, B.C.
   Canada V7Y 1C6
   patr@xcert.com



















Boeyen, Howes & Richard                                        [Page 16] 11]



----