home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pkix-ipki2opp-00.txt < prev    next >
Text File  |  1997-03-20  |  34KB  |  903 lines
  1. Internet Draft                                          
  2. PKIX Working Group                                     
  3. draft-ietf-pkix-ipki2opp-00.txt
  4.  
  5. Expires in 6 months                                        March 1997
  6.  
  7.                                   S. Boeyen (Entrust Technologies)
  8.                                   R. Housley (SPYRUS)
  9.                                   T. Howes (Netscape)
  10.                                   M. Myers (Verisign)
  11.                                   P. Richard (Xcert)
  12.  
  13.                   Internet Public Key Infrastructure
  14.  
  15.                     Part 2: Operational Protocols
  16.  
  17.                    <draft-ietf-pkix-ipki2opp-00.txt>
  18.  
  19. Status of this Memo
  20.  
  21. This document is an Internet-Draft. Internet-Drafts are working 
  22. documents of the Internet Engineering Task Force (IETF), its areas, 
  23. and its working groups. Note that other groups may also distribute 
  24. working documents as Internet-Drafts.
  25.  
  26. Internet-Drafts are draft documents valid for a maximum of six 
  27. months and may be updated, replaced, or obsoleted by other 
  28. documents at any time. It is inappropriate to use Internet-Drafts 
  29. as reference material or to cite them other than as "work in 
  30. progress."
  31.  
  32. To learn the current status of any Internet-Draft, please check the 
  33. "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 
  34. Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 
  35. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 
  36. ftp.isi.edu (US West Coast).
  37.  
  38. Abstract
  39.  
  40. This is the first draft of the Internet Public Key Infrastructure 
  41. X.509 Operational Protocols. This document identifies candidate 
  42. protocols for retrieval of X.509 v3 certificates and v2 CRLs as 
  43. well as a candidate protocol for online status checking of X.509 v3 
  44. certificates. It is proposed that this document serve as the basis 
  45. for the PKIX Part 2 standardization effort. Please send comments on 
  46. this document to the ietf-pkix@tandem.com mail list.
  47.  
  48. 1. Introduction
  49.  
  50. This specification is Part 2 of a multi-part standard for development 
  51. of a Public Key Infrastructure (PKI) for the Internet. This 
  52. specification addresses the requirements to provide retrieval of 
  53. certificates and CRLs from an information repository.  Two 
  54. protocol profiles are provided to satisfy this requirement. One is 
  55.  
  56.                                [Page 1]
  57. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  58.  
  59. based on the Lightweight Directory Access Protocol (LDAP) and the 
  60. other on the File Transfer Protocol (FTP).  In addition, the 
  61. requirement for a user to validate the status of a certificate 
  62. online, directly from a CA is addressed and supporting protocol is 
  63. specified.
  64.  
  65. 1.1 Model
  66.  
  67. The PKI components, as defined in PKIX Part 1, which are involved 
  68. in PKIX operational protocol interactions include:
  69.  
  70. -  End Entities
  71. -  Certification Authorities (CA)
  72. -  Repository
  73.  
  74. End entities and CAs retrieve certificates and/or CRLs from the 
  75. repository using either the Lightweight Directory Access Protocol 
  76. (LDAP) profile defined in section 2 or the File Transfer Protocol 
  77. (FTP) profile defined in section 3 of this specification.
  78.  
  79. Otherwise, entities validate the status of a certificate, by 
  80. communicating directly with a CA, using the Online Certificate 
  81. Status Protocol (OCSP) defined in section 4 of this specification.
  82.  
  83. 2. Lightweight Directory Access Protocol (LDAP)
  84.  
  85. This section examines the retrieval of information from the 
  86. certificate/CRL repository and defines a subset of the LDAPv2  
  87. protocol for providing this retrieval mechanism. Two scenarios, 
  88. satisfying different sets of requirements are provided in 2.1 and 
  89. 2.2 below.  Section 2.1 satisfies the requirement to retrieve 
  90. information (a certificate, CRL, or other information of interest)  
  91. from an entry in the repository, where the retrieving entity 
  92. (either an end entity or a CA) has knowledge of the name of the 
  93. entry. This is termed "repository read".  Section 2.2 satisfies the 
  94. same requirement as 2.1 for the situation where the name of the 
  95. entry is not known, but some other related information which can be 
  96. used as a filter against candidate entries in the repository, is 
  97. known.  This is termed "repository search".  
  98.  
  99. The subset of LDAPv2 needed to support each of these functions is 
  100. described below. Note that the repository search service  is a 
  101. superset of the repository read service  in terms of the LDAPv2 
  102. functionality needed.
  103.  
  104. Note also that all tags are implicit by default in the ASN.1 
  105. definitions that follow.
  106.  
  107. 2.1 LDAP Repository Read
  108.  
  109. To retrieve information from an entry corresponding to the subject 
  110. or issuer name of a certificate, requires a subset of the following 
  111.  
  112.     [Page 2]
  113.  
  114. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  115.  
  116. three LDAP operations:
  117.  
  118.   BindRequest (and BindResponse)
  119.   SearchRequest (and SearchResponse)
  120.   UnbindRequest
  121.  
  122. The subset of each operation is given below.
  123.  
  124. 2.1.1 Bind
  125.  
  126. 2.1.1.1 Bind Request
  127.  
  128. The full LDAP v2 Bind Request is defined in RFC 1777.
  129. An application providing a LDAP repository read service MUST 
  130. implement the following subset of this operation:
  131.  
  132.    BindRequest ::=
  133.        [APPLICATION 0] SEQUENCE {
  134.             version      INTEGER (2),
  135.             name         LDAPDN, -- MUST accept NULL LDAPDN
  136.             simpleauth [0] OCTET STRING  -- MUST accept NULL simple
  137.             }
  138.  
  139. An application providing a LDAP repository read service MAY 
  140. implement other aspects of the BindRequest as well.
  141.  
  142. Different services may have different security requirements. Some 
  143. services may allow anonymous search, others may require 
  144. authentication. Those services allowing anonymous search may only 
  145. allow search based on certain criteria and not others.
  146.  
  147. A LDAP repository read service SHOULD implement some level of 
  148. anonymous search access. A Public-Key Search service MAY implement 
  149. authenticated search access. 
  150.  
  151. 2.1.1.2 BindResponse
  152.  
  153. The full LDAPv2 BindResponse is described in RFC 1777.
  154.  
  155. An application providing a LDAP repository read service MUST 
  156. implement this entire protocol element, though only the following 
  157. errors codes may be returned from a Bind operation:
  158.  
  159.   success                      (0),
  160.   operationsError              (1),
  161.   protocolError                (2),
  162.   authMethodNotSupported       (7),
  163.   noSuchObject                 (32),
  164.   invalidDNSyntax              (34),
  165.   inappropriateAuthentication  (48),
  166.   invalidCredentials           (49),
  167.   busy                         (51),
  168.  
  169.     [Page 3]
  170.  
  171. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  172.  
  173.   unavailable                  (52),
  174.   unwillingToPerform           (53),
  175.   other                        (80)
  176.  
  177. 2.1.2 Search
  178.  
  179. 2.1.2.1 SearchRequest
  180.  
  181. The full LDAPv2 SearchRequest is defined in RFC 1777.  An 
  182. application providing a LDAP repository read service MUST implement 
  183. the following subset of the SearchRequest.
  184.  
  185.    SearchRequest ::=
  186.        [APPLICATION 3] SEQUENCE {
  187.             baseObject     LDAPDN,
  188.             scope             ENUMERATED {
  189.                               baseObject   (0),
  190.                                          },
  191.             derefAliases   ENUMERATED {
  192.                               neverDerefAliases   (0),
  193.                                       },
  194.             sizeLimit      INTEGER (0),
  195.             timeLimit      INTEGER (0),
  196.             attrsOnly      BOOLEAN, -- FALSE only
  197.             filter         Filter,
  198.             attributes     SEQUENCE OF AttributeType
  199.                                 }
  200.  
  201.    Filter ::=
  202.        CHOICE {
  203.            present        [7] AttributeType, -- "objectclass" only
  204.               }
  205.  
  206. This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read" 
  207. operation: a base object search with a filter testing for the 
  208. existence of the objectClass attribute.
  209.  
  210. An application providing a LDAP repository read service MAY 
  211. implement other aspects of the SearchRequest as well.
  212.  
  213. 2.1.2.2 SearchResponse
  214.  
  215. The full LDAPv2 SearchResponse is defined in RFC 1777.
  216.  
  217. An application providing a LDAP repository read service over LDAPv2 
  218. MUST implement the full SearchResponse.
  219.  
  220. 2.1.3 Unbind
  221.  
  222. The full LDAPv2 UnbindRequest is defined in RFC 1777.
  223.  
  224. An application providing a LDAP repository read service MUST 
  225.  
  226.     [Page 4]
  227.  
  228. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  229.  
  230. implement the full UnbindResponse.
  231.  
  232. 2.2 LDAP Repository Search
  233.  
  234. To search for an entry in a repository containing a user's public 
  235. key using arbitrary criteria requires a subset of the following 
  236. three LDAP operations:
  237.  
  238.   BindRequest (and BindResponse)
  239.   SearchRequest (and SearchResponse)
  240.   UnbindRequest
  241.  
  242. The subset of each operation required is given below.
  243.  
  244. 2.2.1 Bind
  245.  
  246. The BindRequest and BindResponse subsets needed are the same as 
  247. those described in Section 2.1.1.
  248.  
  249. The full LDAP v2 Bind Request is defined in RFC 1777.
  250.  
  251. 2.2.2 Search
  252.  
  253. 2.2.2.1 SearchRequest
  254.  
  255. The full LDAPv2 SearchRequest is defined in RFC 1777.
  256.  
  257. An application providing a LDAP repository search service MUST 
  258. implement the following subset of the SearchRequest protocol unit.
  259.  
  260.    SearchRequest ::=
  261.        [APPLICATION 3] SEQUENCE {
  262.             baseObject     LDAPDN,
  263.             scope          ENUMERATED {
  264.                                 baseObject     (0),
  265.                                 singleLevel    (1),
  266.                                 wholeSubtree   (2)
  267.                                       },
  268.             derefAliases   ENUMERATED {
  269.                                 neverDerefAliases     (0),
  270.                                       },
  271.             sizeLimit      INTEGER (0 .. maxInt),
  272.             timeLimit      INTEGER (0 .. maxInt),
  273.             attrsOnly      BOOLEAN,  -- FALSE only
  274.             filter         Filter,
  275.             attributes     SEQUENCE OF AttributeType
  276.                                  }
  277.  
  278. All aspects of the SearchRequest MUST be supported, except for the 
  279. following:
  280.  
  281. - Only the neverDerefAliases value of derefAliases needs to be 
  282.  
  283.     [Page 5]
  284.  
  285. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  286.  
  287. supported
  288.  
  289. - Only the FALSE value for attrsOnly needs to be supported
  290.  
  291. This subset provides a more general search capability. It is a 
  292. superset of the SearchRequest subset defined in Section 2.1.2.1. 
  293. The elements added to this service are:
  294.  
  295. - singleLevel and wholeSubtree scope needs to be supported
  296.  
  297. - sizeLimit is included
  298.  
  299. - timeLimit is included
  300.  
  301. - Enhanced filter capability
  302.  
  303. An application providing a LDAP repository search service MAY 
  304. implement other aspects of the SearchRequest as well.
  305.  
  306. 2.2.2.2 SearchResponse
  307.  
  308. The full LDAPv2 SearchResponse is defined in RFC 1777.
  309.  
  310. An application providing a LDAP repository search service over 
  311. LDAPv2 MUST implement the full SearchResponse.
  312.  
  313. 2.2.3 Unbind
  314.  
  315. An application providing a LDAP repository search service MUST 
  316. implement the full UnbindRequest.
  317.  
  318. 2.3 Transport
  319.  
  320. An application providing a LDAP repository read service or a LDAP 
  321. repository search service MUST support LDAPv2 transport over TCP, 
  322. as defined in Section 3.1 of RFC 1777.
  323.  
  324. An application providing a LDAP repository read service or a LDAP 
  325. repository search service MAY support LDAPv2 transport over other 
  326. reliable transports as well.
  327.  
  328. 2.4 Security Considerations
  329.  
  330. For LDAP, since the elements of information which are key to the 
  331. PKI service (certificates and CRLs) are both digitally signed 
  332. pieces of information, no additional integrity service is required.  
  333. As neither information element need be kept secret and anonymous 
  334. access to such information is generally acceptable, no privacy 
  335. service is required.  As CAs may have access to information 
  336. elements in the repository which anonymous users will not, it is 
  337. recommended that even though anonymous access can be provided to 
  338. end entities, CAs should bind to the repository with a minimum of 
  339.  
  340.     [Page 6]
  341.  
  342. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  343.  
  344. simple authentication.
  345.  
  346. 3. File Transfer Protocol (FTP)
  347.  
  348. Some CAs mandate the use of on-line validation services, while 
  349. others distribute CRLs to allow certificate users to perform 
  350. certificate validation themselves.  In general, CAs make CRLs 
  351. available to certificate users by posting them in the Directory.  
  352. The Directory is also the normal distribution mechanism for 
  353. certificates.  However, Directory Services are not available in 
  354. many parts of the Internet today, and the File Transfer Protocol 
  355. (FTP), defined in RFC 959,  offers an alternate method for 
  356. certificate and CRL distribution.
  357.  
  358. Within certificate extensions and CRL extensions, URI form of 
  359. GeneralName is used to specify the location where issuer 
  360. certificates and CRL may be obtained.  For instance, a URI 
  361. identifying the subject of a certificate can be carried in 
  362. subjectAltName certificate extension. An IA5String describes the 
  363. use of anonymous, or authenticated FTP to fetch certificate or CRL.  
  364. For example:
  365.  
  366.    ftp://ftp.netcom.com/sp/spyrus/housley.cer 
  367.    ftp://ftp.your.org/pki/id48.cer
  368.    ftp://ftp.your.org/pki/id48.no42.crl
  369.  
  370. Internet users may publish the URI reference to a file that 
  371. contains their certificate on their business card.  This practice 
  372. is useful when there is no Directory entry for that user. FTP is 
  373. widely deployed, and anonymous FTP is accommodated by many 
  374. firewalls.  Thus, FTP is an attractive alternative to Directory 
  375. access protocols for certificate and CRL distribution.
  376.  
  377. For convenience, the names of files that contain certificates 
  378. should have a suffix of ".cer".  Likewise, the names of files that 
  379. contain CRLs should have a suffix of ".crl".
  380.  
  381. Note that this service satisfies the the requirement to retrieve 
  382. information related to a certificate which is already identified by 
  383. a URI. It is not intended to satisfy the more general problem of 
  384. finding a certificate for a user about whom some other information, 
  385. such as their email address or corporate affiliation, is known.
  386.  
  387. 4. Online Certificate Status Protocol (OCSP) 
  388.  
  389. There exists a requirement for CAs to provide an Online Certificate 
  390. Status Protocol (OCSP) service characterized by a high degree of 
  391. availability and a rapid response time.  Instances where this 
  392. service would be used include those where:
  393.  
  394. - Application vendors may not implement the syntax and semantics
  395.   required for standards-compliant certificate path validation.
  396.  
  397.     [Page 7]
  398.  
  399. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  400.  
  401. - Application vendors who implement compliant certificate path
  402.   validation logic may not implement the logic associated with
  403.   periodic Certificate Revocation Lists (CRLs).
  404.  
  405. - Application vendors may find that while CRL processing is within
  406.   their reach, implementing the protocols necessary to obtain CRLs
  407.   from public repositories (e.g. an X.500 Directory System) is not.
  408.  
  409. - In lieu of or as a supplement to checking against a periodic CRL,
  410.   it may be necessary to obtain immediate status regarding a
  411.   certificate's revocation state (cf. PKIX Part 1, Section 3.3).
  412.   Examples include high-value funds transfer or the compromise of a
  413.   highly sensitive key.
  414.  
  415. Two meta-level requirements factor into the specification of OCSP.  
  416. First, it should be significantly easier to implement than the 
  417. corresponding local CRL processing it supplements.  This will 
  418. enable the rapid integration of the protocol into emerging 
  419. certificate-enabled applications.
  420.  
  421. Secondly, the specification of OCSP should enable rapid 
  422. assimilation and deployment of the service among CA product and 
  423. service vendors. Since the task of certificate management is 
  424. largely unaffected by the mode of a certificate's use, it is 
  425. optimal from the CA perspective that a single OCSP implementation 
  426. would meet the needs of IPSEC, S/MIME, EDI and other diverse 
  427. applications.  Recognizing that this goal may not be achievable, 
  428. the semantics of the OCSP transaction model should remain invariant 
  429. against the syntactic constraints of the transport protocol used to 
  430. convey the OCSP.  For example, it's easily forseeable that use of 
  431. SMTP as a transport model is the path of least resistance for e-
  432. mail User Agents, while HTTP is an optimal choice for Web browsers.  
  433. The OCSP syntax for each may differ according to each transport 
  434. protocol's usage patterns; the semantic constructs should not.
  435.  
  436. 4.1 Protocol Overview
  437.  
  438. The Online Certificate Status Protocol (OCSP) enables applications 
  439. to efficiently and rapidly determine the validity and revocation 
  440. state of an identified certificate.  An application issues a status 
  441. request to the certificate issuer (CA) and suspends further 
  442. certificate acceptance processing until the CA responds with a 
  443. status indication.
  444.  
  445. 4.1.1 Query
  446.  
  447. An OCSP query is semantically defined by the following three 
  448. elements:
  449.  
  450. 1  protocol version
  451. 2  service request
  452.  
  453.     [Page 8]
  454.  
  455. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  456.  
  457. 3  target certificate identifier
  458.  
  459. Upon receipt of a query, the CA first determines if: 1) the message 
  460. is well formed, 2) the CA provides the requested service, and 3) 
  461. the CA issued the subject certificate.  If any one of the prior 
  462. conditions are not met, an error message is produced; otherwise, a 
  463. definitive response is returned.
  464.  
  465. 4.1.2 Response
  466.  
  467. All definitive response messages are authenticated with the 
  468. responding CA's digital signature.  A definitive response message 
  469. is composed of:
  470.  
  471. 1  date and time of response
  472. 2  repeat of target certificate identifier
  473. 3  certificate status value
  474. 4  signature algorithm OID
  475. 5  signature computed across hash of previous four values
  476.  
  477. This specification defines the following "definitive" response 
  478. values:
  479.  
  480. 1  VALID
  481. 2   INVALID
  482. 3  REVOKED
  483. 4  NOT REVOKED
  484. 5  EXPIRED
  485.  
  486. Two error response semantics are defined. The first favors service 
  487. availability at the expense of security.  This is a "minimal" error 
  488. response.  The second option provides the converse balance:  
  489. enhancing the authenticity of CA error responses through the use of 
  490. a signed error message, although at the risk of denial of service.  
  491. (The Performance Considerations and Security Considerations 
  492. sections of this document provide amplifying discussions.)
  493.  
  494. The syntactic definition of a minimal error message is expected to 
  495. vary by transport protocol.  For example, when using HTTP to convey 
  496. OCSP, a minimal error response would be a single space character.  
  497. This is viewed as sufficient to inform the requesting party that, 
  498. with some degree of likelihood, the CA received the message but 
  499. could not return an otherwise definitive response.
  500. Signed error messages are semantically identical to definitive 
  501. response messages, extending the set of definitive response values 
  502. to include the previously identified error conditions:
  503.  
  504. 1  ILLFORMED MESSAGE
  505. 2  SERVICE UNAVAILABLE
  506. 3  DID NOT ISSUE CERTIFICATE
  507.  
  508. In the case of an ill-formed message, it may not be possible for 
  509.  
  510.     [Page 9]
  511.  
  512. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  513.  
  514. the receiving CA to parse the certificate identifier from the 
  515. received message.  To regularize the implementation of response 
  516. generation and response processing logic, a null certificate 
  517. identifier is defined.
  518.  
  519. 4.2 Requirements
  520.  
  521. For the purposes of requirements specification, abstract response 
  522. values are indicated by UPPER CASE.  A syntactic-level 
  523. interpretation of these abstract values per transport protocol is 
  524. provided in Section 4.3.1 of this specification.
  525.  
  526. 4.2.1 Definition of Services
  527.  
  528. Certificate status service information can be organized into three 
  529. categories:  1) certificate path validation; 2) current revocation 
  530. status; and 3) historical revocation status.  Path validation 
  531. services enable applications to defer all processing associated 
  532. with determining a certificate's validity state to a trusted third 
  533. party. The current revocation status service provides the means to 
  534. determine whether or not an otherwise valid certificate has been 
  535. revoked within the interval of its validity period and maintains 
  536. this state for some limited time thereafter.  The historical 
  537. revocation status service extends the current revocation status 
  538. service over an extended period of time beyond a certificate's 
  539. expiration.
  540.  
  541. 4.2.2 Error Responses
  542.  
  543. Upon receipt of a query which fails to parse against defined OCSP 
  544. semantics, the receiving CA shall respond with an error message.  
  545. If a CA provides signed error responses, a failure to parse an 
  546. incoming query shall be indicated by an ILLFORMED MESSAGE response.  
  547. The value of the certificate identifier of such a response shall be 
  548. NULL_CERT_ID.
  549.  
  550. For service request categories not supported by a CA, the CA shall 
  551. respond with an error message. If a CA provides signed error 
  552. responses, non-availability of the requested service shall be 
  553. indicated by a SERVICE UNAVAILABLE response.
  554.  
  555. For service request categories supported by a CA, if the receiving 
  556. CA did not issue the subject certificate, the CA shall respond with 
  557. an error message. If a CA provides signed error responses, this 
  558. error situation shall be indicated by a DID NOT ISSUE CERTIFICATE 
  559. response.
  560.  
  561. CAs shall produce a minimal error response as described in Section 
  562. 2.1.2.  They may provide signed error responses as described in 
  563. Section 2.1.2.  They should provide the option to do both.  The 
  564. means by which a CA signals to a relying party which error behavior 
  565. is offered should be through certificate contents.
  566.  
  567.     [Page 10]
  568.  
  569. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  570.  
  571. 4.2.3 Required and Optional Services
  572.  
  573. CAs which offer online certificate status services shall at a 
  574. minimum provide the current revocation status service defined in 
  575. Section 3.1.
  576.  
  577. Upon receipt by a CA of a current revocation status request for a 
  578. certificate issued by the recipient CA, the CA shall respond with 
  579. either REVOKED or NOT_REVOKED, according to the certificate's 
  580. status, throughout the duration of the certificate's validity 
  581. interval and continuing for a given number days following the date 
  582. of the subject certificate's expiration.  This latter interval is 
  583. identified as the certificate's "inclusion interval".  
  584. Specification of a certificate's inclusion interval is considered a 
  585. matter of a CA's certification practices, and should be documented 
  586. in the CA's Certification Practices Statement.
  587.  
  588. If a subject certificate was not revoked prior to the expiration of 
  589. its validity period, but a current revocation status request is 
  590. received by its issuer within the subject certificate's inclusion 
  591. interval, the CA shall respond with a status indicating EXPIRED.
  592.  
  593. Thereafter, CAs may respond with an error message. If a CA provides 
  594. signed error responses, this error situation shall be indicated by 
  595. a DID NOT ISSUE CERTIFICATE response.  (That is, the CA is not 
  596. required to maintain online records regarding issuance beyond some 
  597. well-defined interval. The automatic mechanisms that produce OCSP 
  598. responses may not therefore be able to differentiate between the 
  599. expiration of a certificate previously issued and a certificate 
  600. that was never issued. This requirement is not intended to 
  601. establish the full extent of a CA's record-keeping obligations.  
  602. The means by which CAs enable the resolution of such queries via 
  603. other mechanisms and for other purposes are beyond the scope of 
  604. this specification.)
  605.  
  606. CAs may extend a certificate's inclusion interval to some 
  607. arbitrarily longer period of time, thereby providing historical 
  608. revocation status service. This interval is identified as a 
  609. certificate's "online status retention interval". Specification of 
  610. a certificate's online status retention interval is considered a 
  611. matter of a CA's certification practices, and should be documented 
  612. in the CA's Certification Practices Statement.  (The same caveat 
  613. applies here regarding online vs. off-line records access 
  614. requirements.)
  615.  
  616. Queries on certificates beyond the online status retention interval 
  617. are considered by this specification to be more properly addressed 
  618. by CA Archive services.  Interactions with CA Archive services are 
  619. beyond the scope of this specification.
  620.  
  621. CAs may provide online certificate path validation status services; 
  622.  
  623.     [Page 11]
  624.  
  625. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  626.  
  627. they are not required to do so.  However, if a CA does provide this 
  628. service, then upon receipt of a path validation request for a 
  629. certificate issued by the recipient CA, the CA shall respond as 
  630. follows:
  631.  
  632. If the subject certificate is:                  CA responds with:
  633. ------------------------------                  -----------------
  634. within validity interval and valid:             VALID
  635. within validity interval and invalid:           INVALID
  636. within validity interval and revoked:           REVOKED
  637. within inclusion interval and not revoked:      EXPIRED
  638. within inclusion interval and revoked:          REVOKED
  639.  
  640. 4.2.4 Use of PKIX AuthorityInfoAccess Extension
  641.  
  642. In order to convey to certificate-using systems a well-known point 
  643. of information access, CAs that provide online certificate status 
  644. services shall provide the capability to include the 
  645. AuthorityInfoAccess extension (defined in PKIX Part 1, section 
  646. 4.2.2.2) in certificates intended to be applied to the service.
  647.  
  648. At a minimum this extension shall contain a value for certStatus 
  649. field.
  650.  
  651. Conversely, certificate-using systems shall be capable of 
  652. processing the AuthorityInfoAccess extension for the purposes of 
  653. obtaining the AccessDescription value of the certStatus field.
  654.  
  655. 4.2.5 Required and Optional Access Methods
  656.  
  657. CAs which provide certificate status services shall provide a value 
  658. for a uniformResourceIndicator (URI) accessLocation and the OID 
  659. value httpID for the accessMethod in the AccessDescription SEQUENCE 
  660. of the certStatus field.  (The httpID OID value is defined in PKIX 
  661. Part 1, Section 8: ASN.1 Structures and OIDs.)
  662.  
  663. CAs may provide additional values of AccessDescription in the 
  664. certStatus field of AuthorityInfoAccess.
  665.  
  666. Certificate-using systems are not required to implement mechanisms 
  667. for all values of AccessDescription.
  668.  
  669. However, to ensure the development and deployment of a globally 
  670. interoperable infrastructure with the minimum number of 
  671. requirements, PKIX-compliant certificate-using systems shall be 
  672. capable of recognizing the httpID accessMethod and be capable of 
  673. using the corresponding URI accessLocation value in accordance with 
  674. the protocol syntax and semantics defined in Section 4.3.1 of this 
  675. document.
  676.  
  677. The syntax, semantics and OIDs of each additional included 
  678. AccessDescription syntax of certStatus shall conform to PKIX Part 
  679.  
  680.     [Page 12]
  681.  
  682. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  683.  
  684. 1.
  685.  
  686. For each AccessDescription included in the certStatus SEQUENCE of a 
  687. given certificate, the issuing CA shall ensure that: 1) all 
  688. information required to obtain a certificate's status is included 
  689. in the accessLocation value; and 2), the status response is 
  690. invariant with respect to the use of any AccessDescription value 
  691. included in the certStatus SEQUENCE.
  692.  
  693. 4.2.6 Access Method Symmetry
  694.  
  695. For each AccessDescription for which a CA provides a certificate 
  696. status service, the CA shall transmit responses using the access 
  697. method used to receive the correspondingly prior query.  That is, 
  698. queries transmitted using HTTP will result in HTTP responses; 
  699. queries transmitted using SMTP will result in SMTP responses; and 
  700. so forth.
  701.  
  702. Conversely, certificate-using system which initiate a query using a 
  703. given access method shall be capable of receiving the corresponding 
  704. response using that same access method.
  705.  
  706. 4.3 Detailed Protocol
  707.  
  708. This section specifies the details of OCSP per access method.  At 
  709. present, only the HTTP access method is specified.  Specifications 
  710. of OCSP over other access methods will follow.
  711.  
  712. 4.3.1 HTTP
  713.  
  714. 4.3.1.1 Query Syntax
  715.  
  716. An HTTP-based OCSP query is a text-based message composed of a URL 
  717. followed by a sequence of keyword-value pairs. The following loose 
  718. grammar specifies the query portion of the protocol.  Quoted 
  719. syntactic elements are terminal elements of the grammar.
  720.  
  721. OCSP_query       :      url request version cert_id
  722. url              :      protocol "://" domain_name "/"
  723. protocol         :      "http"
  724. request          :      service_class "/" action
  725. service_class    :      "status"
  726. action           :      "check"
  727. cert_id          :      "ID" "/" hash
  728. hash             :      hash_of(Issuer DN | cert serial number)
  729.  
  730. The cert_id field could be a straightforward reiteration of the 
  731. Issuer DN and certificate serial number.  However, OCSP should be 
  732. responsive to bandwidth issues associated with high usage frequency 
  733. (i.e millions of hits per day on a responding server).  Backend 
  734. search efficiency should be a factor as well, for exactly the same 
  735. reason.
  736.  
  737.     [Page 13]
  738.  
  739. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  740.  
  741. A hash of issuer DN with certificate serial number meets these 
  742. needs, both reducing the bits on the wire and also providing an 
  743. unstructured index useful for high speed, random access to large 
  744. data repositories.
  745.  
  746. There is no cryptographic relevance to the use of a hash in OCSP 
  747. queries.  The requirement is production of a compact, unique 
  748. identification.  MD5 meets these needs and further yields fewer 
  749. bits on the wire than, for example, SHA-1. Support for other hashes 
  750. will require inclusion of a hash algorithm identifier, further 
  751. extending the number of bits on the wire. Consequently, the OCSP 
  752. query hash value shall be the base-64 representation of a hash 
  753. computed using MD5.
  754.   
  755. 4.3.1.2 Response Syntax
  756.  
  757. An HTTP-based OCSP response is composed of a sequence of data 
  758. fields separated by a "#" character.  Response codes are returned 
  759. as the ASCII encoding of a decimal number.  Values with a minus 
  760. sign (ASCII encoding of "-") indicate definitive error values.
  761.  
  762. OCSP_response      :    definitive_rsp | error_rsp
  763. definitive_rsp     :    base status_value signature_block
  764. error_rsp          :    minimal_error | definitive_error
  765.  
  766. minimal_error      :    0x20                             // " " //
  767. definitive_error   :    base error_value signature_block
  768.  
  769. base               :    time "#" prior_id "#"
  770. time               :    YYYYMMDDHHMMSSZ
  771. prior_id           :    // cert_id value of corresponding query //
  772.  
  773. error_value        :    illformed_msg | no_service | not_my_cert
  774. illformed_msg      :    0x2d 0x31                       // "-1" //
  775. no_service         :    0x2d 0x32                       // "-2" //
  776. not_my_cert        :    0x2d 0x33                       // "-3" //
  777.  
  778. status_value       :    valid|invalid|revoked|not_revoked|expired 
  779. not_revoked        :    0x31                            // "1"  //
  780. revoked            :    0x32                            // "2"  //
  781. invalid            :    0x33                            // "3"  //
  782. valid              :    0x34                            // "4"  //
  783. expired            :    0x35                            // "5"  //
  784.  
  785. signature_block    :    sig_alg_oid "#" signature
  786. sig_alg_oid        :    // OID used to generate signature //
  787. signature          :    // base-64 encoded value corresponding to 
  788.                            the result of using sig-alg-oid //
  789.  
  790. To produce a signed response, the responder first calculates a hash 
  791. across the to-be-transmitted sequence
  792.  
  793.     [Page 14]
  794.  
  795. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  796.  
  797.             { time#prior_id#response_value#sign_alg_oid# },
  798.  
  799. signs the hash using the algorithm indicated by sig_alg_oid, base-
  800. 64 encodes the result and then concatenates it to the prior fields. 
  801.  
  802. 4.4 Performance Considerations
  803.  
  804. Performance considerations may motivate the use of a cache on the 
  805. status server end to retain recently retrieved state information.  
  806. When doing so, the effect of cache refresh rates need to be 
  807. considered.  It is possible when using such an approach to reduce 
  808. the timeliness of the certificate status service to that 
  809. approaching periodic CRL distribution.
  810.  
  811. 4.5 Security Considerations
  812.  
  813. For this service to be effective, certificate using system must 
  814. connect to the certificate status service provider. In the event 
  815. such a connection cannot be obtained, certificate-using systems 
  816. should implement CRL processing logic as a fall-back position.
  817.  
  818. A denial of service vulnerability is evident with respect to a 
  819. flood of queries constructed to produce error responses.  The 
  820. production of a cryptographic signature significantly affects 
  821. response generation cycle time, thereby exacerbating the situation. 
  822. Performance studies on a preliminary implementation of OCSP capable 
  823. of handling two million hits per day without degradation suggest 
  824. this effect is of an orders of magnitude per response. Unsigned 
  825. error responses provide a reasonable tradeoff against protection 
  826. against this particular attack.
  827.  
  828. The use of unsigned error messages introduces a vulnerability to 
  829. intermediation attacks. It is reasonable to ask for error messages 
  830. to be signed to address this vulnerability.  A request to do so 
  831. however must also consider the converse risk identified above-
  832. namely that increasing the response cycle time of error messages 
  833. through use of cryptographic signing increases the impact of 
  834. flooding attacks.  CAs that wish to offer to their relying parties 
  835. the benefit of signed error responses should strongly consider the 
  836. use of hardware-assisted cryptography.  Do so will reduce the 
  837. threat of flood attacks.
  838.  
  839. To mitigate the effects of replay attacks (by using previously 
  840. signed responses), applications should match the certificate 
  841. identifier and time field of the incoming response to the previous 
  842. query before acting on the response.
  843.  
  844. Finally, the results delivered to the certificate acceptance 
  845. decision function may be mediated by one or more software 
  846. components which provide no explicit means to establish or maintain 
  847. a trusted path. Ultimately, the relying party (or, in the case of 
  848.  
  849.     [Page 15]
  850.  
  851. Draft-ietf-pkix-ipki2opp-00.txt         March 1997
  852.  
  853. automated machine processing, the owner/operator of a router, Web 
  854. Server, X.400 MTA, etc.) is responsible for placing trust in the 
  855. results.
  856.  
  857. Author Addresses:
  858.  
  859. Sharon Boeyen
  860. Entrust Technologies
  861. 2 Constellation Crescent, Nepean
  862. P.O. Box 3511,Station C
  863. Ottawa, Ontario
  864. Canada K1Y 4H7
  865. boeyen@entrust.com
  866.  
  867. Russell Housley
  868. SPYRUS
  869. PO Box 1198
  870. Herndon, VA 20172
  871. USA
  872. housley@spyrus.com
  873.  
  874. Tim Howes
  875. Netscape Communications Corp.
  876. 501 E. Middlefield Rd.
  877. Mountain View, CA 94043
  878. USA
  879. howes@netscape.com
  880.  
  881. Michael Myers
  882. VeriSign Inc.
  883. 2593 Coast Avenue
  884. Mountain View, CA 94043
  885. USA
  886. myers@psn.net
  887.  
  888.  
  889. Patrick Richard
  890. Xcert Software Inc.
  891. Suite 1001, 701 W. Georgia Street
  892. P.O. Box 10145
  893. Pacific Centre
  894. Vancouver, B.C.
  895. Canada V7Y 1C6
  896. patr@xcert.com
  897.  
  898.  
  899.  
  900.     [Page 16]
  901.  
  902.  
  903.