[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DVCS Compliance Matrix
The protocol proposed mainly consists of the service
validate/certify public key certificate of DVCS.
Some general remarks:
- DVCS does not distinguish between DPV and DPD. The difference
is defined by a policy. A client that does not interprete
a response in details is considered to be a DPV client,
whilst a client that reevaluates the results has the
characteristics of a DPD client.
- DVCS is a framework protocol that needs some profiling
for particular service configurations.
- The DVCS authentication framework is very loosely coupled
to the payload. Different authentication methods can
be used in a general way. The authentication envelopes
can be removed in relays and in the payload identities
of the participating entities can be set.
- At the time of the specification, only a very small set
of detailed error information had been defined through
the use of PKIStatus. It is assumed that a set of
additional error indicators can be added to PKIstatus
in case this is necessary.
- Some update is foreseen for DVCS to correct at least
the few obvious ASN1 errors which had slipped through
the different protocol implementations.
Topic 1: Basic Protocol
1. If the DPV server does not support the client requested
validation policy, then the DPV server MUST return an error. (4.1.
Basic Protocol)
A DVCS request contains a field DVCS includes a field
requestPolicy [1] PolicyInformation OPTIONAL
as part of the DVCSRequestInformation.
- The 'requestPolicy' field SHOULD indicate the policy under which
the validation is requested. This field MUST be checked by the
DVCS to verify agreement with its own policy. The absence of this
field indicates that any policy is acceptable.
2. If the DPV request does not specify a validation policy, the
server response MUST indicate the validation policy that was used.
(4.1. Basic Protocol)
The type DVCSCertInfo contains the field
policy [1] PolicyInformation OPTIONAL
it is optional because the possible policy field in
the request is contained in another field.
3. The protocol MUST allow the client to include these policy
dependent parameters in the DPV request; however, it is expected
that most clients will simply reference a validation policy for a
given application or accept the DPV server's default validation
policy. (4.1. Basic Protocol)
[For the candidate protocol, state the provisions it includes for
such parameters.]
The specification for a certificate may include additional
certificates, certification policy information, etc to
direct of limit the validation activity.
Since DVCS is a framework protocol, application specific profiles
may be useful or necessary to define common sets of
potential parameters.
policy may provide for the option to add for example
server certificates of other validation services indicating
the trustworthy access points. Such certificates should
have a information access extensions filled with the
access points of the server.
A policy basically indicates an entry in a configuration
which is corresponds to a particular application context.
4. The DPV server MUST obtain revocation status information for
the validation time in the client request. (4.1. Basic Protocol)
[a. Indicate how a conformant server for the candidate protocol deals
with other than "current time" validation requests.]
No special handling is specified in DVCS. The server indicated
the date that is associated with the response.
A clarification of the usage in can be added to the protocol
for example that the server always honors the date indicated
in the request (if this is possible).
A server also has the possiblity to indicate success or
failure in the PKIstaus elemsnt that accompany each
certificate, the certificate path and the whole response.
[b. For the candidate protocol, indicate which revocation status
methods a conformant server is required to support. A DPV server
must support some revocation status methods, but the methods
used by different CAs may differ, suggesting that a server needs to
be prepared to deal with several such methods. A server may need
to be configured to use specific methods for specific CAs. How
does the candidate protocol accommodate this need?]
This is not a particular topic for the DVCS protocol but
for the configuration management of the server. On the
other hand, a client certificate may have indications*
for CRL distribution points or OCSP servers, and, a client
may also provide trustworthy OCSP or DVCS server certificates
in the request.
Actually no minimal requirements are made for a conformant
server for support of a particular revocation status method
used. Should one?
5. If the revocation status information for the requested validation
time is unavailable, then the DPV server MUST return a status
indicating that the certificate is invalid. Additional information
about the reason for invalidity MAY also be provided. (4.1 Basic
Protocol)
All error indications returned by DVCS use a type PKIstatusInfo
defined in CMP. Status information may be returned individually
for each certificate in a chain, a total chain, and an overall
status. badTime (3) can be used to indicate a time problem.
The use of additional fields of PKIstatus needs to be clarified
in a revised version of DVCS.
6. The certificate to be validated MUST either be directly provided
in the request or unambiguously referenced, such as the CA
distinguished name, certificate serial number, and the hash of the
certificate, like ESSCertID as defined in [ESS] or
OtherSigningCertificate as defined in [ES-F]. (4.1 Basic Protocol)
[For the candidate protocol, specify which formats for certificate
references MUST be supported by conformant clients and servers.
The lists may differ for clients vs. servers, e.g., servers may bear
the burden of having to accept a larger range of reference types, to
ease the burden on clients.]
The DVCS framework provides for several ways to indicate
certificate. This includes specification formats from
OCSP, ESS. A client may also specify a DVCS or
OCSP response to obtain validation.
7. The DPV client MUST be able to provide to the validation
server, associated with each certificate to be validated, useful
certificates, as well as useful revocation information. (4.1 Basic
Protocol)
[For the candidate protocol, indicate which forms of revocation
status info a conformant client is allowed to provide, and what
forms of revocation status data a conformant server MUST be
prepared to accept from a client.]
As already said, DVCS may allow additional certificates to
be used or useful for the validation. The usage and acceptance
needs to be defined in a server policy.
8. The DPV server MUST have the certificate to be validated.
When the certificate is not provided in the request, the server
MUST obtain the certificate and then verify that the certificate is
indeed the one being unambiguous referenced by the client. (4.1
Basic Protocol)
[For the candidate protocol, specify what mechanisms a conformant
server MUST implement in support of this requirement, e.g.,
retrieval of a certificate via LDAP queries.]
DVCS makes no assumption on how the actual certificate
is obtained, not even, whether the certificate itself is actually
known to the service. Depending on policy, the server
may return a complete certificate chain.
9. The DPV server MUST include either the certificate or an
unambiguous reference to the certificate (in case of a CA key
compromise) in the DPV response. (4.1 Basic Protocol)
A DVCS server may return references to certificates instead
of an actual certificate when the actual certificate
may be found either in another chain, in another place
of the response, or in any cases where the certificate can
be obtained or is known to the server.
10. The DPV response MUST indicate one of the following status
alternatives:
1. the certificate is valid according to the validation policy.
2. the certificate is not valid according to the validation
policy.
3. the validity of the certificate is unknown according to the
validation policy.
4. the validity could not be determined due to an error.
(source for 10: 4.1 Basic Protocol)
The actual specification of DVCS only provided for valid and invalid
status based on the values of PKIStatus. no difference between
unknown and invalid can be made. The interpretation of what unknown
should mean to the client is not clear from the requirements
(and neither from OCSP where it has its origins. If it means that
the configuration does not has a trust anchor to that certificate
then requirement seems to be a subpart if requirement 2.
RFC510bis provides for more error codes in PKIStatus,
in particular
systemUnavail (24),
-- the request cannot be handled due to system unavailability
systemFailure (25),
-- the request cannot be handled due to system failure
which are foreseen to be possible in a revised version.
11. When the certificate is not valid according to the validation
policy, then the reason MUST also be indicated. Invalidity reasons
include:
1. the DPV server cannot determine the validity of the
certificate because a certification path cannot be
constructed.
2. the DPV server successfully constructed a certification path,
but it was not valid according to the validation algorithm in
[PKIX-1].
3. the certificate is not valid at this time. If another
request could be made later on, the certificate could possibly
be determined as valid. This condition may occur before a
certificate validity period has begun or while a certificate
is suspended.
(Source for 11: 4.1 Basic Protocol)
[For the candidate protocol, indicate what if any, other invalidity
reasons are reportable by a conformant server.]
In DVCS the different types of errors cannot be determined directly
by an error code in a PKIstatus. if it seems necessary that
a cleint should be able to distinguish easily, i.e., by a
simple code different cases.
12. The protocol MUST prevent replay attacks, and the replay
prevention mechanism employed by the protocol MUST NOT rely
on synchronized clocks. (4.1 Basic Protocol)
[For the candidate protocol, describe the means by which conformant
clients and servers detect and reject replay attacks.]
DVCS can use a Nonce in the request to be returned in the
response. It is up to the client to verify if nonces
are correctly returned. nonces can be chained through
relays.
Furthermore, the protocol allows to apply additional
protection mechanismn of S/MIME and SSL/TLS to protect
the payloads.
13. The DPV request MUST allow the client to request that the
server include in its response additional information which will
allow relying parties not trusting the DPV server to be confident
that the certificate validation has correctly been performed.
[...] When the certificate is valid according to the validation
policy, the server MUST, upon request, include that information in
the response. However, the server MAY omit that information when
the certificate is invalid or when it cannot determine the validity.
(4.1 Basic Protocol)
[For the candidate protocol, specify the additional information
that a conformant server MUST be able to provide and indicate how
the set of information to be returned is determined, e.g., if it
may vary depending on the client or other parameters.]
Depending on policy a DVCS may return the complete set
of information that had been used to create a valid
path. This may include the complete path and additional
validation information about all or some paths in the
chain.
14. The DPV server MUST be able, upon request, copy a text field
provided by the client into the DPV response. (4.1 Basic Protocol)
DVCS allows to specify several information parameters in the
input. The PolicyInformation in the input policy allows
a free set of textual parameters. The fields requestor and
dvcs provide the means to indicate additional information
about which entities are requesting or supposed to respond.
15. The DPV response MUST be bound to the DPV request so that
the client can be sure that all the parameters from the request have
been taken into consideration by the DPV server to build the
response. This can be accomplished by including a one-way hash
of the request in the response.
[For the candidate protocol, describe how this binding is effected.]
In some environments it may be necessary to present only a DPV
response to another relying party without the corresponding
request. In this case the response MUST be self contained. This
can be accomplished by repeating only the important components
from the request in the response. (4.1 Basic Protocol)
DVCS copies requestinformation fields into the response.
16. For the client to be confident that the certificate validation was
handled by the expected DPV server, the DPV response MUST be
authenticated, unless an error is reported (such as a badly
formatted request or unknown validation policy).
[For the candidate protocol, specify the response message authentication
mechanisms that a conformant server MUST support, and those
that a conformant client MUST support. Note that clients might be
required to support fewer mechanisms, or might be required to
support only one mechanism from a set, while a server might be
required to support all of the mechanisms in the set, e.g., as a
means of ensuring interoperation.]
For the client to be able prove to a third party that trusts the same
DPV server that the certificate validation was handled correctly,
the DPV response MUST be digitally signed, unless an error is
reported. The DPV server's certificate MUST authenticate the DPV
server. (4.1 Basic Protocol)
The 3029 defined SMIME signatures (signedData) as authentication
envelope. This authentication is optional and can be replaced
(or used together) with SSL/TLS authentication or any other
lower layer method to authenticate response.
In case, when the response is need for another relying party
besides CMS Signeddata, DVCS provides for the possiblity to
establish a validation service for DVCS responses using the
vsd service.
In general, error responses are protected in the same way
as DVCs.
No special assumption is made about the number of authentication
envelopes present, i.e., multiple signatures may be present.
17. The DPV server MAY require client authentication, therefore,
the DPV request MUST be able to be authenticated. (4.1 Basic
Protocol)
[For the candidate protocol, describe the request message
authentication mechanisms that a conformant server MUST
support, and those that a conformant client MUST support, to
ensure a minimal level of interoperability. Note that clients might
be required to support fewer mechanisms, or might be required to
support only one mechanism from a set, while a server might be
required to support all of the mechanisms in the set, e.g., as a
means of ensuring interoperation.]
CMS protection, or any other lower layer protection mechanism.
The identity of the client can be indicated in the payload
to achieve independance of the actual mechanism.
When confidentiality and server authentication is required, requests
and responses MAY be protected using appropriate mechanisms (e.g.,
CMS encapsulation [RFC 2630] or TLS [RFC2246]).
Server authentication is highly recommended for the vsd and cpd
service.
Client identification and authentication MAY use services defined by
TLS [RFC2246]) instead of, or in addition to, using a CMS format
providing authentication.
18. When the DPV request is authenticated, the client SHOULD be
able to include a client identifier in the request for the DPV server
to copy into the response. Mechanisms for matching this identifier
with the authenticated identity depends on local DPV server
conditions and/or the validation policy. The DPV server MAY
choose to blindly copy the identifier, omit the identifier, or return
an error response. (4.1 Basic Protocol)
[For the candidate protocol, describe provisions for confidentiality,
if any.]
The identity of the requesting entity or entities can be
set in the request payload. It is up to the server policy,
to accept the client indication and to return it to the
client in the response. The server may also choose to
determine the client's identity from the authentication
method and to return this information.
Confidentiality is not a part of the protocol. Confidentiality
is assumed to be treated by lower level protection like
CMS EnvelopedData, TLS, or IPsec.
Topic 2: Relay and Redirection
19. Protocols designed to satisfy these requirements MAY include
optional fields and/or extensions to support relaying, re-direction
or multicasting. [...] If the protocol supports such features,
the protocol MUST include provisions for DPV clients and DPV
servers that do not support such features, allowing them to
conform to the basic set of requirements. (4.2. Relaying, Re-
direction and Multicasting)
[For the candidate protocol, describe any relay, referral, or
multicasting facilities required of conformant server.]
Relaying to another DVCS service is a normal feature in DVCS.
The returned responses may either be included as assertions
in the augmented certificate paths or the relaying service
may just add an additional signedData envelope.
20. When a server supports a relay mechanism, a mechanism to
detect loops or repetition MUST be provided. (4.2. Relaying, Re-
direction and Multicasting)
DVCS uses a combination of requester and server names to detect
loops.
21. When a protocol provides the capability for a DPV server to
redirect a request to another DPV server (that is, the protocol
chooses to provide a referral mechanism), a mechanism to provide
information to be used for the re-direction SHOULD be supported.
If such re-direction information is sent back to clients, then the
protocol MUST allow conforming clients to ignore it. (4.2.
Relaying, Re-direction and Multicasting)
[For the candidate protocol, describe what strategy is employed to
deal with redirection by a conformant server and what redirection
features are mandated for a conformant client.]
Redirection has not been specified directly in the protocol
but the framework allows to implement this in a simple way:
By return a certificate of a DVCS service containing a
information access extension, a service can inform a client
about redirection. This feature needs to be documented.
22. Optional parameters in the protocol request and/or response
MAY be provide support for relaying, re-direction or multicasting.
DPV clients that ignore any such optional parameters MUST be
able to use the DPV service. DPV servers that ignore any such
optional parameters MUST still be able to offer the DPV service,
although they might not be able to overcome the limitations
imposed by the network topology. In this way, protocol
implementers do not need to understand the syntax or semantics of
any such optional parameters. (4.2. Relaying, Re-direction and
Multicasting)
DVCS clients may specifu identities of one or more dvcs
services to be used to provide the service.
The augmented inpiut certificate chain may contain certificates
and assertions to further direct the processing of the
relay.
Details for such processes need to be defined in profile
and policy documents.
Topic 3: DPD Requirements
23. Clients MUST be able to specify whether they want, in
addition to the certification path, the revocation information
associated with the path, for the end-entity certificate, for the CA
certificates, or for both. (5. Delegated Path Discovery Protocol)
[For the candidate protocol, specify what revocation status data
types MUST be supported by a conformant server.]
DVCS makes no distinction between DPV and DPD. Whether a response
is considered as DPD or DPD depends on the policy.
24. If the DPD server does not support the client requested path
discovery policy, the DPD server MUST return an error. (5.
Delegated Path Discovery Protocol)
The DVCS server indicates the policy that is used to
perform the service.
The protocol can be esily augmented to support addition
return codes as described in the 2510bis (or in 3161).
25. The DPD request MUST allow more elaborated path discovery
policies to be referenced. (5. Delegated Path Discovery Protocol)
[For the candidate protocol, specify the parameters for path
discovery that a conformant server MUST support, i.e., the
minimum path discovery policy supported, and specify what
optional path discovery parameters a server SHOULD/MAY
support.]
DVCS does not assume any difference between path discovery
and path validation. path discovery is in any case the
initial step to be performed, and the validation policy
indicates to which degree the path needs to be validated.
26. If the trust anchor is a self-signed certificate, that self-signed
certificate MUST NOT be included. In addition, if requested, the
revocation information associated with each certificate in the path
MUST also be returned. (5. Delegated Path Discovery Protocol)
[For the candidate protocol, specify the types of revocation status
data that a conformant server MUST support.]
DVCS makes no assumption of what constitues a trust anchor.
The server returns whatever is a valid certification path.
27. By default, the DPD server MUST return a single certification
path for each end-entity certificate in the DPD request. (5.
Delegated Path Discovery Protocol)
A server MAY also return multiple paths (all of them.)
28. Therefore, the DPD client MUST have a means of obtaining
more than one certification path for each end-entity certificate in
the DPD request. At the same time, the mechanism for obtaining
additional certification paths MUST NOT impose protocol state on
the DPD server. (5. Delegated Path Discovery Protocol)
[For the candidate protocol, provide a state machine description of DPD
operation, to demonstrate that this requirement is met.]
DVCS does not describe a particular mechanism for a protocol
to retrieve multiple paths in several parts.
29. Path discovery MUST be performed according to the path
discovery policy. The DPD response MUST indicate one of the
following status alternatives:
1. one or more certification paths was found according to the
path discovery policy, with all of the requested revocation
information present.
2. one or more certification paths was found according to the
path discovery policy, with a subset of the requested
revocation information present.
3. one or more certification paths was found according to the
path discovery policy, with none of the requested revocation
information present.
4. no certification path was found according to the path
d iscovery policy.
5. path construction could not be performed due to an error.
(Source for 29: 5. Delegated Path Discovery Protocol)
DVCS make no difference between DPV and DPD. In the case
of the usage as DPD, it can be assumed that the client
can interprete the totality of the results, i.e. the client
has to determine whatever it like from the resulting
augmented path which may or may include several paths,
and:or revocation information.
30. For the client to be confident that all of the elements from the
response originate from the expected DPD server, an authenticated
response MAY be required. For example, the server might sign
the response or data authentication might also be achieved using a
lower-layer security protocol. (5. Delegated Path Discovery
Protocol)
[For the candidate protocol, specify whether conformant
servers MUST be capable of generating authenticated responses,
what authentication mechanisms they MUST support, and what
authentication mechanisms conformant clients MUST support.
Note that clients might be required to support fewer mechanisms,
or might be required to support only one mechanism from a set,
while a server might be required to support all of the mechanisms
in the set, e.g., as a means of ensuring interoperation.]
DVCS does not distinguish between DPD and DPV. A DVCS
server always produced a response that can be authenticated.
it may be possible that in a very simplified case, e.g. where
a DVCS service only operates a a front end to a directory
which itself does not produce authenticated answer, the
resulting DVC does not need any authentication.
A server can for example return a SINGLE path obtained
from a directory, and CRL(s) whose validity are assumed
to be checkable by the client.
31. The DPD server MAY require client authentication, allowing
the DPD request MUST to be authenticated. (5. Delegated Path
Discovery Protocol)
[For the candidate protocol, specify whether conformant servers
MUST be capable of authenticating requests, what authentication
mechanisms they MUST support, and what authentication mechanisms
conformant clients MUST support. Note that clients might be
required to support fewer mechanisms, or might be required to
support only one mechanism from a set, while a server might be
required to support all of the mechanisms in the set, e.g., as a
means of ensuring interoperation..]
See above for DPV client authentication.
32. Using a separate request/response pair, the DPV or DPD client
MUST be able to obtain references for the default policy or for all
of the policies supported by the server. (6. DPV and DPD Policy
Query)
DVCS does not provide a particular form for policy
return.
Nevertheless, if necessary, a particular request using a particular
policy could be used to indicate to return for example
a list of policies in a PathProcInput.
Furthermore, one actual implementation uses the format of
a DVC containing lists of CA certificats, OCSP, or DVCS service
to indicate a policy configuration. It is assumed that
a policy can be described as a certificate path augmented
by additional service indications represented by server
certificates of DVCs (or if really necessary, by extensions).
A DVCS server can provide a policy to return this information.
(for example to an administrator of the service. )
33. In order to succeed, one valid certification path (none of the
certificates in the path are expired or revoked) MUST be found
between an end-entity certificate and a trust anchor and all
constraints that apply to the certification path MUST be verified.
(7. Validation Policy)
In DVCS a valid certification path is whatever an
implementation and configuration decides.
34. The validation policy MUST specify the source of revocation
information:
1. full CRLs (or full Authority Revocation Lists) have to be
collected.
2. OCSP responses, using [OCSP], have to be collected.
3. delta CRLs and the relevant associated full CRLs (or full
Authority Revocation Lists) are to be collected.
4. any available revocation information has to be collected.
5. no revocation information need be collected.
(Source for 34: 7.3. Revocation Requirements)
A DVCS server MAY return depending on policy all information
that had been used to validate (or invalidate a certificate).
It is assumed that in order to determine why a server
had made his decision, this can be done by looking
a the response.
35. The validation policy MUST specify the source of revocation
information:
- full CRLs (or full Authority Revocation Lists) have to be
collected.
- OCSP responses, using [OCSP], have to be collected.
- delta CRLs and the relevant associated full CRLs (or full
Authority Revocation Lists) are to be collected.
- any available revocation information has to be collected.
- no revocation information need be collected.
(source for 35: 7. Validation Policy)
[For the candidate protocol, describe the path validation and path
discovery policy parameters that a conformant server MUST or
SHOULD support, e.g., trust anchor names, keys, name
constraints and policy constraints for trust anchors, path depth
limits, key usage constraints, extended key usage constraints,
required/allowed revocation status data types, etc.]
As with DPV, a client may add a partial path or additional
certificates in the request. The rules of the framework
are the same as for DPV.
The current assumption about policy definitions is that they
can be represented as a sequence of certificates and some
other information. This can be cross certificates containing
the appropriate extension to point to CRL providers, OCSP
servers or others.
Ths feature are considered as configuration and not as part
of the core protocol.
If another document defines a syntax for a policy definition
to be exchangeable between clients and servers, and in particular
between an administrator and a server, this can be regarded
as a possible extension to a DVCS protocol.
Peter