Re: DPD & DPV Basics

[Stephen Kent <kent@xxxxxxx>]

Steve,

> Stephen Kent wrote:
> > I agree with your example, in almost every detail (I'd like to see
> > reference to the trust anchors in the call, not have the reference
> > implicit by client ID).
>
> I'm glad to hear we're approaching agreement on this. Why would you like
> to make the trust anchors explicit, especially if the rest of the
> validation parameters are implicit? Or are you simply arguing that the
> client should have consider flexibility in deciding which parameters are
> explicit and which ones implicit?

I'm open to specifying parameters as a mix of explicit ones and ones specified by reference to a policy configured at the server, with the explicit ones overriding the specified ones, UNLESS the policy precludes such override. I think this is what the strawman spec says.

> > I think the current spec alludes to the capability you describe,
> > specifically it says:
> > 
> > "For a non-PKI aware, non-ASN.1-capable client, the results returned
> > by the DPV protocol should not be merely a certificate and a status
> > indication. Rather, the contents of a certificate that are relevant to
> > the client application should be returned as distinct values, in a
> > syntax appropriate for the client. For example, the public key and
> > associated algorithm, the subject name (and/or alternate names) and
> > the issuer name (and alternate names), the key usage bits, and the
> > extended key usage field are all candidate values to be returned as
> > distinct objects to the client."
> > 
> > We have not included these specific requirements so far, because we
> > have not agreed whether it is appropriate to provide the results in
> > ASN.1 or via some other means, a tension noted elsewhere in the
> > requirements spec.
>
> It sounds like we need to decide whether non-PKI aware,
> non-ASN.1-capable clients need to be supported. If so, we should
> probably define a set of requirements for such clients and include this
> item in that list. I would suggest that such clients are an important
> group and should be supported.

I put this question to the list in my strawman spec over 2 weeks ago, and have not yet gotten a concrete proposal on how to accommodate such clients.  I will soon decide that we will NOT support them for now, unless I see such a proposal.

> > I would expect the (IKE) client to send in the target cert and either
> > explicit validation parameters, or a reference to a stored set.
> > Checking the key usage could be done at the server or in the client.
> > But I do expect the client to do the ID matching against the returned
> > cert or cert contents.  I would not want the the server to do this
> > because it is application specific and we don't want to require
> > servers to know about such things for every application that might
> > make use of them.
>
> I am also reluctant to have the server perform application-specific
> checks. But matching an ID against a set of subject names and subject
> alternative names can be complicated. This is especially true for email
> addresses and DNS host names (for TLS/SSL connections), since there are
> legacy conventions for including these names in X.500 names, as well as
> specific name types for subject alternative names.
>
> Therefore, I think there's a strong case that, at least for non-PKI
> aware, non-ASN.1-capable clients, the DPV server should perform this
> check.

I sympathize with the concern, but there is still the issue of why should we do this application-specific function, vs. others that might arise in the future?

Steve