Subject: certificate path services [ was RE: NEW Data type for certificate selection ? ]

From: Sarbari Gupta <[email-masked]>
Date: Thu, 15 Oct 1998 10:46:29 -0400

I seem to agree with Alan that there are certain situations where it
would be very beneficial to have third-party services available to
assist with certificate path development and/or validation. 

If (and when) large scale PKIs become widely deployed, it could become a
real problem for each end entity to look up and then validate the
certificate path to its peer's certificate. It requires a large amount
of processing power as well as complicated path processing software to
do this task. Additionally, it requires repeated interactions with a
remote Directory Server to build the certificate path.

There are (at least) two ways to resolve this issue:

1) We introduce the concept of a trusted service, let's call it
"Certificate Path Validation Service (CPVS)" which could take in
requests for validation (comprising the end entity certificate and
possibly a trusted root, policy IDs, etc.) and return an YES/NO answer.
The  CPVS could be hosted on a high-end server that caches recent
requests and has the capability to interface with
Directories/Repositories over the internet to quickly obtain an answer
for the subscriber, thus relieving the end entity system from the
overhead of certificate path processing. The CPVS would also support
revocation models. The CPVS would be particularly useful in an
organizational environment, where a single dedicated system runs the
CPVS for that organization and services path validation requests for
other users within the organization. To support the notion of a CPVS
service, a new service interface needs to be defined and standardized. 

2) We extend the services offered by a Directory Server to allow the
retrieval of an entire certificate path is one call. Thus, the end
system would issue a single LDAP call to the Directory Server (providing
as inputs, the end entity certificate, trust anchors, etc.)  to retrieve
an entire certificate path. The actual path validation would be done on
the end system itself. In this case, there is no need to trust the
Directory since the actual path validation is done locally. The
Directory Service is extended to support path development - also
implying an extension to the LDAP interfaces. 

I think it would be beneficial to offer viable alternatives to
developers of PKI-based systems/products to unburden them from
complicated path processing functions. I am curious to hear others'
opinions on these ideas.

- Sarbari Gupta
=============================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 ext 217
[email-masked]
=============================

> -----Original Message-----
> From:	Alan Lloyd [SMTP:[email-masked]]
> Sent:	Wednesday, October 14, 1998 6:06 PM
> To:	'Sarbari Gupta '
> Cc:	''David Boyce' '; [email-masked] '
> Subject:	RE: NEW Data type for certificate selection ? 
> 
> Yes the problem is a path issue. where CAs may have multiple paths to
> their roots or other CAs, multiple approaches to revokation, Users
> have
> multiple certficates, clients might be root and domain agile, etc.
> 
> I have views on this which says we should not complicate the
> certificate
> any more-  so the client gets even more complex and untrusted, we
> should
> use some simpler methods of validation with the assistance of the
> directory service.
> 
> Phone systems are good - my telephone does not have software in it to
> prove the telephone company can provide it with its phone number ! :-)
> 
> see lloyd-dir-cert-stat-00.txt - I thought it was a good start in the
> right direction - but I am biased of course :-)
> regards alan 
> 
> ----------
> From: David Boyce
> To: Sarbari Gupta
> Cc: 'David Boyce'; [email-masked]
> Sent: 10/14/98 12:48:24 AM
> Subject: Re: NEW Data type for certificate selection ? 
> 
> Sarbari Gupta writes (quoting David Boyce):
> >>(I don't believe specifying 'prefix of Name' is adequate, since it
> may
> >>not be acceptable to match an Issuer at some greater depth than
> >>intended.  Both SubtreeSpecification and NameConstraintsSyntax
> permit
> >>limits to be placed on the depth of the matching, and also permit
> the
> >>explicit exclusion of Names which would otherwise match.)
> >
> >In the context of discussing a mechanism for "selecting" end entity
> >certificates for use, I do not understand why the 'prefix of name'
> >criterion is inadequate.
> 
> Let me see if I can clarify what I mean.  As I understand it, a
> matching rule which supported 'prefix of Issuer' (without further
> qualification) would be adequate for the specific purpose you
> described ONLY if ANY Issuer whose name contained the prefix specified
> would satisfy the intended purpose of the selection.  I think there
> might be other scenarios for which this would not be sufficient.
> 
> For example, consider an environment in which an organization has a
> mixture of 'high-trust' CAs at one level, subordinate to the
> organization, and other 'Low-trust' CAs subordinate to them.  All
> these CAs would satisfy a selection criterion of 'prefix of Issuer'
> with a value corresponding to the organization's name; clearly if the
> intention was to select only 'high-trust' CAs, "prefix of Issuer" is
> inadequate; some other discriminator would have to be used,
> e.g. policyIds.
> 
> A Certificate Matching rule which used NameConstraintsSyntax against
> the Issuer name would permit successful discrimination in this case on
> the basis of Issuer name alone, as specifying a permittedSubtrees.base
> of the organisation name, with a permittedSubtrees.minimum of 1 and
> permittedSubtrees.maximum of 1, the 'low-trust' CAs would not be
> considered.
> 
> In general, once a shortcoming in the present mechanism has been
> identified, it's worth trying to think about what other constraints a
> certificate selector might wish to specify with regard to the Issuer
> name.  (Of course, this whole discussion also has application to
> Subject name and their respective altName extenstions.)
> 
> You have indicated a need for 'prefix of Issuer'; by suggesting
> e.g. NameConstraintsSyntax, I'm trying to address that need, and at
> the same time think about what other aspects of the same problem might
> need to be addressed.  "prefix of Issuer" matching may well be
> adequate for your own environment; but it may not be for other
> environments.
> 
> > On the other hand, if we were discussing
> >certificate path validation, I would agree with you completely; for
> CA
> >certificates in the path to be validated, the NameConstraints
> extension
> >with the permitted and excluded subtrees would be absolutely
> relevant.
> 
> We're not discussing certificate path validation (although clearly
> certificate selection has a bearing on subsequent certificate path
> validation).
> 
> In the above discussion, I'm suggesting extending/adapting the current
> NameConstraintsSyntax definition so that it becomes a basis for a
> matching rule for Issuer name.
> 
> >Apparently, what is needed to support "selection of a certificate for
> >use" by secure applications is the ability to draw upon the richness
> >that is already present in the X.509 v3 certificate syntax. 
> 
> I am beginning to realise there is a more general problem here: how to
> select a Certificate Path (end user certificate plus zero or more CA
> certs) which will permit authentication.  So far we have just been
> discussing the selection of an end-user certificate while assuming
> that the Cert path follows automatically ... it might make sense to
> use X.509 certificatePairMatch for this.
> 
> David.
> 
> -- 
> David Boyce
> 
> Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
> Email:	[email-masked]	Isode's WWW:
> http://www.isode.com/
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Oct 1998 19:35:19 -0400

Sarbari,

>service, a new service interface needs to be defined and standardized.

Well, this certainly makes it clear which single, online system to attack
if one wants to be able to spoof all users in an enterprise environemnt.

>implying an extension to the LDAP interfaces.

This is a lot better than option 1, if I have to choose bewteen the two.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 16 Oct 1998 15:16:25 -0700

Sarbari,

It is nice to hear from you on the PKIX list now.

I will take the occasion of this new thread to comment about the CDS draft
and place this requirement in a broader perspective. This means a rather
long E-mail.  :-(

> remote Directory Server to build the certificate path.

Agreed.

> service, a new service interface needs to be defined and standardized.

This can be seen as one of the services a "Data Validation Service (DVS)"
(see later for the justification of this new name) would provide.

The comments are relative to the document: Internet X.509 Public Key
Infrastructure. Data Certification Server Protocols
<draft-ietf-pkix-dcs-00.txt>. The various facets of the DCS functionality
need to be looked at very carefully before looking at the protocols (i.e. I
will not deal with the protocols).

The abstract says:

"Useful Data Certification Server responsibilities in a PKI are to validate
signatures and to provide up-to-date information regarding the status of
public key certificates".

This addresses two items:

a) validation of signatures,
b) up-to-date information regarding the status of public key certificates.

Let us address the validation of signatures first.

When a signer signs something this is in accordance with a security policy.
That policy may specify one OR MORE trusted points but also the allowed
certification paths that can be used. That policy may be implicit for a
given application/context or may be extracted from the data itself, e.g.
when you receive a signed contract that contains the policy.

The policy does not specify only the trusted points. It may also specify
other conditions, like which TSAs (Time Stamping Authorities) need to be
involved, the grace time period for a user to ask for the revocation of its
certificate in case of a private key compromise, ...

The implication is that nominating one or more trusted points is not enough
in the general case and only a security policy is able to encompass all the
checks that need to be made.

Degenerated cases may consider only one or more trusted point, but saying
that the signature is *valid* is insufficient unless we say against what
(see later the various cases that may be considered).

Considering a "certification path validity checking" would thus be more
appropriate but still restrictive.

An intermediate conclusion is thus to consider in addition to the validity
of a signature, the validity of a certification path. What means performing
a checking against trusted points ? This includes the certification path
that may be used. One way (but not the single one) to define them, is to use
self-signed certificates that include naming constraints. The key point is
to remember that it is not because a certificate exists in a Repository that
it should be used.

When trust points are used instead of security policies, it would be needed
to refer to ONE OR MORE self-signed certificates. In order to make sure that
the path used for the verification is correct, it should be given back
(including CRLs or OCSP responses and ARLs) to the requester so that either
it can check that it is OK and/or that it can be rechecked in the same way
by another DVS.

Let us then address the second item: up-to-date information regarding the
status of public key certificates.

The *status* of public key certificates is already being addressed by OCSP,
so we should not duplicate the work here. It is NOT addressed for an old
status, but it is not evident that it should (see arguments later on, why it
should not).

It would be better to consider "up-to-date information regarding the
*validity* of public key certificates".

Since both items would be about validity/validation, a better name would be
a Data Validation Server (DVS) instead of DCS where the word "Certification"
(from Data Certification server) may be confusing with the function of a CA.
As an example of this kind of problem the actual text speaks about: "When
certifying a public key certificate, the DCS verifies ..." A CA
(Certification Authority) does such a certification, not a DCS.

In the introduction (section 1) three functions are introduced:

1) validity and correctness of an entity's claim to possess data,
2) validity and revocation status of an entity's public key certificate,
3) validity and correctness of another entity's signature.

For the item 1, the TSA (Time Stamping Authority) already allows to prove
that the requester possessed the data in the request at the time indicated
by the DVS.

Is it thus needed in addition to consider the case where a single entity
(the DVS) both proves that the requester possessed the data in the request
and a valid signature key at the time indicated by the DVS ?

It would be better to keep the two functionality independent. The TSA
signature is always for later use, while the DVS signature is not (see
additional arguments later on). If needed, the same entity can support both
protocols. Since the last case (3) is about any entity's signature, it would
be easier to consider only that case and use the TSA, in addition, when
needed.

In the item 2, if validity is checked, by implication the revocation status
is also checked.

Note: It is not clear to understand what "correctness" means in addition to
validity in the items 1) and 3).

This let me to conclude that the various facets to consider for a DVS would
then be along the following:

1) validity of an entity's public key certificate.
2) validity of a certification path.
3) validity of an entity's signature.

The validity may be checked against:

a) a security policy.
b) one or more self-signed certificates.
c) one or more certification paths.
d) one or more trusted points (provided that the path being used is
returned).

The next question is what kind of information should be given to the DVS ?

There is not a single answer to this question, but it would be better to
restrict some of the possibilities when verifications "in the past" occur.

When something is signed, it seems natural that the verifier makes sure
that, at the first time it makes the verification, it gets everything back
that he will need later on to prove that the signature was valid (according
to a non repudiation policy).

If he (or someone else) wants to make the verification later on, it seems
then natural that he provides what he got at that time. This has two
important implications:

1) This means that the DVS does not have to fetch, e.g. back 3 years old
CRLs or ARLs.

2) This also means that the DVS should return all what is needed for later
proof. That stuff may then be used by any DVS to make the verification,
without the need for anyone to trust the first DVS for its good faith. This
would be a nice way to support the IDUP APIs where such a functionality
exists.

CRLS, OCSP responses and ARLs may then be part of the data that is given or
returned to the DVS. Time Stamp tokens may also be part of it.

All the functions listed above can be used in the context where the DVS is a
server trusted only by its requester and not necessarily by all the other
users. This minimizes the problem of a single point of  attack as mentioned
by Steve.

> implying an extension to the LDAP interfaces.

From my previous remarks, this second option would not be workable since we
would need a very intelligent Directory to do so. Anyway a protocol
different from LDAP would be needed and would not provide all the
flexibility that is needed.

> complicated path processing functions. I am curious to hear others'

Regards,

Denis

---

From: Al Arsenault <[email-masked]>
Date: Tue, 20 Oct 1998 09:29:30 -0400

The recent postings by Sarbari Gupta and Denis Pinkas, along with the draft
DCS protocol <draft-ietf-pkix-dcs-00.txt> seem to be further steps toward
an architecture that I've looked at in the past.  I'm  curious as to
whether that's where some people really want to go.

The architecture in question is modeled after what many people believe is
the way the credit card system works.  That is, I go into a store to
purchase an item.  I hand my credit card to the clerk to pay for the item.
The clerk contacts an account authority, and asks the question "is this
user (i.e., the credit card number) valid for this transaction (giving the
dollar amount in question)?".  The system responds with one of a variety of
possible answers:

		- reject the transaction because:  
			- the credit card has been reported stolen (i.e., the "private key" has
been compromised)
			- the credit card has expired
			- this transaction exceeds the available credit on the card
			- ...

		- accept the transaction; here's the authorization code.

(Obviously, this is generally done electronically - the clerk or the
customer swipes the card and the data are fed to a computer which provides
the answer; the human clerk doesn't talk to another human unless there's
some problem.)

The clerk's next action depends on the account authority's response:  write
down the authorization code if approved; return the card with explanation
if expired; keep card and call police if stolen; etc.

To replicate this in the world of certificates, one would do something like:

	- establish an account authority or transaction server to do all of the
certificate path construction and validation; policy checking; etc.  (You'd
probably have more than one, depending on overall system load, reliability
requirements, etc.)
	- configure each end-entity with the name and certificate of the
transaction server to trust (again, you'd probably configure each one with
a primary and one or more back-ups, but that could be worked on a
case-by-case basis). 
	- when an end-entity receives something to be validated (e.g., a signed
S/MIME message; a request for SSL session set-up) it sends that information
to the transaction server; basically, it's asking "right now, to the best
of your knowledge, is this valid for what the sender wants to do?" 
	- the transaction server receives the request, crunches through all of the
signature validation, cert path construction and validation, policy
processing, etc., and determines an answer which it sends to the requesting
end-entity
	- the end-entity accepts or rejects the initial request based on the
response it gets.

We actually looked at this for a while in the MISSI effort (well, at least
some of us did :-).  There were a number of potential customers who wanted
something like this because of some perceived advantages:

	1 - it seems to fit the 'thin client' model that was all the rage a year
or so ago.  All the end-entity has to know is how to contact a transaction
server; it doesn't have to have all of the cert path construction and
validation logic.  This makes the software with the most copies deployed be
as small, simple, and cheap as possible.  

	2 - it doesn't force any user interactions at the end-entity.  At worst,
the user is told "accepted; authorization code = .." or "rejected: reason...".

	3 - it results in all of the information needed for non-repudiation (e.g.,
certificates, cert paths, CRLs, etc.) being stored at one or a few central
places, rather than having it scattered at various workstations all over
the net.  Further, since it was envisioned that the transaction servers
would be high-end machines located in data centers, it would be easier to
establish the procedures and processes necessary to protect and store the
non-repudiation information.

	4 - it seems to provide the most timely revocation notification of the
system designs presented so far.  Particularly if the transaction server is
also the CA who issued the certificate in the first place, revocation
notification can be distributed almost instantly upon the revocation
decision being made.

On the other hand, it does have a number of potential "issues" (to be
polite). Some of them were:

	1 - as Steve Kent has pointed out, it makes the transaction server an
attractive target.  I can derive great benefit from taking it over, and I
can probably derive some benefit just from crashing the thing.  (Military
folk tend not to like designs with single points of failure; it's too
darned easy to just drop a bomb on the thing.)As Denis Pinkas pointed out,
you can alleviate some of this, but there's a cost attached.

	2 - without worrying about attacks, it's likely that the transaction
server will have major reliability & communications bandwidth requirements,
especially if we're dealing with approvals required prior to the
establishment of real-time connections.  This will cause it to be a very
expensive suite of hardware & software, compared with the rest of the
system.  

	3 - it's relatively straightforward to handle signed messages.  Encryption
is worse, though - if you want the transaction server to handle encrypting
and decrypting of data, you've turned your environment into something that
looks a lot like what's described in Dean & Ottaway's
<draft-ietf-smime-domsec-00.txt>.  You lose the ability to have data
encrypted from end-user to end-user; you can only encrypt it from end-user
to server or even server to server.  Then, the data pass in the clear
between end-user and server, or have to be separately encrypted for that
link. That's not necessarily bad, but it may not be something that
everybody wants to do.  (If you want to have the transaction server handle
signature but not encryption, you lose much of the benefit, because the
end-entity will have to do all of the certificate path construction and
validation just to encrypt & decrpyt data.)

None of these "issues" is necessarily unsolvable in general, but they may
be too hard in any particular environment, and taken together they can
cause a lot of pain.  (Ultimately, we didn't implement anything like this,
because it was going to take a lot of time and money to solve the "issues",
and it wasn't clear that all of them were readily solvable given our
particular constraints.)

Now, the reason for this long-winded message:  with OCSP, PKIX took the
first step toward this architecture, by setting up a server to basically
check CRLs for the end-user.  With DCS, it looks like we're taking the
second step, with the cs and cpkc transaction types.  So:  will PKIX
eventually move toward supporting the full architecture?  If that's
anybody's goal, should we be starting to look now at the entire set of
things necessary to get there, rather than taking it piece by piece?

Or, is it the case that nobody thinks that the architecture I described is
ever in the plans, and all we're looking at is incremental service
enhancements?

				Al Arsenault

- my opinions are my own, yada, yada, yada

---

From: "Stephen P. Wilson" <[email-masked]>
Date: Tue, 20 Oct 1998 17:09:21 +0100

Al Arsenault wrote:
> 
> 3 - it's relatively straightforward to handle signed messages. 
> Encryption is worse, though - if you want the transaction server to 
> handle encrypting and decrypting of data, you've turned your 
> environment into something that looks a lot like what's described in 
> Dean & Ottaway's <draft-ietf-smime-domsec-00.txt>.  You lose the 
> ability to have data encrypted from end-user to end-user; you can only 
> encrypt it from end-user to server or even server to server.  

Just to clarify - the domsec draft doesn't prevent end to end user
encryption. 

Steve.

-- 
Stephen Wilson. BSc (hons), AMIEE.          [email-masked] 
The views and statements contained in this message are entirely those 
of the author and should not be considered as the opinion or policy 
of any other person or organisation.

---

From: Eric Murray <[email-masked]>
Date: Wed, 21 Oct 1998 08:35:19 -0700 (PDT)

> dollar amount in question)?".  The system responds with one of a variety of

[deletia]

The account authority model is very useful for systems which
require authentication of messages from end-entity by a central
authority.  As you point out, it's not as useful for key exchange
between end entities.  But there are a lot of systems where
there isn't a key exchange but is authentication of end entities
by an authority.

The ANSI X9.59 electronic payment protocol (from the X9A10 working group)
is based on the account authority model.  It integrates well with
systems like credit-card processing.

X9.59's model for account-authority authentication is based on
Lynn Wheeler's AADS work.  See http://www.garlic.com/~lynn/.

-- 
Eric Murray          N*Able Technologies                    www.nabletech.com
(email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Oct 1998 14:51:41 -0400

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.

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.

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.

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.

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.

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

---

From: Al Arsenault <[email-masked]>
Date: Fri, 23 Oct 1998 10:50:01 -0400

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:

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

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

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

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

>process isn't all that bad and is well within the capabilities of cert

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.

>i.e.,  slime has been tracked onto the slope by those trying to escape the

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!!