[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DPD & DPV requirements

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, ...

Steve,

I have seen an avalanche of messages on that topic, but let me reply to your
message which is not that old.

<snip>

[Steve]

Self-signed certs are not the only way to deal with multiple roots, and it
often seems to me that they are a poor way, when we want to make use of
features like naming constraints. Why not just have cross certs issued to
other "roots" by a local CA and embed the naming (and policy?) constraints
into those cross certs?


[Denis]

This would be quite an artificial way to do this, and more complex than
simply adding the elements to define the policy and naming constraints. The
proposal is simply to define the policy constraints and the name
constraints. Take a look at the document being progressed in the S/MIME WG
which defines a validation policy format for non repudiation: Electronic
Signature Policies <draft-ietf-smime-espolicies>

I don't think of it as artificial at all. Cross certification is a standard way to create links between PKIs, and to express constraints on these links. It has the advantage that path validation can be applied uniformly rather than having to treat each trust point specially, associating name and policy constraints etc. via special means. But, I'm not hard over on this.

<snip>

[Steve]

I see your example, but I also stand by my observation that providing
anything other than the target cert per se has potential problems and adds
complexity to the server. We'll have to decide whether we want to impose
such adde complexity on servers, and whether we can provide clean,
algorithmic means of dealing with this complexity.

[Denis]

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.

<snip>
 >

[Steve]

A DPV client MAY be not PKI-aware, but that is not the only case we agreed
to address. I'll need to see more comments from WG members to persuade me
that we wish to restrict DPV interactions to clients that are presumed to be
PKI-ignorant, to use your term.

[Denis]

I would rephrase your wording as :" Make sure that a DPV client can be used
by a PKI-ignorant client".

OK.


<snip>

[Steve]

There was some sentiment for having the "was it valid then" function as
provided in SCVP, but if there is not continued support we could delete it.
I want to get more feedback on this issue.

[Denis]

So, let us wait and see ...

I'm not seeing any support for retrospective queries, so I think we'll drop it.


<snip>

[Steve]

I'll remove it if I hear from a few more people who agree that it is best
provided as a separate call to a TSA.

[Denis]

Up to now, there has been one other message posted to the list, asking for
the TSA removal.

OK, done.

<snip>

[Steve]

As I noted, a client might acquire cert paths and CRLs via a protocol like
SSL or IKE. Such clients could be ASN.1 capable but want to offload
validation for the reasons cited earlier.

[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.

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.

<snip>

[Steve]

If we don't agree on whether a DPV client might still pass on certs and CRLs
acquired via a protocol exchange, we can't proceed along these lines. Such a
DPV client looks a lot like a DPD client in terms of what it might pass to
the server in a request. In any case the servers do much the same function,
with the primary differences being the form in which validation parameters
are specified by the client, and the form of the answers returned by the
server. The vast majority of the processing performed by the servers for DPD
and DPV is the same, even for a PKI-ignorant client.

[Denis]

The resolution on that point is pending the result of the number of "blob"
data structures that would need to be supported for:

a) certificate(s) or certificate references that *might* be useful for the
server,
b) revocation information that *might* be useful for the server.


yes. see comments above.

<snip>
[Steve]

I don't think I have seen anyone suggest that DPD return partial path info,
but maybe I have overlooked this. We obviously have different models here.

[Denis]

If the request parameters are "coarse" (e.g. no naming constraints or no
certification policy constraints), nothing would prevent the server to find
more than one acceptable certification path.

But these multiple paths should each be complete, not partial, relative to whatever constraints were established.

<snip>

[Steve]

Protocols 2 & 3 are quite similar because I assume that a DPV client using
ASN.1 will be able to supply cert path and revocation status data in cases
such as the ones I noted, e.g., when the protocols allow clients to pass
this info around even if they do not understand it. We have examples of such
protocols now. It's a reasonable design approach, allowing a mix of
PKI-aware and PKI-ignorant implementations for the same protocol.

[Denis]

A DPD client is supposed to be both ASN.1-aware and PKI-aware, so he may
format the cerths and the revocation data that he already got from the
application protocols in any desired way. The same assumption does not
necessarily stand for a DPV client that might be ASN.1-aware but would be
PKI-ignorant.

If we adopt a small set of data structures for passing certs and CRLs (and maybe OCSP responses), then why can't DPD clients use the same structures? If so, then the ASN.1 protocols (2 & 3) look a lot alike. Anyway, I don't think we should devote too much more energy to this discussion, for 2 reasons. As I mentioned in responses to other messages this week, if we want to have different request/response formats for DPV and DPD (in ASN.1), then I'm comfortable doing that, even though I bet we'll see quite a bit of overlap in arguments. Paul's message suggests that we not mandate non-ASN.1 (e.g., XML) support in DPV for now, so that we can make progress more quickly here. These two observations suggest that we don't need to argue about the similarities or differences for the 3 protocol cases you described.

<snip>

[Steve]

I begin to see the differences in our perspectives here. Yes, return of a
single path and associated revocation status data would seem to suffice for
DPV, but I don't think that DPD necessarily returns multiple paths, and I
certainly don't think of it doing so in most cases. Also, why would a DPV
server not return OSCP responses as part of its revocation status data, in
an opaque blob? I would assume that either type of server might return
either CRLs or OCSP responses, unless otherwise directed by the client (or
by locally configured parameters).

[Denis]

It is what I said. So we strongly agree. :-) If the OCSP response is part of
the blob, then it is no more directly visible. To this respect the
individual OCSP response that is indeed returned is of no interest anymore
since it is part of the revocation data blob.

OK.

<snip>

[Steve]

The wording here may be confusing me. Are you saying that DPD could be
implemented as an extension to OCSP (as has been proposed), because an OCSP
client must be PKI-aware, whereas a DPV client is nominally PKI-ignorant and
thus would never use OCSP in the first place?

[Denis]

Yes, I mean this.

[Steve]

I agree with that analysis, although it only suggests that the DPD/OCSP
combination is plausible, not necessarily preferable, and that a DPV/OCSP
combination is less plausible. though not impossible.

[Denis]

Good ! Since the later combination is, using your terminology, "less
plausible", I do not see why we should support it, taking into consideration
one further argument: the caller may be ASN1-ignorant (and XML-aware). In
such case it is not possible to piggy back the DPV protocol on top on an
ASN.1 protocol.

OK.

This means that there is no need to piggy back the two protocols (i.e. OCSP
and DPV) ... unless more information than simply revocation status data is
returned. OCSP *theoretically* allows to carry extensions. We have observed,
by experience, that different people had different interpretations on how
such extensions would work. :-(

At this point of time, I would imagine that DPV would also be able to carry
some extensions, e.g. to ask some additional information on the account of
the leaf certificate holder. We should take great care on how such
extensions would be supported.

I always worry about extensions in protocols, as they create opportunities for vendor-specific functions that result in non-interoperability. if we have an extension facility I would want a criticality flag analogous to v3 certificate extensions. If I had my druthers, I would not provide extensions but would insist on new version numbers as we add protocol features and change syntax. But, you can't always get what you want ...

Steve