Subject: DVCS Compliance Matrix

From: Peter Sylvester <[email-masked]>
Date: Tue, 24 Dec 2002 17:37:50 +0100 (MET)

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

----- End Included Message -----