Subject: Strawman proposals for DPV and DPD

From: Denis Pinkas <[email-masked]>
Date: Tue, 23 Jan 2001 10:44:55 +0100

Since we now basically agree on many/most issues, it is time to draft
strawman
proposals if we want to reach an agreement at the end of this month. You
will find hereunder a description for DPV and DPD. The input /output
parameters for each protocol are identified.

STRAWMAN PROPOSAL FOR DPV:

Goals : Validate a leaf certificate according to a validation policy or one
trust anchor (public key value and CA name associated with CP and naming
constraints).

Obtain a signed "valid", "invalid" or "incomplete" answer to the question.

Optionally obtain the evidence to support the "valid" answer 

Mandatory input :

Unambiguous reference of the certificate to be validated : either the
certificate itself or the ESSCertID (with issuerSerial present).

ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   Hash ::= OCTET STRING -- SHA1 hash of entire certificate

   IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber
   }

Mandatory input :

A flag indicating whether or not the evidence of the assertion shall be
returned : the certification path and its associated revocation information.

Optional input :

either one trust anchor, or 
an unambiguous reference of the validation policy to be used: either the
description of the validation policy, or a reference to the validation
policy and its hash :

ValidationPolicyRef   ::= SEQUENCE {
        valPolicyId             ValPolicyId,
        valPolicyIDHash         ValPolicyHash,
        valPolicyQualifiers     SEQUENCE SIZE (1..MAX) OF
                                ValPolicyQualifierInfo OPTIONAL}
}

ValPolicyId     ::= OBJECT IDENTIFIER

ValPolicyHash   ::= OCTET STRING -- SHA1 hash of entire certificate

ValPolicyQualifierInfo   :== SEQUENCE {
        valPolicyQualifierId    ValPolicyQualifierId,
        valQualifier            ANY DEFINED BY valPolicyQualifierId }
}

ValPolicyQualifierId ::= OBJECT IDENTIFIER 

Note 1 : if the ValidationPolicyRef or the trust anchor parameter is missing
in the request, then the server will return back either the
ValidationPolicyRef that has been used or alternatively a description of the
validation policy or one trust anchor.

Optional input :

Useful certificates, in the form they are in the current protocols : S/MIME,
IPSEC, TLS and ES formats, so that " blobs " can be used.

Optional input :

Useful revocation information, in the various forms in the current protocols
: S/MIME, IPSEC, TLS and ES formats, so that " blobs " can be used.

Optional input : A nonce, if no time is present on the client.

Mandatory output : A digital signature over the following items :

  - a status : valid, invalid, incomplete.
  - the reference of the certificate being validated or the certificate
    itself.
  - the date of validation,
  - the reference of the validation policy that has been used during the
    validation process or its description,
  - optionally, the hash of the evidence.

Note 2 : a separate digital signature over the evidence (full path and
associated revocation information) should be avoided in order to avoid the
cost of two signatures. In order to be able to store the yes /no answer in
one place without the need to store the evidence (that may be quite big) in
the same place, it is proposed to include the hash of the evidence in the
signed answer. This does not augment too much the size of the answer while
providing integrity protection without the need of a second digital
signature.

Optional output :

If requested, the evidence of the assertion as a " blob " : a single
certification path and its associated revocation information. 

Note 3 : The document <draft-ietf-smime-esformats> provides elements for
such a structure inside the blob.

Optional output : The sent nonce if it was present (to detect replays).

STRAWMAN PROPOSAL FOR DPD :

Goals : Obtain one or more certification paths and optionally its associated
revocation information for a leaf certificate according either to a
validation policy, a trust anchor or a root key (public key value with CA
name).

Obtain a "success" or "failure" indication for the operation that has been
requested.

Note 1 : Either a full path is returned or nothing (no path nor revocation
information).

Note 2 : A full path may be found, but not necessarily all the associated
revocation information. The revocation information that has been found is
returned.

Note 3 : For each element of the path, both a CRL (or base CRL and delta)
and an OCSP response may be returned (if both exist) as associated
revocation information.

Mandatory input : Unambiguous reference of the certificate to be validated :
either the certificate itself or the ESSCertID (with issuerSerial present).

Mandatory input : When ESSCertID is being used, a flag indicating whether
the certificate itself should be returned.

Mandatory input : Flag indicating whether revocation information for the
path should be returned.

Mandatory input : A nonce (to detect replays).

Conditional input : If, revocation information for the path should be
returned, then a four states flag indicating whether CRLs and /or OCSP
responses should be returned for the leaf certificate (CRL only, OCSP only,
both if they exist, either don't care).

Conditional input : If, revocation information for the path should be
returned, then a  four states flag indicating whether CRLs and /or OCSP
responses should be returned for each CA certificate from the path (CRL
only, OCSP only, both if they exist, either don't care).

Optional input : One of the following :

a)  reference of the validation policy to be used (ValidationPolicyRef),
b)  the description of the validation policy,
c)  a self-signed certificate designating a root-key,
d)  a trust anchor ( a root key with CP and naming constraints),
e)  a root key (a public key value and an associated DN name of a CA),

Note 4 : if this parameter is missing, then the server must designate in the
response either the validation policy, the default root key or the
self-signed certificate that has been used.

Optional input : A sequence of useful CA certificates and a sequence of
useful revocation information (CRLs and/or OCSP responses).

Mandatory output : A primary status indicating: "success" if the operation
that has been requested has been accomplished, or "failure" in the other
case.

Mandatory output : A secondary status indicating : full path found / not
found.

Mandatory output : A secondary status indicating : full revocation
information found / not found.

Mandatory output : A secondary status indicating : leaf certificate found /
not found.

Mandatory output : The sent nonce (to detect replays).

Mandatory output : The reference of the certificate being validated or the
certificate itself.

Conditional output : one or more certification paths and optionally
associated revocation information.

Note 5: each path starts with the leaf certificate (or its reference) and
ends up either with a self-signed certificate or a root key associated with
a CA name.

Note 6 : When only the reference of the certificate is provided in the
request (i.e. ESSCertID) and when requested, the server may include the leaf
certificate in the returned paths.

Mandatory output : A digital signature over all the outputs (including the
input parameters as well) in order to
provide authentication with integrity.

Note 7: in case full revocation information is not found, the client should
sent back (using the sequence of useful certificates and a sequence of
useful revocation information) one of the certification path and the
associated revocation information that he got, he may then get more
revocation information. This avoids to have a stateful server. 

Similar structures or easy to convert structures for on one side the input
parameters : " useful " certificates and " useful " revocation information ;
and on the other side the output parameter : certification path and
associated revocation information ; should thus be considered.

Regards,

Denis