Subject: Requirements for remote path processing services

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 May 2000 10:59:45 -0700

After the discussion in Adelaide, a group of us got together to hammer
out what we consider requirements for remote path processing services.
The general consensus of that group follows. The group who came to
agreement that these are in fact a good statement of requirements
include:

Ambarish Malpani, ValiCert
Carlisle Adams, Entrust
Michael Myers, VeriSign
Michael Zolotarev, Baltimore
Paul Hoffman, IMC & VPNC
Peter Sylvester, EdelWeb
Stephen Farrell, Baltimore
Stephen Kent, BBN

1. Requirements for remote path processing services

Remote path processing provides two primary services: delegated path
construction for client-based path validation, and delegated path
validation. Not all clients require both services in all scenarios. Many
clients require only delegated path construction (including path
discovery) to help them perform their own path validation, while other
clients have requirements for offloaded path validation and have no need
for data acquisition.

The delegated path construction features of remote path processing are
valuable for clients that do much of the PKI processing themselves and
simply want a server to collect information for them. The server need
not even be trusted, because the client will ultimately perform path
validation. Offloading path validation to a server may be required by a
client that lacks the processing, and/or communication capabilities to
perform path discovery and path validation. (Path discovery may not be
required in all cases, e.g., some applications provide means for
certification paths to be transmitted as part of the protocol.) Another
motivation for offloading path validation is that it allows centralized
management of validation policies in a consistent fashion across an
enterprise.

A client that performs path validation for itself may still benefit in
several ways from using a server to acquire certificates, CRLs, and OCSP
responses to aid in the validation process. In this context, the client
is relying on the server to interact with repositories to acquire the
data that the client would otherwise have to acquire using LDAP, HTTP,
and so on. Since these data items are digitally signed, the client need
not trust the server to return the "right" data any more than the client
would have to trust the repositories. There are several benefits to this
approach; for example, a single query to a server can replace multiple
queries to one or more directories and caching by the server can reduce
latency. Another benefit to the client system is that it need not
incorporate a diverse set of software to interact with various forms of
repositories, perhaps via different protocols, nor to perform the graph
processing necessary to discover paths, separate from making the queries
to acquire path validation data.

A client whose networking and/or processing capabilities are limited may
be unable to perform path validation itself. In this case, there must be
a fully-trusted server to which the client can delegate path validation
services. Such a server can take direction from the client about how
path validation should be done (such as which roots are to be trusted),
and the server can even provide to the client proof (e.g., certificates
and CRLs or OCSP responses) of how the server validated the target
certificate. Even clients that are able to do their own path validation
might instead rely on a trusted server to do path validation if the
client is in an environment where centralized management of trusted
roots or centralized management of non-standard policy processing is
needed for some applications.

1.1 Collecting path validation information

An untrusted server can provide a client the certificate path needed for
path validation. It also can provide clients with revocation
information, e.g., CRLs and OCSP responses, that the client can use to
perform path validation. These services can be valuable to client
systems that do not include the protocols needed to find and download
all of the intermediate certificates, CRLs, and OCSP responses needed
for the client to perform complete path validation.

1.2 Delegating path validation

A server can perform full certificate validation for the client. If a
client uses this service, it inherently trusts the server as much as it
would its own path validation software (if it contained such software).
One reason that a client may want to delegate to such a server is that
the client does not have sufficient processing or networking resources
to perform path validation for each certificate it receives. In
addition, because the algorithms required for path validation are
complex, not all applications may embody high quality implementations of
this processing. In constrained execution environments such as
telephones and PDAs, memory and processing limitations may preclude
implementation of complete, PKIX-compliant path validation.

In applications where minimum latency is critical, delegating validation
to a trusted server can offer significant advantages. The time required
to send the target certificate to the validation server, receive the
response, and verify the signature on the response, can be considerably
less than the time required by the client to perform path discovery and
validation. Even if a certificate path were readily available to the
client, the delay associated with processing the signatures for each
certificate in the path might (under some circumstances such as very
long paths or very limited processor speed) be greater than the delay
associated with use of a validation server.

1.3 Centralized trust and policy

Organizations that impose a centralized management discipline usually
want consistent policy enforcement across all clients in particular
scenarios. In such cases, allowing a client to manage its own set of
trusted roots or the policies that it accepts during path validation is
unacceptable. A trusted server can enforce particular policy decisions
while performing path validation. Also, experience shows that it is
difficult to manage software configuration on end systems in a corporate
environment.

Because path validation software is controlled by many parameters which,
if incorrectly set, may result in insecure behavior, it is often
important to be able to centralize path validation in a single or small
set of servers, where system security administrators can carefully
manage them. Both services (delegated path construction and delegated
path validation) can be potentially used by the enterprise for enforcing
various aspects of centralized policy.

Note that it is not clear which aspects of PKI policy can, in general,
be usefully separated from other application specific policy using this
approach. This is a matter for further study.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Andy Dowling" <[email-masked]>
Date: Mon, 29 May 2000 12:01:30 +0100

Paul + co.,

Having read your post, I was just wondering if these remote path processing
services could be applied to ACs for authorisation purposes? I've put
together a few points on the subject (see below).

Comments would be appreciated.

Regards,

Andy

1) OVERVIEW

In addition to remote path processing services:

a) delegated path construction
b) delegated path verification
c) trust and policy centralisation

that apply to public key certificates, there may be scope for
the application of these services to authorisation-related certificates
i.e. Attribute Certificates could be verified remotely by a single
trusted entity, and this would bring the benefits of centralised
trust/policy management and simpler clients.

2) MOTIVATION

Firstly, let's present some arguments *against* introducing remote AC
validation:

a) The current profile for AC validation is relatively simpler than
   that of PKC validation:

        a) AC chains are not used
        b) AAControls is optional
        c) AC revocation checking is optional

   Consequently, a very minimal (and conformant) AC validator can be
   implemented and would be "lightweight" enough to provide on clients.

b) AC validation for authorisation purposes is typically a server-side
   operation anyway, and clients would hardly need to validate an AC.

In response to argument (a):

     Whilst a client may indeed conform to the simplest version of the AC
     profile with a lightweight implementation, such an implementation
     would have no control over which attributes can be issued by which
     authorities (AAControls), due to the lack of chain processing.
     In addition, the client cannot safely validate long-lived ACs.
     This is due to the lack of revocation processing.

In response to argument (b):

     Clients *may* need to validate ACs in the push model to
     ensure the integrity of the AC before passing it on to other
     servers. (Complications arise here when the AC is pushed to a
     different "trust domain" where the AC validation policy differs
     to that of the clients policy, so there's scope for further study here)

     A client will need to validate an AC if it is used in the making of
     a client-side access decision. Scenarios in which a client-side
     access decision would need to be made are:

            --> Checking the permissions of downloaded content:
                --> Has a piece of downloaded code have execute permission
                    from the system admin?

            --> Client-side content filtering:
                 -> Checking if downloaded content has a "rating" attribute
                    (12, 15, 18, PG-13, NC-17, R, etc.)

It is apparent that there is indeed a requirement for:
       (a) clients to validate ACs
       (b) AC validation to be performed "fully". That is, AAControls
           and revocation checking should be done for security reasons.

Given these requirements, it seems logical to migrate these verification
tasks to a dedicated AC validation server.

2) BENEFITS:

The benefits are the same as for remote PKC processing:

a) Centralised trust and policy for authorisation purposes

    (i)   Administrator(s) can say what AAs are trusted by the enterprise
    (ii)  Administrator(s) can implement complicated trust management via
                           AAControls and/or AC Chain validation
    (iii) Administrator(s) can implement AC revocation checking

b) Simplified clients
    (i)  No need for the client to implement any form of AC verification,
         path processing (for AAControls), LDAP/OCSP clients, etc.

c) Server-side caching to improve turnaround time on a validation request

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 30 May 2000 16:22:01 +0200

Paul,

Thank you for posting the requirements. In general I do not find the
document precise enough, so that we can make sure we really agree on
the goals. There are too many variants possible and I would have
prefer to have identified the various functions that would be
offered and the various parameters that would been sent and
received, of course, at a broad level.

There are several duplications of text and ideas and a more concise
document would be more appropriate. However, this is better than the
previous situation. :-)

> 1. Requirements for remote path processing services

It would be important to say upfront against "what" a path may be
validated. I see two options :

1) against a security policy defined by an OID,
2) against multiple roots, Certification Policy constraints and
naming constraints.

> simply want a server to collect information for them. 

Does this means :

1) collect all ?
2) collect only the certification chain ?
3) collect the certification chain and the associated revocation
information ?
   When revocation information is requested, does this mean:
       a) anything ?
       b) CRLs ? 
       c) OCSP responses ?  

  ... and is it for the leaf certificate only or for all the
elements of the chain ?

> The server need

I would say : Such a server MUST take directions from the client
about how path validation should be done.
 
> certificate. 

Yes. It must be able to say whether or not the information shall be
returned.

> Even clients that are able to do their own path validation

Good point.

> perform path validation. 

See the questions raised above about the granularity of the
information to be returned.

> These services can be valuable to client

Even if the validation is fully done by the server, I would still
like in that case that the information that has been used is
returned. It is not clear whether this is the case. See the
questions raised above about the granularity of the information to
be returned.
 
> associated with use of a validation server.

A basic question that is not answered is the following: Does the
client want to take advantage of the signed response and make the
server liable in case of an error ? If this is the case, then the
response MUST contain the criteria against which the validation has
been performed by the server, otherwise this is not necessary. 

> difficult to manage software configuration on end systems in a corporate

The case of a client working with a single (or a small set of)
policy is not our scope and so the protocol should be able to handle
multiple validation schemes at the same time. If a server decides to
support one and only one policy, that's fine, but this should not be
visible at the level of the protocol. So I wonder why this section
has been added, because it should not change anything in the design
of the protocol. I probably missed something. :-)

> various aspects of centralized policy.

Well, requesters might "forget" to correctly use the result of the
server, so enforcement of the policy might be a dream in some cases.
:-)

Denis