[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

PKIX Working Group                                               M. Pala
Internet-Draft                                         Dartmouth College
Intended status: Experimental                           December 8, 2008
Expires: June 11, 2009


                   PKI Resource Query Protocol (PRQP)
                        draft-ietf-pkix-prqp-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 11, 2009.

Abstract

   One of the most strategic problems still open in PKIX is locating
   public data and services associated with a Certification Authority
   (CA).  This issue impacts interoperability and usability in PKIX.

   This draft describes the PKI Resource Query Protocol (PRQP), its
   design, definition, and its impact in already deployed PKIX
   protocols.








Pala                      Expires June 11, 2009                 [Page 1]


Internet-Draft                    PRQP                     December 2008


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Overview of existing solutions . . . . . . . . . . . . . .  4
       2.1.1.  Certificate Extensions . . . . . . . . . . . . . . . .  4
       2.1.2.  DNS SRV records  . . . . . . . . . . . . . . . . . . .  5
       2.1.3.  Local Network Oriented Solutions . . . . . . . . . . .  5
   3.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  The Resource Query Authority (RQA) . . . . . . . . . . . .  6
     3.2.  PRQP Overview  . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  PRQP Request . . . . . . . . . . . . . . . . . . . . .  7
         3.2.1.1.  Request Syntax . . . . . . . . . . . . . . . . . .  8
       3.2.2.  PRQP Response  . . . . . . . . . . . . . . . . . . . . 10
         3.2.2.1.  Response Syntax  . . . . . . . . . . . . . . . . . 10
   4.  Object Identifiers for PKI resources . . . . . . . . . . . . . 12
     4.1.  The RQA Service identifier . . . . . . . . . . . . . . . . 13
     4.2.  The OCSP identifier  . . . . . . . . . . . . . . . . . . . 13
     4.3.  The Issuer's Certificate identifier  . . . . . . . . . . . 13
     4.4.  The Timestamping Service identifier  . . . . . . . . . . . 13
     4.5.  The SCVP Server identifier . . . . . . . . . . . . . . . . 14
     4.6.  The CRL Distribution Point identifier  . . . . . . . . . . 14
     4.7.  The Certificates Repository identifier . . . . . . . . . . 14
     4.8.  The CRL Repository identifier  . . . . . . . . . . . . . . 14
     4.9.  The Cross Certificates Repository identifier . . . . . . . 15
     4.10. The CMS Gateway identifier . . . . . . . . . . . . . . . . 15
     4.11. The SCEP Gateway identifier  . . . . . . . . . . . . . . . 15
     4.12. The HTML Gateway identifier  . . . . . . . . . . . . . . . 15
     4.13. The XKMS Gateway identifier  . . . . . . . . . . . . . . . 16
     4.14. The Certificate Policy (CP) identifier . . . . . . . . . . 16
     4.15. The Certification Practice Statement (CPS) identifier  . . 16
     4.16. The Endorsed Trust Anchors identifier  . . . . . . . . . . 16
     4.17. The LOA Policy (LP) identifier . . . . . . . . . . . . . . 17
     4.18. The Certificate LOA Modifier identifier  . . . . . . . . . 17
     4.19. The HTML Certificate Request Service identifier  . . . . . 17
     4.20. The HTML Certificate Revoke Service identifier . . . . . . 18
     4.21. The HTML Certificate Renew Service identifier  . . . . . . 18
     4.22. The HTML Certificate Suspend Service identifier  . . . . . 18
     4.23. The Grid Accreditation Body identifier . . . . . . . . . . 18
     4.24. The Grid Policy identifier . . . . . . . . . . . . . . . . 19
     4.25. The Grid DistributionUpdate identifier . . . . . . . . . . 19
     4.26. The TAMP Update identifier . . . . . . . . . . . . . . . . 19
     4.27. The CA Incident Report identifier  . . . . . . . . . . . . 19
     4.28. The Private Resources identifier . . . . . . . . . . . . . 20
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   6.  PRQP Design Rationale  . . . . . . . . . . . . . . . . . . . . 20
     6.1.  Response Complexity  . . . . . . . . . . . . . . . . . . . 20
     6.2.  RQA's URL distribution . . . . . . . . . . . . . . . . . . 21



Pala                      Expires June 11, 2009                 [Page 2]


Internet-Draft                    PRQP                     December 2008


     6.3.  Security Considerations  . . . . . . . . . . . . . . . . . 21
     6.4.  Time Validity  . . . . . . . . . . . . . . . . . . . . . . 21
     6.5.  Message Format . . . . . . . . . . . . . . . . . . . . . . 22
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     8.2.  Non-Normative References . . . . . . . . . . . . . . . . . 24
   Appendix A.  Transport Protocol Specifications for PRQP
                Messages  . . . . . . . . . . . . . . . . . . . . . . 24
     A.1.  PRQP over HTTP . . . . . . . . . . . . . . . . . . . . . . 24
       A.1.1.  Request  . . . . . . . . . . . . . . . . . . . . . . . 24
       A.1.2.  Response . . . . . . . . . . . . . . . . . . . . . . . 25
       A.1.3.  Message Caching  . . . . . . . . . . . . . . . . . . . 25
     A.2.  PRQP over Peer-to-Peer Network . . . . . . . . . . . . . . 26
   Appendix B.  RQA address Retrieval . . . . . . . . . . . . . . . . 26
     B.1.  DHCP Specifications  . . . . . . . . . . . . . . . . . . . 26
       B.1.1.  PRQP Servers IPv4 Option for DHCPv4  . . . . . . . . . 26
       B.1.2.  PRQP Servers IPv6 Option for DHCPv6  . . . . . . . . . 27
       B.1.3.  DHCP Configuration . . . . . . . . . . . . . . . . . . 28
       B.1.4.  DHCP Client Processing . . . . . . . . . . . . . . . . 28
     B.2.  DNS SRV Records  . . . . . . . . . . . . . . . . . . . . . 29
       B.2.1.  SRV Record Format for PRQP . . . . . . . . . . . . . . 29
       B.2.2.  Example: PRQP enabled zone file  . . . . . . . . . . . 30
   Appendix C.  PRQP ASN1.1 Specification . . . . . . . . . . . . . . 30
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 35

























Pala                      Expires June 11, 2009                 [Page 3]


Internet-Draft                    PRQP                     December 2008


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Introduction

   An increasing number of services and protocols are being defined to
   address different needs of users and administrators of PKIs.  With
   the deployment of new applications and services, the need to access
   information and services provided by Certificate Service Providers
   (CSPs) is critical.  Currently Certification Authorities (CAs) barely
   publish access details on their official web sites, this includes URL
   of provided services and repositories.

   Using the PRQP, resources provided by a CA can be automatically and
   securely discovered by an application.

2.1.  Overview of existing solutions

   Currently there are three options to find URLs providing access to
   PKI data:

   o  by including such data in certificate extensions

   o  by searching easily accessible repositories (e.g.  DNS, local
      database, etc.)

   o  by adapting existing protocols (e.g.  SLP)

2.1.1.  Certificate Extensions

   To provide pointers to published data it is possible to use the
   Authority Information Access (AIA) Subject Information Access (SIA)
   extensions defined by PKIX [RFC3280].

   The former can provide information about services associated with the
   issuer of the certificate, while the latter carries information
   (inside a CA certificate) about offered CA services.

   AIA and SIA extensions are static, i.e. not modifiable unless the
   certificate is re-issued.  If a CA inserts the AIA extension into
   every certificate it issues, e.g., to identify the location of an
   OCSP responder, then changing that location would require re-issuance
   of all these certificates, a substantial barrier to such a change.
   If a CA certificate is self-signed and used as a trust anchor, then



Pala                      Expires June 11, 2009                 [Page 4]


Internet-Draft                    PRQP                     December 2008


   re-issuing the certificate to change the content of the SIA
   extension, e.g., to reflect a change in the location of a time
   stamping server would be very disruptive.  In closed PKIs, e.g.,
   enterprises, use of these extensions may be replaced by manual
   configuration and management of this data via ad hoc means.  Because
   of the centrally controlled nature of such environments, the static
   nature of SIA and AIA extensions is not a concern.

   However in order to promote interoperability between PKIs, PRQP
   enables dynamic management of pointers to such services (e.g.,
   adding/removing or moving) without requiring changes in the
   certificate contents or third parties to manually configure services
   in their applications.  Even in closed environments, PRQP could help
   manage PKI services analogous the way DHCP facilitates network
   management.

2.1.2.  DNS SRV records

   The SRV record technique provides pointers to servers via the DNS
   [RFC1035].

   As defined in [RFC2782], the introduction of this type of record
   allows administrators to perform operations similar to what we
   require in order to solve the problem we are addressing in this
   draft, i.e., to provide URLs to services.

   The problem in the adoption of this mechanism is that, in contrast to
   the DNS environment, usually in PKIX there is no fixed mapping
   between certificates and the DNS name space.  The only exception is
   when the Domain Component (DC) attributes are used in the
   certificate's Subject.

   Currently this approach is not widely adopted.  Moreover, it is not
   always easy to identify the right DNS to query to, when trying to
   find a particular service provided by a CA, because of the lack of
   such information in certificates.

2.1.3.  Local Network Oriented Solutions

   Another approach to provide reliable information is to use existing
   protocols for service location such as Jini, Universal Plug and Play
   protocol (UPnP) or Service Location Protocol (SLP) [RFC2608]
   [RFC2609].

   The IETF defined the SLP to provide a service location mechanism that
   is language and technology independent.  Some issues, however, make
   it not the right choice to solve our problem, e.g., the protocol is
   quite complex to implement when considering the scope of the problem



Pala                      Expires June 11, 2009                 [Page 5]


Internet-Draft                    PRQP                     December 2008


   we are addressing.

   The definition of a specific and simple protocol for PKI service and
   resource location is needed to ease PKI integration into existing and
   future applications, especially for mobile devices which have limited
   computational power and communication bandwidth.


3.  Protocol Details

   The PRQP protocol is a request-response protocol, formed by the
   exchanging of two messages, i.e., a request and a response between a
   client and a server, called the Resource Query Authority (RQA).

   The requesting entity (the client) may be any entity that needs to
   access information about repositories and services related to a
   certificate.

   The RQA is the authority entitled to answer for a particular CA or to
   act as a PRQP Trusted Authority (PTA) for a set of users, e.g., users
   in an enterprise environment.

   In the first case the RQA is directly designated by a CA to act as an
   RQA, by having the CA issue a certificate to the RQA with a specific
   value set in the extendedKeyUsage extension.  In this case the RQA
   provides authoritative responses for requests regarding the CA that
   issued the RQA's certificate.

   When operating as a PTA, the RQA may provide responses about multiple
   CAs, without the need to have been directly certified by them.  To
   operate as such, a specific extension (prqpTrustedAuthority) should
   be present in RQA's certificate and its value should be set to TRUE.

3.1.  The Resource Query Authority (RQA)

   The Resource Query Authority is the designated authority to act as
   PRQP responder.  The RQA's signing key needs not to be the same as
   that of the CA that designated it.

   The CA may designate an RQA by issuing a certificate containing a
   unique value for the extendedKeyUsage in RQA's certificate.  The RQA
   may also act as a trusted responder.  PRQP signing delegation SHALL
   be designated by the inclusion of id-kp-PRQPSigning in the
   extendedKeyUsage extension within the PRQP response signer's
   certificate.






Pala                      Expires June 11, 2009                 [Page 6]


Internet-Draft                    PRQP                     December 2008


      id-kp-PRQPSigning OBJECT IDENTIFIER ::= {id-kp 10}

   When operating as a PTA, the RQA may provide responses about multiple
   CAs, without the need to have been directly certified by them.  To
   operate as a PTA a specific extension (prqpTrustedAuthority) should
   be present in RQA's certificate and its value should be set to TRUE.

      prqpTrustedAuthority ::= BOOLEAN DEFAULT TRUE

   We also define two new OIDs to identify the PRQP protocol and the PTA
   extension as follows:

      id-prqp OBJECT IDENTIFIER ::= { id-pkix 23 }

      id-prqp-pta OBJECT IDENTIFIER ::= { id-prqp 1 }

3.2.  PRQP Overview

   The protocol encompasses the exchange of a single round of messages
   between a client and an RQA:

   1.  the client requests a resource token by sending a request to the
       RQA

   2.  the RQA replies by sending a response to the client

   Upon receiving the response the client MUST verify the status error
   returned in the response.  If no error is present, the client MUST
   verify the various fields contained in the ResourceResponseToken and
   the validity of the associated digital signature (if present).  A
   nonce MAY be used to guarantee that the response is associated with a
   specific request in order to avoid reply attacks.

   The client also SHOULD check the validity period of the response.  It
   SHOULD NOT, in order to minimize the load on an RQA, request again
   the location of the same resource within this interval to the same
   RQA.

   If the response is signed, the client SHOULD check the RQA's
   certificate validity.

3.2.1.  PRQP Request

   A PRQP request contains the following data:

   o  protocol version





Pala                      Expires June 11, 2009                 [Page 7]


Internet-Draft                    PRQP                     December 2008


   o  nonce

   o  MaxResponse

   o  ResourceRequestToken

   o  Extensions

   The ASN.1 syntax imports terms defined in [RFC4210].  For signature
   calculation, the data to be signed is encoded by using the DER
   format.  ASN.1 EXPLICIT tagging is used as a default unless specified
   otherwise.  The terms imported from [RFC3280] are: Extensions,
   Certificate, CertificateSerialNumber, SubjectPublicKeyInfo, Name,
   AlgorithmIdentifier.

3.2.1.1.  Request Syntax

   The PRQP request syntax is as follows:

       PRQPRequest ::= SEQUENCE {
           requestData            TBSReqData,
           signature              [0] EXPLICIT Signature OPTIONAL }

       TBSReqData ::= SEQUENCE {
           version                INTEGER { v(1) },
           nonce              [0] INTEGER              OPTIONAL,
                 -- very large number
           producedAt             GeneralizedTime,
                 -- time when the request has been generated
           serviceToken           ResourceRequestToken,
                 -- token identifying the requested service
           extensions         [1] IMPLICIT Extensions  OPTIONAL }

   The version field (currently v1) describes the version of the PRQP
   request.  The nonce field, if present, is an integer between 80 bits
   and 256 bit in length.  The producedAt define the time-frame when the
   request has been generated.

         ResourceRequestToken ::= SEQUENCE {
           ca                      CertIdentifier,
           servicesList        [0] SET OF ResourceIdentifier OPTIONAL }

   The ca field is of type CertIdentifier.  This is used to identify the
   certificate of the CA whose services are requested.

   The CertIdentifier syntax is as follows:





Pala                      Expires June 11, 2009                 [Page 8]


Internet-Draft                    PRQP                     December 2008


        BasicCertIdentifier ::= SEQUENCE {
          issuerNameHash              OCTET STRING,
          serialNumber                CertificateSerialNumber  }

        ExtendedCertInfo ::= SEQUENCE {
          certificateHash             OCTET STRING,
          subjectKeyHash              OCTET STRING,
          subjectKeyIdentifier    [0] KeyIdentifier          OPTIONAL,
          issuerKeyIdentifier     [1] KeyIdentifier          OPTIONAL  }

        CertIdentifier ::= SEQUENCE {
          hashAlgorithm               AlgorithmIdentifier,
          basicCertIdentifier         BasicCertIdentifier,
          extInfo                     [0] ExtendedCertInfo    OPTIONAL,
          caCertificate               [1] Certificate         OPTIONAL,
          issuedCertificate           [2] Certificate         OPTIONAL }

   The resourceList specifies the resources or services being requested.

        ResourceIdentifier ::= SEQUENCE {
          resourceId             OBJECT IDENTIFIER,
          version            [0] INTEGER             OPTIONAL
            --- version of the protocol or data format (if applicable) }

   The ResourceIdentifier is formed by an OID that identifies the
   service or the data being requested (e.g.  OCSP, LDAP, CRL, etc... )
   and an optional version number that may be used to better identify
   the requested resource.  All fields SHOULD be used whenever
   applicable.

   If one or more ResourceIdentifier are provided in the request, the
   RQA should report back the location for each of the requested
   services.  If no ResourceIdentifier is present in the request, the
   response should carry all the available service locations for the
   specified CA (with respect to the MaxResponse and optional parameters
   constrain).

   The signature field is of type Signature and it is defined in
   [RFC2560]:

         Signature ::= SEQUENCE {
           signatureAlgorithm     AlgorithmIdentifier,
           signature              BIT STRING,
           certs              [0] EXPLICIT SEQUENCE OF Certificate
                                                             OPTIONAL }

   Extensions can be used for future protocol enhancement.




Pala                      Expires June 11, 2009                 [Page 9]


Internet-Draft                    PRQP                     December 2008


3.2.2.  PRQP Response

   The PRQP response contains the following data:

   o  protocol version

   o  nonce

   o  status

   o  CA identifier

   o  ResourceResponseToken

   o  Extensions

3.2.2.1.  Response Syntax

   The response syntax is as follows:

       PRQPResponse ::= SEQUENCE {
         respData               TBSRespData,
         signature          [0] EXPLICIT Signature OPTIONAL }

       TBSRespData ::= SEQUENCE {
         version                INTEGER { v(1)},
         nonce              [0] INTEGER              OPTIONAL,
               -- as duplicated from the request
         producedAt             GeneralizedTime,
               -- time when the response has been generated
         nextUpdate         [1] GeneralizedTime      OPTIONAL,
               -- time till when the response should be considered valid
         pkiStatus              PKIStatusInfo,
               -- status of the response
         caCertId               CertIdentifier,
               -- identifier of the CA certificate that issued the
               -- targeted certificate
         responseToken      [2] SEQUENCE OF ResourceResponseToken
                                                               OPTIONAL,
               -- token carrying information about
               -- requested services
         extensions         [3] EXPLICIT Extensions  OPTIONAL }

   The version field (currently v1) describes the version of the used
   PRQP response.  The nonce, if present, binds the response to a
   specific request.  The usage of the nonce is meaningful only in
   signed responses and its value must be copied directly from the
   corresponding request.  If not present in the request, the nonce MUST



Pala                      Expires June 11, 2009                [Page 10]


Internet-Draft                    PRQP                     December 2008


   be omitted.

   The pkiStatus field is based on the definition of status in section
   3.2.3 of [RFC4210].  However, to limit the complexity of the field,
   the statusString field is of type UTF8String instead of PKIFreeText.

         PKIStatusInfo ::= SEQUENCE {
           status        PKIStatus,
           statusString  [0] UTF8String     OPTIONAL,
           failInfo      [1] PKIFailureInfo  OPTIONAL  }

   If status has value zero, a responseToken MUST be present in the
   response.  When the status value is non zero, the responseToken MUST
   be omitted and the reason code MUST be one of the values in
   PKIStatus.

         PKIStatus ::= INTEGER {
           ok                     (0),
              -- when the PKIStatus contains the value zero one or
                 more responseToken is present
           badRequest             (1),
              -- the request is badly formatted
           caNotPresent           (2),
              -- the requested CA is not present
           systemFailure          (3)
              -- a system failure has occurred }

   The signature field is of type Signature and it is defined in
   [RFC2560]:

         Signature ::= SEQUENCE {
           signatureAlgorithm     AlgorithmIdentifier,
           signature              BIT STRING,
           certs              [0] EXPLICIT SEQUENCE OF Certificate
                                                             OPTIONAL }

   The responseToken carries information about the services requested by
   the client.  For each of the requested service, the RQA should
   include a ResourceResponseToken which bears the OID of the service
   and the corresponding URI.

   The ResourceResponseToken syntax is described below:









Pala                      Expires June 11, 2009                [Page 11]


Internet-Draft                    PRQP                     December 2008


        ResourceResponseToken ::= SEQUENCE {
          resourceId              OBJECT IDENTIFIER,
              --- resource identifier
          resourceLocatorList [0] EXPLICIT SEQUENCE OF IA5String,
              --- sequence of resource locators (URI)
          version             [1] INTEGER             OPTIONAL,
              --- version of the protocol or data format (if applicable)
          resourceInfo        [2] UTF8Sting           OPTIONAL,
              --- additional service Info (eg. technical contacts) }

   The resourceId field value is copied from the corresponding request
   and it bears the OID of the service about which the client inquired.
   In section Section 4 we define a list of default PKI resources.


   The producedAt and nextUpdate define the time-frame when the response
   data is to be considered valid.  Within the defined period, the
   client SHOULD NOT request for the same service.  Use of wider time-
   frames values can help the RQA avoid duplication of requests from the
   same client thus potentially lowering the load of the responder.
   However, providing this data to a client does not ensure a lower
   query rate, as a server cannot rely on clients to obey the advice
   provided in the response.

   The resourceLocator bears access information for the service
   identified by the serviceId.  The name MUST be an absolute URL, and
   it MUST follow the URL syntax and encoding rules specified in
   [RFC4248] and [RFC4266].  The resourceLocator includes both a scheme
   (e.g., HTTP or FTP) and a scheme specific part.  The scheme specific
   part is supposed to carry information on how to reach the requested
   service, this is, for example, a fully qualified domain name or IP
   address as the host.  If the requested service is not available or it
   is unknown by the server, the resourceLocator value should be empty.

   Optional Extensions may be added if requested.


4.  Object Identifiers for PKI resources

   The PRQP defines a set of standard OIDs that are used to identify
   resources related to a Certification Authority.  In this section we
   provide a description for each of the defined OIDs.

   The services are all defined under the id-ad-prqp OID which is
   defined as follows:

     id-ad-prqp                OBJECT IDENTIFIER ::= {id-ad 12}




Pala                      Expires June 11, 2009                [Page 12]


Internet-Draft                    PRQP                     December 2008


4.1.  The RQA Service identifier

   When id-ad-prqp-rqa is used in a PRQP message, the associated value
   in the response is the location of the PRQP server (i.e., an RQA)
   using the conventions in this document or subsequent updates.

     id-ad-prqp-rqa            OBJECT IDENTIFIER ::= {id-ad-prqp 0}

   The version field, if used, indicates the supported protocol version.

4.2.  The OCSP identifier

   When id-ad-prqp-ocsp appears in a PRQP request or response, the
   associated value in the response is the location of the OCSP
   responder, using the conventions defined in [RFC2560].  The version
   field, if used, indicates the supported protocol version.

     id-ad-prqp-ocsp           OBJECT IDENTIFIER ::= {id-ad-prqp 1 }

4.3.  The Issuer's Certificate identifier

   When id-ad-issuerCert is used in a PRQP message, the associated value
   is in the response the location of the DER formatted certificate of
   the issuer of the identified CA.  The version field in the request
   SHOULD NOT be used and SHOULD be ignored in case it is present.  The
   version field MAY be used to specify the version of the certificate
   pointed by the URL in a PRQP Response message.  In order to enhance
   interoperability between applications and reduce development efforts,
   the URI should point directly to the certificate and not to a
   redirection service.

     id-ad-prqp-issuerCert     OBJECT IDENTIFIER ::= {id-ad-prqp 2 }

   HTTP server implementations accessed via the URI SHOULD specify the
   media type "application/x-x509-ca-cert" in the content-type header
   field of the response.

4.4.  The Timestamping Service identifier

   When id-ad-timestamping is used in a PRQP message, the associated
   value in the response is the location of the Timestamping responder,
   using the conventions defined in [RFC3161].  The version field, if
   used, indicates the supported protocol version.

     id-ad-prqp-timestamping   OBJECT IDENTIFIER ::= {id-ad-prqp 3 }






Pala                      Expires June 11, 2009                [Page 13]


Internet-Draft                    PRQP                     December 2008


4.5.  The SCVP Server identifier

   When id-ad-prqp-scvp appears in a PRQP request or response, the
   associated value in the response is the location of the SCVP
   responder, using the conventions defined in [RFC5055].  The version
   field, if used, indicates the supported protocol version.

     id-ad-prqp-scvp           OBJECT IDENTIFIER ::= {id-ad-prqp 4 }

4.6.  The CRL Distribution Point identifier

   When id-ad-prqp-crlDistribution appears in a PRQP message, the
   associated value in the response is a pointer to the current CRL.
   The URI MUST point to a single DER encoded CRL as specified in
   [RFC2585].  The version field, if used, indicates the version of the
   pointed CRL.  In order to enhance interoperability between
   applications and reduce development efforts, the URI should point
   directly to the CRL and not to a redirection service.

     id-ad-prqp-crlDistribution   OBJECT IDENTIFIER ::= {id-ad-prqp 5 }

   HTTP server implementations accessed via the URI SHOULD specify the
   media type "application/pkix-crl" in the content-type header field of
   the response.

4.7.  The Certificates Repository identifier

   When id-ad-prqp-certRepository appears in a PRQP message, the
   associated value in the response is a pointer to a set of
   certificates.  The URI MUST point to a collection of certificates in
   a DER encoded "certs-only" CMS message as specified in [RFC2797].

     id-ad-prqp-certRepository OBJECT IDENTIFIER ::= {id-ad-prqp 6 }

   HTTP server implementations accessed via the URI SHOULD specify the
   media type "application/pkcs7-mime" [RFC2797] in the content-type
   header field of the response.  The name of the returned file SHOULD
   have a suffix of ".p7c" [RFC2797].

4.8.  The CRL Repository identifier

   When id-ad-prqp-crlRepository appears in a PRQP message, the
   associated value is a pointer to a set of CRL.  The URI MUST point to
   a collection of CRLs in a DER encoded CMS message as.

     id-ad-prqp-crlRepository  OBJECT IDENTIFIER ::= {id-ad-prqp 7 }

   HTTP server implementations accessed via the URI SHOULD specify the



Pala                      Expires June 11, 2009                [Page 14]


Internet-Draft                    PRQP                     December 2008


   media type "application/pkcs7-mime" [RFC2797] in the content-type
   header field of the response.  The name of the returned file SHOULD
   have a suffix of ".p7c"

4.9.  The Cross Certificates Repository identifier

   When id-ad-prqp-crossCertRepository appears in a PRQP message, the
   associated value in the response is a pointer to a set of Cross
   Certificates.  The URI MUST point to a collection of certificates in
   DER encoded CertificatePair object defined as:

     CertificatePair ::= SEQUENCE {
        forward [0] Certificate OPTIONAL,
        reverse [1] Certificate OPTIONAL,
        -- at least one of the pair shall be present -- }

   The id-ad-prqp-crossCertRepository is defined as follows:

     id-ad-prqp-crossCertRepository
                               OBJECT IDENTIFIER ::= {id-ad-prqp 8 }

   As defined in [RFC4523], LDAP implementation store the
   CertificatePair in the crossCertificatePair attribute.

4.10.  The CMS Gateway identifier

   When id-ad-prqp-cmsGateway appears in a PRQP message, the associated
   value in the response is the location of the CMM over CMS service,
   using the conventions defined in [RFC2797].  As the [RFC2797] does
   not define a version for the protocol, if the version field is used
   to identify the service, applications SHOULD ignore it.

     id-ad-prqp-cmsGateway     OBJECT IDENTIFIER ::= {id-ad-prqp 10 }

4.11.  The SCEP Gateway identifier

   When id-ad-prqp-scepGateway appears in a PRQP message, the associated
   value in the response is the location of the CMM over CMS service,
   using the conventions defined in [I-D.nourse-scep].  The version
   field used to identify the service, if present, SHOULD be set to 0.

     id-ad-prqp-scepGateway    OBJECT IDENTIFIER ::= {id-ad-prqp 11 }

4.12.  The HTML Gateway identifier

   When id-ad-prqp-htmlGateway appears in a PRQP message, the associated
   value in the response is the location of a HTML CA service.  The
   version field identifies the version of HTML data.



Pala                      Expires June 11, 2009                [Page 15]


Internet-Draft                    PRQP                     December 2008


     id-ad-prqp-htmlGateway    OBJECT IDENTIFIER ::= {id-ad-prqp 12 }

4.13.  The XKMS Gateway identifier

   When id-ad-prqp-xkmsGateway appears in a PRQP message, the associated
   value in the response is the location of an XKMS server, using the
   conventions defined in [W3C.xkms] and [W3C.REC-xkms2-20050628].  The
   version field used to identify the service, if present, SHOULD be set
   to 1 for services compliant to [W3C.xkms] and to 2 for services
   compliant to [W3C.REC-xkms2-20050628].

     id-ad-prqp-xkmsGateway    OBJECT IDENTIFIER ::= {id-ad-prqp 13 }

4.14.  The Certificate Policy (CP) identifier

   When id-ad-prqp-certPolicy appears in a PRQP message, the associated
   value in the response is the location of a certificate Policy (CP).
   A CP may be used by a relying party to help in deciding whether a
   certificate, and the binding therein, are sufficiently trustworthy
   and otherwise appropriate for a particular application.

     id-ad-prqp-certPolicy     OBJECT IDENTIFIER ::= {id-ad-prqp 20 }

   More information can be found in [RFC2527].

4.15.  The Certification Practice Statement (CPS) identifier

   When id-ad-prqp-certPolicy appears in a PRQP message, the associated
   value in the response is the location of a Certification Practice
   Statement (CPS) published by the CA.  A CPS is a document that
   details the practices and procedures established by a CA that will
   cover the life-cycle of certificates issued by the CA.  That is it
   covers how the certificate will be generated, suspended and revoked.
   An internally focused document covering the internal environment of
   the CA.

     id-ad-prqp-certPracticeStatement
                               OBJECT IDENTIFIER ::= {id-ad-prqp 21 }

   More information can be found in [RFC2527].

4.16.  The Endorsed Trust Anchors identifier

   When id-ad-prqp-endorsedTA appears in a PRQP message, the associated
   value in the response is a pointer to a set of Trust Anchors (TA) in
   the form of certificates.  The URI MUST point to a collection of
   certificates in a DER encoded CMS signedData message as specified in
   [RFC2797].



Pala                      Expires June 11, 2009                [Page 16]


Internet-Draft                    PRQP                     December 2008


     id-ad-prqp-endorsedTA     OBJECT IDENTIFIER ::= {id-ad-prqp 22 }

   HTTP server implementations accessed via the URI SHOULD specify the
   media type "application/pkcs7-mime" [RFC2797] in the content-type
   header field of the response.  The name of the returned file SHOULD
   have a suffix of ".p7" [RFC2797].  The returned data object SHOULD be
   signed by the CA the endorsedTA service has been requested for.  The
   application SHOULD verify the signature on the CMS message before
   proceeding in accepting the set of TAs.  Moreover the application MAY
   import the set of certificates in its own certificate store as
   trusted depending on previous trust settings or input from the user.

4.17.  The LOA Policy (LP) identifier

   When id-ad-prqp-loaPolicy appears in a PRQP message, the associated
   value in the response is the location of a Level of Assurance Policy
   (LP) published by the CA.  An LP is a document that details the
   practices and procedures established by a CA that will cover the
   requirements for each Level of Assurance.

     id-ad-prqp-loaPolicy      OBJECT IDENTIFIER ::= {id-ad-prqp 25 }

   More information can be found in [RFC2527].

4.18.  The Certificate LOA Modifier identifier

   When id-ad-prqp-certLOAModifier appears in a PRQP message, the
   associated value in the response is the location of a LOA Level
   Modifier.  The LOA modifier service is used to identify the current
   LOA Level of the certificate (not the LOA under which the certificate
   has been issued).

     id-ad-prqp-certLOAModifier OBJECT IDENTIFIER ::= {id-ad-prqp 26 }

4.19.  The HTML Certificate Request Service identifier

   When id-ad-prqp-htmlRequestCertificate appears in a PRQP message, the
   associated value in the response is the location of a HTML
   certificate request service.  The version field, when present,
   identifies the version of the supported HTML format.  As not standard
   exists that describes how to interact with a CA via HTML, this
   locator should be mainly used for browser-based certification
   requests.

     id-ad-prqp-htmlRequestCertificate
                               OBJECT IDENTIFIER ::= {id-ad-prqp 30}





Pala                      Expires June 11, 2009                [Page 17]


Internet-Draft                    PRQP                     December 2008


4.20.  The HTML Certificate Revoke Service identifier

   When id-ad-prqp-htmlRevokeCertificate appears in a PRQP message, the
   associated value in the response is the location of a HTML
   certificate revoking service.  The version field, when present,
   identifies the version of the supported HTML format.  As not standard
   exists that describes how to interact with a CA via HTML, this
   locator should be mainly used for browser-based certification
   requests.

     id-ad-prqp-htmlRevokeCertificate
                               OBJECT IDENTIFIER ::= {id-ad-prqp 31}

4.21.  The HTML Certificate Renew Service identifier

   When id-ad-prqp-htmlRenewCertificate appears in a PRQP message, the
   associated value in the response is the location of a HTML
   certificate renewal service.  The version field, when present,
   identifies the version of the supported HTML format.  As not standard
   exists that describes how to interact with a CA via HTML, this
   locator should be mainly used for browser-based certificate renewal
   requests.

     id-ad-prqp-htmlRenewCertificate
                               OBJECT IDENTIFIER ::= {id-ad-prqp 32}

4.22.  The HTML Certificate Suspend Service identifier

   When id-ad-prqp-htmlSuspendCertificate appears in a PRQP message, the
   associated value in the response is the location of a HTML
   certificate suspension service.  The version field, when present,
   identifies the version of the supported HTML format.  As not standard
   exists that describes how to interact with a CA via HTML, this
   locator should be mainly used for browser-based certificate
   suspension requests.

     id-ad-prqp-htmlRenewCertificate
                               OBJECT IDENTIFIER ::= {id-ad-prqp 33}

4.23.  The Grid Accreditation Body identifier

   When id-ad-prqp-grid-accreditationBody appears in a PRQP message, the
   associated value in the response is the location of the main
   information point of the Grid Policy Management Authority (GPMA) that
   accredited the CA.  The pointer SHOULD NOT be present if the CA has
   not been accredited by the GPMA.

     id-ad-prqp-grid-accreditationBody



Pala                      Expires June 11, 2009                [Page 18]


Internet-Draft                    PRQP                     December 2008


                                   OBJECT IDENTIFIER ::= {id-ad-prqp 50}

4.24.  The Grid Policy identifier

   When id-ad-prqp-grid-accreditationPolicy appears in a PRQP message,
   the associated value in the response is the location of an
   Accreditation Policy published by a Grid Policy Management Authority
   (GPMA).  The pointer SHOULD NOT be present if the CA has not been
   accredited by the GPMA.  A Grid Policy (GP) is a document that
   details the practices and procedures required from a CA in order to
   be accredited by the GPMA.

     id-ad-prqp-grid-accreditationPolicy
                                   OBJECT IDENTIFIER ::= {id-ad-prqp 51}

4.25.  The Grid DistributionUpdate identifier

   When id-ad-prqp-grid-commonDistributionUpdate appears in a PRQP
   message, the associated value in the response is the location of the
   Grid Distribution Package associated with the Grid Policy Management
   Authority (GPMA) that accredited the CA.  The pointer SHOULD NOT be
   present if the CA has not been accredited by the GPMA.

     id-ad-prqp-grid-commonDistributionUpdate
                                   OBJECT_IDENTIFIER ::= {id-ad-prqp 53}

4.26.  The TAMP Update identifier

   When id-ad-prqp-tampUpdate appears in a PRQP message, the associated
   value in the response is the location of a Trust Anchor Management
   data package, using the conventions defined in [I-D.pkix-tamp].  The
   version field used to identify the service, if present, SHOULD
   reflect the supported TAMP version.

     id-ad-prqp-tampUpdate     OBJECT IDENTIFIER ::= {id-ad-prqp 70 }

4.27.  The CA Incident Report identifier

   When id-ad-prqp-caIncidentReport appears in a PRQP message, the
   associated value in the response is the location of a Incident Report
   submission service.  No standard mechanisms are currently defined for
   this type of service, therefore the The resourceInfo field in the
   response SHOULD be used to provide information on the provided
   Incident Report service.  For example while the URI could point to a
   web-page carrying contacts information or a ticketing system for
   reporting CA-related incidents, the resourceInfo field could provide
   text carrying information that may be displayed to the user (e.g., a
   support phone number).  This would allow support for a wide range of



Pala                      Expires June 11, 2009                [Page 19]


Internet-Draft                    PRQP                     December 2008


   different devices and applications as long as they have the ability
   to display or read the content of the resourceInfo field to the user.

     id-ad-prqp-caIncidentReport
                               OBJECT IDENTIFIER ::= {id-ad-prqp 90}

4.28.  The Private Resources identifier

   When an application wants to identify private resources, i.e.
   services that are not standardized in the PRQP standard definition,
   id-ad-prqp-private should be used as the base OID:

     id-ad-prqp-private        OBJECT IDENTIFIER ::= {id-ad-prqp 100}

   The OIDs for a private resource can be identified as follows:

     myPrivateResource     OBJECT IDENTIFIER ::= {id-ad-prqp-private N}


5.  IANA Considerations

   This document has no actions for IANA.


6.  PRQP Design Rationale

   In this section we provide some considerations about the protocol
   design and its details.

6.1.  Response Complexity

   An important design consideration is the complexity of messages.
   Some type of services, e.g. delta CRLs, can be directly detected upon
   data downloading.  On the contrary if a client is looking for a
   specific version of a protocol or data type, the definition of a
   fine-grained query system would allow for data downloading only when
   it is actually supported by the requesting client, thus reducing the
   server's load.

   At present we think that keeping the protocol simple will encourage
   its adoption in current environments because the flexibility
   introduced by PRQP is a big enhancement over the current options.

   Moreover, without requiring changes to the protocol, extensions could
   be defined to provide more fine grained options.

   Future versions of the protocol may implement extended request and
   response types if required by applications.



Pala                      Expires June 11, 2009                [Page 20]


Internet-Draft                    PRQP                     December 2008


6.2.  RQA's URL distribution

   The AIA and SIA extensions in certificates can be used to carry the
   pointer to the RQA.  If no RQA address is present in the certificate,
   a client application could use a default configured URL.

   Although this approach seems to contradict the criticism of
   Certificate extensions use in Section 2.1.1, using only one extension
   to locate the RQA would provide an easy way to distribute the RQA's
   URL.

   The usage of PRQP will provide a gateway for all the other services
   and data URLs.

6.3.  Security Considerations

   The PRQP provides URLs for PKI resources.  This means that it
   provides locators to data and services, not the data per se.  It
   still remains the client's job to access the provided URLs to gather
   the needed data.

   Both NONCEs and signatures are optional in order to provide
   flexibility in how requests and responses are generated.

   It is possible to provide pre-computed responses in case the NONCE is
   not provided by the client.  This allows the RQA to generate off-line
   signatures for responses, an optimization used in OCSP.

   Moreover if an authenticated secure channel is used at the transport
   level between the client and the RQA (e.g.  HTTPS or SFTP) signatures
   in requests and responses can be safely omitted.

6.4.  Time Validity

   The time validity should reflect the frequency of updates in
   configured URLs.  An interesting aspect to be considered is how often
   would users execute the protocol for a given set of data.

   If the clients query the server often it could be a serious burden on
   the server but, if executed rarely, clients would not be able to
   discover changes in provided resources.

   As described in more detail in Appendix A, the adoption of a validity
   time frame for responses can be used as a mean to balance the trade
   off between this two aspects, but this is merely advisory data for
   clients and thus not a guarantee against DoS attacks by clients.





Pala                      Expires June 11, 2009                [Page 21]


Internet-Draft                    PRQP                     December 2008


6.5.  Message Format

   Two different candidates have been considered.  The first one is the
   Extensible Markup Language (XML), while the second one is the
   Distinguished Encoding Rules (DER).

   The adoption of the Abstract Syntax Notation (ASN.1) to describe the
   data structures allows a software developer to provide either DER or
   XML based implementations of the protocol.

   However we think that a DER based implementation of PRQP is the best
   choice because of compatibility considerations with existing
   applications and APIs.  Moreover DER encoded messages are smaller in
   size then XML encoded ones and almost all PKI aware applications
   already support it.


7.  Acknowledgments

   The authors would like to thank Stephen Kent for his insightful
   comments about PRQP and his help in writing this document.


8.  References

8.1.  Normative References

   [I-D.ietf-dhc-option-guidelines]
              Hankins, D., "Guidelines for Creating New DHCP Options",
              draft-ietf-dhc-option-guidelines-03 (work in progress),
              October 2008.

   [I-D.pkix-tamp]
              Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
              Management Protocol (TAMP)", draft-ietf-pkix-tamp (work in
              progress), October 2008.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2527]  Chokhani, S. and W. Ford, "Internet X.509 Public Key
              Infrastructure Certificate Policy and Certification
              Practices Framework", RFC 2527, March 1999.

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.



Pala                      Expires June 11, 2009                [Page 22]


Internet-Draft                    PRQP                     December 2008


              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

   [RFC2585]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
              Infrastructure Operational Protocols: FTP and HTTP",
              RFC 2585, May 1999.

   [RFC2608]  Guttman, E., Perkins, C., Veizades, J., and M. Day,
              "Service Location Protocol, Version 2", RFC 2608,
              June 1999.

   [RFC2609]  Guttman, E., Perkins, C., and J. Kempf, "Service Templates
              and Service: Schemes", RFC 2609, June 1999.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2797]  Myers, M., Liu, X., Schaad, J., and J. Weinstein,
              "Certificate Management Messages over CMS", RFC 2797,
              April 2000.

   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, August 2001.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210, September 2005.

   [RFC4248]  Hoffman, P., "The telnet URI Scheme", RFC 4248,
              October 2005.

   [RFC4266]  Hoffman, P., "The gopher URI Scheme", RFC 4266,
              November 2005.

   [RFC5055]  Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
              Polk, "Server-Based Certificate Validation Protocol
              (SCVP)", RFC 5055, December 2007.



Pala                      Expires June 11, 2009                [Page 23]


Internet-Draft                    PRQP                     December 2008


8.2.  Non-Normative References

   [I-D.nourse-scep]
              Liu, X., "Cisco Systems' Simple Certificate Enrollment
              Protocol", draft-nourse-scep-17 (work in progress),
              June 2008.

   [PEACH]    Pala, M. and S. Smith, "Peaches and Peers", LNCS 5057,
              June 2008.

   [RFC4523]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP) Schema Definitions for X.509 Certificates",
              RFC 4523, June 2006.

   [W3C.REC-xkms2-20050628]
              Mysore, S. and P. Hallam-Baker, "XML Key Management
              Specification (XKMS 2.0)", World Wide Web Consortium
              Recommendation REC-xkms2-20050628, June 2005,
              <http://www.w3.org/TR/2005/REC-xkms2-20050628>.

   [W3C.xkms]
              Ford, W., Hallam-Baker, P., Fox, B., Dillaway, B.,
              LaMacchia, B., Epstein, J., and J. Lapp, "XML Key
              Management Specification (XKMS)", W3C Note xkms,
              March 2001, <http://www.w3.org/TR/xkms/>.


Appendix A.  Transport Protocol Specifications for PRQP Messages

A.1.  PRQP over HTTP

   This section describes the formatting needed in order to route PRQP
   request and response over HTTP.

A.1.1.  Request

   HTTP based PRQP requests SHOULD use the POST method to submit their
   requests.  Where privacy is a requirement, PRQP transactions
   exchanged using HTTP MAY be protected using either TLS/SSL or some
   other lower layer protocol.

   The required HTTP headers for the request are:

   o  Content-Type

   o  Content-Transfer-Encoding





Pala                      Expires June 11, 2009                [Page 24]


Internet-Draft                    PRQP                     December 2008


   o  Content-Length

   The Content-Type header SHOULD be set to "application/prqp-request".
   The Content-Transfer-Encoding SHOULD be set to "Binary", while the
   Content-Length SHOULD be set to the length (in bytes) of the body of
   the request.  The body of the HTTP message MUST carry the binary
   value of the DER encoding of the PRQPRequest.

A.1.2.  Response

   An HTTP-based PRQP response is composed of the appropriate HTTP
   headers, followed by the binary value of the DER encoding of the
   PRQPPResponse.

   The required HTTP headers for the response are:

   o  Content-Type

   o  Content-Transfer-Encoding

   o  Content-Length

   The Content-Type header SHOULD be set to "application/prqp-response".
   The Content-Transfer-Encoding SHOULD be set to "Binary", while the
   Content-Length SHOULD be set to the length (in bytes) of the body of
   the request.  The body of the HTTP message MUST carry the binary
   value of the DER encoding of the PRQPResponse.

A.1.3.  Message Caching

   To minimize bandwidth usage, clients MUST locally cache authoritative
   PRQP responses for the validity period of the request.  To enable
   proxy servers to be able to cache responses as well, additional HTTP
   headers MAY be used in the response.

   The PRQP responder MAY ease caching by setting the following headers:

   o  date

   o  last-modified

   o  expires

   In particular, the date field SHOULD carry the date at which the HTTP
   response has been generated.  The last-modified, instead, SHOULD bear
   the date at which the response has been modified.  This field SHOULD
   carry the same date as the producedAt field of the PRQPResponse.  The
   expires field SHOULD carry the date till when the response is to be



Pala                      Expires June 11, 2009                [Page 25]


Internet-Draft                    PRQP                     December 2008


   considered valid.  This field SHOULD carry the same date as in the
   nextUpdate field of the PRQPResponse.

   An example HTTP response would look like:

         HTTP/1.0 200 OK
         Content-Type: application/prqp-response
         Content-Transfer-Encoding: Binary
         Content-Length: 860
         Date: Thu, 03 May 2007 04:43:43 GMT
         Last-Modified: Thu, 03 May 2007 04:43:42 GMT
         Expires: Thu, 04 May 2007 04:43:42 GMT

         <...response data...>

   PRQP clients SHOULD NOT included a no-cache header in PRQP request
   messages, unless the client encounters an expired response which may
   be a result of an intermediate proxy caching stale data.

A.2.  PRQP over Peer-to-Peer Network

   PRQP offers a starting point for the development of a PKI Resource
   Discovery Architecture where different RQAs cooperate to access data
   not locally available.

   One technology that already provides good results in data sharing is
   Peer-to-Peer (P2P) networking.

   Signed PRQP requests and responses can be routed also on existing P2P
   networks or a PRQP-specific network can be setup to provide a World
   Wide PKI Resources Discovery Architecture (PRDA), the definition of
   which is out of the scope of this document.  An example of such an
   architecture is PEACH [PEACH]


Appendix B.  RQA address Retrieval

B.1.  DHCP Specifications

   This section describes the needed steps to distribute RQAs addresses
   by using DHCP extensions.  In particular we define the DHCP option
   needed to identify an RQA server and we suggest options parsing for
   DHCP server and clients.

B.1.1.  PRQP Servers IPv4 Option for DHCPv4

   We define a prqp-servers option for DHCPv4 that specifies a list of
   Resource Query Authorities (PRQP servers) available to the client.



Pala                      Expires June 11, 2009                [Page 26]


Internet-Draft                    PRQP                     December 2008


   The RQA address MUST be expressed as IPv4 addresses.  Servers SHOULD
   be listed in order of preference and clients MUST treat the list of
   PRQP servers as an ordered list.

   The format for the prqp-servers option is as shown below:

        Code   Len  Address 1               Address 2
        +-----+-----+-----+-----+-----+-----+-----+--
        | TBD |  n  | a1  | a2  | a3  | a4  | a1  |  ...
        +-----+-----+-----+-----+-----+-----+-----+--

   The code for the pki resource query authority list option is TBD.
   The minimum length for this option is 1 octets.

B.1.2.  PRQP Servers IPv6 Option for DHCPv6

   We define a prqp-servers option for DHCPv6 that specifies a list of
   Resource Query Authorities (PRQP servers) available to the client.
   The RQA address MUST be expressed as IPv6 addresses (128-bit).
   Servers SHOULD be listed in order of preference and clients MUST
   treat the list of PRQP servers as an ordered list.

   The format for the prqp-servers option is as follows:

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        OPTION_RQA_LIST        |         option-len            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                    PRQP server (IPv6 address)                 |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                    PRQP server (IPv6 address)                 |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code:  OPTION_PRQP_SERVERS (TBD)

    option-len:   Length of the 'PRQP servers' field in octets; it must
                  be a multiple of 16

    PRQP server:  IPv6 address of Resource Query Authority (PRQP) Server

   The RQA address(es) specified in the 'PRQP server' MUST be encoded as



Pala                      Expires June 11, 2009                [Page 27]


Internet-Draft                    PRQP                     December 2008


   IPv6 addresses.  The code for the prqp-servers option for IPv6 is
   TBD.  The minimum length for this option is 1 octets.

B.1.3.  DHCP Configuration

   As reported in [I-D.ietf-dhc-option-guidelines], one of the most
   deployed DHCP package is the ISC DHCP, mostly written by Ted Lemon in
   cooperation with Nominum, Inc. and now maintained by Internet Systems
   Consortium, Inc. ("ISC").  In order to provide developers and system
   administrators with deployment guidelines, we provide example
   configurations for both the server and the client.

   Below is a sample configuration for the pki resource query
   authorities option that can be added both the dhclient.conf (on
   clients) and dhcpd.conf (on servers) for IPv4:

        option prqp-servers code TBD = array of ip-address;

   If your environment supports IPv6, you should provide the option as a
   list of IPv6 addresses as follows:

        option prqp-servers code TBD = array of ipv6-address;

   In addition to this, in order for the server to pass on the
   configuration to the clients, the following example configuration
   options could be used in the server's configuration file (typically
   /etc/dhcpd.conf):

        ...
        subnet XXX.XXX.XXX.XXX netmask YYY.YYY.YYY.YYY {
             ...
             option prqp-servers   rqa.openca.org,
                                   rqa3.dartmouth.edu,
                                   rqa5.mydomain.org;
        }
        ...

B.1.4.  DHCP Client Processing

   In order to provide applications deriving their configuration
   parameters from values provided by this DHCP option, the dhcp client
   needs to format the on-the-wire bits in a more digestible one.  In
   particular for the "prqp-servers" option, a configuration file should
   be created as:

          /etc/pki.conf

   where the list of addresses can be stored.  An example of such a file



Pala                      Expires June 11, 2009                [Page 28]


Internet-Draft                    PRQP                     December 2008


   is reported below:

          queryauthority rqa.openca.org
          queryauthority rqa3.dartmouth.edu
          queryauthority 127.0.0.1

   where each line has the format:

          queryauthority <ADDRESS>

B.2.  DNS SRV Records

   This section describes the needed steps to distribute RQAs addresses
   by using DNS SRV records.  In particular we define the format to use
   for the SRV records.  As an example we also provide a sample zone
   file.

B.2.1.  SRV Record Format for PRQP

   The format for DNS SRV records MUST be compliant with [RFC2782].  In
   particular, in order to support PRQP, a DNS server MUST use the
   following:

      _Service._Proto.Name TTL Class SRV Priority Weight Port Target

   Where:

   o  Service is the symbolic name of the desired service.  This field
      MUST be set to "rqa"

   o  Proto is the symbolic name of the protocol to be used.  This field
      MUST be set to "_tcp"

   o  Name is the domain this RR refers to, i.e. the hostname of the RQA
      server

   o  TTL has the standard DNS meaning, refer to [RFC1035] for more
      information.

   o  Class has Standard DNS meaning [RFC1035].  This field MUST be set
      to "IN"

   o  Priority is the priority of this target host.  The allowed range
      of values is 0-65535 (16 bit unsigned integer in network byte
      order).

   o  Weight is used for server selection mechanism.  The weight field
      specifies a relative weight for entries with the same priority.



Pala                      Expires June 11, 2009                [Page 29]


Internet-Draft                    PRQP                     December 2008


      The allowed range of values is 0-65535 (16 bit unsigned integer in
      network byte order).  A more detailed description of the Weight
      usage can be found in [RFC2782].

B.2.2.  Example: PRQP enabled zone file

   In this section we provide a sample zone file for the domain
   .openca.org.  In this example we configure service records for three
   different RQAs.

         $ORIGIN openca.org.
         @               SOA server.openca.org. root.openca.org. (
                             1995032001 3600 3600 604800 86400 )
                      NS  server.openca.org.
                      NS  ns1.ip-provider.net.
                      NS  ns2.ip-provider.net.
         ; first two rqa server lines, they have the same priority,
         ; but different weight
         _rqa._tcp    SRV 0  1 830 rqa.openca.org.
                      SRV 0  3 830 rqa2.openca.org.
         ; last chance - lower priority because it is a very slow box
                      SRV 10 0 830 rqa-slow.openca.org.
         rqa          A   129.170.214.89
         rqa2         A   129.170.212.31
         rqa-slow     A   64.233.167.99
         ; NO other services are supported
         *._tcp       SRV  0 0 0 .
         *._udp       SRV  0 0 0 .


Appendix C.  PRQP ASN1.1 Specification

PRQP DEFINITIONS EXPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS

      -- Directory Authentication Framework (X.509)
            Certificate, AlgorithmIdentifier
            FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                     module(1) authenticationFramework(7) 3 }


      --  PKIX Certificate Extensions
            AuthorityKeyIdentifier, SubjectKeyIdentifier, KeyIdentifier,



Pala                      Expires June 11, 2009                [Page 30]


Internet-Draft                    PRQP                     December 2008


          FROM PKIX1Implicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-implicit-88(2)}


             CertificateSerialNumber, Extensions, id-kp, id-ad-prqp
          FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-explicit-88(1)};


    PRQPRequest ::= SEQUENCE {
        requestData            TBSReqData,
        signature              [0] EXPLICIT Signature OPTIONAL }

    TBSReqData ::= SEQUENCE {
        version                INTEGER { v(1) },
        nonce              [0] INTEGER              OPTIONAL,
              -- very large number
        producedAt             GeneralizedTime,
              -- time when the request has been generated
        serviceToken           ResourceRequestToken,
              -- token identifying the requested service
        extensions         [1] IMPLICIT Extensions  OPTIONAL }

    ResourceRequestToken ::= SEQUENCE {
        ca                      CertIdentifier,
        servicesList        [0] SET OF ResourceIdentifier OPTIONAL }

      BasicCertIdentifier ::= SEQUENCE {
        issuerNameHash              OCTET STRING,
        serialNumber                CertificateSerialNumber  }

      ExtenderCertInfo ::= SEQUENCE {
        certificateHash             OCTET STRING,
        subjectKeyHash              OCTET STRING,
        subjectKeyIdentifier    [0] KeyIdentifier          OPTIONAL,
        issuerKeyIdentifier     [1] KeyIdentifier          OPTIONAL  }

      CertIdentifier ::= SEQUENCE {
        hashAlgorithm               AlgorithmIdentifier,
        basicCertIdentifier         BasicCertIdentifier,
        extInfo                     [0] ExtendedCertInfo    OPTIONAL,
        caCertificate               [1] Certificate         OPTIONAL,
        issuedCertificate           [2] Certificate         OPTIONAL }


      ResourceIdentifier ::= SEQUENCE {



Pala                      Expires June 11, 2009                [Page 31]


Internet-Draft                    PRQP                     December 2008


        resourceId             OBJECT IDENTIFIER,
        version            [0] INTEGER             OPTIONAL
          --- version of the protocol or data format (if applicable) }


    PRQPResponse ::= SEQUENCE {
        respData               TBSRespData,
        signature          [0] EXPLICIT Signature OPTIONAL           }


    TBSRespData ::= SEQUENCE {
        version                INTEGER { v(1)},
        nonce                  INTEGER              OPTIONAL,
              -- as duplicated from the request
        producedAt             GeneralizedTime,
              -- time when the response has been generated
        nextUpdate         [0] GeneralizedTime      OPTIONAL,
              -- time till when the response should be considered
              -- valid
        pkiStatus              PKIStatusInfo,
              -- status of the response
        caCertId               CertIdentifier,
              -- identifier of the CA the targeted certificate is
              -- issued from
        responseToken          SEQUENCE OF ResourceResponseToken
                                                             OPTIONAL,
              -- token carrying information about
              -- requested services
        extensions         [0] EXPLICIT Extensions  OPTIONAL }


    PKIStatusInfo ::= SEQUENCE {
        status        PKIStatus,
        statusString  [0] UTF8String     OPTIONAL,
        failInfo      [1] PKIFailureInfo  OPTIONAL  }


    PKIStatus ::= INTEGER {
        ok                     (0),
           -- when the PKIStatus contains the value zero one or
              more responseToken is present
        badRequest             (1),
           -- the request is badly formatted
        caNotPresent           (2),
           -- the requested CA is not present
        systemFailure          (3)
           -- a system failure has occourred }




Pala                      Expires June 11, 2009                [Page 32]


Internet-Draft                    PRQP                     December 2008


    Signature ::= SEQUENCE {
        signatureAlgorithm     AlgorithmIdentifier,
        signature              BIT STRING,
        certs              [0] EXPLICIT SEQUENCE OF Certificate
                                                          OPTIONAL }

    ResourceResponseToken ::= SEQUENCE {
        resourceId              OBJECT IDENTIFIER,
           --- resource identifier
        resourceLocatorList [0] EXPLICIT SEQUENCE OF IA5String,
            --- sequence of resource locators (URI)
        version             [1] INTEGER             OPTIONAL,
            --- version of the protocol or data format (if applicable)
        resourceInfo        [2] UTF8Sting           OPTIONAL,
            --- additional service Info (eg. technical contacts) }


-- Object Identifiers

id-kp-PRQPSigning       OBJECT IDENTIFIER ::= { id-kp 10 }
id-prqp                 OBJECT IDENTIFIER ::= { id-pkix 23 }
id-prqp-pta             OBJECT IDENTIFIER ::= { id-prqp 1 }


id-ad-prqp                    OBJECT IDENTIFIER ::= {id-ad 12 }
id-ad-prqp-rqa                OBJECT IDENTIFIER ::= {id-ad-prqp 0}
id-ad-prqp-ocsp               OBJECT IDENTIFIER ::= {id-ad-prqp 1}
id-ad-prqp-issuerCert         OBJECT IDENTIFIER ::= {id-ad-prqp 2}
id-ad-prqp-timestamping       OBJECT IDENTIFIER ::= {id-ad-prqp 3}
id-ad-prqp-scvp               OBJECT IDENTIFIER ::= {id-ad-prqp 4}
id-ad-prqp-crlDistribution    OBJECT IDENTIFIER ::= {id-ad-prqp 5}
id-ad-prqp-certRepository     OBJECT IDENTIFIER ::= {id-ad-prqp 6}
id-ad-prqp-crlRepository      OBJECT IDENTIFIER ::= {id-ad-prqp 7}
id-ad-prqp-crossCertRepository OBJECT IDENTIFIER ::= {id-ad-prqp 8}
id-ad-prqp-cmsGateway         OBJECT IDENTIFIER ::= {id-ad-prqp 10}
id-ad-prqp-scepGateway        OBJECT IDENTIFIER ::= {id-ad-prqp 11}
id-ad-prqp-htmlGateway        OBJECT IDENTIFIER ::= {id-ad-prqp 12}
id-ad-prqp-xkmsGateway        OBJECT IDENTIFIER ::= {id-ad-prqp 13}
id-ad-prqp-certPolicy         OBJECT IDENTIFIER ::= {id-ad-prqp 20}
id-ad-prqp-certPracticesStatement OBJECT IDENTIFIER ::= {id-ad-prqp 21}
id-ad-prqp-endorsedTA         OBJECT IDENTIFIER ::= {id-ad-prqp 22}
id-ad-prqp-loaPolicy          OBJECT IDENTIFIER ::= {id-ad-prqp 25}
id-ad-prqp-certLOALevel       OBJECT IDENTIFIER ::= {id-ad-prqp 26}
id-ad-prqp-htmlRequestCertificate OBJECT IDENTIFIER ::= {id-ad-prqp 30}
id-ad-prqp-htmlRevokeCertificate OBJECT IDENTIFIER ::= {id-ad-prqp 31}
id-ad-prqp-htmlRenewCertificate OBJECT IDENTIFIER ::= {id-ad-prqp 32}
id-ad-prqp-htmlSuspendCertificate OBJECT IDENTIFIER ::= {id-ad-prqp 33}
id-ad-prqp-tampUpdate         OBJECT IDENTIFIER ::= {id-ad-prqp 70}



Pala                      Expires June 11, 2009                [Page 33]


Internet-Draft                    PRQP                     December 2008


id-ad-prqp-caIncidentReport   OBJECT IDENTIFIER ::= {id-ad-prqp 90}
id-ad-prqp-private            OBJECT IDENTIFIER ::= {id-ad-prqp 100}



Author's Address

   Massimiliano Pala
   Dartmouth College
   6211 Sudikoff PKI/Trust Lab
   Hanover, NH  03755
   US

   Email: pala@cs.dartmouth.edu
   URI:   http://www.openca.org




































Pala                      Expires June 11, 2009                [Page 34]


Internet-Draft                    PRQP                     December 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Pala                      Expires June 11, 2009                [Page 35]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/