PKI Resource Query Protocol (PRQP)Dartmouth College6211 Sudikoff PKI/Trust LabHanoverNH03755USpala@cs.dartmouth.eduhttp://www.openca.org
Security
PKIX Working GroupPKIResource DiscoveryProtocolOne 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.
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 .
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.
Currently there are three options to find URLs providing
access to PKI data:
by including such data in certificate extensionsby searching easily accessible repositories (e.g. DNS, local
database, etc.)by adapting existing protocols (e.g. SLP)
To provide pointers to published data it is possible to use
the Authority Information Access (AIA) Subject Information Access
(SIA) extensions defined by PKIX .
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 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.
The SRV record technique provides pointers to servers via the
DNS .
As defined in , 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.
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) .
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 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.
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.
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.
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 }
The protocol encompasses the exchange of a single round of messages
between a client and an RQA:
the client requests a resource token by sending a request to the
RQAthe 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.
A PRQP request contains the following data:
protocol versionnonceMaxResponseResourceRequestTokenExtensions
The ASN.1 syntax imports terms defined in .
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 are: Extensions, Certificate,
CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier.
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:
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
:
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL }
Extensions can be used for future protocol enhancement.
The PRQP response contains the following data:
protocol versionnoncestatusCA identifierResourceResponseTokenExtensions
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 be omitted.
The pkiStatus field is based on the definition of status in section 3.2.3
of . 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
:
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:
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 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
and .
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.
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}
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.
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
. The version field, if used, indicates the supported
protocol version.
id-ad-prqp-ocsp OBJECT IDENTIFIER ::= {id-ad-prqp 1 }
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.
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
. The version field, if used, indicates the supported
protocol version.
id-ad-prqp-timestamping OBJECT IDENTIFIER ::= {id-ad-prqp 3 }
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
. The version field, if used, indicates the supported
protocol version.
id-ad-prqp-scvp OBJECT IDENTIFIER ::= {id-ad-prqp 4 }
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 . 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.
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 .
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" in the content-type header field
of the response. The name of the returned file SHOULD have a suffix of ".p7c"
.
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 media type
"application/pkcs7-mime" in the content-type header field
of the response. The name of the returned file SHOULD have a suffix of ".p7c"
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 , LDAP implementation store the CertificatePair in
the crossCertificatePair attribute.
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 . As the 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 }
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 . 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 }
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.
id-ad-prqp-htmlGateway OBJECT IDENTIFIER ::= {id-ad-prqp 12 }
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 and . The version field used to
identify the service, if present, SHOULD be set to 1 for services compliant to
and to 2 for services compliant to .
id-ad-prqp-xkmsGateway OBJECT IDENTIFIER ::= {id-ad-prqp 13 }
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 .
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 .
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 .
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" in the content-type header field
of the response. The name of the returned file SHOULD have a suffix of ".p7"
. 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.
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 .
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 }
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}
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}
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}
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}
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
OBJECT IDENTIFIER ::= {id-ad-prqp 50}
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}
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}
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 . 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 }
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 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}
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}
This document has no actions for IANA.
In this section we provide some considerations about the protocol design
and its details.
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.
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 , 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.
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.
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 ,
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.
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.
The authors would like to thank Stephen Kent for his insightful comments
about PRQP and his help in writing this document.
Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
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
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS TRACK] Domain names - implementation and specificationUSC/ISI4676 Admiralty WayMarina del ReyCA90291US+1 213 822 1511A DNS RR for specifying the location of services (DNS SRV)Troll TechWaldemar Thranes gate 98BOsloN-0175NO+47 22 806390+47 22 806380arnt@troll.noInternet Software Consortium950 Charter StreetRedwood CityCA94063US+1 650 779 7001Microsoft CorporationOne Microsoft WayRedmondWA98052USlevone@microsoft.comThis document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS TRACK]X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSPVeriSign, Inc.1350 Charleston RoadMountain ViewCA94043USmmyers@verisign.comCertCo, LLC13506 King Charles Dr.ChantillyVA20151USrankney@erols.comValiCert, Inc.1215 Terra Bella AvenueMountain ViewCA94043US+1 650 567 5457ambarish@valicert.comMy CFO, Inc.1945 Charleston RoadMountain ViewCA94043USgalperin@mycfo.comEntrust Technologies750 Heron RoadSuite E08OttawaOntarioK1V 1A7CAcadams@entrust.comThis document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.An overview of the protocol is provided in section 2. Functional
requirements are specified in section 4. Details of the protocol are
in section 5. We cover security issues with the protocol in section
6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
syntactic elements and appendix C specifies the mime types for the
messages.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document (in uppercase, as shown) are to be interpreted as described
in.The telnet URI SchemeThis document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS TRACK]The gopher URI SchemeThis document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS TRACK]Dynamic Host Configuration Protocol for IPv6 (DHCPv6)Guidelines for Creating New DHCP OptionsThis document seeks to provide guidance to prospective DHCP Option authors, to help them in producing option formats that are easily adoptable.Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS TRACK]Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTPSPYRUS381 Elden StreetSuite 1120Suite 1120HerndonVA20170UShousley@spyrus.comInternet Mail Consortium127 Segre PlaceSanta CruzCA95060USphoffman@imc.orgThe protocol conventions described in this document
satisfy some of
the operational requirements of the Internet Public Key
Infrastructure (PKI).
This document specifies the conventions for
using the File Transfer Protocol (FTP) and the Hypertext Transfer
Protocol (HTTP) to obtain certificates and certificate revocation
lists (CRLs) from PKI repositories.
Additional mechanisms addressing
PKIX operational requirements are specified in separate
documents.Certificate Management Messages over CMSVeriSign Inc.1350 Charleston RoadMountain ViewCA94043US+1 650 429 3402mmyers@verisign.comcisco Systems170 West Tasman DriveSan JoseCA95134US+1 480 526 7430xliu@cisco.comjimsch@nwlink.comjsw@meer.netThis document defines a Certificate Management protocol using CMS. This protocol addresses two immediate needs within the Internet PKI community:1. The need for an interface to public key certification products and services based onand, and
2. The need infor a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys.A small number of additional services are defined to supplement the core certificate request service.Throughout this specification the term CMS is used to refer to bothand. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntaxthat provides a superset of the PKCS7 syntax. The term CMC refers to this specification.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 [RFC 2119].Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices FrameworkCygnaCom Solutions, Inc.Suite 100 West7927 Jones Branch DriveMcLeanVA22102US+1 703 848 0883+1 703 848 0960chokhani@cygnacom.comVeriSign, Inc.301 Edgewater PlaceSuite 210WakefieldMA01880US+1 781 245 6996 x225+1 781 245 6006wford@verisign.comThis document presents a framework to assist the writers of
certificate policies or certification practice statements for
certification authorities and public key infrastructures.
In particular, the framework provides a comprehensive list of topics
that potentially (at the writer's discretion) need to be covered in a
certificate policy definition or a certification practice
statement.Trust Anchor Management Protocol (TAMP)This document describes a transport independent protocol for the
management of trust anchors and community identifiers stored in a
trust anchor store. The protocol makes use of the Cryptographic
Message Syntax (CMS), and a digital signature is used to provide
integrity protection and data origin authentication. The protocol
can be used to manage trust anchor stores containing trust anchors
represented as Certificate, TBSCertificate or TrustAnchorInfo
objects.
Server-Based Certificate Validation Protocol (SCVP)The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server. The path construction or validation (e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. [STANDARDS TRACK]Service Location Protocol, Version 2Sun MicrosystemsBahnstr. 2Waibstadt74915DE+49 7263 911701Erik.Guttman@sun.comSun Microsystems901 San Antonio RoadMountain ViewCA94040US+1 650 786 6464cperkins@sun.com@Home Network425 Broadway StreetRedwood CityCA94063US+1 650 569 5243veizades@home.netVinca Corporation.1201 North 800 EastOremUT84097US+1 801 376 5083mday@vinca.comThe Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users
less tolerant or able to fulfill the demands of network system administration.Service Templates and Service: SchemesSun MicrosystemsBahnstr. 2Waibstadt74915DE+49 7263 911484+1 650 786 5992erik.guttman@sun.comSun Microsystems15 Network CircleMenlo ParkCA94025US+1 650 786 6464+1 650 786 6445cperkins@sun.comSun Microsystems15 Network CircleMenlo ParkCA94025US+1 650 786 5890+1 650 786 6445james.kempf@sun.comThe "service:" URL scheme name is used to define URLs (called "service: URLs" in this document) that are primarily intended to be used by the Service Location Protocol in order to distribute service access information. These schemes provide an extensible framework for client-based network software to obtain configuration information required to make use of network services. When registering a service: URL, the URL is accompanied by a set of well-defined attributes which define the service. These attributes convey configuration information to client software, or service characteristics meaningful to end users.This document describes a formal procedure for defining and standardizing new service types and attributes for use with the service:" scheme. The formal descriptions of service types and attributes are templates that are human and machine understandable. They SHOULD be used by administrative tools to parse service
registration information and by client applications to provide localized translations of service attribute strings.Peaches and Peers
Dartmouth College
Dartmouth College
In this paper we propose an extension to PRQP in order to distribute PRQP
messages over a Peer-to-Peer (P2P) network.
In this work we combine PRQP with Distributed Hash Tables (DHTs)
to efficiently distribute contents over a dynamic P2P overlay network.
Our work enhances interoperability between existing PKIs and allows for
easy configuration of applications, thus augmenting PKI technology usability.
XML Key Management Specification (XKMS)VeriSignwford@verisign.comVeriSignpbaker@verisign.comMicrosoftbfox@EXCHANGE.MICROSOFT.comMicrosoftblaird@microsoft.comMicrosoftbal@microsoft.comwebMethodsjepstein@webmethods.comwebMethodsjlapp@webmethods.comLightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 CertificatesThis document describes schema for representing X.509 certificates, X.521 security information, and related elements in directories accessible using the Lightweight Directory Access Protocol (LDAP). The LDAP definitions for these X.509 and X.521 schema elements replace those provided in RFCs 2252 and 2256. [STANDARDS TRACK]XML Key Management Specification (XKMS 2.0)Cisco Systems' Simple Certificate Enrollment ProtocolThis document specifies the Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations.
This section describes the formatting needed in order to route PRQP
request and response over HTTP.
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:
Content-TypeContent-Transfer-EncodingContent-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.
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:
Content-TypeContent-Transfer-EncodingContent-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.
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:
datelast-modifiedexpires
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
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.
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
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.
We define a prqp-servers option for DHCPv4 that specifies a list
of Resource Query Authorities (PRQP servers) available to the client.
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.
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
IPv6 addresses.
The code for the prqp-servers option for IPv6 is TBD. The
minimum length for this option is 1 octets.
As reported in ,
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;
}
...
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 is reported below:
queryauthority rqa.openca.org
queryauthority rqa3.dartmouth.edu
queryauthority 127.0.0.1
where each line has the format:
queryauthority <ADDRESS>
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.
The format for DNS SRV records MUST be compliant with
. 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:
Service is the symbolic name of the desired service. This field
MUST be set to "rqa"
Proto is the symbolic name of the protocol to be used. This field
MUST be set to "_tcp"
Name is the domain this RR refers to, i.e. the hostname of the RQA
server
TTL has the standard DNS meaning, refer to
for more information.
Class has Standard DNS meaning . This field
MUST be set to "IN"
Priority is the priority of this target host. The allowed range of
values is 0-65535 (16 bit unsigned integer in network byte order).
Weight is used for server selection mechanism. The weight field
specifies a relative weight for entries with the same priority. 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 .
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 .
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,
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 {
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 }
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}
id-ad-prqp-caIncidentReport OBJECT IDENTIFIER ::= {id-ad-prqp 90}
id-ad-prqp-private OBJECT IDENTIFIER ::= {id-ad-prqp 100}