Re: DPD & DPV requirements

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Steve,

Thanks for your detailed answer. We now mostly agree. See a few comments
below.

> Denis,
> 
> >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.
> 
> yes
> 
> >
> >Obtain a signed " yes, no or incomplete " answer to the question together
> >with the date of validation.
> 
> yes
> 
> >Optionally provide a replay protection if no time is available on the
> >client.
> 
> I would say that replay protection is necessary, period. The question
> is whether the protocol will meet this requirement via nonces or some
> other mechanism.

O.K. 

> >Optionally obtain the evidence to support the yes answer
> 
> I think it is a client option to request evidence, but a server MUST
> be able to provide the evidence.

O.K.

> >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.
> 
> yes, plus any other validation parameters defined by 2459bis.
> 
> >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.
> 
> yes, from the configured, default policy
> 
> >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.
> 
> this is getting a bit detailed to be a goal, but I agree with the motivation.
> 
> >  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.
> 
> As above, this may be a client option to request, but a server must
> be prepared to provide the revocation status info.

O.K.

> >Optionally specify naming and CP constraints.
> 
> I assume the same set of constraints as for DPV, right?

Right, while I would expect a DPV client either to reference a validation
policy or look if the used policy is acceptable, rather than specifying in
detail that validation policy.

> >Provide a replay protection (no date is necessary).
> 
> Necessary.
> 
> >Note 1 : Either a full certification path is returned or nothing (no
> >certification path nor revocation information).
> 
> OK.
> 
> >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.
> 
> No. I want the path to be valid, and if the server can't provide the
> revocation status info, then it does not know if the path is valid.

We have a slight disagreement here. You accepted the goal which is: "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.". In that sentence, the word "valid" does not exist. In
other words, DPD only *helps* a PKI-aware client to know whether a
certificate is valid. It is better to return what can be returned as far a
revocation information is concerned rather than nothing. You also noticed
that a client may only request the certification path, without the
revocation information.    

> >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.
> 
> For EACH (not one) element ...

Correct.

> >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.
> 
> right, see note above re point Note 2 under DPV.
> 
> >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.
> 
> each path ends with a trust anchor

Yes.

> >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.
> 
> OK.
> 
> >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.
> 
> The strawman spec already allows the client to submit a set of certs
> and revocation status data so this is an unduly narrow
> characterization.
> 
> >
> >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.
> 
> we're getting closer, but I see most of these "goals" as a subset of
> or refinement of the strawman spec. I don't want to reduce the scope
> of that spec to the subset required above. also, I've seen some
> comments suggesting that optional support for post-facto validation
> for DPV is desirable.

This topic is being discussed on another thread and is still open.

Denis

Note: No more comments below.
 
> >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).
> 
> Good point. IF we adopt that structure, it would avoid the problems I
> noted above.
> 
> >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 ?
> 
> Yes.
> 
> Steve