idnits 2.17.1 draft-ietf-pkix-ocspv2-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 338 instances of too long lines in the document, the longest one being 79 characters in excess of 72. ** There are 101 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 182: '...ts and responses SHALL conform to this...' RFC 2119 keyword, line 183: '...definitions MAY extend these requireme...' RFC 2119 keyword, line 187: '...Requests SHALL include the following c...' RFC 2119 keyword, line 191: '... optionalSignature [0] EXPLICIT Signature OPTIONAL }...' RFC 2119 keyword, line 195: '... requestorName [1] EXPLICIT GeneralName OPTIONAL,...' (120 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2560' on line 243 looks like a reference -- Missing reference section? 'RFC2119' on line 975 looks like a reference -- Missing reference section? '0' on line 866 looks like a reference -- Missing reference section? '1' on line 867 looks like a reference -- Missing reference section? '2' on line 868 looks like a reference -- Missing reference section? '3' on line 768 looks like a reference -- Missing reference section? 'RFC2459' on line 967 looks like a reference -- Missing reference section? 'RFC2630' on line 477 looks like a reference -- Missing reference section? 'ACPROF' on line 987 looks like a reference -- Missing reference section? 'RFC2437' on line 994 looks like a reference -- Missing reference section? 'SHA1' on line 991 looks like a reference -- Missing reference section? 'DSS' on line 997 looks like a reference -- Missing reference section? '4' on line 662 looks like a reference -- Missing reference section? 'HTTP' on line 971 looks like a reference -- Missing reference section? 'URL' on line 978 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Michael Myers 2 draft-ietf-pkix-ocspv2-02.txt TraceRoute Security 3 March, 2001 Rich Ankney 4 Expires in six months Certco 5 Carlisle Adams 6 Entrust 7 Stephen Farrell 8 Baltimore 9 Carlin Covey 10 Cylink 12 Online Certificate Status Protocol, version 2 13 draft-ietf-pkix-ocspv2-02.txt 15 Status of this memo 17 This document is an Internet-Draft and is in full conformance with all pro- 18 visions of Section 10 of RFC 2026. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months and 25 may be updated, replaced, or obsoleted by other documents at any time. It 26 is inappropriate to use Internet-Drafts as reference material or to cite 27 them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 1. Abstract 37 This document advances the specification of RFC 2560 [RFC2560] towards the 38 acquisition of any data relevant to determining a digital certificate's reliability; interoperability with [RFC2560] is maintained. Such data include a 39 certificate's revocation status, it's validation status and ancillary 40 information supporting these assertions. Three services are defined: 41 Online Revocation Status (ORS); Delegated Path Validation (DPV); and Delegated 42 Path Discovery (DPD). Ancillary extensions defined in [RFC2560] are also 43 maintained. The means by which a certificate may be identified is also 44 expanded. 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 47 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 48 uppercase, as shown) are to be interpreted as described in [RFC2119]. 50 TABLE OF CONTENTS 52 1. Abstract 1 53 2. Protocol Overview 3 54 3. General Protocol Requirements 4 55 3.1 Requests 4 56 3.1.1 Service Identification 5 57 3.1.2 Certificate Identification 5 58 3.1.3 Signed Requests 6 59 3.2 Response Envelope 6 60 3.2.1 Definition of Basic OCSP Response 7 61 3.2.2 Error Responses 7 62 3.2.3 Signed Responses 8 63 3.2.4 Response Acceptance Criteria 8 64 3.3 Certificate Content 8 65 3.4 Authorized Responders 8 66 3.5 Use of ASN.1 Syntax 10 67 3.6 Application to Attribute Certificates 10 68 3.7 Mandatory and Optional Cryptographic Algorithms 10 69 4. Service Deployment Requirements 10 70 5. Online Revocation Status 11 71 5.1 Request 11 72 5.2 Response 11 73 5.2.1 Interpretation of CertStatus Field 11 74 5.2.2 Response Signature Production and Validation 12 75 5.2.3 Interpretation of Time-related Fields 12 76 5.2.4 Other Fields 13 77 5.2.5 CA Key Revocation 13 78 6. Delegated Path Validation 13 79 6.1 Request 13 80 6.2 Response 14 81 6.2.1 Interpretation of CertStatus Field 14 82 6.3 Processing Considerations 15 83 7. Delegated Path Discovery 15 84 7.1 Request 15 85 7.2 Response 16 86 7.3 Processing Considerations 17 87 8. Extensions 17 88 8.1 Nonce 17 89 8.2 CRL References 17 90 8.3 Acceptable Response Types 18 91 8.4 Archive Cutoff 18 92 8.5 Service Locator 18 93 8.6 CRL Entry Extensions 19 94 9. Security Considerations 19 95 10. Acknowledgments 19 96 11. References 19 97 12. Authors' Addresses 20 98 13. Appendix A. OCSP over HTTP 20 99 14. Appendix B. OCSP in ASN.1 21 100 15. Appendix C. MIME registrations 21 101 2. Protocol Overview 103 OCSP is a online request-response PKI information acquisition protocol composed 104 of generic envelope and a set of standardized request and response types. An 105 OCSP request message is composed of protocol version number, a request type 106 object identifier and other request data relevant to a particular request type. 107 Requests may be digitally signed. Responses are correspondingly structured as 108 an OID and associated response data. Responses may or may not be digitally 109 signed depending on service request type or error processing. 111 A request-response pair defines a service type. The Online Revocation Status 112 (ORS), Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) 113 service types are of particular interest. 115 The ORS service enables certificate processing software to obtain timely 116 information regarding the revocation status of a certificate beyond that 117 typically available through the use of CRLs. While useful to the deployment of 118 this service in certain instances, CRLs are not mandatory to implement ORS. 120 The DPV service enables an environment to offload certificate path validation 121 complexity to a centralized server, thereby yielding benefits to thin clients 122 and enterprise security policy management. DPV provides client-side control 123 points whereby a client may govern essential aspects of a server's technical 124 behavior. These are: 126 a. OID-based specification of policies relevant to path validation logic; 128 b. specification of paths or partial paths to be respected by the server; 130 c. a means to specify a time context for historical references; 132 d. inclusion of revocation information, whether CRLs or OCSP; and 134 e. flags that stimulate a DPV server to return ancillary information, including: 135 the path used, the revocation information relied on, a timestamp on the entire 136 process and an OID-based identification of the policy or policies enforced in 137 the validation process. 139 DPV control points are optional elements. Minimally, the relationship between a 140 DPV client and a DPV server is an answer to the question "is this certificate 141 valid now?" The control points enable a client to dynamically tailor its 142 definition of "valid" in accordance with localized policies. 144 The DPD service enables certificate processing software to acquire the 145 certificate and revocation data a DPV server might otherwise use, thereby 146 yielding benefits in integrating a single PKI information access protocol across 147 a potentially diverse set of more general data retrieval mechanisms (e.g. X.500, 148 LDAP, HTTP, FTP, etc.) As with DPV, the DPD service specification provides for 149 optional client-side control points. These are: 151 a. an iterative mechanism that enables a client to walk through several 152 technically valid paths to discover an path acceptable to the client's 153 operational policies (should such multiple paths exist); 154 b. OID-based specification of policies relevant to path validation logic; 156 c. specification of paths or partial paths to be respected by the server; 158 d. a means to specify a time context for historical references; and 160 e. flags that stimulate a DPD server to return ancillary information, including: 161 a timestamp on the entire process; an OID-based identification of the policy or 162 policies enforced in the path construction process; and whether or not the 163 client prefers CRLs, OCSP responses or either (in some instances one or the 164 other might not be available to a DPD server). 166 OCSP also provides for the use of extensions that enable specialization of 167 service types towards unique circumstances. These extensions, originally 168 defined by [RFC2560] and carried forward in this document, include: 170 a. Nonces useful for replay detection needs; 172 b. CRL references, enable clients to acquire the CRLs used; 174 c. Archive Cutoff specification applicable to historical references; 176 d. CRL entry extensions for a acquisition of specific CRL content; and 178 e. Service Locator mechanism that enables client-driven server redirection. 180 3. General Protocol Requirements 182 Service requests and responses SHALL conform to this Section 3.0. Service 183 definitions MAY extend these requirements. 185 3.1 Requests 187 Requests SHALL include the following content: 189 OCSPRequest ::= SEQUENCE { 190 tbsRequest TBSRequest, 191 optionalSignature [0] EXPLICIT Signature OPTIONAL } 193 TBSRequest ::= SEQUENCE { 194 version [0] EXPLICIT Version DEFAULT v1, 195 requestorName [1] EXPLICIT GeneralName OPTIONAL, 196 requestList SEQUENCE OF Request, 197 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 199 Version ::= INTEGER { v1(0), v2(1) } 200 A requestExtensions field SHALL ONLY be included if the requestExtensions field 201 contains one or more values, else the field SHALL be omitted from OCSPRequest. 203 3.1.1 Service Identification 205 As a general rule, service request types are identified by an OID in the 206 requestExtensions field of TBSRequest. An exception is made for the Online 207 Revocation Status (ORS) service. Other than ORS, the requests of all OCSP-based 208 service SHALL be an OID identifying the requested service in the 209 requestExtensions field of TBSRequest; he ORS service MAY be so identified. To 210 determine if an request is or is not a request for ORS service, servers SHALL 211 implement logic equivalent to the following: 213 a. Upon receipt of a request, examine the contents of the requestExtensions 214 field. 216 b. If the requestExtensions field is absent, the request SHALL be considered an 217 ORS service request. 219 c. If the requestExtensions field contains one or more OIDs, then if any one of 220 those values matches the ORS service type OID defined in this document, the 221 request SHALL be considered an ORS service request. 223 3.1.2 Certificate Identification 225 The ReqCert structure enables clients to identify a certificate in the means 226 most suitable to the technical constraints of their local environment. This 227 structure interoperably extends the CertID definition defined in [RFC2560]. The 228 following options are available: 230 ReqCert ::= CHOICE { 231 certID CertID, 232 issuerSerial [0] IssuerandSerialNumber, 233 pKCert [1] Certificate, 234 name [2] GeneralName, 235 certHash [3] OCTET STRING} 237 CertID ::= SEQUENCE { 238 hashAlgorithm AlgorithmIdentifier, 239 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 240 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 241 serialNumber CertificateSerialNumber } 243 As noted, [RFC2560] interoperablity can be obtained through the use of the 244 certID element of the ReqCert CHOICE. If certID is used in ReqCert, the value 245 for version in the tbsRequest field of OCSPRequest SHALL be v1. If any other 246 choice in ReqCert is used, the value for version SHALL be v2. 248 Clients claiming compliance to this specification SHALL support either 249 issuerSerial OR PKCert. Servers claiming compliance to this specification SHALL 250 be capable of responding to both. Support for other options is STRONGLY 251 ENCOURAGED. 253 The value for issuerNameHash SHALL be calculated over the DER encoding of the 254 issuer's name field in the certificate being checked. 256 The value for issuerKeyHash SHALL be calculated over the value of the BIT STRING 257 subjectPublicKey key field (excluding tag and length) in the issuer's 258 certificate. 260 The hash algorithm used for both these hashes, is identified in hashAlgorithm. 261 serialNumber is the serial number of the certificate for which status is being 262 requested. 264 3.1.3 Signed Requests 266 Service definitions MAY require the use of digital signatures over requests. 267 When required, signed request SHALL be produced as follows: 269 Signature ::= SEQUENCE { 270 signatureAlgorithm AlgorithmIdentifier, 271 signature BIT STRING, 272 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL} 274 Request ::= SEQUENCE { 275 reqCert ReqCert, 276 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 278 Signed requests SHALL identify the requestor in the requestorName field of 279 TBSRequest (see Section 3.1). Signed requests MAY include in the certs field of 280 the Signature element certificates that assist the OCSP responder in verifying 281 the requestor's signature. 283 3.2 Response Envelope 285 Responses SHALL contain a responseStatus field. A value for the responseBytes 286 field SHALL be included if the value for responseStatus is "successful". A 287 value for the responseBytes field MAY be included for responseStatus values 288 other than "successful". The responseBytes field SHALL be composed of an OBJECT 289 IDENTIFIER identifying the response type and the bytes of the actual response 290 encoded as an OCTET STRING. 292 OCSPResponse ::= SEQUENCE { 293 responseStatus OCSPResponseStatus, 294 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 296 OCSPResponseStatus ::= ENUMERATED { 297 successful (0), 298 malformedRequest (1), 299 internalError (2), 300 tryLater (3), 301 --(4) is not used for legacy reasons 302 sigRequired (5), 303 unauthorized (6), 304 noMoreData (7) } 306 ResponseBytes ::= SEQUENCE { 307 responseType OBJECT IDENTIFIER, 308 response OCTET STRING } 310 3.2.1 Definition of Basic OCSP Response 312 This section defines syntax useful to both the ORS and DPV services. Other 313 services MAY reuse this syntax as needs dictate. In cases where this syntax is 314 used, service definitions SHALL provide a definition for the certStatus field of 315 SingleResponse. 317 BasicOCSPResponse ::= SEQUENCE { 318 tbsResponseData ResponseData, 319 signatureAlgorithm AlgorithmIdentifier, 320 signature BIT STRING, 321 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 323 ResponseData ::= SEQUENCE { 324 version [0] EXPLICIT Version DEFAULT v1, 325 responderID ResponderID, 326 producedAt GeneralizedTime, 327 responses SEQUENCE OF SingleResponse, 328 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 330 ResponderID ::= CHOICE { 331 byName [1] Name, 332 byKey [2] KeyHash } 334 SingleResponse ::= SEQUENCE { 335 reqCert ReqCert, 336 certStatus CertStatus, 337 thisUpdate GeneralizedTime, 338 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 339 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 341 3.2.2 Error Responses 343 A server produces the "malformedRequest" response if the request received does 344 not conform to the required syntax. 346 The response "internalError" indicates that the server reached an inconsistent 347 internal state. The query should be retried, potentially with another responder. 349 In the event that a server is operational but unable to return a status for the 350 requested certificate, the "tryLater" response can be used to indicate that the 351 service exists, but is temporarily unable to respond. 353 The response "sigRequired" is returned in cases where the server requires the 354 client sign the request in order to construct a response. 356 The response "unauthorized" is returned in cases where the client is not 357 authorized to make this query to this server. 359 The response "noMoreData" is returned in cases where the server has previously 360 returned the last positive response to a related sequence of requests. 362 3.2.3 Signed Responses 364 Response messages containing only a value for responseStatus SHALL NOT be 365 digitally signed. Response signatures SHALL be computed over the DER encoding 366 of the tbsRequest structure. 368 3.2.4 Response Acceptance Criteria 370 Clients SHALL reject as invalid any response that does not satisfy all of the 371 following criteria: 373 a. the certificate(s) identified in a received response matches that (or those) 374 identified in the corresponding request; 376 b. the signature on the response is valid; 378 c. the identity of the signer matches the intended recipient of the request; 380 d. the signer is currently authorized to sign the response; 382 e. when available, the time at which the status being indicated is known to be 383 correct is sufficiently recent; and 385 f. when available, the time at or before which newer information will be 386 available is greater than the current time. 388 3.3 Certificate Content 390 Certificate-producing entities SHALL be capable of including the 391 AuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1) in 392 certificates. Alternatively, the accessLocation for the OCSP provider may be 393 configured locally at the OCSP client. 395 Certificate-producing entities supporting this protocol SHALL be capable of 396 providing for the inclusion of a value for a uniformResourceIndicator (URI) 397 accessLocation and the OID value id-ad-ocsp for the accessMethod in the 398 AccessDescription SEQUENCE. 400 The value of the accessLocation field in the subject certificate defines the 401 transport (e.g. HTTP) used to access the OCSP responder and may contain other 402 transport dependent information (e.g. a URL). 404 3.4 Authorized Responders 406 The key that signs a certificate's status information need not be the same key 407 that signed the certificate. It is necessary however to ensure that the entity 408 signing this information is authorized to do so. Therefore, a certificate's 409 issuer SHALL either: 411 a. sign the OCSPresponses itself using a private key under the control of the 412 issuer; or 414 b. explicitly delegate this authority to another entity. OCSP signing 415 delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an 416 extendedKeyUsage certificate extension included in the OCSP response signer's 417 certificate. This certificate MUST be issued directly by the CA that issued the 418 certificate in question. 420 Explicit delegation of OCSP signing authority SHALL be indicated by inclusion of 421 the following value in the extendedKeyUsage extension of certificate needed to 422 validate an OCSP response signature produced by such an entity: 424 id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} 426 Systems or applications that rely on OCSP responses SHALL be capable of 427 detecting and enforcing use of the id-ad-ocspSigning value as described above. 428 They MAY provide a means of locally configuring one or more OCSP signing 429 authorities, and specifying the set of CAs for which each signing authority is 430 trusted. They SHALL reject the response if the certificate required to validate 431 the signature on the response fails to meet at least one of the following 432 criteria:ee 434 a. Matches a local configuration of OCSP signing authority for the certificate 435 in question; 437 b. is a certificate corresponding to a private key under control of the CA that 438 issued the certificate in question; or 440 c. includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and is 441 issued by the CA that issued the certificate. 443 Additional acceptance or rejection criteria may apply to either the response 444 itself or to the certificate used to validate the signature on the response. 446 Since an Authorized Responder provides status information for one or more CAs, 447 OCSP clients need to know how to check that an Authorized Responder's 448 certificate has not been revoked. CAs may choose to deal with this problem in 449 one of three ways: 451 - A CA may specify that an OCSP client can trust an Authorized Responder for 452 the lifetime of the responder's certificate. The CA does so by including 453 the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical 454 extension. The value of the extension is NULL. CAs issuing 455 such a certificate should realize that a compromise of the 456 Authorized Responder's key, is as serious as the compromise of a CA key 457 used to sign CRLs, at least for the validity period of this certificate. 458 CAs may choose to issue this type of certificate with a very short 459 lifetime and renew it frequently. 461 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 462 - A CA may specify how the responder's certificate is to be checked for 463 revocation. This can be done using CRL Distribution Points if the 464 check should be done using CRLs or CRL Distribution Points, or 465 Authority Information Access if the check should be done in some 466 other way. Details for specifying either of these two mechanisms are 467 available in [RFC2459]. 469 - A CA may choose not to specify any method of revocation checking 470 for the responder's certificate, in which case, it would be up to the 471 OCSP client's local security policy to decide whether that 472 certificate should be checked for revocation or not. 474 3.5 Use of ASN.1 Syntax 476 The ASN.1 syntax used in this document imports terms defined in [RFC2459] and 477 [RFC2630]. For Signature calculation, the data to be signed is encoded using the 478 ASN.1 distinguished encoding rules (DER) [X.690]. 480 ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. 482 The terms imported from elsewhere are: Extensions, CertificateSerialNumber, 483 SubjectPublicKeyInfo, Name, AlgorithmIdentifier, CRLReason and 484 IssuerAndSerialNumber. 486 3.6 Application to Attribute Certificates 488 OCSP MAY be used without modification to provide status on attribute 489 certificates (ACs) conforming to [ACPROF]. Note that since [ACPROF], section 490 4.2.3, mandates that the issuer field uses a single X.500 name to identify the 491 AC issuer, and also ([ACPROF], section 4.5) mandates that an AC issuer cannot 492 also be a PKC issuer (at least using the same name/key), there are no syntactic 493 changes required to support ACs. An OCSP responder that only supports PKCs will 494 treat a request for status on an AC in the same way as it would treat a request 495 for an issuer/serial combination for which it had no information. That is, a 496 conforming OCSP responder need not have any specific ability to handle ACs. 498 3.7 Mandatory and Optional Cryptographic Algorithms 500 Clients and servers SHALL support the RSA signature algorithm in accordance with 501 RFC 2437 [RFC2437] and the SHA1 hashing algorithm as defined in FIPS Pub 180-1 502 [SHA1]. DSA signature support MAY be provided. If provided, this algorithm SHALL 503 be implemented in accordance with FIPS Pub 186 [DSS]. 505 4. Service Deployment Requirements 507 This document defines three standard services: Online Revocation Status (ORS), 508 Delegated Path Validation (DPD) and Delegated Path Discovery (DPD). Other 509 services MAY be defined for environments with more local needs. Environments 510 MAY deploy any or all of these services in any combination. That is, a server 511 MAY be implemented and operated to only perform the DPD service.Equivalently, 512 delivery of the ORS service is NOT required to deliver the DPV service. Servers 513 SHOULD be capable of delivering all three services. 515 5. Online Revocation Status 517 This section defines the Online Revocation Status (ORS) service. This service 518 enables certificate processing software to determine if a certificate is or is 519 not revoked. This information MAY be recorded in non-CRL formats. While useful 520 to the deployment of this service in certain instances, CRLs are NOT required to 521 implement ORS. 523 Responders SHALL be capable of producing responses of the id-pkix-ocsp-basic 524 response type. Correspondingly, OCSP clients SHALL be capable of receiving and 525 processing responses of the id-pkix-ocsp-basic response type. 527 The value for response SHALL be the DER encoding of BasicOCSPResponse. 529 5.1 Request 531 An ORS request SHALL conform to the specifications detailed in Section 3.1 of 532 this document. An ORS request MAY be digitally signed. Clients are STRONGLY 533 ENCOURAGED to include a value of id-pkix-ocsp-ors-req as a value for the 534 requestExtensions field. Servers claiming compliance to this OCSPv2 535 specification SHALL: 1) be capable of recognizing the id-pkix-ocsp-ors-req 536 value; and 2) be capable of identifying ORS requests according to the mechanisms 537 described in Section 3.1.1 of this document. 539 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 540 id-pkix-ocsp-ors-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 542 5.2 Response 544 The responseType field of an ORS response SHALL contain a value of id-pkix-ocsp- 545 basic: 547 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 548 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 550 The responseBytes field of an ORS response SHALL be composed of the 551 BasicOCSPResponse syntax defined in Section 3.2.1 of this document. 553 5.2.1 Interpretation of CertStatus Field 555 The CertStatus field of BasicOCSPResponse SHALL be interpreted as follows when 556 the value of responseType is id-pkix-ocsp-basic. 558 ORSCertStatus ::= CHOICE { 559 good [0] IMPLICIT NULL, 560 revoked [1] IMPLICIT RevokedInfo, 561 unknown [2] IMPLICIT UnknownInfo } 563 RevokedInfo ::= SEQUENCE { 564 revocationTime GeneralizedTime, 565 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 567 UnknownInfo ::= NULL -- this can be replaced with an enumeration 569 The "good" state indicates that the certificate has not been revoked. It does 570 not indicate that the certificate was ever issued, is or is in its validity 571 interval. 573 The "revoked" state indicates that the certificate has been revoked (either 574 permanantly or temporarily (on hold)). 576 The "unknown" state indicates that the responder doesn't know about the 577 certificate being requested. 579 5.2.2 Response Signature Production and Validation 581 ORS response messages SHALL be digitally signed if and only if they contain a 582 value for responseBytes. ORS signature calculation and production SHALL conform 583 to Section 3.2 of this document. The key used to sign an ORS response MAY be 584 any key trusted by the client for this purpose. The means by which this key is 585 established is beyond the scope of the document. Such keys include: 587 1. the key used to sign the subject certificate; 589 2. a key associated with the CA (i.e. a CA's "OCSP Signing" key); 591 3. a key certified by the issuing CA as an Authorized Responder; or 593 4. a key otherwise trusted by the requestor. 595 The key that signs a certificate's status information need not be the same key 596 that signed the certificate. A certificate's issuer explicitly delegates OCSP 597 signing authority by issuing a certificate containing a unique value for 598 extendedKeyUsage in the OCSP signer's certificate. This certificate MUST be 599 issued directly to the responder by the cognizant CA. 601 Responders MAY pre-produce signed responses. The time at which the status was 602 known to be correct SHALL be reflected in the thisUpdate field of the response. 603 The time at or before which newer information will be available SHALL be 604 indicated in the nextUpdate field. The time at which the response was produced 605 SHALL appear in the producedAt field. 607 5.2.3 Interpretation of Time-related Fields 609 The thisUpdate, nextUpdate and producedAt fields SHALL be interpreted as 610 follows: 612 - thisUpdate: The time at which the status being indicated is known 613 to be correct 614 - nextUpdate: The time at or before which newer information will be 615 available about the status of the certificate 616 - producedAt: The time at which the responder signed the response. 618 If nextUpdate is not set, the responder is indicating that newer revocation 619 information is available all the time. 621 The thisUpdate and nextUpdate fields define a recommended validity interval. If 622 CRLs are used as the basis for basic response production, this interval 623 corresponds to the {thisUpdate, nextUpdate} interval in those CRLs; otherwise it 624 corresponds to equivalent database management functions. 626 Responses whose nextUpdate value is earlier than the local system time value 627 SHOULD be considered unreliable. Responses whose thisUpdate time is later than 628 the local system time SHOULD be considered unreliable. Responses where the 629 nextUpdate value is not set are equivalent to a CRL with no time for nextUpdate. 631 5.2.4 Other Fields 633 When the byKey CHOICE of ResponderID is used, the value for KeyHash SHALL be 634 calculated over the value of the BIT STRING subjectPublicKey key field 635 (excluding tag and length) in the issuer's certificate. 637 5.2.5 CA Key Revocation 639 If a responder knows that a particular CA's private key has been revoked, it MAY 640 return the "revoked" state for all certificates issued by that CA. 642 6. Delegated Path Validation 644 This section identifies and defines the Delegated Path Validation (DPV) service. 645 This service may be useful to environments that wish to offload [RFC2459]- 646 compliant certificate validation functions to a centralized server. 648 6.1 Request 650 A DPV request SHALL include a value of id-pkix-ocsp-valid-req in the 651 requestExtensions field of TBSRequest. 653 id-pkix-ocsp-valid-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 655 The corresponding value of the associated requestExtensions element SHALL 656 contain the following: 658 DPVOptions :: = SEQUENCE{ 659 pathParams PathParameters OPTIONAL, 660 validAt [2] GeneralizedTime OPTIONAL, 661 revInfo [3] SEQUENCE OF RevocationInfo OPTIONAL, 662 dPVFLags [4] DPVFlags OPTIONAL } 664 PathParameters ::= SEQUENCE { 665 initialPolicySet [0] PolicyList OPTIONAL, 666 trustPoints [1] SEQUENCE OF ReqCert OPTIONAL } 668 DPVFlags ::= BIT STRING { 669 returnpath (0), 670 returnrevinfo (1), 671 returntsp (2), 672 returnpolicy (3) } 674 RevocationInfo ::= CHOICE { 675 cRL CertificateList, 676 oCSP OCSPResponse } 678 PolicyList ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 680 The initialPolicySet option enables a requestor to establish one or more initial 681 policy identifiers as defined in [RFC2459]. Definition of such policies is 682 beyond the scope of this specification. 684 The trustPoints option enables specification of one or more certificates 685 relevant to the relying party's trust model. If included, a successful 686 validation request will pass through at least one of these trust points, else an 687 "unknown" response will be generated. 689 A client request MAY specify the time relative to which the validation is to be 690 performed. If omitted, the current time SHALL be assumed. 692 6.2 Response 694 A DPV response SHALL contain a value of id-pkix-ocsp-valid-rsp in the 695 ResponseType field of the ResponseBytes syntax. 697 id-pkix-ocsp-valid-rsp OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 699 The responseBytes field of an DPV response SHALL be composed of the 700 BasicOCSPResponse syntax defined in Section 3.2.1 of this document. 702 Servers that produce DPV responses SHALL execute path validation logic that 703 produces outputs compliant with [RFC2459]. 705 6.2.1 Interpretation of CertStatus Field 707 The CertStatus field of BasicOCSPResponse SHALL be interpreted as follows when 708 the value of responseType is id-pkix-ocsp-valid. 710 DPVCertStatus ::= CHOICE { 711 valid [0] IMPLICIT NULL, 712 invalid [1] IMPLICIT NULL, 713 unknown [2] IMPLICIT NULL } 715 The "valid" state SHALL be interpreted as indicating that the certificate at a 716 minimum satisfies the path validation rules defined in [RFC2459]. Servers MAY 717 further predicate production of a "valid" response upon additional and locally- 718 defined authorization criteria. 720 The "invalid" state SHALL be interpreted as indicating that the subject 721 certificate does not satisfy one or more conditions necessary to the production 722 of a "valid" state. 724 The "unknown" state SHALL be interpreted as indicating that the server has no 725 knowledge of the subject certificate. 727 If a DPV request contains a non-NULL value for initialPolicySet, all OIDs 728 included in that set SHALL be used as initial policy identifier values in the 729 validation logic according to [RFC2459]. 731 If a DPV request contains a non-NULL value for trustPoints, the receiving server 732 SHALL attempt to produce a response that incorporates these certificates. If 733 the receiving server cannot form such a path, the server SHALL return a status 734 value of "unknown" in the response. 736 6.3 Processing Considerations 738 [additional work needed on the various options] 740 7. Delegated Path Discovery 742 The path validation logic defined by [RFC2459] requires certificate-processing 743 systems to accumulate the set of certificates from which certificate chains may 744 be constructed as well as revocation data for each such certificate. These data 745 may originate from diverse sources. Commonly used technologies for retrieving 746 this information include X.500, LDAP, HTTP, FTP among other methods. Delegating 747 this acquisition process to a separate server greatly simplifies and reduces the 748 size of public-key based credential validation systems or other relying party 749 software. It may also be useful to such software to be able to select from 750 among various trust paths in the event multiple paths exist. The Delegated Path 751 Discovery (DPD) service addresses these needs. 753 7.1 Request 755 A DPD request SHALL contain a value of id-pkix-ocsp-path-req in the ResponseType 756 field of the ResponseBytes syntax. 758 id-pkix-ocsp-path-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 760 The corresponding value of the associated requestExtensions element SHALL 761 contain the following: 763 DPDOptions :: = SEQUENCE{ 764 retryReference OCTET STRING, 765 initialPolicySet [0] EXPLICIT PolicyList OPTIONAL, 766 trustPoints [1] SEQUENCE OF ReqCert OPTIONAL, 767 validAt [2] GeneralizedTime OPTIONAL, 768 dDPFlags [3] DPDFlags OPTIONAL} 770 DPDFlags ::= BIT STRING { 771 returnTSP (0), 772 returnpolicy (1), 773 crlonly (2), 774 ocsponly (3), 775 either (4) } 777 The RetryReference enables a requestor to acquire the next of potentially 778 several valid paths known to the OCSP server based on a previous response. If 779 this field is omitted then the request is considered to be a "new" request and 780 the responder may return any path that meets the request criteria. If a client 781 does specify a RetryReference then the responder SHALL NOT return any path that 782 was previously returned with that reference (i.e. the responder MUST either 783 return a different path meeting the request or an error). 785 7.2 Response 787 A DPD response SHALL contain a value of id-pkix-ocsp-path-rsp in the 788 ResponseType field of the ResponseBytes syntax. 790 id-pkix-ocsp-path-rsp OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 792 The responseBytes field of a DPD response SHALL consists of the following 793 information. 795 DPDOCSPResponse ::= SEQUENCE OF PathResponse 796 -- one for each certificate included in the requestList field of TBSRequest 798 PathResponse ::= SEQUENCE { 799 retryReference BIT STRING, 800 certificates SEQUENCE OF Certificate, 801 crls SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL, 802 ocspReps SEQUENCE SIZE (1..MAX) OF OCSPResponse OPTIONAL } 804 The sequence of certificates SHALL form a potentially valid certification path, 805 in order, from end-entity certificate (element 0 of the sequence), up to and 806 including a "final" CA certificate, (which need not, but MAY be self-certified). 808 The RetryReference SHOULD uniquely refer to all path validation data (including 809 the data in the current response) that has been returned to the requester with 810 respect to this request. 812 The responder MAY also include a set of CRLs and/or OCSP responses which, if 813 included, SHOULD relate to the certificates in the set of certificates. 815 7.3 Processing Considerations 817 DPD servers SHALL: 819 a. Upon receipt of an authorized path discovery request, where possible, deliver 820 to the requestor a collection of certificates and optionally CRLs and other OCSP 821 responses that may be used to validate a certificate according to [RFC2459]; 823 b. Either establish a stateful association enabling a requestor to serially ask 824 for the next path via the retry option, to the extent that multiple validation 825 paths exist and the receiving OCSP server is aware of these paths or respond 826 with a noStateMaintained error to all retry requests if the server does not 827 maintain state; and 829 c. In the event that the server is stateful and a prior response was the last 830 path known to the responder, respond to subsequent retry requests with a 831 noMoreData value in OSCPResponseStatus. 833 [additional work needed on the various options] 835 8. Extensions 837 This section defines several extensions that could be of use in specific 838 instances. Support for any specific extension is OPTIONAL. Additional 839 extensions MAY be defined in additional RFCs. Unrecognized extensions MUST be 840 ignored (unless they have the critical flag set and are not understood). 842 8.1 Nonce 844 The nonce cryptographically binds a request and a response to prevent replay 845 attacks (assuming that the requester-generated nonce is a large random number 846 that the requester has not used previously). The nonce is included as one 847 of the requestExtensions in requests, while in responses it would be included as 848 one of the responseExtensions. In both the request and the response, the nonce 849 will be identified by the object identifier id-pkix-ocsp-nonce, while the 850 extnValue is the value of the nonce. 852 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 854 8.2 CRL References 856 It may be desirable for the OCSP responder to indicate the CRL on which a 857 revoked or onHold certificate is found. This can be useful where OCSP is used 858 between repositories, and also as an auditing mechanism. The CRL may be 859 specified by a URL (the URL at which the CRL is available), a number (CRL 860 number) or a time (the time at which the relevant CRL was created). These 861 extensions will be specified as singleExtensions. The identifier for this 862 extension will be id-pkix-ocsp-crl, while the value will be CrlID. 864 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 865 CrlID ::= SEQUENCE { 866 crlUrl [0] EXPLICIT IA5String OPTIONAL, 867 crlNum [1] EXPLICIT INTEGER OPTIONAL, 868 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 870 For the choice crlUrl, the IA5String will specify the URL at which the CRL is 871 available. For crlNum, the INTEGER will specify the value of the CRL number 872 extension of the relevant CRL. For crlTime, the GeneralizedTime will indicate 873 the time at which the relevant CRL was issued. 875 8.3 Acceptable Response Types 877 An OCSP client MAY wish to specify the kinds of response types it understands. 878 To do so, it SHOULD use an extension with the OID id-pkix-ocsp-response, and the 879 value AcceptableResponses. This extension is included as one of the 880 requestExtensions in requests. The OIDs included in AcceptableResponses are the 881 OIDs of the various response types this client can accept (e.g., id-pkix-ocsp- 882 basic). 884 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 886 AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER 888 8.4 Archive Cutoff 890 An OCSP responder MAY retain information relevant to a certificate's validity 891 beyond a certificate's expiration. The date obtained by subtracting this 892 retention interval value from the producedAt time in an ORS or DPV response is 893 defined as the certificate's "archive cutoff" date. Applications would use an 894 archive cutoff date to contribute to a proof that a digital signature was (or 895 was not) reliable on the date it was produced even if the certificate needed to 896 validate the signature has long since expired. OCSP servers SHOULD include an 897 archive cutoff date extension in responses where applicable. If included, this 898 value SHALL be provided as an OCSP singleExtensions extension identified by id- 899 pkix-ocsp-archive-cutoff and of syntax GeneralizedTime. 901 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 903 ArchiveCutoff ::= GeneralizedTime 905 To illustrate, if a server is operated with a 7-year retention interval policy 906 and status was produced at time t1 then the value for ArchiveCutoff in the 907 response would be (t1 - 7 years). 909 8.5 Service Locator 911 An OCSP server may be operated in a mode whereby the server receives a request 912 and routes it to the OCSP server which is known to be authoritative for the 913 identified certificate. The serviceLocator request extension is defined for 914 this purpose. This extension is included as one of the singleRequestExtensions 915 in requests. 917 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 918 ServiceLocator ::= SEQUENCE { 919 issuer Name, 920 locator AuthorityInfoAccessSyntax OPTIONAL } 922 Values for these fields are obtained from the corresponding fields in the 923 subject certificate. 925 8.6 CRL Entry Extensions 927 All the extensions specified as CRL Entry Extensions - in Section 5.3 of 928 [RFC2459] - are also supported as singleExtensions. 930 9. Security Considerations 932 For this service to be effective, certificate using systems must connect to the 933 certificate status service provider. In the event such a connection cannot be 934 obtained, certificate-using systems could implement CRL processing logic as a 935 fall-back position. 937 A denial of service vulnerability is evident with respect to a flood of queries. 938 The production of a cryptographic signature significantly affects response 939 generation cycle time, thereby exacerbating the situation. Unsigned error 940 responses open up the protocol to another denial of service attack, where the 941 attacker sends false error responses. 943 The use of precomputed responses allows replay attacks in which an old (good) 944 response is replayed prior to its expiration date but after the certificate has 945 been revoked. Deployments of OCSP should carefully evaluate the benefit of 946 precomputed responses against the probability of a replay attack and the costs 947 associated with its successful execution. 949 Requests do not contain the responder they are directed to. This allows an 950 attacker to replay a request to any number of OCSP responders. 952 The reliance of HTTP caching in some deployment scenarios may result in 953 unexpected results if intermediate servers are incorrectly configured or are 954 known to possess cache management faults. 956 Implementors are advised to take the reliability of HTTP cache mechanisms into 957 account when deploying OCSP over HTTP. 959 10. Acknowledgments 961 The authors appreciate the hard work of all members of the IETF PKIX Working 962 Group in refining the text of this specification. We extend special thanks to 963 Denis Pinkas, Ambarish Malpani, and Peter Gutman for their efforts and support. 965 11. References 967 [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 968 X.509 Public Key Infrastructure Certificate and CRL 969 Profile", RFC 2459, January 1999. 971 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. 972 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 973 2068, January 1997. 975 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 976 Requirement Levels", BCP 14, RFC 2119, March 1997. 978 [URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform 979 Resource Locators (URL)", RFC 1738, December 1994. 981 [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, 982 Information Technology - ASN.1 encoding rules: 983 Specification of Basic Encoding Rules (BER), Canonical 984 Encoding Rules (CER) and Distinguished Encoding Rules 985 (DER). 987 [ACPROF] Farrell, S., Housley, R., "An Internet Attribute Certificate 988 Profile for Authorization", Internet Draft draft-ietf-pkix- 989 ac509prof-xx.txt (work in progress). 991 [SHA1] National Institute of Standards and Technology. 992 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 994 [RFC2437] Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", 995 RFC 2437, October 1998. 997 [DSS] National Institute of Standards and Technology. 998 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 1000 12. Authors' Addresses 1002 Michael Myers 1003 TraceRoute Security, Inc. 1004 myers@coastside.net 1005 +415.819.1362 1007 Rich Ankney 1008 rankney@erols.com 1010 Carlisle Adams 1011 Entrust Technologies 1012 cadams@entrust.com 1014 13. Appendix A. OCSP over HTTP 1016 A.1 OCSP over HTTP 1018 This section describes the formatting that will be done to the 1019 request and response to support HTTP. 1021 A.1.1 Request 1023 HTTP based OCSP requests can use either the GET or the POST method to 1024 submit their requests. To enable HTTP caching, small requests (that 1025 after encoding are less than 255 bytes), MAY be submitted using GET. 1026 If HTTP caching is not important, or the request is greater than 255 1027 bytes, the request SHOULD be submitted using POST. Where privacy is 1028 a requirement, OCSP transactions exchanged using HTTP MAY be 1029 protected using either TLS/SSL or some other lower layer protocol. 1031 An OCSP request using the GET method is constructed as follows: 1033 GET {url}/{url-encoding of base-64 encoding of the DER encoding of 1034 the OCSPRequest} 1036 where {url} may be derived from the value of AuthorityInfoAccess or 1037 other local configuration of the OCSP client. 1039 An OCSP request using the POST method is constructed as follows: The 1040 Content-Type header has the value "application/ocsp-request" while 1041 the body of the message is the binary value of the DER encoding of 1042 the OCSPRequest. 1044 A.1.2 Response 1046 An HTTP-based OCSP response is composed of the appropriate HTTP 1047 headers, followed by the binary value of the DER encoding of the 1048 OCSPResponse. The Content-Type header has the value 1049 "application/ocsp-response". The Content-Length header SHOULD specify 1050 the length of the response. Other HTTP headers MAY be present and MAY 1051 be ignored if not understood by the requestor. 1053 14. Appendix B. OCSP in ASN.1 1055 [MODULE TO BE AGGREGATED AND IDENTIFIED] 1057 15. Appendix C. MIME registrations 1059 C.1 application/ocsp-request 1061 To: ietf-types@iana.org 1062 Subject: Registration of MIME media type application/ocsp-request 1064 MIME media type name: application 1066 MIME subtype name: ocsp-request 1068 Required parameters: None 1070 Optional parameters: None 1072 Encoding considerations: binary 1073 Security considerations: Carries a request for information. This 1074 request may optionally be cryptographically signed. 1076 Interoperability considerations: None 1078 Published specification: IETF PKIX Working Group Draft on Online 1079 Certificate Status Protocol - OCSP 1081 Applications which use this media type: OCSP clients 1083 Additional information: 1085 Magic number(s): None 1086 File extension(s): .ORQ 1087 Macintosh File Type Code(s): none 1089 Person & email address to contact for further information: 1090 Ambarish Malpani 1092 Intended usage: COMMON 1094 Author/Change controller: 1095 Ambarish Malpani 1097 C.2 application/ocsp-response 1099 To: ietf-types@iana.org 1100 Subject: Registration of MIME media type application/ocsp-response 1102 MIME media type name: application 1104 MIME subtype name: ocsp-response 1106 Required parameters: None 1108 Optional parameters: None 1109 Encoding considerations: binary 1111 Security considerations: Carries a cryptographically signed response 1113 Interoperability considerations: None 1115 Published specification: IETF PKIX Working Group Draft on Online 1116 Certificate Status Protocol - OCSP 1118 Applications which use this media type: OCSP servers 1120 Additional information: 1122 Magic number(s): None 1123 File extension(s): .ORS 1124 Macintosh File Type Code(s): none 1125 Person & email address to contact for further information: 1126 Ambarish Malpani 1128 Intended usage: COMMON 1130 Author/Change controller: 1131 Ambarish Malpani ambarish@valicert.com