idnits 2.17.1 draft-pala-prqp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1031. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1042. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1049. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1055. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (June 30, 2008) is 5751 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 930 -- Looks like a reference, but probably isn't: '1' on line 903 -- Looks like a reference, but probably isn't: '2' on line 869 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group M. Pala 3 Internet-Draft Dartmouth College 4 Intended status: Experimental June 30, 2008 5 Expires: January 1, 2009 7 PKI Resource Query Protocol (PRQP) 8 draft-pala-prqp-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 1, 2009. 35 Abstract 37 One of the most strategic problems still open in PKIX is locating 38 public data and services associated with a Certification Authority 39 (CA). This issue impacts interoperability and usability in PKIX. 41 This draft describes the PKI Resource Query Protocol (PRQP), its 42 design, definition, and its impact in already deployed PKIX 43 protocols. 45 Table of Contents 47 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.1. Overview of existing solutions . . . . . . . . . . . . . . 3 50 2.1.1. Certificate Extensions . . . . . . . . . . . . . . . . 3 51 2.1.2. DNS SRV records . . . . . . . . . . . . . . . . . . . 4 52 2.1.3. Local Network Oriented Solutions . . . . . . . . . . . 4 53 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. The Resource Query Authority (RQA) . . . . . . . . . . . . 5 55 3.2. PRQP Overview . . . . . . . . . . . . . . . . . . . . . . 6 56 3.2.1. PRQP Request . . . . . . . . . . . . . . . . . . . . . 6 57 3.2.1.1. Request Syntax . . . . . . . . . . . . . . . . . . 7 58 3.2.2. PRQP Response . . . . . . . . . . . . . . . . . . . . 9 59 3.2.2.1. Response Syntax . . . . . . . . . . . . . . . . . 9 60 3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 61 4. PRQP Design Rationale . . . . . . . . . . . . . . . . . . . . 13 62 4.1. Response Complexity . . . . . . . . . . . . . . . . . . . 14 63 4.2. RQA's URL distribution . . . . . . . . . . . . . . . . . . 14 64 4.3. Security Considerations . . . . . . . . . . . . . . . . . 14 65 4.4. Time Validity . . . . . . . . . . . . . . . . . . . . . . 15 66 4.5. Message Format . . . . . . . . . . . . . . . . . . . . . . 15 67 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 70 6.2. Non-Normative References . . . . . . . . . . . . . . . . . 16 71 Appendix A. Distribution of PRQP Responses . . . . . . . . . . . 16 72 A.1. PRQP over HTTP . . . . . . . . . . . . . . . . . . . . . . 16 73 A.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 17 74 A.1.2. Response . . . . . . . . . . . . . . . . . . . . . . . 17 75 A.1.3. Message Caching . . . . . . . . . . . . . . . . . . . 17 76 A.2. PRQP over Peer-to-Peer Network . . . . . . . . . . . . . . 18 77 Appendix B. PRQP ASN1.1 Specification . . . . . . . . . . . . . . 19 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 Intellectual Property and Copyright Statements . . . . . . . . . . 24 81 1. Requirements notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Introduction 89 An increasing number of services and protocols are being defined to 90 address different needs of users and administrators of PKIs. With 91 the deployment of new applications and services, the need to access 92 information and services provided by Certificate Service Providers 93 (CSPs) is critical. Currently Certification Authorities (CAs) barely 94 publish access details on their official web sites, this includes URL 95 of provided services and repositories. 97 Using the PRQP, resources provided by a CA can be automatically and 98 securely discovered by an application. 100 2.1. Overview of existing solutions 102 Currently there are three options to find URLs providing access to 103 PKI data: 105 o by including such data in certificate extensions 107 o by searching easily accessible repositories (e.g. DNS, local 108 database, etc.) 110 o by adapting existing protocols (e.g. SLP) 112 2.1.1. Certificate Extensions 114 To provide pointers to published data it is possible to use the 115 Authority Information Access (AIA) Subject Information Access (SIA) 116 extensions defined by PKIX [RFC3280]. 118 The former can provide information about services associated with the 119 issuer of the certificate, while the latter carries information 120 (inside a CA certificate) about offered CA services. 122 AIA and SIA extensions are static, i.e. not modifiable unless the 123 certificate is re-issued. If a CA inserts the AIA extension into 124 every certificate it issues, e.g., to identify the location of an 125 OCSP responder, then changing that location would require re-issuance 126 of all these certificates, a substantial barrier to such a change. 127 If a CA certificate is self-signed and used as a trust anchor, then 128 re-issuing the certificate to change the content of the SIA 129 extension, e.g., to reflect a change in the location of a time 130 stamping server would be very disruptive. In closed PKIs, e.g., 131 enterprises, use of these extensions may be replaced by manual 132 configuration and management of this data via ad hoc means. Because 133 of the centrally controlled nature of such environments, the static 134 nature of SIA and AIA extensions is not a concern. 136 However in order to promote interoperability between PKIs, PRQP 137 enables dynamic management of pointers to such services (e.g., 138 adding/removing or moving) without requiring changes in the 139 certificate contents or third parties to manually configure services 140 in their applications. Even in closed environments, PRQP could help 141 manage PKI services analogous the way DHCP facilitates network 142 management. 144 2.1.2. DNS SRV records 146 The SRV record technique provides pointers to servers via the DNS 147 [RFC1035]. 149 As defined in [RFC2782], the introduction of this type of record 150 allows administrators to perform operations similar to what we 151 require in order to solve the problem we are addressing in this 152 draft, i.e., to provide URLs to services. 154 The problem in the adoption of this mechanism is that, in contrast to 155 the DNS environment, usually in PKIX there is no fixed mapping 156 between certificates and the DNS name space. The only exception is 157 when the Domain Component (DC) attributes are used in the 158 certificate's Subject. 160 Currently this approach is not widely adopted. Moreover, it is not 161 always easy to identify the right DNS to query to, when trying to 162 find a particular service provided by a CA, because of the lack of 163 such information in certificates. 165 2.1.3. Local Network Oriented Solutions 167 Another approach to provide reliable information is to use existing 168 protocols for service location such as Jini, Universal Plug and Play 169 protocol (UPnP) or Service Location Protocol (SLP) [RFC2608] 170 [RFC2609]. 172 The IETF defined the SLP to provide a service location mechanism that 173 is language and technology independent. Some issues, however, make 174 it not the right choice to solve our problem, e.g., the protocol is 175 quite complex to implement when considering the scope of the problem 176 we are addressing. 178 The definition of a specific and simple protocol for PKI service and 179 resource location is needed to ease PKI integration into existing and 180 future applications, especially for mobile devices which have limited 181 computational power and communication bandwidth. 183 3. Protocol Details 185 The PRQP protocol is a request-response protocol, formed by the 186 exchanging of two messages, i.e., a request and a response between a 187 client and a server, called the Resource Query Authority (RQA). 189 The requesting entity (the client) may be any entity that needs to 190 access information about repositories and services related to a 191 certificate. 193 The RQA is the authority entitled to answer for a particular CA or to 194 act as a PRQP Trusted Authority (PTA) for a set of users, e.g., users 195 in an enterprise environment. 197 In the first case the RQA is directly designated by a CA to act as an 198 RQA, by having the CA issue a certificate to the RQA with a specific 199 value set in the extendedKeyUsage extension. In this case the RQA 200 provides authoritative responses for requests regarding the CA that 201 issued the RQA's certificate. 203 When operating as a PTA, the RQA may provide responses about multiple 204 CAs, without the need to have been directly certified by them. To 205 operate as such, a specific extension (prqpTrustedAuthority) should 206 be present in RQA's certificate and its value should be set to TRUE. 208 3.1. The Resource Query Authority (RQA) 210 The Resource Query Authority is the designated authority to act as 211 PRQP responder. The RQA's signing key needs not to be the same as 212 that of the CA that designated it. 214 The CA may designate an RQA by issuing a certificate containing a 215 unique value for the extendedKeyUsage in RQA's certificate. The RQA 216 may also act as a trusted responder. PRQP signing delegation SHALL 217 be designated by the inclusion of id-kp-PRQPSigning in the 218 extendedKeyUsage extension within the PRQP response signer's 219 certificate. 221 id-kp-PRQPSigning OBJECT IDENTIFIER ::= {id-kp 10} 223 When operating as a PTA, the RQA may provide responses about multiple 224 CAs, without the need to have been directly certified by them. To 225 operate as a PTA a specific extension (prqpTrustedAuthority) should 226 be present in RQA's certificate and its value should be set to TRUE. 228 prqpTrustedAuthority ::= BOOLEAN DEFAULT TRUE 230 We also define two new OIDs to identify the PRQP protocol and the PTA 231 extension as follows: 233 id-prqp OBJECT IDENTIFIER ::= { id-pkix 23 } 235 id-prqp-pta OBJECT IDENTIFIER ::= { id-prqp 1 } 237 3.2. PRQP Overview 239 The protocol encompasses the exchange of a single round of messages 240 between a client and an RQA: 242 1. the client requests a resource token by sending a request to the 243 RQA 245 2. the RQA replies by sending a response to the client 247 Upon receiving the response the client MUST verify the status error 248 returned in the response. If no error is present, the client MUST 249 verify the various fields contained in the ResourceResponseToken and 250 the validity of the associated digital signature (if present). A 251 nonce MAY be used to guarantee that the response is associated with a 252 specific request in order to avoid reply attacks. 254 The client also SHOULD check the validity period of the response. It 255 SHOULD NOT, in order to minimize the load on an RQA, request again 256 the location of the same resource within this interval to the same 257 RQA. 259 If the response is signed, the client SHOULD check the RQA's 260 certificate validity. 262 3.2.1. PRQP Request 264 A PRQP request contains the following data: 266 o protocol version 267 o nonce 269 o MaxResponse 271 o ResourceRequestToken 273 o Extensions 275 The ASN.1 syntax imports terms defined in [RFC4210]. For signature 276 calculation, the data to be signed is encoded by using the DER 277 format. ASN.1 EXPLICIT tagging is used as a default unless specified 278 otherwise. The terms imported from [RFC3280] are: Extensions, 279 Certificate, CertificateSerialNumber, SubjectPublicKeyInfo, Name, 280 AlgorithmIdentifier. 282 3.2.1.1. Request Syntax 284 The PRQP request syntax is as follows: 286 PRQPRequest ::= SEQUENCE { 287 requestData TBSReqData, 288 signature [0] EXPLICIT Signature OPTIONAL } 290 TBSReqData ::= SEQUENCE { 291 version INTEGER { v(1) }, 292 nonce INTEGER OPTIONAL, 293 -- very large number 294 maxRespEntries INTEGER OPTIONAL, 295 -- maximum number of accepted entries in 296 -- corresponding response 297 serviceToken ResourceRequestToken, 298 -- token identifying the requested service 299 extensions [0] IMPLICIT Extensions OPTIONAL } 301 The version field (currently v1) describes the version of the PRQP 302 request. The nonce field, if present, is an integer between 80 bits 303 and 256 bit in length. 305 The MaxResponse identifier is used to tell the RQA the maximum number 306 of ResourceResponseToken that presenting can include in the response. 308 The ResourceRequestToken is used to identify the requested services. 309 It carries information about the requested services. It contains a 310 CA identifier and optionally one or more service identifiers. 312 ResourceRequestToken ::= SEQUENCE { 313 ca CertIdentifier, 314 servicesList [0] SET OF ResourceIdentifier OPTIONAL } 316 The ca field is of type CertIdentifier. This is used to identify the 317 certificate of the CA whose services are requested. 319 The CertIdentifier syntax is as follows: 321 BasicCertIdentifier ::= SEQUENCE { 322 issuerNameHash OCTET STRING, 323 serialNumber CertificateSerialNumber } 325 ExtenderCertInfo ::= SEQUENCE { 326 certificateHash OCTET STRING, 327 subjectKeyHash OCTET STRING, 328 subjectKeyIdentifier [0] KeyIdentifier OPTIONAL, 329 issuerKeyIdentifier [1] KeyIdentifier OPTIONAL } 331 CertIdentifier ::= SEQUENCE { 332 hashAlgorithm AlgorithmIdentifier, 333 basicCertIdentifier BasicCertIdentifier, 334 extInfo [0] ExtendedCertInfo OPTIONAL, 335 caCertificate [1] Certificate OPTIONAL, 336 issuedCertificate [2] Certificate OPTIONAL } 338 The resourceList specifies the resources or services being requested. 340 ResourceIdentifier ::= SEQUENCE { 341 resourceId OBJECT IDENTIFIER, 342 version [0] INTEGER OPTIONAL 343 --- version of the protocol or data format (if applicable) } 345 The ResourceIdentifier is formed by an OID that identifies the 346 service or the data being requested (e.g. OCSP, LDAP, CRL, etc... ) 347 and an optional version number that may be used to better identify 348 the requested resource. All fields SHOULD be used whenever 349 applicable. 351 If one or more ResourceIdentifier are provided in the request, the 352 RQA should report back the location for each of the requested 353 services. If no ResourceIdentifier is present in the request, the 354 response should carry all the available service locations for the 355 specified CA (with respect to the MaxResponse and optional parameters 356 constrain). 358 The signature field is of type Signature and it is defined in 359 [RFC2560]: 361 Signature ::= SEQUENCE { 362 signatureAlgorithm AlgorithmIdentifier, 363 signature BIT STRING, 364 certs [0] EXPLICIT SEQUENCE OF Certificate 365 OPTIONAL } 367 Extensions can be used for future protocol enhancement. 369 3.2.2. PRQP Response 371 The PRQP response contains the following data: 373 o protocol version 375 o nonce 377 o status 379 o CA identifier 381 o ResourceResponseToken 383 o Extensions 385 3.2.2.1. Response Syntax 387 The response syntax is as follows: 389 PRQPResponse ::= SEQUENCE { 390 respData TBSRespData, 391 signature [0] EXPLICIT Signature OPTIONAL } 393 TBSRespData ::= SEQUENCE { 394 version INTEGER { v(1)}, 395 nonce INTEGER OPTIONAL, 396 -- as duplicated from the request 397 producedAt GeneralizedTime, 398 -- time when the response has been generated 399 nextUpdate [0] GeneralizedTime OPTIONAL, 400 -- time till when the response should be considered valid 401 pkiStatus PKIStatusInfo, 402 -- status of the response 403 caCertId CertIdentifier, 404 -- identifier of the CA certificate that issued the 405 -- targeted certificate 406 responseToken SEQUENCE OF ResourceResponseToken 407 OPTIONAL, 408 -- token carrying informations about 409 -- requested services 410 extensions [0] EXPLICIT Extensions OPTIONAL } 412 The version field (currently v1) describes the version of the used 413 PRQP response. The nonce, if present, binds the response to a 414 specific request. The usage of the nonce is meaningful only in 415 signed responses and its value must be copied directly from the 416 corresponding request. If not present in the request, the nonce MUST 417 be omitted. 419 The pkiStatus field is based on the definition of status in section 420 3.2.3 of [RFC4210]. However, to limit the complexity of the field, 421 the statusString field is of type UTF8String instead of PKIFreeText. 423 PKIStatusInfo ::= SEQUENCE { 424 status PKIStatus, 425 statusString [0] UTF8String OPTIONAL, 426 failInfo [1] PKIFailureInfo OPTIONAL } 428 If status has value zero, a responseToken MUST be present in the 429 response. When the status value is non zero, the responseToken MUST 430 be omitted and the reason code MUST be one of the values in 431 PKIStatus. 433 PKIStatus ::= INTEGER { 434 ok (0), 435 -- when the PKIStatus contains the value zero one or 436 more responseToken is present 437 badRequest (1), 438 -- the request is badly formatted 439 caNotPresent (2), 440 -- the requested CA is not present 441 systemFailure (3) 442 -- a system failure has occourred } 444 The signature field is of type Signature and it is defined in 445 [RFC2560]: 447 Signature ::= SEQUENCE { 448 signatureAlgorithm AlgorithmIdentifier, 449 signature BIT STRING, 450 certs [0] EXPLICIT SEQUENCE OF Certificate 451 OPTIONAL } 453 The responseToken carries information about the services requested by 454 the client. For each of the requested service, the RQA should 455 include a ResourceResponseToken which bears the OID of the service 456 and the corresponding URI. 458 The ResourceResponseToken syntax is described below: 460 ResourceInfo ::= SEQUENCE { 461 resourceUri IA5String, 462 --- resource locator 463 version [0] INTEGER OPTIONAL, 464 --- version of the protocol or data format (if applicable) 465 } 467 ResourceResponseToken ::= SEQUENCE { 468 serviceId OBJECT IDENTIFIER, 469 resourceLocator [0] EXPLICIT SEQUENCE OF ResourceInfo } 471 The serviceId field value is copied from the corresponding request 472 and it bears the OID of the service about which the client inquired. 473 We define the following OIDs that SHOULD be used to identify the 474 specified PKI services: 476 id-ad-prqp OBJECT IDENTIFIER ::= {id-ad 12 } 477 id-ad-prqp-ocsp OBJECT IDENTIFIER ::= {id-ad-prqp 1} 478 id-ad-prqp-caIssuers OBJECT IDENTIFIER ::= {id-ad-prqp 2} 479 id-ad-prqp-timestamping OBJECT IDENTIFIER ::= {id-ad-prqp 3} 480 id-ad-prqp-dvcs OBJECT IDENTIFIER ::= {id-ad-prqp 4} 481 id-ad-prqp-caRepository OBJECT IDENTIFIER ::= {id-ad-prqp 5} 482 id-ad-prqp-http-certs OBJECT IDENTIFIER ::= {id-ad-prqp 6} 483 --- HTTP certificate repository 484 id-ad-prqp-http-crls OBJECT IDENTIFIER ::= {id-ad-prqp 7} 485 --- HTTP CRL download URL 487 id-ad-prqp-xkmsGateway OBJECT IDENTIFIER ::= {id-ad-prqp 10} 488 --- XKMS Gateway 489 id-ad-prqp-cmsGateway OBJECT IDENTIFIER ::= {id-ad-prqp 11} 490 --- CMS Gateway 491 id-ad-prqp-scepGateway OBJECT IDENTIFIER ::= {id-ad-prqp 12} 492 --- SCEP Gateway 494 --- Certificate Policies 495 id-ad-prqp-certPolicy OBJECT IDENTIFIER ::= {id-ad-prqp 20} 496 --- Certificate Policy (CP) URL 497 id-ad-prqp-certPracticesStatement 498 OBJECT IDENTIFIER ::= {id-ad-prqp 21} 499 --- Certification Practices Statement (CPS) URL 501 --- Level Of Assurance 502 id-ad-prqp-certLOAPolicy OBJECT IDENTIFIER ::= {id-ad-prqp 25} 503 --- LOA Policy URL 504 id-ad-prqp-certLOALevel OBJECT IDENTIFIER ::= {id-ad-prqp 26} 505 --- Certificate LOA Modifier URL 507 --- HTTP (Browsers) based services 508 id-ad-prqp-httpRevokeCertificate 509 OBJECT IDENTIFIER ::= {id-ad-prqp 30} 510 --- HTTP Based Certificate Revocation Service 511 id-ad-prqp-httpRequestCertificate 512 OBJECT IDENTIFIER ::= {id-ad-prqp 31} 513 --- HTTP Based Certificate Request Service 514 id-ad-prqp-httpRenewCertificate 515 OBJECT IDENTIFIER ::= {id-ad-prqp 32} 516 --- HTTP Based Certificate Renewal Service 517 id-ad-prqp-httpSuspendCertificate 518 OBJECT IDENTIFIER ::= {id-ad-prqp 33} 519 --- Certificate Suspension Service 521 --- Webdav Services 522 id-ad-prqp-webdavCert OBJECT IDENTIFIER ::= {id-ad-prqp 40} 523 --- Webdav Certificate Validation 524 id-ad-prqp-webdavRev OBJECT IDENTIFIER ::= {id-ad-prqp 41} 525 --- Webdav Certificate Revocation 527 --- Grid Specific Services 528 id-ad-prqp-grid-accreditationBody 529 OBJECT IDENTIFIER ::= {id-ad-prqp 50} 530 --- CA Accreditation Body(s) 531 id-ad-prqp-grid-accreditationPolicy 532 OBJECT IDENTIFIER ::= {id-ad-prqp 51} 533 --- CA Accreditation Policy Document(s) 534 id-ad-prqp-grid-accreditationStatus 535 OBJECT IDENTIFIER ::= {id-ad-prqp 52} 536 --- CA Accreditation Status Document(s) 537 id-ad-prqp-grid-commonDistributionUpdate 538 OBJECT_IDENTIFIER ::= {id-ad-prqp 53} 539 --- Grid Distribution Package(s) 540 id-ad-prqp-grid-accreditedCACerts 541 OBJECT IDENTIFIER ::= {id-ad-prqp 54} 542 --- Certificates of Currently Accredited CAs 544 The producedAt and nextUpdate define the time-frame when the response 545 data is to be considered valid. Within the defined period, the 546 client SHOULD NOT request for the same service. Use of wider time- 547 frames values can help the RQA avoid duplication of requests from the 548 same client thus potentially lowering the load of the responder. 549 However, providing this data to a client does not ensure a lower 550 query rate, as a server cannot rely on clients to obey the advice 551 provided in the rersponse. 553 The resourceLocator bears access information for the service 554 identified by the serviceId. The name MUST be an absolute URL, and 555 it MUST follow the URL syntax and encoding rules specified in 556 [RFC4248] and [RFC4266]. The resourceLocator includes both a scheme 557 (e.g., HTTP or FTP) and a scheme specific part. The scheme specific 558 part is supposed to carry information on how to reach the requested 559 service, this is, for example, a fully qualified domain name or IP 560 address as the host. If the requested service is not available or it 561 is unknown by the server, the resourceLocator value should be empty. 563 Optional Extensions may be added if requested. 565 3.3. IANA Considerations 567 This document has no actions for IANA. 569 4. PRQP Design Rationale 571 In this section we provide some considerations about the protocol 572 design and its details. 574 4.1. Response Complexity 576 An important design consideration is the complexity of messages. 577 Some type of services, e.g. delta CRLs, can be directly detected upon 578 data downloading. On the contrary if a client is looking for a 579 specific version of a protocol or data type, the definition of a 580 fine-grained query system would allow for data downloading only when 581 it is actually supported by the requesting client, thus reducing the 582 server's load. 584 At present we think that keeping the protocol simple will encourage 585 its adoption in current environments because the flexibility 586 introduced by PRQP is a big enhancement over the current options. 588 Moreover, without requiring changes to the protocol, extensions could 589 be defined to provide more fine grained options. 591 Future versions of the protocol may implement extended request and 592 response types if required by applications. 594 4.2. RQA's URL distribution 596 The AIA and SIA extensions in certificates can be used to carry the 597 pointer to the RQA. If no RQA address is present in the certificate, 598 a client application could use a default configured URL. 600 Although this approach seems to contraddict the criticism of 601 Certificate extensions use in Section 2.1.1, using only one extension 602 to locate the RQA would provide an easy way to distribute the RQA's 603 URL. 605 The usage of PRQP will provide a gateway for all the other services 606 and data URLs. 608 4.3. Security Considerations 610 The PRQP provides URLs for PKI resources. This means that it 611 provides locators to data and services, not the data per se. It 612 still remains the client's job to access the provided URLs to gather 613 the needed data. 615 Both NONCEs and signatures are optional in order to provide 616 flexibility in how requests and responses are generated. 618 It is possible to provide pre-computed responses in case the NONCE is 619 not provided by the client. This allows the RQA to generate off-line 620 signatures for responses, an optimization used in OCSP. 622 Moreover if an authenticated secure channel is used at the transport 623 level between the client and the RQA (e.g. HTTPS or SFTP) signatures 624 in requests and responses can be safely omitted. 626 4.4. Time Validity 628 The time validity should reflect the frequency of updates in 629 configured URLs. An interesting aspect to be considered is how often 630 would users execute the protocol for a given set of data. 632 If the clients query the server often it could be a serious burden on 633 the server but, if executed rarely, clients would not be able to 634 discover changes in provided resources. 636 As described in more detail in Appendix A, the adoption of a validity 637 time frame for responses can be used as a mean to balance the trade 638 off between this two aspects, but this is merely advisory data for 639 clients and thus not a guarantee against DoS attacks by clients. 641 4.5. Message Format 643 Two different candidates have been considered. The first one is the 644 Extensible Markup Language (XML), while the second one is the 645 Distinguished Encoding Rules (DER). 647 The adoption of the Abstract Syntax Notation (ASN.1) to describe the 648 data structures allows a software developer to provide either DER or 649 XML based implementations of the protocol. 651 However we think that a DER based implementation of PRQP is the best 652 choice because of compatibility considerations with existing 653 applications and APIs. Moreover DER encoded messages are smaller in 654 size then XML encoded ones and almost all PKI aware applications 655 already support it. 657 5. Acknowledgments 659 The authors would like to thank Stephen Kent for his insightful 660 comments about PRQP and his help in writing this document. 662 6. References 664 6.1. Normative References 666 [RFC1035] Mockapetris, P., "Domain names - implementation and 667 specification", STD 13, RFC 1035, November 1987. 669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 670 Requirement Levels", BCP 14, RFC 2119, March 1997. 672 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 673 Adams, "X.509 Internet Public Key Infrastructure Online 674 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 676 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 677 "Service Location Protocol, Version 2", RFC 2608, 678 June 1999. 680 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 681 and Service: Schemes", RFC 2609, June 1999. 683 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 684 specifying the location of services (DNS SRV)", RFC 2782, 685 February 2000. 687 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 688 X.509 Public Key Infrastructure Certificate and 689 Certificate Revocation List (CRL) Profile", RFC 3280, 690 April 2002. 692 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 693 "Internet X.509 Public Key Infrastructure Certificate 694 Management Protocol (CMP)", RFC 4210, September 2005. 696 [RFC4248] Hoffman, P., "The telnet URI Scheme", RFC 4248, 697 October 2005. 699 [RFC4266] Hoffman, P., "The gopher URI Scheme", RFC 4266, 700 November 2005. 702 6.2. Non-Normative References 704 [PEACH] Pala, M. and S. Smith, "Peaches and Peers", LNCS 5057, 705 June 2008. 707 Appendix A. Distribution of PRQP Responses 709 A.1. PRQP over HTTP 711 This section describes the formatting needed in order to route PRQP 712 request and response over HTTP. 714 A.1.1. Request 716 HTTP based PRQP requests SHOULD use the POST method to submit their 717 requests. Where privacy is a requirement, PRQP transactions 718 exchanged using HTTP MAY be protected using either TLS/SSL or some 719 other lower layer protocol. 721 The required HTTP headers for the request are: 723 o Content-Type 725 o Content-Transfer-Encoding 727 o Content-Length 729 The Content-Type header SHOULD be set to "application/prqp-request". 730 The Content-Transfer-Encoding SHOULD be set to "Binary", while the 731 Content-Length SHOULD be set to the length (in bytes) of the body of 732 the request. The body of the HTTP message MUST carry the binary 733 value of the DER encoding of the PRQPRequest. 735 A.1.2. Response 737 An HTTP-based PRQP response is composed of the appropriate HTTP 738 headers, followed by the binary value of the DER encoding of the 739 PRQPPResponse. 741 The required HTTP headers for the response are: 743 o Content-Type 745 o Content-Transfer-Encoding 747 o Content-Length 749 The Content-Type header SHOULD be set to "application/prqp-response". 750 The Content-Transfer-Encoding SHOULD be set to "Binary", while the 751 Content-Length SHOULD be set to the length (in bytes) of the body of 752 the request. The body of the HTTP message MUST carry the binary 753 value of the DER encoding of the PRQPResponse. 755 A.1.3. Message Caching 757 To minimize bandwidth usage, clients MUST locally cache authoritative 758 PRQP responses for the validity period of the request. To enable 759 proxy servers to be able to cache responses as well, additional HTTP 760 headers MAY be used in the response. 762 The PRQP responder MAY ease caching by setting the following headers: 764 o date 766 o last-modified 768 o expires 770 In particular, the date field SHOULD carry the date at which the HTTP 771 response has been generated. The last-modified, instead, SHOULD bear 772 the date at which the response has been modified. This field SHOULD 773 carry the same date as the producedAt field of the PRQPResponse. The 774 expires field SHOULD carry the date till when the response is to be 775 considered valid. This field SHOULD carry the same date as in the 776 nextUpdate field of the PRQPResponse. 778 An example HTTP response would look like: 780 HTTP/1.0 200 OK 781 Content-Type: application/prqp-response 782 Content-Transfer-Encoding: Binary 783 Content-Length: 860 784 Date: Thu, 03 May 2007 04:43:43 GMT 785 Last-Modified: Thu, 03 May 2007 04:43:42 GMT 786 Expires: Thu, 04 May 2007 04:43:42 GMT 788 <...response data...> 790 PRQP clients SUOULD NOT included a no-cache header in PRQP request 791 messages, unless the client encounters an expired response which may 792 be a result of an intermediate proxy caching stale data. 794 A.2. PRQP over Peer-to-Peer Network 796 PRQP offers a starting point for the development of a PKI Resource 797 Discovery Architecture where different RQAs cooperate to access data 798 not locally available. 800 One technology that already provides good results in data sharing is 801 Peer-to-Peer (P2P) networking. 803 Signed PRQP requests and responses can be routed also on existing P2P 804 networks or a PRQP-specific network can be setup to provide a World 805 Wide PKI Resources Discovery Architecture (PRDA), the definition of 806 which is out of the scope of this document. An example of such an 807 architecture is PEACH [PEACH] 809 Appendix B. PRQP ASN1.1 Specification 811 PRQP DEFINITIONS EXPLICIT TAGS ::= 813 BEGIN 815 -- EXPORTS ALL -- 817 IMPORTS 819 -- Directory Authentication Framework (X.509) 820 Certificate, AlgorithmIdentifier 821 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 822 module(1) authenticationFramework(7) 3 } 824 -- PKIX Certificate Extensions 825 AuthorityKeyIdentifier, SubjectKeyIdentifier, KeyIdentifier, 826 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 827 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 828 id-mod(0) id-pkix1-implicit-88(2)} 830 CertificateSerialNumber, Extensions, id-kp, id-ad-prqp 831 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 832 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 833 id-mod(0) id-pkix1-explicit-88(1)}; 835 PRQPRequest ::= SEQUENCE { 836 requestData TBSReqData, 837 signature [0] EXPLICIT Signature OPTIONAL } 839 TBSReqData ::= SEQUENCE { 840 version INTEGER { v(1) }, 841 nonce INTEGER OPTIONAL, 842 -- very large number 843 maxRespEntries INTEGER OPTIONAL, 844 -- maximum number of accepted entries in 845 -- corresponding response 846 serviceToken ResourceRequestToken, 847 -- token identifying the requested service 848 extensions [0] IMPLICIT Extensions OPTIONAL } 850 ResourceRequestToken ::= SEQUENCE { 851 ca CertIdentifier, 852 servicesList [0] SET OF ResourceIdentifier OPTIONAL } 854 BasicCertIdentifier ::= SEQUENCE { 855 issuerNameHash OCTET STRING, 856 serialNumber CertificateSerialNumber } 858 ExtenderCertInfo ::= SEQUENCE { 859 certificateHash OCTET STRING, 860 subjectKeyHash OCTET STRING, 861 subjectKeyIdentifier [0] KeyIdentifier OPTIONAL, 862 issuerKeyIdentifier [1] KeyIdentifier OPTIONAL } 864 CertIdentifier ::= SEQUENCE { 865 hashAlgorithm AlgorithmIdentifier, 866 basicCertIdentifier BasicCertIdentifier, 867 extInfo [0] ExtendedCertInfo OPTIONAL, 868 caCertificate [1] Certificate OPTIONAL, 869 issuedCertificate [2] Certificate OPTIONAL } 871 ResourceIdentifier ::= SEQUENCE { 872 resourceId OBJECT IDENTIFIER, 873 version [0] INTEGER OPTIONAL 874 --- version of the protocol or data format (if applicable) } 876 PRQPResponse ::= SEQUENCE { 877 respData TBSRespData, 878 signature [0] EXPLICIT Signature OPTIONAL } 880 TBSRespData ::= SEQUENCE { 881 version INTEGER { v(1)}, 882 nonce INTEGER OPTIONAL, 883 -- as duplicated from the request 884 producedAt GeneralizedTime, 885 -- time when the response has been generated 886 nextUpdate [0] GeneralizedTime OPTIONAL, 887 -- time till when the response should be considered 888 -- valid 889 pkiStatus PKIStatusInfo, 890 -- status of the response 891 caCertId CertIdentifier, 892 -- identifier of the CA the targeted certificate is 893 -- issued from 894 responseToken SEQUENCE OF ResourceResponseToken 895 OPTIONAL, 896 -- token carrying informations about 897 -- requested services 898 extensions [0] EXPLICIT Extensions OPTIONAL } 900 PKIStatusInfo ::= SEQUENCE { 901 status PKIStatus, 902 statusString [0] UTF8String OPTIONAL, 903 failInfo [1] PKIFailureInfo OPTIONAL } 905 PKIStatus ::= INTEGER { 906 ok (0), 907 -- when the PKIStatus contains the value zero one or 908 more responseToken is present 909 badRequest (1), 910 -- the request is badly formatted 911 caNotPresent (2), 912 -- the requested CA is not present 913 systemFailure (3) 914 -- a system failure has occourred } 916 Signature ::= SEQUENCE { 917 signatureAlgorithm AlgorithmIdentifier, 918 signature BIT STRING, 919 certs [0] EXPLICIT SEQUENCE OF Certificate 920 OPTIONAL } 922 ResourceInfo ::= SEQUENCE { 923 resourceUri IA5String, 924 --- resource locator 925 version [0] INTEGER OPTIONAL, 926 --- version of the protocol or data format (if applicable)} 928 ResourceResponseToken ::= SEQUENCE { 929 serviceId OBJECT IDENTIFIER, 930 resourceLocator [0] EXPLICIT SEQUENCE OF ResourceInfo } 932 -- Object Identifiers 934 id-kp-PRQPSigning OBJECT IDENTIFIER ::= { id-kp 10 } 935 id-prqp OBJECT IDENTIFIER ::= { id-pkix 23 } 936 id-prqp-pta OBJECT IDENTIFIER ::= { id-prqp 1 } 938 id-ad-prqp OBJECT IDENTIFIER ::= {id-ad 12 } 939 id-ad-prqp-ocsp OBJECT IDENTIFIER ::= {id-ad-prqp 1} 940 id-ad-prqp-caIssuers OBJECT IDENTIFIER ::= {id-ad-prqp 2} 941 id-ad-prqp-timestamping OBJECT IDENTIFIER ::= {id-ad-prqp 3} 942 id-ad-prqp-dvcs OBJECT IDENTIFIER ::= {id-ad-prqp 4} 943 id-ad-prqp-caRepository OBJECT IDENTIFIER ::= {id-ad-prqp 5} 944 id-ad-prqp-http-certs OBJECT IDENTIFIER ::= {id-ad-prqp 6} 945 --- HTTP certificate repository 946 id-ad-prqp-http-crls OBJECT IDENTIFIER ::= {id-ad-prqp 7} 947 --- HTTP CRL download URL 949 id-ad-prqp-xkmsGateway OBJECT IDENTIFIER ::= {id-ad-prqp 10} 950 --- XKMS Gateway 951 id-ad-prqp-cmsGateway OBJECT IDENTIFIER ::= {id-ad-prqp 11} 952 --- CMS Gateway 953 id-ad-prqp-scepGateway OBJECT IDENTIFIER ::= {id-ad-prqp 12} 954 --- SCEP Gateway 956 --- Certificate Policies 957 id-ad-prqp-certPolicy OBJECT IDENTIFIER ::= {id-ad-prqp 20} 958 --- Certificate Policy (CP) URL 959 id-ad-prqp-certPracticesStatement 960 OBJECT IDENTIFIER ::= {id-ad-prqp 21} 961 --- Certification Practices Statement (CPS) URL 963 --- Level Of Assurance 964 id-ad-prqp-certLOAPolicy OBJECT IDENTIFIER ::= {id-ad-prqp 25} 965 --- LOA Policy URL 966 id-ad-prqp-certLOALevel OBJECT IDENTIFIER ::= {id-ad-prqp 26} 967 --- Certificate LOA Modifier URL 969 --- HTTP (Browsers) based services 970 id-ad-prqp-httpRevokeCertificate 971 OBJECT IDENTIFIER ::= {id-ad-prqp 30} 972 --- HTTP Based Certificate Revocation Service 973 id-ad-prqp-httpRequestCertificate 974 OBJECT IDENTIFIER ::= {id-ad-prqp 31} 975 --- HTTP Based Certificate Request Service 976 id-ad-prqp-httpRenewCertificate 977 OBJECT IDENTIFIER ::= {id-ad-prqp 32} 978 --- HTTP Based Certificate Renewal Service 979 id-ad-prqp-httpSuspendCertificate 980 OBJECT IDENTIFIER ::= {id-ad-prqp 33} 981 --- Certificate Suspension Service 983 --- Webdav Services 984 id-ad-prqp-webdavCert OBJECT IDENTIFIER ::= {id-ad-prqp 40} 985 --- Webdav Certificate Validation 986 id-ad-prqp-webdavRev OBJECT IDENTIFIER ::= {id-ad-prqp 41} 987 --- Webdav Certificate Revocation 989 --- Grid Specific Services 990 id-ad-prqp-grid-accreditationBody 991 OBJECT IDENTIFIER ::= {id-ad-prqp 50} 992 --- CA Accreditation Body(s) 993 id-ad-prqp-grid-accreditationPolicy 994 OBJECT IDENTIFIER ::= {id-ad-prqp 51} 995 --- CA Accreditation Policy Document(s) 996 id-ad-prqp-grid-accreditationStatus 997 OBJECT IDENTIFIER ::= {id-ad-prqp 52} 998 --- CA Accreditation Status Document(s) 999 id-ad-prqp-grid-commonDistributionUpdate 1000 OBJECT_IDENTIFIER ::= {id-ad-prqp 53} 1001 --- Grid Distribution Package(s) 1002 id-ad-prqp-grid-accreditedCACerts 1003 OBJECT IDENTIFIER ::= {id-ad-prqp 54} 1004 --- Certificates of Currently Accredited CAs 1006 Author's Address 1008 Massimiliano Pala 1009 Dartmouth College 1010 6211 Sudikoff PKI/Trust Lab 1011 Hanover, NH 03755 1012 US 1014 Email: pala@cs.dartmouth.edu 1015 URI: http://www.openca.org 1017 Full Copyright Statement 1019 Copyright (C) The IETF Trust (2008). 1021 This document is subject to the rights, licenses and restrictions 1022 contained in BCP 78, and except as set forth therein, the authors 1023 retain all their rights. 1025 This document and the information contained herein are provided on an 1026 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1027 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1028 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1029 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1030 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1031 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1033 Intellectual Property 1035 The IETF takes no position regarding the validity or scope of any 1036 Intellectual Property Rights or other rights that might be claimed to 1037 pertain to the implementation or use of the technology described in 1038 this document or the extent to which any license under such rights 1039 might or might not be available; nor does it represent that it has 1040 made any independent effort to identify any such rights. Information 1041 on the procedures with respect to rights in RFC documents can be 1042 found in BCP 78 and BCP 79. 1044 Copies of IPR disclosures made to the IETF Secretariat and any 1045 assurances of licenses to be made available, or the result of an 1046 attempt made to obtain a general license or permission for the use of 1047 such proprietary rights by implementers or users of this 1048 specification can be obtained from the IETF on-line IPR repository at 1049 http://www.ietf.org/ipr. 1051 The IETF invites any interested party to bring to its attention any 1052 copyrights, patents or patent applications, or other proprietary 1053 rights that may cover technology that may be required to implement 1054 this standard. Please address the information to the IETF at 1055 ietf-ipr@ietf.org.