Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])

[Al Arsenault <aarsenault@xxxxxxxxxx>]

Steve,

	While I agree with many of your points, I think I disagree with your
conclusion.  

	From the standpoint of PKIX, the question is whether or not somebody
develops a full protocol for "dumb client talking to validation server"
communication, which would be a generalization of the OCSP and DCS
protocols introduced to this point.  That's the only thing we could do that
fits within the IETF's bailiwick; other architectural issues I think belong
with some other group (although I'm not sure which one).  I'm not willing
to push that protocol right now (or maybe ever), but I was trying find out
whether somebody is planning on introducing it in the future (Michael?
Carlisle? Anybody? :-), since we seem to be heading there one step at a time.

	However, I do think that the type of architecture I described has some
applicabiity in the PKI world.  Not everywhere, to be sure, but in some
places.  What I was trying to do was find out whether I'm out in left field
(again :-) with that belief, or there are some others who are looking in
that direction. There's an issue with exactly how much functionality goes
in the end-entity, but I think that there's definitely a place for a
validation server.  

	Now, some specific comments:

At 02:51 PM 10/21/98 -0400, Stephen Kent wrote:
>Al,
>
>First I just wanted to point out that your credit card  example isn't quite
>complete.  In principle, the merchant makes the authorization request to
>the issuing bank (though not directly), equivalent to asking the issuing CA
>about the status of a cert.  This is necessary because the request is not
>really authentication, which could be statically validated, but an
>authorization check, which depends on the current credit limit for the
>account, which is know only by the issuing bank.
>

AWA:  are PKIs for authentication only, or are they also useful to support
authorization checks?  I've always believed that PKIs can be used to
support authorization checks, although this is clearly a much harder
problem than mere authentication.

>Now, in fact, intermediaries have become part of this scheme, and they will
>confer authorization codes, even though they don't have access to all the
>necessary credit data.  These "factors" take a piece of the action for this
>service, and are liable for the transaction cost as a result.  It is not at
>all clear that this later model is appropriate for the PKI environment, for
>other than financial transactions. For one thing, it may be hard to attach
>a price to many non-financial transactions, which makes it difficult for a
>third party to accept liability.  Also, if you look at the CPS for most
>public CAs, they really try to avoid all liability, or limit it
>substantially, which  calls into question the real utility of folks who
>would perform this as a public service.
>

AWA:  I agree with you on this.  It is unfortunate that many of the
"intermediaries" (and a lot of the "public CAs") that exist in the PKI
world today charge a fee for their service but don't really provide
anything of value.  I have enough confidence in the marketplace, though, to
believe (or at least hope) that they will either start providing a useful
service or disappear soon enough.  (I for one refuse to deal with any
public CAs - or private ones, for that matter - that I believe don't
provide value.  If they won't accept liability for their actions, then I'm
stuck with the consequences.  If I'm stuck with the consequences, I'm just
going to do the work myself, and the heck with them.)  However, I don't
believe that this invalidates the entire model of "validation servers",
particularly when those servers are the CAs themselves.


>If one thinks about the model in a more local context, some of these issues
>change, but then it also seems less likely that one should expect a high
>availability, high security server to be provided in such contexts.
>

AWA:  yes, I think that a lot of the concerns about "intermediaries" and
"public CAs" go away.  However, the requirements for "high availability,
high security" will be a function of the specific locale, so it will still
be an issue for some.  As an example, an organization processing
very-large-dollar transactions may set up its own PKI, separate from the
rest of the world, but still have very stringent security and availability
requirements for certificate validation, because of the risk involved.

>One of the biggest features of a well designed PKI is that it embodies a
>distributed security model that scales through simple replication of static
>data, a problem we know how to solve.  It also has the property that to
>spoof the identity of an end entity, one ought to have to subvert the CA
>that issued the cert to that entity, although sloppy cross certification
>and bad choices for PKI structure can make this situation worse.
>

AWA:  agreed, it should be a required property of a PKI that the only ways
to spoof the identity of an end-entity should be (1) defeating the CA (by
taking over the CA's machine & private key; by tricking the CA into issuing
the certificate improperly; etc.); and (2) defeating the end user (by
stealing his private key & the ability to use it without detection).

>The notion of cert validation servers is thus very disturbing.  It might be
>quite helpful for a server to collect certs and CRLs on behalf of users,
>caching them locally, to facilitate cert path validation, so long as the
>relying party does the validation.  The reduced commiunication overhead
>would be a good side effect, and fancy heuristics for figuring out where to
>look to find the right certs could be centralized.  However, once one has a
>candidate cert path, and matching CRLs/OCSP responses, the validation
>process isn't all that bad and is well within the capabilities of cert
>clients.

AWA:  in principle, I agree.  Sometimes the notion of a 'thin client' is
stretched so much that I think it should really be called a 'dumb
terminal'.  Personally, I want the software on my machine to do the cert
path validation.  However, there are some folks who seem to be willing to
let the security of their system depend on the actions of a validation
server.  If, understanding all of the risks, they really want to do that, I
won't try to stop them.

>
>Pushing validation off to a third party, especially in a public context,
>further complicates the murky "trust model" problems we already face in the
>PKI arena, e.g., because organizations that are authoritative for data are
>failing to act as CAs (or at least RAs).  In a country where few people can
>program VCRs, the notion of complex certification hierarchies is
>unrealistic, whether distributed or centralized processing is performed;
>moving cert validation to servers will not fix this problem and it
>certainly has the potential to create significant new vulnerabilities for
>PKI implementations.
>
>My view has been that OCSP is an appropriate mechanism IF the responder is
>operated by the cognizant CA or an explicit delegee thereof.  Once one
>moves in the direction of having other than the issuer of a cert vouch for
>its validity, one is heading down the slippery slope you descibed. At the
>bottom of this slope is a swamp, which explains why the slope is slippery,
>i.e.,  slime has been tracked onto the slope by those trying to escape the
>swamp :-).
>
>Steve

AWA:  the model I described can't work unless the validation server is
either the CA or someone explicitly designated by her - otherwise, the
revocation information won't necessarily be correct; the operator of the
validation server won't accept liability and thus there's no value added;
and the risks are increased too much.  (When we looked at this, we first
thought of having our CA - which did its assigned job very well - be the
validation server.  We weren't sure it was up to the performance
requirements, and we didn't want to risk the security of our CA
implementation by throwing on a bunch of extraneous tasks.) 

Re your last sentence: yes this can add significant new vulnerabilities,
but it also provides an opportunity to concentrate the hard problem of
dealing with complex certification hierarchies into a few places, and you
may have a better chance of getting it right.  It comes down to how much
trust you're willing to place in the client<-->validation server connections.


			Al Arsenault

-- you all know the disclaimer about my opinions by now.  As if any
employer would actually admit to sharing them!!