idnits 2.17.1 draft-ietf-pkix-prqp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1462 has weird spacing: '...servers rqa....' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2009) is 5269 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 1676 -- Looks like a reference, but probably isn't: '1' on line 1678 -- Looks like a reference, but probably isn't: '2' on line 1680 -- Looks like a reference, but probably isn't: '3' on line 1683 == Unused Reference: 'RFC2797' is defined on line 1204, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 1217, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-dhc-option-guidelines-03 ** Obsolete normative reference: RFC 2527 (Obsoleted by RFC 3647) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2797 (Obsoleted by RFC 5272) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-23) exists of draft-nourse-scep-17 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 6 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 November 16, 2009 5 Expires: May 20, 2010 7 PKI Resource Query Protocol (PRQP) 8 draft-ietf-pkix-prqp-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on May 20, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 One of the most strategic problems still open in PKIX is locating 57 public data and services associated with a Certification Authority 58 (CA). This issue impacts interoperability and usability in PKIX. 60 This draft describes the PKI Resource Query Protocol (PRQP), its 61 design, definition, and its impact in already deployed PKIX 62 protocols. 64 Table of Contents 66 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Overview of existing solutions . . . . . . . . . . . . . . 4 69 2.1.1. Certificate Extensions . . . . . . . . . . . . . . . . 4 70 2.1.2. DNS SRV records . . . . . . . . . . . . . . . . . . . 5 71 2.1.3. Local Network Oriented Solutions . . . . . . . . . . . 5 72 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1. The Resource Query Authority (RQA) . . . . . . . . . . . . 6 74 3.2. PRQP Overview . . . . . . . . . . . . . . . . . . . . . . 7 75 3.2.1. PRQP Request . . . . . . . . . . . . . . . . . . . . . 7 76 3.2.1.1. Request Syntax . . . . . . . . . . . . . . . . . . 8 77 3.2.2. PRQP Response . . . . . . . . . . . . . . . . . . . . 10 78 3.2.2.1. Response Syntax . . . . . . . . . . . . . . . . . 10 79 4. Object Identifiers for PKI resources . . . . . . . . . . . . . 12 80 4.1. The RQA Service identifier . . . . . . . . . . . . . . . . 13 81 4.2. The OCSP identifier . . . . . . . . . . . . . . . . . . . 13 82 4.3. The Subject's Certificate identifier . . . . . . . . . . . 13 83 4.4. The Issuer's Certificate identifier . . . . . . . . . . . 14 84 4.5. The Timestamping Service identifier . . . . . . . . . . . 14 85 4.6. The SCVP Server identifier . . . . . . . . . . . . . . . . 15 86 4.7. The CRL Distribution Point identifier . . . . . . . . . . 15 87 4.8. The Certificates Repository identifier . . . . . . . . . . 15 88 4.9. The CRL Repository identifier . . . . . . . . . . . . . . 15 89 4.10. The Cross Certificates Repository identifier . . . . . . . 16 90 4.11. The CMC Gateway identifier . . . . . . . . . . . . . . . . 16 91 4.12. The CMP Gateway identifier . . . . . . . . . . . . . . . . 16 92 4.13. The SCEP Gateway identifier . . . . . . . . . . . . . . . 17 93 4.14. The HTML Gateway identifier . . . . . . . . . . . . . . . 17 94 4.15. The XKMS Gateway identifier . . . . . . . . . . . . . . . 17 95 4.16. The Certificate Policy (CP) identifier . . . . . . . . . . 17 96 4.17. The Certification Practice Statement (CPS) identifier . . 18 97 4.18. The Endorsed Trust Anchors identifier . . . . . . . . . . 18 98 4.19. The LOA Policy (LP) identifier . . . . . . . . . . . . . . 18 99 4.20. The Certificate LOA Modifier identifier . . . . . . . . . 19 100 4.21. The HTML Certificate Request Service identifier . . . . . 19 101 4.22. The HTML Certificate Revoke Service identifier . . . . . . 19 102 4.23. The HTML Certificate Renew Service identifier . . . . . . 20 103 4.24. The HTML Certificate Suspend Service identifier . . . . . 20 104 4.25. The HTML Certificate Recovery Service Identifier . . . . . 20 105 4.26. The Grid Accreditation Body identifier . . . . . . . . . . 20 106 4.27. The Grid Policy identifier . . . . . . . . . . . . . . . . 21 107 4.28. The Grid Distribution Update identifier . . . . . . . . . 21 108 4.29. The Grid Accredited CA Certificates identifier . . . . . . 21 109 4.30. The Apex Trust Anchor Update identifier . . . . . . . . . 22 110 4.31. The Trust Anchor Update identifier . . . . . . . . . . . . 22 111 4.32. The CA Incident Report identifier . . . . . . . . . . . . 22 112 4.33. The Private Resources identifier . . . . . . . . . . . . . 23 113 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 114 6. PRQP Design Rationale . . . . . . . . . . . . . . . . . . . . 23 115 6.1. Response Complexity . . . . . . . . . . . . . . . . . . . 23 116 6.2. RQA's URL distribution . . . . . . . . . . . . . . . . . . 24 117 6.3. Security Considerations . . . . . . . . . . . . . . . . . 24 118 6.4. Time Validity . . . . . . . . . . . . . . . . . . . . . . 24 119 6.5. Message Format . . . . . . . . . . . . . . . . . . . . . . 25 120 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 121 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 122 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 123 8.2. Non-Normative References . . . . . . . . . . . . . . . . . 27 124 Appendix A. Transport Protocol Specifications for PRQP 125 Messages . . . . . . . . . . . . . . . . . . . . . . 27 126 A.1. PRQP over HTTP . . . . . . . . . . . . . . . . . . . . . . 27 127 A.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 27 128 A.1.2. Response . . . . . . . . . . . . . . . . . . . . . . . 28 129 A.1.3. Message Caching . . . . . . . . . . . . . . . . . . . 28 130 A.2. PRQP over Peer-to-Peer Network . . . . . . . . . . . . . . 29 131 Appendix B. RQA address Retrieval . . . . . . . . . . . . . . . . 29 132 B.1. DHCP Specifications . . . . . . . . . . . . . . . . . . . 29 133 B.1.1. PRQP Servers IPv4 Option for DHCPv4 . . . . . . . . . 30 134 B.1.2. PRQP Servers IPv6 Option for DHCPv6 . . . . . . . . . 30 135 B.1.3. DHCP Configuration . . . . . . . . . . . . . . . . . . 31 136 B.1.4. DHCP Client Processing . . . . . . . . . . . . . . . . 32 137 B.2. DNS SRV Records . . . . . . . . . . . . . . . . . . . . . 32 138 B.2.1. SRV Record Format for PRQP . . . . . . . . . . . . . . 32 139 B.2.2. Example: PRQP enabled zone file . . . . . . . . . . . 33 140 Appendix C. PRQP ASN1.1 Specification . . . . . . . . . . . . . . 34 141 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 143 1. Requirements notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. Introduction 151 An increasing number of services and protocols are being defined to 152 address different needs of users and administrators of PKIs. With 153 the deployment of new applications and services, the need to access 154 information and services provided by Certificate Service Providers 155 (CSPs) is critical. Currently Certification Authorities (CAs) barely 156 publish access details on their official web sites, this includes URL 157 of provided services and repositories. 159 Using the PRQP, resources provided by a CA can be automatically and 160 securely discovered by an application. 162 2.1. Overview of existing solutions 164 Currently there are three options to find URLs providing access to 165 PKI data: 167 o by including such data in certificate extensions 169 o by searching easily accessible repositories (e.g. DNS, local 170 database, etc.) 172 o by adapting existing protocols (e.g. SLP) 174 2.1.1. Certificate Extensions 176 To provide pointers to published data it is possible to use the 177 Authority Information Access (AIA) Subject Information Access (SIA) 178 extensions defined by PKIX [RFC3280]. 180 The former can provide information about services associated with the 181 issuer of the certificate, while the latter carries information 182 (inside a CA certificate) about offered CA services. 184 AIA and SIA extensions are static, i.e. not modifiable unless the 185 certificate is re-issued. If a CA inserts the AIA extension into 186 every certificate it issues, e.g., to identify the location of an 187 OCSP responder, then changing that location would require re-issuance 188 of all these certificates, a substantial barrier to such a change. 189 If a CA certificate is self-signed and used as a trust anchor, then 190 re-issuing the certificate to change the content of the SIA 191 extension, e.g., to reflect a change in the location of a time 192 stamping server would be very disruptive. In closed PKIs, e.g., 193 enterprises, use of these extensions may be replaced by manual 194 configuration and management of this data via ad hoc means. Because 195 of the centrally controlled nature of such environments, the static 196 nature of SIA and AIA extensions is not a concern. 198 However in order to promote interoperability between PKIs, PRQP 199 enables dynamic management of pointers to such services (e.g., 200 adding/removing or moving) without requiring changes in the 201 certificate contents or third parties to manually configure services 202 in their applications. Even in closed environments, PRQP could help 203 manage PKI services analogous the way DHCP facilitates network 204 management. 206 2.1.2. DNS SRV records 208 The SRV record technique provides pointers to servers via the DNS 209 [RFC1035]. 211 As defined in [RFC2782], the introduction of this type of record 212 allows administrators to perform operations similar to what we 213 require in order to solve the problem we are addressing in this 214 draft, i.e., to provide URLs to services. 216 The problem in the adoption of this mechanism is that, in contrast to 217 the DNS environment, usually in PKIX there is no fixed mapping 218 between certificates and the DNS name space. The only exception is 219 when the Domain Component (DC) attributes are used in the 220 certificate's Subject. 222 Currently this approach is not widely adopted. Moreover, it is not 223 always easy to identify the right DNS to query to, when trying to 224 find a particular service provided by a CA, because of the lack of 225 such information in certificates. 227 2.1.3. Local Network Oriented Solutions 229 Another approach to provide reliable information is to use existing 230 protocols for service location such as Jini, Universal Plug and Play 231 protocol (UPnP) or Service Location Protocol (SLP) [RFC2608] 232 [RFC2609]. 234 The IETF defined the SLP to provide a service location mechanism that 235 is language and technology independent. Some issues, however, make 236 it not the right choice to solve our problem, e.g., the protocol is 237 quite complex to implement when considering the scope of the problem 238 we are addressing. 240 The definition of a specific and simple protocol for PKI service and 241 resource location is needed to ease PKI integration into existing and 242 future applications, especially for mobile devices which have limited 243 computational power and communication bandwidth. 245 3. Protocol Details 247 The PRQP protocol is a request-response protocol, formed by the 248 exchanging of two messages, i.e., a request and a response between a 249 client and a server, called the Resource Query Authority (RQA). 251 The requesting entity (the client) may be any entity that needs to 252 access information about repositories and services related to a 253 certificate. 255 The RQA is the authority entitled to answer for a particular CA or to 256 act as a PRQP Trusted Authority (PTA) for a set of users, e.g., users 257 in an enterprise environment. 259 In the first case the RQA is directly designated by a CA to act as an 260 RQA, by having the CA issue a certificate to the RQA with a specific 261 value set in the extendedKeyUsage extension. In this case the RQA 262 provides authoritative responses for requests regarding the CA that 263 issued the RQA's certificate. 265 When operating as a PTA, the RQA may provide responses about multiple 266 CAs, without the need to have been directly certified by them. To 267 operate as such, a specific extension (prqpTrustedAuthority) should 268 be present in RQA's certificate and its value should be set to TRUE. 270 3.1. The Resource Query Authority (RQA) 272 The Resource Query Authority is the designated authority to act as 273 PRQP responder. The RQA's signing key needs not to be the same as 274 that of the CA that designated it. 276 The CA may designate an RQA by issuing a certificate containing a 277 unique value for the extendedKeyUsage in RQA's certificate. The RQA 278 may also act as a trusted responder. PRQP signing delegation SHALL 279 be designated by the inclusion of id-kp-PRQPSigning in the 280 extendedKeyUsage extension within the PRQP response signer's 281 certificate. 283 id-kp-PRQPSigning OBJECT IDENTIFIER ::= {iso(1) identified- 284 organization(2) dod(6) internet(1) security(5) mechanisms(5) 285 pkix(7) kp(3) 11} 287 When operating as a PTA, the RQA may provide responses about multiple 288 CAs, without the need to have been directly certified by them. To 289 operate as a PTA a specific extension (prqpTrustedAuthority) should 290 be present in RQA's certificate and its value should be set to TRUE. 292 prqpTrustedAuthority ::= BOOLEAN DEFAULT TRUE 294 We also define two new OIDs to identify the PRQP protocol and the PTA 295 extension as follows: 297 id-prqp OBJECT IDENTIFIER ::= { id-pkix 23 } 299 id-prqp-pta OBJECT IDENTIFIER ::= { id-prqp 1 } 301 3.2. PRQP Overview 303 The protocol encompasses the exchange of a single round of messages 304 between a client and an RQA: 306 1. the client requests a resource token by sending a request to the 307 RQA 309 2. the RQA replies by sending a response to the client 311 Upon receiving the response the client MUST verify the status error 312 returned in the response. If no error is present, the client MUST 313 verify the various fields contained in the ResourceResponseToken and 314 the validity of the associated digital signature (if present). A 315 nonce MAY be used to guarantee that the response is associated with a 316 specific request in order to avoid reply attacks. 318 The client also SHOULD check the validity period of the response. It 319 SHOULD NOT, in order to minimize the load on an RQA, request again 320 the location of the same resource within this interval to the same 321 RQA. 323 If the response is signed, the client SHOULD check the RQA's 324 certificate validity. 326 3.2.1. PRQP Request 328 A PRQP request contains the following data: 330 o protocol version 332 o nonce 334 o MaxResponse 336 o ResourceRequestToken 338 o Extensions 340 The ASN.1 syntax imports terms defined in [RFC4210]. For signature 341 calculation, the data to be signed is encoded by using the DER 342 format. ASN.1 EXPLICIT tagging is used as a default unless specified 343 otherwise. The terms imported from [RFC3280] are: Extensions, 344 Certificate, CertificateSerialNumber, SubjectPublicKeyInfo, Name, 345 AlgorithmIdentifier. 347 3.2.1.1. Request Syntax 349 The PRQP request syntax is as follows: 351 PRQPRequest ::= SEQUENCE { 352 requestData TBSReqData, 353 signature [0] EXPLICIT Signature OPTIONAL } 355 TBSReqData ::= SEQUENCE { 356 version INTEGER { v(1) }, 357 nonce [0] INTEGER OPTIONAL, 358 -- very large number 359 producedAt GeneralizedTime, 360 -- time when the request has been generated 361 serviceToken ResourceRequestToken, 362 -- token identifying the requested service 363 extensions [1] IMPLICIT Extensions OPTIONAL } 365 The version field (currently v1) describes the version of the PRQP 366 request. The nonce field, if present, is an integer between 80 bits 367 and 256 bit in length. The producedAt define the time-frame when the 368 request has been generated. 370 ResourceRequestToken ::= SEQUENCE { 371 ca CertIdentifier, 372 servicesList [0] SET OF ResourceIdentifier OPTIONAL } 374 The ca field is of type CertIdentifier. This is used to identify the 375 certificate of the CA whose services are requested. 377 The CertIdentifier syntax is as follows: 379 BasicCertIdentifier ::= SEQUENCE { 380 issuerNameHash OCTET STRING, 381 serialNumber CertificateSerialNumber } 383 ExtendedCertInfo ::= SEQUENCE { 384 certificateHash OCTET STRING, 385 subjectKeyHash OCTET STRING, 386 subjectKeyIdentifier [0] KeyIdentifier OPTIONAL, 387 issuerKeyIdentifier [1] KeyIdentifier OPTIONAL } 389 CertIdentifier ::= SEQUENCE { 390 hashAlgorithm AlgorithmIdentifier, 391 basicCertIdentifier BasicCertIdentifier, 392 extInfo [0] ExtendedCertInfo OPTIONAL, 393 caCertificate [1] Certificate OPTIONAL, 394 issuedCertificate [2] Certificate OPTIONAL } 396 The resourceList specifies the resources or services being requested. 398 ResourceIdentifier ::= SEQUENCE { 399 resourceId OBJECT IDENTIFIER, 400 version [0] INTEGER OPTIONAL 401 --- version of the protocol or data format (if applicable) 402 oid [1] OBJECT IDENTIFIER OPTIONAL, 403 --- object identifier associated with the URL 404 --- (if applicable) } 406 The ResourceIdentifier is formed by an OID that identifies the 407 service or the data being requested (e.g. OCSP, LDAP, CRL, etc... ) 408 and an optional version number that may be used to better identify 409 the requested resource. All fields SHOULD be used whenever 410 applicable. 412 If one or more ResourceIdentifier are provided in the request, the 413 RQA should report back the location for each of the requested 414 services. If no ResourceIdentifier is present in the request, the 415 response should carry all the available service locations for the 416 specified CA (with respect to the MaxResponse and optional parameters 417 constrain). 419 The signature field is of type Signature and it is defined in 420 [RFC2560]: 422 Signature ::= SEQUENCE { 423 signatureAlgorithm AlgorithmIdentifier, 424 signature BIT STRING, 425 certs [0] EXPLICIT SEQUENCE OF Certificate 426 OPTIONAL } 428 Extensions can be used for future protocol enhancement. 430 3.2.2. PRQP Response 432 The PRQP response contains the following data: 434 o protocol version 436 o nonce 438 o status 440 o CA identifier 442 o ResourceResponseToken 444 o Extensions 446 3.2.2.1. Response Syntax 448 The response syntax is as follows: 450 PRQPResponse ::= SEQUENCE { 451 respData TBSRespData, 452 signature [0] EXPLICIT Signature OPTIONAL } 454 TBSRespData ::= SEQUENCE { 455 version INTEGER { v(1)}, 456 nonce [0] INTEGER OPTIONAL, 457 -- as duplicated from the request 458 producedAt GeneralizedTime, 459 -- time when the response has been generated 460 nextUpdate [1] GeneralizedTime OPTIONAL, 461 -- time till when the response should be considered valid 462 pkiStatus PKIStatusInfo, 463 -- status of the response 464 caCertId CertIdentifier, 465 -- identifier of the CA certificate that issued the 466 -- targeted certificate 467 responseToken [2] SEQUENCE OF ResourceResponseToken 468 OPTIONAL, 469 -- token carrying information about 470 -- requested services 471 extensions [3] EXPLICIT Extensions OPTIONAL } 473 The version field (currently v1) describes the version of the used 474 PRQP response. The nonce, if present, binds the response to a 475 specific request. The usage of the nonce is meaningful only in 476 signed responses and its value must be copied directly from the 477 corresponding request. If not present in the request, the nonce MUST 478 be omitted. 480 The pkiStatus field is used to return useful information to the 481 client on the status of the query. 483 PKIStatusInfo ::= SEQUENCE { 484 status PKIStatus, 485 statusString [0] UTF8String OPTIONAL, 486 failInfo [1] PKIFailureInfo OPTIONAL, 487 referrals [2] EXPLICIT SEQUENCE OF IA5String 488 OPTIONAL } 490 If status has value zero, a responseToken MUST be present in the 491 response. When the status value is non zero, the responseToken MUST 492 be omitted and the reason code MUST be one of the values in 493 PKIStatus. When the PKIStatus value is set to caNotPresent (2) or 494 sytemFailure (3), a list referral URLs MAY be included in the 495 response to facilitate the client in finding the required resource 496 from other known servers. 498 PKIStatus ::= INTEGER { 499 ok (0), 500 -- when the PKIStatus contains the value zero one or 501 more responseToken is present 502 badRequest (1), 503 -- the request is badly formatted 504 caNotPresent (2), 505 -- the requested CA is not present 506 systemFailure (3) 507 -- a system failure has occurred } 509 The signature field is of type Signature and it is defined in 510 [RFC2560]: 512 Signature ::= SEQUENCE { 513 signatureAlgorithm AlgorithmIdentifier, 514 signature BIT STRING, 515 certs [0] EXPLICIT SEQUENCE OF Certificate 516 OPTIONAL } 518 The responseToken carries information about the services requested by 519 the client. For each of the requested service, the RQA should 520 include a ResourceResponseToken which bears the OID of the service 521 and the corresponding URI. 523 The ResourceResponseToken syntax is described below: 525 ResourceResponseToken ::= SEQUENCE { 526 resourceId OBJECT IDENTIFIER, 527 --- resource identifier 528 resourceLocatorList [0] EXPLICIT SEQUENCE OF IA5String, 529 --- sequence of resource locators (URI) 530 version [1] INTEGER OPTIONAL, 531 --- version of the protocol or data format (if applicable) 532 oid [2] OBJECT IDENTIFIER OPTIONAL, 533 --- object identifier associated with the URL 534 --- (if applicable) 535 resourceInfo [3] UTF8Sting OPTIONAL, 536 --- additional service Info (eg. technical contacts) } 538 The resourceId field value is copied from the corresponding request 539 and it bears the OID of the service about which the client inquired. 540 In section Section 4 we define a list of default PKI resources. 542 The producedAt and nextUpdate define the time-frame when the response 543 data is to be considered valid. Within the defined period, the 544 client SHOULD NOT request for the same service. Use of wider time- 545 frames values can help the RQA avoid duplication of requests from the 546 same client thus potentially lowering the load of the responder. 547 However, providing this data to a client does not ensure a lower 548 query rate, as a server cannot rely on clients to obey the advice 549 provided in the response. 551 The resourceLocator bears access information for the service 552 identified by the serviceId. The name MUST be an absolute URL, and 553 it MUST follow the URL syntax and encoding rules specified in 554 [RFC4248] and [RFC4266]. The resourceLocator includes both a scheme 555 (e.g., HTTP or FTP) and a scheme specific part. The scheme specific 556 part is supposed to carry information on how to reach the requested 557 service, this is, for example, a fully qualified domain name or IP 558 address as the host. If the requested service is not available or it 559 is unknown by the server, the resourceLocator value should be empty. 561 Optional Extensions may be added if requested. 563 4. Object Identifiers for PKI resources 565 The PRQP defines a set of standard OIDs that are used to identify 566 resources related to a Certification Authority. In this section we 567 provide a description for each of the defined OIDs. 569 The services are all defined under the id-ad-prqp OID which is 570 defined as follows: 572 id-ad-prqp OBJECT IDENTIFIER ::= {id-ad 12} 574 4.1. The RQA Service identifier 576 When id-ad-prqp-rqa is used in a PRQP message, the associated value 577 in the response is the location of the PRQP server (i.e., an RQA) 578 using the conventions in this document or subsequent updates. 580 id-ad-prqp-rqa OBJECT IDENTIFIER ::= {id-ad-prqp 0} 582 The version field, if used, indicates the supported PRQP protocol 583 version. 585 4.2. The OCSP identifier 587 When id-ad-prqp-ocsp appears in a PRQP request or response, the 588 associated value in the response is the location of the OCSP 589 responder, using the conventions defined in [RFC2560]. The version 590 field, if used, indicates the supported protocol version. 592 id-ad-prqp-ocsp OBJECT IDENTIFIER ::= {id-ad-prqp 1 } 594 4.3. The Subject's Certificate identifier 596 When id-ad-subjectCert is used in a PRQP message, the associated 597 value in the response is the location of the DER formatted 598 certificate of the identified CA. The version field MAY be used to 599 specify the version of the certificate pointed by the URL in a PRQP 600 Response message. In order to enhance interoperability between 601 applications and reduce development efforts, the URI should point 602 directly to the certificate and not to a redirection service. 604 id-ad-prqp-subjectCert OBJECT IDENTIFIER ::= {id-ad-prqp 2 } 606 HTTP server implementations accessed via the URI SHOULD specify the 607 media type "application/x-x509-ca-cert" in the content-type header 608 field of the response. 610 This field allows applications to check for renewal of CA 611 certificates. When the application wants to check if a new version 612 of the identified certificate exists, it can use this service and 613 download the certificate from the URL. If the downloaded certificate 614 differs from the one already possesed by the client, two different 615 cases are possible: 617 1. The current certificate is not self-signed: in this case, the 618 checks on the new certificate follow the rules specified in 619 [RFC5280]. The new certificate can be safely added to the 620 application's store (but not added to the list of Trusted 621 Certificates or Trust Anchors) if it has been issued by the same 622 issuer of the identified CA certificate. 624 2. The current certificate is self-signed: in this case, to avoid 625 trust issues, the application should trust the pointed 626 certificate only if the certificate has the same public key as 627 the old one AND it is self signed (this provides proof of 628 possession of the same private key). 630 For more complex trust anchor operations, please refer to 631 Section 4.18, Section 4.30 or Section 4.31. 633 4.4. The Issuer's Certificate identifier 635 When id-ad-issuerCert is used in a PRQP message, the associated value 636 is in the response the location of the DER formatted certificate of 637 the issuer of the identified CA. The version field MAY be used to 638 specify the version of the certificate pointed by the URL in a PRQP 639 Response message. In order to enhance interoperability between 640 applications and reduce development efforts, the URI should point 641 directly to the certificate and not to a redirection service. 643 id-ad-prqp-issuerCert OBJECT IDENTIFIER ::= {id-ad-prqp 3 } 645 HTTP server implementations accessed via the URI SHOULD specify the 646 media type "application/x-x509-ca-cert" in the content-type header 647 field of the response. 649 The content of this service is the same as the content of caIssuers 650 when the provided URI refers to the CA Issuer's certificate 651 [RFC5280]. This field allows applications to dynamically download 652 and build validation paths and may be extremely useful when cross 653 certificates are used (eg., in bridge CAs). 655 4.5. The Timestamping Service identifier 657 When id-ad-timestamping is used in a PRQP message, the associated 658 value in the response is the location of the Timestamping responder, 659 using the conventions defined in [RFC3161]. The version field, if 660 used, indicates the supported protocol version. 662 id-ad-prqp-timestamping OBJECT IDENTIFIER ::= {id-ad-prqp 4 } 664 4.6. The SCVP Server identifier 666 When id-ad-prqp-scvp appears in a PRQP request or response, the 667 associated value in the response is the location of the SCVP 668 responder, using the conventions defined in [RFC5055]. The version 669 field, if used, indicates the supported protocol version. 671 id-ad-prqp-scvp OBJECT IDENTIFIER ::= {id-ad-prqp 5 } 673 4.7. The CRL Distribution Point identifier 675 When id-ad-prqp-crlDistribution appears in a PRQP message, the 676 associated value in the response is a pointer to the current CRL. 677 The URI MUST point to a single DER encoded CRL as specified in 678 [RFC2585]. The version field, if used, indicates the version of the 679 pointed CRL. In order to enhance interoperability between 680 applications and reduce development efforts, the URI should point 681 directly to the CRL and not to a redirection service. 683 id-ad-prqp-crlDistribution OBJECT IDENTIFIER ::= {id-ad-prqp 6 } 685 HTTP server implementations accessed via the URI SHOULD specify the 686 media type "application/pkix-crl" in the content-type header field of 687 the response. 689 4.8. The Certificates Repository identifier 691 When id-ad-prqp-certRepository appears in a PRQP message, the 692 associated value in the response is a pointer to a set of 693 certificates. The URI MUST point to a collection of certificates in 694 a DER encoded "certs-only" CMS message as specified in [RFC5272]. 696 id-ad-prqp-certRepository OBJECT IDENTIFIER ::= {id-ad-prqp 7 } 698 HTTP server implementations accessed via the URI SHOULD specify the 699 media type "application/pkcs7-mime" [RFC5272] in the content-type 700 header field of the response. The name of the returned file SHOULD 701 have a suffix of ".p7c" [RFC5272]. 703 4.9. The CRL Repository identifier 705 When id-ad-prqp-crlRepository appears in a PRQP message, the 706 associated value is a pointer to a set of CRL. The URI MUST point to 707 a collection of CRLs in a DER encoded CMS message. The type of 708 message should be a Simple PKI Response where the CRLs are placed in 709 the CRL bag. 711 id-ad-prqp-crlRepository OBJECT IDENTIFIER ::= {id-ad-prqp 8 } 713 HTTP server implementations accessed via the URI SHOULD specify the 714 media type "application/pkcs7-mime" [RFC5272] in the content-type 715 header field of the response. The name of the returned file SHOULD 716 have a suffix of ".p7c" 718 4.10. The Cross Certificates Repository identifier 720 When id-ad-prqp-crossCertRepository appears in a PRQP message, the 721 associated value in the response is a pointer to a set of Cross 722 Certificates. The URI MUST point to a collection of certificates in 723 DER encoded CertificatePair object defined as: 725 CertificatePair ::= SEQUENCE { 726 forward [0] Certificate OPTIONAL, 727 reverse [1] Certificate OPTIONAL, 728 -- at least one of the pair shall be present -- } 730 The id-ad-prqp-crossCertRepository is defined as follows: 732 id-ad-prqp-crossCertRepository 733 OBJECT IDENTIFIER ::= {id-ad-prqp 9 } 735 As defined in [RFC4523], LDAP implementation store the 736 CertificatePair in the crossCertificatePair attribute. 738 4.11. The CMC Gateway identifier 740 When id-ad-prqp-cmcGateway appears in a PRQP message, the associated 741 value in the response is the location of the CMM over CMS service, 742 using the conventions defined in [RFC5272]. As the [RFC5272] does 743 not define a version for the protocol, if the version field is used 744 to identify the service, applications SHOULD ignore it. 746 id-ad-prqp-cmcGateway OBJECT IDENTIFIER ::= {id-ad-prqp 10 } 748 4.12. The CMP Gateway identifier 750 When id-ad-prqp-cmpGateway appears in a PRQP message, the associated 751 value in the response is the location of the CMP over CMS service, 752 using the conventions defined in [RFC4210]. As the [RFC4210] defines 753 the protocol version in the pvno field of PKIHeader, the version 754 field MAY be used to to identify the required/supported service 755 version. 757 id-ad-prqp-cmpGateway OBJECT IDENTIFIER ::= {id-ad-prqp 11 } 759 4.13. The SCEP Gateway identifier 761 When id-ad-prqp-scepGateway appears in a PRQP message, the associated 762 value in the response is the location of the CMS service gateway, 763 using the conventions defined in [I-D.nourse-scep]. The version 764 field used to identify the service, if present, SHOULD be set to 0. 766 id-ad-prqp-scepGateway OBJECT IDENTIFIER ::= {id-ad-prqp 12 } 768 4.14. The HTML Gateway identifier 770 When id-ad-prqp-htmlGateway appears in a PRQP message, the associated 771 value in the response is the location of a HTML CA service. 773 id-ad-prqp-htmlGateway OBJECT IDENTIFIER ::= {id-ad-prqp 13 } 775 The version field, if present, identifies the version of the HTML 776 data as follows: 778 +---------------+-----------+ 779 | Version Value | Data Type | 780 +---------------+-----------+ 781 | 0 | HTML | 782 | 1 | XML | 783 +---------------+-----------+ 785 Table 1 787 4.15. The XKMS Gateway identifier 789 When id-ad-prqp-xkmsGateway appears in a PRQP message, the associated 790 value in the response is the location of an XKMS server, using the 791 conventions defined in [W3C.xkms] and [W3C.REC-xkms2-20050628]. The 792 version field used to identify the service, if present, SHOULD be set 793 to 1 for services compliant to [W3C.xkms] and to 2 for services 794 compliant to [W3C.REC-xkms2-20050628]. 796 id-ad-prqp-xkmsGateway OBJECT IDENTIFIER ::= {id-ad-prqp 14 } 798 4.16. The Certificate Policy (CP) identifier 800 When id-ad-prqp-certPolicy appears in a PRQP message, the associated 801 value in the response is the location of a certificate Policy (CP). 802 A CP may be used by a relying party to help in deciding whether a 803 certificate, and the binding therein, are sufficiently trustworthy 804 and otherwise appropriate for a particular application. 806 id-ad-prqp-certPolicy OBJECT IDENTIFIER ::= {id-ad-prqp 20 } 808 More information can be found in [RFC2527]. 810 In order to gather the correct policy under which a certificate is 811 issued, the optional OID field in the PRQPRequest SHOULD be copied 812 from the certificate Policy extension of the EE certificate (i.e., 813 the certificate issued by the CA the client is querying for). 815 4.17. The Certification Practice Statement (CPS) identifier 817 When id-ad-prqp-certPolicycertPracticeStatement appears in a PRQP 818 message, the associated value in the response is the location of a 819 Certification Practice Statement (CPS) published by the CA. A CPS is 820 a document that details the practices and procedures established by a 821 CA that will cover the life-cycle of certificates issued by the CA. 822 That is it covers how the certificate will be generated, suspended 823 and revoked. An internally focused document covering the internal 824 environment of the CA. 826 id-ad-prqp-certPracticeStatement 827 OBJECT IDENTIFIER ::= {id-ad-prqp 21 } 829 More information can be found in [RFC2527]. 831 4.18. The Endorsed Trust Anchors identifier 833 When id-ad-prqp-endorsedTA appears in a PRQP message, the associated 834 value in the response is a pointer to a set of Trust Anchors (TA) in 835 the form of certificates. The URI MUST point to a collection of 836 certificates in a DER encoded CMS signedData message as specified in 837 [RFC5272]. 839 id-ad-prqp-endorsedTA OBJECT IDENTIFIER ::= {id-ad-prqp 22 } 841 HTTP server implementations accessed via the URI SHOULD specify the 842 media type "application/pkcs7-mime" [RFC5272] in the content-type 843 header field of the response. The name of the returned file SHOULD 844 have a suffix of ".p7" [RFC5272]. The returned data object SHOULD be 845 signed directly by the CA or by an authorized Identity whose 846 certificate has been issued by the CA (i.e., an EE certificate). The 847 application SHOULD verify the signature on the CMS message before 848 proceeding in accepting the set of TAs. Moreover the application MAY 849 import the set of certificates in its own certificate store as 850 trusted depending on previous trust settings or input from the user. 852 4.19. The LOA Policy (LP) identifier 854 When id-ad-prqp-loaPolicy appears in a PRQP message, the associated 855 value in the response is the location of a Level of Assurance Policy 856 (LP) published by the CA. An LP is a document that details the 857 practices and procedures established by a CA that will cover the 858 requirements for each Level of Assurance. The OID field in the 859 request/response MAY be used to identify a specific LOA Policy 860 document. 862 id-ad-prqp-loaPolicy OBJECT IDENTIFIER ::= {id-ad-prqp 25 } 864 More information can be found in [RFC2527]. 866 4.20. The Certificate LOA Modifier identifier 868 When id-ad-prqp-certLOAModifier appears in a PRQP message, the 869 associated value in the response is the location of a LOA Level 870 Modifier. The LOA modifier service is used to identify the current 871 LOA Level of the certificate (not the LOA under which the certificate 872 has been issued). 874 id-ad-prqp-certLOAModifier OBJECT IDENTIFIER ::= {id-ad-prqp 26 } 876 4.21. The HTML Certificate Request Service identifier 878 When id-ad-prqp-htmlRequestCertificate appears in a PRQP message, the 879 associated value in the response is the location of a HTML 880 certificate request service. The version field, when present, 881 identifies the version of the supported HTML format. See Table 882 Table 1 for more details. As not standard exists that describes how 883 to interact with a CA via HTML, this locator should be mainly used 884 for browser-based certification requests. 886 id-ad-prqp-htmlRequestCertificate 887 OBJECT IDENTIFIER ::= {id-ad-prqp 30} 889 4.22. The HTML Certificate Revoke Service identifier 891 When id-ad-prqp-htmlRevokeCertificate appears in a PRQP message, the 892 associated value in the response is the location of a HTML 893 certificate revoking service. The version field, when present, 894 identifies the version of the supported HTML format. See Table 895 Table 1 for more details. As not standard exists that describes how 896 to interact with a CA via HTML, this locator should be mainly used 897 for browser-based certification requests. 899 id-ad-prqp-htmlRevokeCertificate 900 OBJECT IDENTIFIER ::= {id-ad-prqp 31} 902 4.23. The HTML Certificate Renew Service identifier 904 When id-ad-prqp-htmlRenewCertificate appears in a PRQP message, the 905 associated value in the response is the location of a HTML 906 certificate renewal service. The version field, when present, 907 identifies the version of the supported HTML format. Table 1 As not 908 standard exists that describes how to interact with a CA via HTML, 909 this locator should be mainly used for browser-based certificate 910 renewal requests. 912 id-ad-prqp-htmlRenewCertificate 913 OBJECT IDENTIFIER ::= {id-ad-prqp 32} 915 4.24. The HTML Certificate Suspend Service identifier 917 When id-ad-prqp-htmlSuspendCertificate appears in a PRQP message, the 918 associated value in the response is the location of a HTML 919 certificate suspension service. The version field, when present, 920 identifies the version of the supported HTML format. See Table 921 Table 1 for more details. As not standard exists that describes how 922 to interact with a CA via HTML, this locator should be mainly used 923 for browser-based certificate suspension requests. 925 id-ad-prqp-htmlSuspendCertificate 926 OBJECT IDENTIFIER ::= {id-ad-prqp 33} 928 4.25. The HTML Certificate Recovery Service Identifier 930 When id-ad-prqp-htmlRecoveryCertificate appears in a PRQP message, 931 the associated value in the response is the location of a HTML 932 certificate recovery service. The version field, when present, 933 identifies the version of the supported HTML format. See Table 934 Table 1 for more details. The recovery service is used when a user's 935 local copy of their keys and key history is destroyed. The recovery 936 service returns the user to a complete state (e.g. so they can 937 decrypt messages that were encrypted with older keys). As not 938 standard exists that describes how to interact with a CA via HTML, 939 this locator should be mainly used for browser-based certificate 940 recovery requests. 942 id-ad-prqp-htmlRecoveryCertificate 943 OBJECT IDENTIFIER ::= {id-ad-prqp 34} 945 4.26. The Grid Accreditation Body identifier 947 When id-ad-prqp-grid-accreditationBody appears in a PRQP message, the 948 associated value in the response is the location of the main 949 information point of the Grid Policy Management Authority (GPMA) that 950 accredited the CA. The pointer SHOULD NOT be present if the CA has 951 not been accredited by the GPMA. 953 id-ad-prqp-grid-accreditationBody 954 OBJECT IDENTIFIER ::= {id-ad-prqp 50} 956 4.27. The Grid Policy identifier 958 When id-ad-prqp-grid-accreditationPolicy appears in a PRQP message, 959 the associated value in the response is the location of an 960 Accreditation Policy published by a Grid Policy Management Authority 961 (GPMA). The OID field SHOULD be used to uniquely identify the 962 accreditation policy under which the CA has been accredited. The 963 pointer SHOULD NOT be present if the CA has not been accredited by 964 the GPMA. A Grid Policy (GP) is a document that details the 965 practices and procedures required from a CA in order to be accredited 966 by the GPMA. 968 id-ad-prqp-grid-accreditationPolicy 969 OBJECT IDENTIFIER ::= {id-ad-prqp 51} 971 4.28. The Grid Distribution Update identifier 973 When id-ad-prqp-grid-commonDistributionUpdate appears in a PRQP 974 message, the associated value in the response is the location of the 975 Grid Distribution Package associated with the Grid Policy Management 976 Authority (GPMA) that accredited the CA. The OID field SHOULD be 977 used to uniquely identify the accreditation policy under which the 978 Grid Distribution Package has been released. The pointer SHOULD NOT 979 be present if the CA has not been accredited by the GPMA. 981 id-ad-prqp-grid-commonDistributionUpdate 982 OBJECT_IDENTIFIER ::= {id-ad-prqp 53} 984 4.29. The Grid Accredited CA Certificates identifier 986 When id-ad-prqp-gridAccreditedCACerts appears in a PRQP message, the 987 associated value in the response is a pointer to a set of Trust 988 Anchors (TA) in the form of certificates accredited by the Grid body/ 989 bodies that the CA is participating to. The URI MUST point to a 990 collection of certificates in a DER encoded CMS signedData message as 991 specified in [RFC5272]. The OID field SHOULD be used to uniquely 992 identify the accreditation policy under which the set of CAs pointed 993 by the URI have been accredited. 995 id-ad-prqp-grid-gridAccreditedCACerts 996 OBJECT_IDENTIFIER ::= {id-ad-prqp 54} 998 HTTP server implementations accessed via the URI SHOULD specify the 999 media type "application/pkcs7-mime" [RFC5272] in the content-type 1000 header field of the response. The name of the returned file SHOULD 1001 have a suffix of ".p7" [RFC5272]. The returned data object SHOULD be 1002 signed by the CA the endorsedTA service has been requested for. The 1003 application SHOULD verify the signature on the CMS message before 1004 proceeding in accepting the set of TAs. Moreover the application MAY 1005 import the set of certificates in its own certificate store as 1006 trusted depending on previous trust settings or input from the user. 1008 4.30. The Apex Trust Anchor Update identifier 1010 When id-ad-prqp-apexTampUpdate appears in a PRQP message, the 1011 associated value in the response is the location of a Apex Trust 1012 Anchor Update (apexTrustAnchorUpdate) message as defined by using the 1013 conventions defined in [I-D.pkix-tamp]. The version field used to 1014 identify the service, if present, SHOULD reflect the supported TAMP 1015 version. 1017 id-ad-prqp-apexTampUpdate OBJECT IDENTIFIER ::= {id-ad-prqp 70} 1019 4.31. The Trust Anchor Update identifier 1021 When id-ad-prqp-tampUpdate appears in a PRQP message, the associated 1022 value in the response is the location of a Trust Anchor Update 1023 (trustAnchorUpdate) message as defined by using the conventions 1024 defined in [I-D.pkix-tamp]. The version field used to identify the 1025 service, if present, SHOULD reflect the supported TAMP version. 1027 id-ad-prqp-tampUpdate OBJECT IDENTIFIER ::= {id-ad-prqp 71 } 1029 4.32. The CA Incident Report identifier 1031 When id-ad-prqp-caIncidentReport appears in a PRQP message, the 1032 associated value in the response is the location of a Incident Report 1033 submission service. No standard mechanisms are currently defined for 1034 this type of service, therefore the The resourceInfo field in the 1035 response SHOULD be used to provide information on the provided 1036 Incident Report service. For example while the URI could point to a 1037 web-page carrying contacts information or a ticketing system for 1038 reporting CA-related incidents, the resourceInfo field could provide 1039 text carrying information that may be displayed to the user (e.g., a 1040 support phone number). This would allow support for a wide range of 1041 different devices and applications as long as they have the ability 1042 to display or read the content of the resourceInfo field to the user. 1044 id-ad-prqp-caIncidentReport 1045 OBJECT IDENTIFIER ::= {id-ad-prqp 90} 1047 4.33. The Private Resources identifier 1049 When an application wants to identify private resources, i.e. 1050 services that are not standardized in the PRQP standard definition, 1051 id-ad-prqp-private should be used as the base OID: 1053 id-ad-prqp-private OBJECT IDENTIFIER ::= {id-ad-prqp 100} 1055 The OIDs for a private resource can be identified as follows: 1057 myPrivateResource OBJECT IDENTIFIER ::= {id-ad-prqp-private N} 1059 5. IANA Considerations 1061 IANA has assigned a value of TBD1 for the DHCP option code described 1062 in Section Appendix B.1.1 of this document. 1064 IANA has assigned a value of TBD2 for the DHCPv6 option code 1065 described in Section Appendix B.1.2 of this document. 1067 6. PRQP Design Rationale 1069 In this section we provide some considerations about the protocol 1070 design and its details. 1072 6.1. Response Complexity 1074 An important design consideration is the complexity of messages. 1075 Some type of services, e.g. delta CRLs, can be directly detected upon 1076 data downloading. On the contrary if a client is looking for a 1077 specific version of a protocol or data type, the definition of a 1078 fine-grained query system would allow for data downloading only when 1079 it is actually supported by the requesting client, thus reducing the 1080 server's load. 1082 At present we think that keeping the protocol simple will encourage 1083 its adoption in current environments because the flexibility 1084 introduced by PRQP is a big enhancement over the current options. 1086 Moreover, without requiring changes to the protocol, extensions could 1087 be defined to provide more fine grained options. 1089 Future versions of the protocol may implement extended request and 1090 response types if required by applications. 1092 6.2. RQA's URL distribution 1094 The AIA and SIA extensions in certificates can be used to carry the 1095 pointer to the RQA. If no RQA address is present in the certificate, 1096 a client application could use a default configured URL. 1098 Although this approach seems to contradict the criticism of 1099 Certificate extensions use in Section 2.1.1, using only one extension 1100 to locate the RQA would provide an easy way to distribute the RQA's 1101 URL. 1103 The usage of PRQP will provide a gateway for all the other services 1104 and data URLs. 1106 6.3. Security Considerations 1108 The PRQP provides URLs for PKI resources. This means that it 1109 provides locators to data and services, not the data per se. It 1110 still remains the client's job to access the provided URLs to gather 1111 the needed data. 1113 Both NONCEs and signatures are optional in order to provide 1114 flexibility in how requests and responses are generated. 1116 It is possible to provide pre-computed responses in case the NONCE is 1117 not provided by the client. This allows the RQA to generate off-line 1118 signatures for responses, an optimization used in OCSP. 1120 Moreover if an authenticated secure channel is used at the transport 1121 level between the client and the RQA (e.g. HTTPS or SFTP) signatures 1122 in requests and responses can be safely omitted. 1124 6.4. Time Validity 1126 The time validity should reflect the frequency of updates in 1127 configured URLs. An interesting aspect to be considered is how often 1128 would users execute the protocol for a given set of data. 1130 If the clients query the server often it could be a serious burden on 1131 the server but, if executed rarely, clients would not be able to 1132 discover changes in provided resources. 1134 As described in more detail in Appendix A, the adoption of a validity 1135 time frame for responses can be used as a mean to balance the trade 1136 off between this two aspects, but this is merely advisory data for 1137 clients and thus not a guarantee against DoS attacks by clients. 1139 6.5. Message Format 1141 Two different candidates have been considered. The first one is the 1142 Extensible Markup Language (XML), while the second one is the 1143 Distinguished Encoding Rules (DER). 1145 The adoption of the Abstract Syntax Notation (ASN.1) to describe the 1146 data structures allows a software developer to provide either DER or 1147 XML based implementations of the protocol. 1149 However we think that a DER based implementation of PRQP is the best 1150 choice because of compatibility considerations with existing 1151 applications and APIs. Moreover DER encoded messages are smaller in 1152 size then XML encoded ones and almost all PKI aware applications 1153 already support it. 1155 7. Acknowledgments 1157 The authors would like to thank Stephen Kent for his insightful 1158 comments about PRQP and his help in writing this document. 1160 8. References 1162 8.1. Normative References 1164 [I-D.ietf-dhc-option-guidelines] 1165 Hankins, D., "Guidelines for Creating New DHCP Options", 1166 draft-ietf-dhc-option-guidelines-03 (work in progress), 1167 October 2008. 1169 [I-D.pkix-tamp] 1170 Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1171 Management Protocol (TAMP)", draft-ietf-pkix-tamp (work in 1172 progress), October 2008. 1174 [RFC1035] Mockapetris, P., "Domain names - implementation and 1175 specification", STD 13, RFC 1035, November 1987. 1177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1178 Requirement Levels", BCP 14, RFC 2119, March 1997. 1180 [RFC2527] Chokhani, S. and W. Ford, "Internet X.509 Public Key 1181 Infrastructure Certificate Policy and Certification 1182 Practices Framework", RFC 2527, March 1999. 1184 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1186 Adams, "X.509 Internet Public Key Infrastructure Online 1187 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1189 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1190 Infrastructure Operational Protocols: FTP and HTTP", 1191 RFC 2585, May 1999. 1193 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 1194 "Service Location Protocol, Version 2", RFC 2608, 1195 June 1999. 1197 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 1198 and Service: Schemes", RFC 2609, June 1999. 1200 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1201 specifying the location of services (DNS SRV)", RFC 2782, 1202 February 2000. 1204 [RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein, 1205 "Certificate Management Messages over CMS", RFC 2797, 1206 April 2000. 1208 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 1209 "Internet X.509 Public Key Infrastructure Time-Stamp 1210 Protocol (TSP)", RFC 3161, August 2001. 1212 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1213 X.509 Public Key Infrastructure Certificate and 1214 Certificate Revocation List (CRL) Profile", RFC 3280, 1215 April 2002. 1217 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1218 and M. Carney, "Dynamic Host Configuration Protocol for 1219 IPv6 (DHCPv6)", RFC 3315, July 2003. 1221 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1222 "Internet X.509 Public Key Infrastructure Certificate 1223 Management Protocol (CMP)", RFC 4210, September 2005. 1225 [RFC4248] Hoffman, P., "The telnet URI Scheme", RFC 4248, 1226 October 2005. 1228 [RFC4266] Hoffman, P., "The gopher URI Scheme", RFC 4266, 1229 November 2005. 1231 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 1232 Polk, "Server-Based Certificate Validation Protocol 1233 (SCVP)", RFC 5055, December 2007. 1235 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1236 (CMC)", RFC 5272, June 2008. 1238 8.2. Non-Normative References 1240 [I-D.nourse-scep] 1241 Liu, X., "Cisco Systems' Simple Certificate Enrollment 1242 Protocol", draft-nourse-scep-17 (work in progress), 1243 June 2008. 1245 [PEACH] Pala, M. and S. Smith, "Peaches and Peers", LNCS 5057, 1246 June 2008. 1248 [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol 1249 (LDAP) Schema Definitions for X.509 Certificates", 1250 RFC 4523, June 2006. 1252 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1253 Housley, R., and W. Polk, "Internet X.509 Public Key 1254 Infrastructure Certificate and Certificate Revocation List 1255 (CRL) Profile", RFC 5280, May 2008. 1257 [W3C.REC-xkms2-20050628] 1258 Mysore, S. and P. Hallam-Baker, "XML Key Management 1259 Specification (XKMS 2.0)", World Wide Web Consortium 1260 Recommendation REC-xkms2-20050628, June 2005, 1261 . 1263 [W3C.xkms] 1264 Ford, W., Hallam-Baker, P., Fox, B., Dillaway, B., 1265 LaMacchia, B., Epstein, J., and J. Lapp, "XML Key 1266 Management Specification (XKMS)", W3C Note xkms, 1267 March 2001, . 1269 Appendix A. Transport Protocol Specifications for PRQP Messages 1271 A.1. PRQP over HTTP 1273 This section describes the formatting needed in order to route PRQP 1274 request and response over HTTP. 1276 A.1.1. Request 1278 HTTP based PRQP requests SHOULD use the POST method to submit their 1279 requests. Where privacy is a requirement, PRQP transactions 1280 exchanged using HTTP MAY be protected using either TLS/SSL or some 1281 other lower layer protocol. 1283 The required HTTP headers for the request are: 1285 o Content-Type 1287 o Content-Transfer-Encoding 1289 o Content-Length 1291 The Content-Type header SHOULD be set to "application/prqp-request". 1292 The Content-Transfer-Encoding SHOULD be set to "Binary", while the 1293 Content-Length SHOULD be set to the length (in bytes) of the body of 1294 the request. The body of the HTTP message MUST carry the binary 1295 value of the DER encoding of the PRQPRequest. 1297 A.1.2. Response 1299 An HTTP-based PRQP response is composed of the appropriate HTTP 1300 headers, followed by the binary value of the DER encoding of the 1301 PRQPPResponse. 1303 The required HTTP headers for the response are: 1305 o Content-Type 1307 o Content-Transfer-Encoding 1309 o Content-Length 1311 The Content-Type header SHOULD be set to "application/prqp-response". 1312 The Content-Transfer-Encoding SHOULD be set to "Binary", while the 1313 Content-Length SHOULD be set to the length (in bytes) of the body of 1314 the request. The body of the HTTP message MUST carry the binary 1315 value of the DER encoding of the PRQPResponse. 1317 A.1.3. Message Caching 1319 To minimize bandwidth usage, clients MUST locally cache authoritative 1320 PRQP responses for the validity period of the request. To enable 1321 proxy servers to be able to cache responses as well, additional HTTP 1322 headers MAY be used in the response. 1324 The PRQP responder MAY ease caching by setting the following headers: 1326 o date 1328 o last-modified 1329 o expires 1331 In particular, the date field SHOULD carry the date at which the HTTP 1332 response has been generated. The last-modified, instead, SHOULD bear 1333 the date at which the response has been modified. This field SHOULD 1334 carry the same date as the producedAt field of the PRQPResponse. The 1335 expires field SHOULD carry the date till when the response is to be 1336 considered valid. This field SHOULD carry the same date as in the 1337 nextUpdate field of the PRQPResponse. 1339 An example HTTP response would look like: 1341 HTTP/1.0 200 OK 1342 Content-Type: application/prqp-response 1343 Content-Transfer-Encoding: Binary 1344 Content-Length: 860 1345 Date: Thu, 03 May 2007 04:43:43 GMT 1346 Last-Modified: Thu, 03 May 2007 04:43:42 GMT 1347 Expires: Thu, 04 May 2007 04:43:42 GMT 1349 <...response data...> 1351 PRQP clients SHOULD NOT included a no-cache header in PRQP request 1352 messages, unless the client encounters an expired response which may 1353 be a result of an intermediate proxy caching stale data. 1355 A.2. PRQP over Peer-to-Peer Network 1357 PRQP offers a starting point for the development of a PKI Resource 1358 Discovery Architecture where different RQAs cooperate to access data 1359 not locally available. 1361 One technology that already provides good results in data sharing is 1362 Peer-to-Peer (P2P) networking. 1364 Signed PRQP requests and responses can be routed also on existing P2P 1365 networks or a PRQP-specific network can be setup to provide a World 1366 Wide PKI Resources Discovery Architecture (PRDA), the definition of 1367 which is out of the scope of this document. An example of such an 1368 architecture is PEACH [PEACH] 1370 Appendix B. RQA address Retrieval 1372 B.1. DHCP Specifications 1374 This section describes the needed steps to distribute RQAs addresses 1375 by using DHCP extensions. In particular we define the DHCP option 1376 needed to identify an RQA server and we suggest options parsing for 1377 DHCP server and clients. 1379 B.1.1. PRQP Servers IPv4 Option for DHCPv4 1381 We define a prqp-servers option for DHCPv4 that specifies a list of 1382 Resource Query Authorities (PRQP servers) available to the client. 1383 The RQA address MUST be expressed as IPv4 addresses. Servers SHOULD 1384 be listed in order of preference and clients MUST treat the list of 1385 PRQP servers as an ordered list. 1387 The format for the prqp-servers option is as shown below: 1389 Code Len Address 1 Address 2 1390 +------+-----+-----+-----+-----+-----+-----+-- 1391 | TBD1 | n | a1 | a2 | a3 | a4 | a1 | ... 1392 +------+-----+-----+-----+-----+-----+-----+-- 1394 The code for the pki resource query authority list option is TBD1. 1395 The minimum length for this option is 1 octets. 1397 B.1.2. PRQP Servers IPv6 Option for DHCPv6 1399 We define a prqp-servers option for DHCPv6 that specifies a list of 1400 Resource Query Authorities (PRQP servers) available to the client. 1401 The RQA address MUST be expressed as IPv6 addresses (128-bit). 1402 Servers SHOULD be listed in order of preference and clients MUST 1403 treat the list of PRQP servers as an ordered list. 1405 The format for the prqp-servers option is as follows: 1407 0 1 2 3 1408 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | OPTION_RQA_LIST | option-len | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | | 1413 | PRQP server (IPv6 address) | 1414 | | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | | 1417 | PRQP server (IPv6 address) | 1418 | | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | ... | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 option-code: OPTION_PRQP_SERVERS (TBD2) 1425 option-len: Length of the 'PRQP servers' field in octets; it must 1426 be a multiple of 16 1428 PRQP server: IPv6 address of Resource Query Authority (PRQP) Server 1430 The RQA address(es) specified in the 'PRQP server' MUST be encoded as 1431 IPv6 addresses. The code for the prqp-servers option for IPv6 is 1432 TBD2. The minimum length for this option is 1 octets. 1434 B.1.3. DHCP Configuration 1436 As reported in [I-D.ietf-dhc-option-guidelines], one of the most 1437 deployed DHCP package is the ISC DHCP, mostly written by Ted Lemon in 1438 cooperation with Nominum, Inc. and now maintained by Internet Systems 1439 Consortium, Inc. ("ISC"). In order to provide developers and system 1440 administrators with deployment guidelines, we provide example 1441 configurations for both the server and the client. 1443 Below is a sample configuration for the pki resource query 1444 authorities option that can be added both the dhclient.conf (on 1445 clients) and dhcpd.conf (on servers) for IPv4: 1447 option prqp-servers code TBD1 = array of ip-address; 1449 If your environment supports IPv6, you should provide the option as a 1450 list of IPv6 addresses as follows: 1452 option prqp-servers code TBD2 = array of ipv6-address; 1454 In addition to this, in order for the server to pass on the 1455 configuration to the clients, the following example configuration 1456 options could be used in the server's configuration file (typically 1457 /etc/dhcpd.conf): 1459 ... 1460 subnet XXX.XXX.XXX.XXX netmask YYY.YYY.YYY.YYY { 1461 ... 1462 option prqp-servers rqa.openca.org, 1463 rqa3.dartmouth.edu, 1464 rqa5.mydomain.org; 1465 } 1466 ... 1468 B.1.4. DHCP Client Processing 1470 In order to provide applications deriving their configuration 1471 parameters from values provided by this DHCP option, the dhcp client 1472 needs to format the on-the-wire bits in a more digestible one. In 1473 particular for the "prqp-servers" option, a configuration file should 1474 be created as: 1476 /etc/pki.conf 1478 where the list of addresses can be stored. An example of such a file 1479 is reported below: 1481 queryauthority rqa.openca.org 1482 queryauthority rqa3.dartmouth.edu 1483 queryauthority 127.0.0.1 1485 where each line has the format: 1487 queryauthority
1489 B.2. DNS SRV Records 1491 This section describes the needed steps to distribute RQAs addresses 1492 by using DNS SRV records. In particular we define the format to use 1493 for the SRV records. As an example we also provide a sample zone 1494 file. 1496 B.2.1. SRV Record Format for PRQP 1498 The format for DNS SRV records MUST be compliant with [RFC2782]. In 1499 particular, in order to support PRQP, a DNS server MUST use the 1500 following: 1502 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 1504 Where: 1506 o Service is the symbolic name of the desired service. This field 1507 MUST be set to "rqa" 1509 o Proto is the symbolic name of the protocol to be used. This field 1510 MUST be set to "_tcp" 1512 o Name is the domain this RR refers to, i.e. the hostname of the RQA 1513 server 1515 o TTL has the standard DNS meaning, refer to [RFC1035] for more 1516 information. 1518 o Class has Standard DNS meaning [RFC1035]. This field MUST be set 1519 to "IN" 1521 o Priority is the priority of this target host. The allowed range 1522 of values is 0-65535 (16 bit unsigned integer in network byte 1523 order). 1525 o Weight is used for server selection mechanism. The weight field 1526 specifies a relative weight for entries with the same priority. 1527 The allowed range of values is 0-65535 (16 bit unsigned integer in 1528 network byte order). A more detailed description of the Weight 1529 usage can be found in [RFC2782]. 1531 B.2.2. Example: PRQP enabled zone file 1533 In this section we provide a sample zone file for the domain 1534 .openca.org. In this example we configure service records for three 1535 different RQAs. 1537 $ORIGIN openca.org. 1538 @ SOA server.openca.org. root.openca.org. ( 1539 1995032001 3600 3600 604800 86400 ) 1540 NS server.openca.org. 1541 NS ns1.ip-provider.net. 1542 NS ns2.ip-provider.net. 1543 ; first two rqa server lines, they have the same priority, 1544 ; but different weight 1545 _rqa._tcp SRV 0 1 830 rqa.openca.org. 1546 SRV 0 3 830 rqa2.openca.org. 1547 ; last chance - lower priority because it is a very slow box 1548 SRV 10 0 830 rqa-slow.openca.org. 1549 rqa A 129.170.214.89 1550 rqa2 A 129.170.212.31 1551 rqa-slow A 64.233.167.99 1552 ; NO other services are supported 1553 *._tcp SRV 0 0 0 . 1554 *._udp SRV 0 0 0 . 1556 Appendix C. PRQP ASN1.1 Specification 1558 PRQP DEFINITIONS EXPLICIT TAGS ::= 1560 BEGIN 1562 -- EXPORTS ALL -- 1564 IMPORTS 1566 -- Directory Authentication Framework (X.509) 1567 Certificate, AlgorithmIdentifier 1568 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1569 module(1) authenticationFramework(7) 3 } 1571 -- PKIX Certificate Extensions 1572 AuthorityKeyIdentifier, SubjectKeyIdentifier, KeyIdentifier, 1573 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1574 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1575 id-mod(0) id-pkix1-implicit-88(2)} 1577 CertificateSerialNumber, Extensions, id-kp, id-ad-prqp 1578 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1579 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1580 id-mod(0) id-pkix1-explicit-88(1)}; 1582 PRQPRequest ::= SEQUENCE { 1583 requestData TBSReqData, 1584 signature [0] EXPLICIT Signature OPTIONAL } 1586 TBSReqData ::= SEQUENCE { 1587 version INTEGER { v(1) }, 1588 nonce [0] INTEGER OPTIONAL, 1589 -- very large number 1590 producedAt GeneralizedTime, 1591 -- time when the request has been generated 1592 serviceToken ResourceRequestToken, 1593 -- token identifying the requested service 1594 extensions [1] IMPLICIT Extensions OPTIONAL } 1596 ResourceRequestToken ::= SEQUENCE { 1597 ca CertIdentifier, 1598 servicesList [0] SET OF ResourceIdentifier OPTIONAL } 1600 BasicCertIdentifier ::= SEQUENCE { 1601 issuerNameHash OCTET STRING, 1602 serialNumber CertificateSerialNumber } 1604 ExtenderCertInfo ::= SEQUENCE { 1605 certificateHash OCTET STRING, 1606 subjectKeyHash OCTET STRING, 1607 subjectKeyIdentifier [0] KeyIdentifier OPTIONAL, 1608 issuerKeyIdentifier [1] KeyIdentifier OPTIONAL } 1610 CertIdentifier ::= SEQUENCE { 1611 hashAlgorithm AlgorithmIdentifier, 1612 basicCertIdentifier BasicCertIdentifier, 1613 extInfo [0] ExtendedCertInfo OPTIONAL, 1614 caCertificate [1] Certificate OPTIONAL, 1615 issuedCertificate [2] Certificate OPTIONAL } 1617 ResourceIdentifier ::= SEQUENCE { 1618 resourceId OBJECT IDENTIFIER, 1619 version [0] INTEGER OPTIONAL 1620 --- version of the protocol or data format (if applicable) 1621 oid [1] OBJECT IDENTIFIER OPTIONAL, 1622 --- object identifier associated with the URL 1623 --- (if applicable) } 1625 PRQPResponse ::= SEQUENCE { 1626 respData TBSRespData, 1627 signature [0] EXPLICIT Signature OPTIONAL } 1629 TBSRespData ::= SEQUENCE { 1630 version INTEGER { v(1)}, 1631 nonce INTEGER OPTIONAL, 1632 -- as duplicated from the request 1633 producedAt GeneralizedTime, 1634 -- time when the response has been generated 1635 nextUpdate [0] GeneralizedTime OPTIONAL, 1636 -- time till when the response should be considered 1637 -- valid 1638 pkiStatus PKIStatusInfo, 1639 -- status of the response 1640 caCertId CertIdentifier, 1641 -- identifier of the CA the targeted certificate is 1642 -- issued from 1643 responseToken SEQUENCE OF ResourceResponseToken 1644 OPTIONAL, 1645 -- token carrying information about 1646 -- requested services 1647 extensions [0] EXPLICIT Extensions OPTIONAL } 1649 PKIStatusInfo ::= SEQUENCE { 1650 status PKIStatus, 1651 statusString [0] UTF8String OPTIONAL, 1652 failInfo [1] PKIFailureInfo OPTIONAL, 1653 referrals [2] EXPLICIT SEQUENCE OF IA5String 1654 OPTIONAL } 1656 PKIStatus ::= INTEGER { 1657 ok (0), 1658 -- when the PKIStatus contains the value zero one or 1659 more responseToken is present 1660 badRequest (1), 1661 -- the request is badly formatted 1662 caNotPresent (2), 1663 -- the requested CA is not present 1664 systemFailure (3) 1665 -- a system failure has occourred } 1667 Signature ::= SEQUENCE { 1668 signatureAlgorithm AlgorithmIdentifier, 1669 signature BIT STRING, 1670 certs [0] EXPLICIT SEQUENCE OF Certificate 1671 OPTIONAL } 1673 ResourceResponseToken ::= SEQUENCE { 1674 resourceId OBJECT IDENTIFIER, 1675 --- resource identifier 1676 resourceLocatorList [0] EXPLICIT SEQUENCE OF IA5String, 1677 --- sequence of resource locators (URI) 1678 version [1] INTEGER OPTIONAL, 1679 --- version of the protocol or data format (if applicable) 1680 oid [2] OBJECT IDENTIFIER OPTIONAL, 1681 --- object identifier associated with the URL 1682 --- (if applicable) 1683 resourceInfo [3] UTF8Sting OPTIONAL, 1684 --- additional service Info (eg. technical contacts) } 1686 -- Object Identifiers 1688 id-kp-PRQPSigning OBJECT IDENTIFIER ::= { id-kp 11 } 1689 id-prqp OBJECT IDENTIFIER ::= { id-pkix 23 } 1690 id-prqp-pta OBJECT IDENTIFIER ::= { id-prqp 1 } 1692 id-ad-prqp OBJECT IDENTIFIER ::= {id-ad 12 } 1693 id-ad-prqp-rqa OBJECT IDENTIFIER ::= {id-ad-prqp 0} 1694 id-ad-prqp-ocsp OBJECT IDENTIFIER ::= {id-ad-prqp 1} 1695 id-ad-prqp-subjectCert OBJECT IDENTIFIER ::= {id-ad-prqp 2} 1696 id-ad-prqp-issuerCert OBJECT IDENTIFIER ::= {id-ad-prqp 3} 1697 id-ad-prqp-timestamping OBJECT IDENTIFIER ::= {id-ad-prqp 4} 1698 id-ad-prqp-scvp OBJECT IDENTIFIER ::= {id-ad-prqp 5} 1699 id-ad-prqp-crlDistribution OBJECT IDENTIFIER ::= {id-ad-prqp 6} 1700 id-ad-prqp-certRepository OBJECT IDENTIFIER ::= {id-ad-prqp 7} 1701 id-ad-prqp-crlRepository OBJECT IDENTIFIER ::= {id-ad-prqp 8} 1702 id-ad-prqp-crossCertRepository OBJECT IDENTIFIER ::= {id-ad-prqp 9} 1703 id-ad-prqp-cmcGateway OBJECT IDENTIFIER ::= {id-ad-prqp 10} 1704 id-ad-prqp-cmpGateway OBJECT IDENTIFIER ::= {id-ad-prqp 11} 1705 id-ad-prqp-scepGateway OBJECT IDENTIFIER ::= {id-ad-prqp 12} 1706 id-ad-prqp-htmlGateway OBJECT IDENTIFIER ::= {id-ad-prqp 13} 1707 id-ad-prqp-xkmsGateway OBJECT IDENTIFIER ::= {id-ad-prqp 14} 1708 id-ad-prqp-certPolicy OBJECT IDENTIFIER ::= {id-ad-prqp 20} 1709 id-ad-prqp-certPracticesStatement OBJECT IDENTIFIER ::= {id-ad-prqp 21} 1710 id-ad-prqp-endorsedTA OBJECT IDENTIFIER ::= {id-ad-prqp 22} 1711 id-ad-prqp-loaPolicy OBJECT IDENTIFIER ::= {id-ad-prqp 25} 1712 id-ad-prqp-certLOALevel OBJECT IDENTIFIER ::= {id-ad-prqp 26} 1713 id-ad-prqp-htmlRequestCertificate OBJECT IDENTIFIER ::= {id-ad-prqp 30} 1714 id-ad-prqp-htmlRevokeCertificate OBJECT IDENTIFIER ::= {id-ad-prqp 31} 1715 id-ad-prqp-htmlRenewCertificate OBJECT IDENTIFIER ::= {id-ad-prqp 32} 1716 id-ad-prqp-htmlSuspendCertificate OBJECT IDENTIFIER ::= {id-ad-prqp 33} 1717 id-ad-prqp-htmlRecoveryCertificate OBJECT IDENTIFIER ::= {id-ad-prqp 34} 1718 id-ad-prqp-gridAccreditationBody OBJECT IDENTIFIER ::= {id-ad-prqp 50} 1719 id-ad-prqp-gridAccreditationPolicy OBJECT IDENTIFIER ::= {id-ad-prqp 51} 1720 id-ad-prqp-gridAccreditationStatus OBJECT IDENTIFIER ::= {id-ad-prqp 52} 1721 id-ad-prqp-gridDistributionUpdate OBJECT IDENTIFIER ::= {id-ad-prqp 53} 1722 id-ad-prqp-gridAccreditedCACerts OBJECT IDENTIFIER ::= {id-ad-prqp 54} 1723 id-ad-prqp-apexTampUpdate OBJECT IDENTIFIER ::= {id-ad-prqp 70} 1724 id-ad-prqp-tampUpdate OBJECT IDENTIFIER ::= {id-ad-prqp 71} 1725 id-ad-prqp-caIncidentReport OBJECT IDENTIFIER ::= {id-ad-prqp 90} 1726 id-ad-prqp-private OBJECT IDENTIFIER ::= {id-ad-prqp 100} 1728 Author's Address 1730 Massimiliano Pala 1731 Dartmouth College 1732 6211 Sudikoff PKI/Trust Lab 1733 Hanover, NH 03755 1734 US 1736 Email: pala@cs.dartmouth.edu 1737 URI: http://www.openca.org