Subject: RE: DCS or DVS ?

From: Robert Zuccherato <[email-masked]>
Date: Thu, 25 Mar 1999 13:27:30 -0500

Denis sent this message to the list back in January and I never got around
to responding to it.  He reminded me last week that I hadn't done so.  My
responses are embedded below.

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	Tuesday, January 19, 1999 6:35 AM
> To: 	IETF-PXIX
> Subject: 	DCS or DVS ?
> 
> 
> 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.
> 
I agree with what you say here.  I will change the introduction to more
fully state "certificate path validity checking" as the purpose of this
protocol.

> 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.
> 
Again, I agree.  I believe that the present draft does this.

> 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".
> 
Again, I agree.  I will change the wording appropriately.

> 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.
> 
Actually a TSA just proves that the data existed at a given point in time,
not that any particular entity possessed it.

> 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.
> 
Exactly.  If you sign a document and get it timestamped, this can prove that
you possessed the data at the given time, but the verifier must still
validate the signature.  By using the DCS service, the DCS would validate
the signature for you and provide a token attesting to the fact.

> 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.
> 
I think everything you say above is supported by the present protocol.  If
it isn't could you please suggest some additions that would be required?

	Robert.