Subject: DCS or DVS ?

From: Denis Pinkas <[email-masked]>
Date: Tue, 19 Jan 1999 12:35:59 +0100

These comments are relative to the document: Internet X.509 Public Key
Infrastructure. Data Certification Server Protocols
During the last IETF meeting I have been requested to re-post these comments.
Here it is.

The various facets of the DCS functionality need to be looked at very
carefully before looking at the protocols.

The abstract says:

"Useful Data Certification Server responsibilities in a PKI are to validate
signatures and to provide up-to-date information regarding the status of
public key certificates".

This addresses two items:

a) validation of signatures,
b) up-to-date information regarding the status of public key certificates.

Let us address the validation of signatures first.

When a signer signs something this is in accordance with a security policy.
That policy may specify one OR MORE trusted points but also the allowed
certification paths that can be used. That policy may be implicit for a given
application/context or may be extracted from the data itself, e.g. when you
receive a signed contract that contains the policy.

The policy does not specify only the trusted points. It may also specify other
conditions, like which TSAs (Time Stamping Authorities) need to be involved,
the grace time period for a user to ask for the revocation of its certificate
in case of a private key compromise, ...

The implication is that nominating one or more trusted points is not enough in
the general case and only a security policy is able to encompass all the
checks that need to be made.

Degenerated cases may consider only one or more trusted point, but saying that
the signature is *valid* is insufficient unless we say against what (see later
the various cases that may be considered).

Considering a "certification path validity checking" would thus be more
appropriate. This would leave room for more complete tests.

An intermediate conclusion is thus to consider in addition to the validity of
a signature, the validity of a certification path. What means performing a
checking against trusted points ? This includes the certification path that
may be used. One way (but not the single one) to define them, is to use
self-signed certificates that include naming constraints. The key point is to
remember that it is not because a certificate exists that it should be used.

When trust points are used instead of security policies, it would be needed to
refer to ONE OR MORE self-signed certificates. In order to make sure that the
path used for the verification is correct, it should be given back to the
requester so that it can check that it is OK.

Let us then address the second item: up-to-date information regarding the
status of public key certificates.

The *status* of public key certificates is already being addressed by OCSP, so
we should not duplicate the work here. It is NOT addressed for an old status,
but it is not evident that it should (see arguments later on, why it should
not).

It would be better to consider "up-to-date information regarding the
*validity* of public key certificates".

So both items would be about validity/validation. A better name would be a
Data Validation Server (DVS) instead of DCS where the word "Certification"
(from Data Certification server) may be confusing with the function of a CA.
As an example of this kind of problem the actual text speaks about: "When
certifying a public key certificate, the DCS verifies ..." A CA (Certification
Authority) does such a certification, not a DCS.

In the introduction (section 1) three functions are introduced:

1) validity and correctness of an entity's claim to possess data,
2) validity and revocation status of an entity's public key certificate,
3) validity and correctness of another entity's signature.

For the item 1, the TSA (Time Stamping Authority) already allows to prove that
the requester possessed the data in the request at the time indicated by the
DVS.

Is it thus needed in addition to consider the case where a single entity (the
DVS) both proves that the requester possessed the data in the request and a
valid signature key at the time indicated by the DVS ?

It would be better to keep the two functionality independent. The TSA
signature is always for later use, while the DVS signature is not (see
additional arguments later on). If needed, the same entity can support both
protocols. Since the last case (3) is about any entity's signature, it would
be easier to consider only that case and use the TSA, in addition, when
needed.

In the item 2, if validity is checked, by implication the revocation status is
also checked.

Note: It is not clear to understand what "correctness" means in addition to
validity in the items 1) and 3).

The various facets to consider for a DVS would then be along the following
(and the document should be restructured along thse lines) :

1) validity of an entity's public key certificate.
2) validity of a certification path.
3) validity of an entity's signature.

The validity may be checked against:

a) a security policy.
b) one or more self-signed certificates.
c) one or more certification paths.
d) one or more trusted points (provided that the path being used is returned).

The next question is what kind of information should be given to the DVS ?

There is not a single answer to this question, but it would be better to
restrict some of the possibilities when verifications "in the past" occur.

When something is signed, it seems natural that the verifier makes sure that,
at the first time it makes the verification, it gets everything back that he
will need later on to prove that the signature was valid (according to a non
repudiation policy).

If he (or someone else) wants to make the verification later on, it seems then
natural that he provides what he got at that time. This has two important
implications:

1) This means that the DVS does not have to fetch, e.g. back 3 years old CRLs
or ARLs.

2) This also means that the DVS *should return all what is needed for later
proof*. That stuff may then be used by any DVS to make the verification,
without the need for anyone to trust the first DVS for its good faith. This
would be a nice way to support the non repudiation APIs described in IDUP
(Independent Data Unit Protection, now RFC 2479 and authored by Carlisle)
where such a functionality exists.

CRLS and ARLs may then be part of the data that is given or returned to the
DVS. Time Stamp tokens may also be part of it.

All the functions listed above can be used in the context where the DVS is a
server trusted only by its requester (a short term signature from the DVS is
being used) and not necessarily by other users.

Regards,

Denis