Re: DPD & DPV requirements

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Denis,

Your message is really too big, so I'll trim it in my response, with
the attendant possibility that I'll through away some context that
will later cause confusion, ...

[Denis]

I will do the same. :-)

Since we now understand much better each other, I will not reproduce all the
issues we agree on. I will answer to one of your questions and comment on 
one issue on which we both agree.

In order to progress, I suggest that we try first to agree on the goals.
Here is a proposal.

DPV goals: 

Validate a leaf certificate according either to a validation policy or one
(or more ?) trust anchor (public key value, CA name and optionally a
validity period) including CP and naming constraints. 

Obtain a signed " yes, no or incomplete " answer to the question together
with the date of validation.

Optionally provide a replay protection if no time is available on the
client.

Optionally obtain the evidence to support the yes answer 

Note 1: A complete certification path is one that satisfies all of the
validation criteria specified in RFC 2459bis and that terminates at a trust
anchor (public key value, CA name and optionally a validity period) that may
include Certification Policy constraints as well as naming constraints.

Note 2 : if a "ValidationPolicyRef" parameter or the trust anchor 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 of the root key that has been used.

Note 3 : 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. 


DPD goals:

Obtain one or more certification paths and optionally its associated
revocation information for a leaf certificate according either to a
validation policy or a trust anchor.

Optionally specify naming and CP constraints.

Provide a replay protection (no date is necessary).

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

Note 2 : When a full path is found, all the associated revocation
information is not necessarily found. However, the revocation information
that has been found is returned.

Note 3 : For one 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.

Note 4 : if the validation policy or a root key (public key value and CA
name) is missing, then the server will designate in the response the default
validation policy or root key or the self-signed certificate that has been
used.

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.

Note 7: in case full revocation information is not found, the client may
send 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, in order to try to obtain
more revocation information. This avoids to have a stateful server. 


If we can agree on these goals, then I am ready to send a detailed proposal
for the input and output parameters for each protocol.


Let me now answer to one of your questions and then comment on another one. 

1. [Steve]

>You say "that providing anything other than the target cert per se has
>potential problems and adds complexity to the server". However, you do not
>provide arguments to support this statement.

Any means of referring to a cert, other than providing the cert, is
problematic. For example, issuer name and serial number is ambiguous
because we can't guarantee uniqueness of issuer names. A hash of a
cert fails to help me locate the cert if I can't find it in a local
cache. A subject key identifier has a similar problem.  We had
similar discussions re certificate references in the attribute
certificate realm.

Your example does not seem to address this concern, or maybe we're
just miscommunicating on another level.

[Denis]

When you use ESSCertID (defined in RFC 2634), it does address your concern,
since ESSCertID may carry both the properties you mentioned: issuer name and
serial number (to locate the certificate) but also a hash of a cert (to make
it unambiguous).


2. [Denis]

>I agree with you that "we already have application protocols where a client
>that is not PKI-aware might acquire cert paths and/or revocation data that
>he could pass on to a DPV server." The S/MIME example I provided is one
>such example. However, this would mean that each blob able to contain 
> such cert paths and/or revocation data would have to be passed 
>"as it is", i.e. without being opened by the application. I made the list 
> of such data structures for three documents from the S/MIME working 
> group. If we proceed in that direction, then we should ask the other 
> working groups (e.g. IPSEC, TLS) to provide us with a list of the data 
> structures that are relevant. If this list is not too large, then it could 
> make sense to support all of them, otherwise, we would have to 
> consider that this is not practical.
>
>If you agree with this idea, it could be interesting that we raise the
>question to the other working groups.

[Steve]

Good points. I have glibly discussed having these apps pass in certs
and CRLs, but without taking into account the implications of this
model. If we agree to support  data structures from these protocols,
then we make life easier for these clients, but servers have to be
aware of each distinct data structure.  We might standardize on a
few, common formats now in use, and encourage future apps to make use
of these structures, while still providing tags to identify them and
thus accommodate new structures if needed.

[Denis]

We both agree. So would you be sending such a request on the IPSEC and TLS
mailing lists ?

Regards,

Denis