Subject: Thin PKI won - You lost

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 15 Dec 2000 11:31:56 +0100

Hi Steve, 
Do you remember the debate I started some 18 months ago when I launched the 
"Thin PKI"/CyberPhone concept in this list? 

   http://www.mobilephones-tng.com/v100/dynamiccerts.html

The concept in a nutshell: When you engage in inter-organizational activities you let an 
"organization server" vouch for its employees (clients) by signing (AC-like) credentials on the fly for 
authentication, and signing outgoing transactions on the clients request. All this without using
any direct PKI-based "connection" between the client and the RP.   BTW, the client does 
not even have to use PKI! 

You claimed that this was a bad idea, while I claimed that this is "the future for PKI".

After reading the S2ML-draft 0.7a I can inform you that this specification, which is supported by
VeriSign, RSA etc. use exactly this scheme for authentications and authorizations.  And so does
BTW VISA's coming 3D-SSL payment solution as well.

                                 Any comments? :-) :-)

My guess is that this will in a couple of years, smash quite a few PKI-projects into pieces!

For those who are engaged in federal or national PKIs, and Bridge-CAs etc.:

                   === You are very likely to be on the wrong track! ===

We need thin "interoperable domains" (VISA's term) between organizations, not giant PKIs where
"everybody is talking to everybody" (certificate-wise).  The banks use the former model, and although
banks cannot be accused for being hi-tech, they have anyway succeeded in doing advanced O2O/B2B-things
(even globally), supporting millions of ordinary users on the Internet,  which none of the many
government-sponsored PKI-programs have achieved, or will ever achieve using current PKI-models.

Signature archival is a built-in feature using Thin PKI, instead of something that
you with great pains "glue" to a basically broken system.

The term "Thin PKI" was coined by me to denote the fact that you with a single cert+key could
"do anything" you'll ever need.  It could actually be extended to organizations as well.

That interoperability becomes a no-issue (at least compared to the "classical" PKI approach), is
the fact that a single commercial TTP can w.o. problems certify millions of organizations.
I.e. much of this CA policy-stuff that some organizations are working with is in vain as most
organizations will buy pre-packaged products.  "Trust" is actually something that has to be created within
organizations and that is (except for a few die-hard PKIers), virtually independent on CA policies.

Anders Rundgren
co-founder
X-OBI
+46 70 - 627 74 37

---

From: Camillo Särs <[email-masked]>
Date: Fri, 15 Dec 2000 14:46:17 +0200

Hi Anders,

(Cc: to PKIX - feel free to disregard this message if it conflicts too
badly with your beliefs.)

Anders Rundgren wrote:
> The concept in a nutshell: When you engage in inter-organizational 
> activities you let an "organization server" vouch for its employees 
> (clients) by signing (AC-like) credentials on the fly for
> authentication, and signing outgoing transactions on the clients 
> request. All this without using any direct PKI-based "connection" 
> between the client and the RP.   BTW, the client does not even have to
> use PKI!

This is beginning to sound familiar, although you are still relying heavily
on the "on-line trusted party" role.  Which is fine in some cases, but not
generally applicable nor stricly speaking always necessary.

> You claimed that this was a bad idea, while I claimed that this is "the 
["You" refers to Stephen Kent]
> 
> After reading the S2ML-draft 0.7a I can inform you that this 
> specification, which is supported by VeriSign, RSA etc. use exactly this 
> scheme for authentications and authorizations.  And so does BTW VISA's 
> coming 3D-SSL payment solution as well.
> 
>                                  Any comments? :-) :-)

Add a few features:
- Ability to generate limited-authority certificates beforehand for limited
periods of time.  E.g. "PP can buy pens today".
- Ability to optionally delegate the rights.
- Ability to restrict rights during delegation.

and what you effectively have is very close the semantics of SPKI.

>                    === You are very likely to be on the wrong track! ===

I tend to agree with you.  For most on-line transactions, the concept of
"identity" is fairly irrelevant - the real issue for the relying party is
the authorization to perform an action.  Once the high-level legal trust
relationships exist [Read: "If you cheat, we will sue you out of
business."], the remaining issues are mostly about transferring
authorization - delegation - and avoiding fraud by the users.

On a side track, current "Qualified Identity Certificate" systems are very
vulnerable to private key exposure and require highly trusted terminals. 
Windows-based PCs are not such trusted terminals, regardless of how many
smart cards you buy.  This issue is usually not discussed at all, which I
find very alarming.

In certificate systems where authorizations are higly granular, atomic and
limited, the risk introduced by improper use of a private key or the
compromise of the signing system is significantly smaller.  As a matter of
fact, I believe this is the only way we can ever make PKI-based eCommerce
work outside laboratories.

Regards,
Camillo Särs
-- 
Camillo Särs <[email-masked]>       http://www.iki.fi/ged/
Security Researcher, F-Secure Corporation      http://www.F-Secure.com
    *** My office phone number has changed to +358 9 2520 5554 ***
   F-Secure products: Securing the Mobile, Distributed Enterprise

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 15 Dec 2000 14:25:11 +0100

Hi Camillo,

> generally applicable nor stricly speaking always necessary.

The reason for having the on-line trusted party (sort of real-time attribute CA) is that
it can generate whatever credential you need, when you need it, and without any
distribution or installation.   For O2O authentications I would say that it is
generally applicable.  It is a pure convenience solution.

<snip>

> and what you effectively have is very close the semantics of SPKI.

But without the distribution hassles.

> compromise of the signing system is significantly smaller. 

Actually I am much less confident that S2ML's authorization system will be that popular,
as there are other solutions like OBI, that keeps authorizations "at home".  And
the kind of granularity you have "at home" can be anything from getting a "Yes"
from the boss, to fully rule-based systems where each individual can do only
exactly what he/she is supposed to do.  To the outside world there is for most
outgoing messages, no real visible authorization.  Small order, large order,
they all look the same.

>As a matter of

You refer to SPKI here I guess?  A bit unfortunate for SPKI, is that it has been shunned by´
the "big ones" and S2ML will just make this worse.

Or did I get that wrong?

/anders

---

From: Camillo Särs <[email-masked]>
Date: Fri, 15 Dec 2000 15:42:05 +0200

Anders Rundgren wrote:
> The reason for having the on-line trusted party (sort of real-time 
> attribute CA) is that it can generate whatever credential you need, when 
> you need it, and without any distribution or installation.

Quite useful, you are right.  But still - there are cases where generating
some credentials beforehand makes sense.  Which means that it makes sense
to allow it.  And "sense" here is "business sense".

> But without the distribution hassles.

Agreed.

> Actually I am much less confident that S2ML's authorization system will 

I wasn't really focusing on that, but rather on the risk model.  Any model
that allows almost arbitrary "contracts" to be signed without discretion
are just too risky for real-life implementation.  The scope of the
authorization granted by the certificate should be minimal, not maximal as
in current X.509-based solutions.  Get a suitable trojan onto a user's
system, and you can sell his house, his car and make him file for divorce.
I, for one, won't be getting any certificates with that risk model. No
way.  They invert the legal burden of proof - I have to show that someone
else did these things.  How many courts of law are technically qualified to
know the difference?

> You refer to SPKI here I guess?  A bit unfortunate for SPKI, is that it 
> has been shunned by´ the "big ones" and S2ML will just make this worse.
> 
> Or did I get that wrong?

You did.  SPKI is just one example of a more suitable semantic model, with
much nicer security properties.  I just happen to like it, preferences
vary.  If the "big ones" want to re-invent the wheel, or make silly
compromises, they are quite free to do so (:-).  My argument was more on
the point that systems *must* limit the power of the signatures.  And that
this limitation cannot happen on the signing client, as it runs highly
vulnerable and untrusted software.  *Any* step that limits the power is
good.  I don't care who takes it, and how, but VISA is one example of an
organization that knows something about risk management.

Regards,
Camillo

---

From: Olaf Kirch <[email-masked]>
Date: Fri, 15 Dec 2000 15:37:53 +0100

On Fri, Dec 15, 2000 at 03:42:05PM +0200, Camillo Särs wrote:
> are just too risky for real-life implementation.

I've started becoming interested in X.509 stuff only quite recently, but
all standards/drafts/etc I've read so far failed to mention the risk of
client platform compromise. This had me baffled quite a bit. The threat
is nothing new (see Kerberos' TGTs), so does this mean that e.g. PKIX
certificates are never supposed to be used on ordinary PCs?

Olaf
-- 
Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
[email-masked]  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
[email-masked]    +-------------------- Why Not?! -----------------------
         UNIX, n.: Spanish manufacturer of fire extinguishers.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Dec 2000 10:02:22 -0500

At 11:31 AM +0100 12/15/00, Anders Rundgren wrote:
>activities you let an
>request. All this without using
>specification, which is supported by

Bad ideas are patentable, marketable, and may even be successful. 
What's your point?

>banks cannot be accused for being hi-tech, they have anyway 
>succeeded in doing advanced O2O/B2B-things

This sort of marketing rhetoric has no place on an IETF mailing list, 
including this one. If you can't restrict your contributions to 
technical discussions, we'll have to ask you to not pot to this list.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 15 Dec 2000 19:21:23 +0100

Steve,

> technical discussions, we'll have to ask you to not pot to this list.

Pardon me, I got a little bit carried away.

But, are you *really* prepared to openly discuss the problems with classical PKI
versus Thin PKI, S2ML, OBI and 3D-SSL?

If so, please comment the section of my posting mentioning banks, as this is something practically
all in this list have some knowledge with.  As this is a very complex subject (my usual
Thin PKI seminar is 2-3 hours!), it is though very important to stay exactly on the track,
otherwise the discussion will deteriorate in no time at all.  Unfortunately I don't think
that any of the main forces behind S2ML, OBI or 3D-SSL are interested in 
"The war of the PKIs", but we'll see.   And in the same way as with PKIXML, I
care more about "marketability" and "deploymentability" than if something is the
"most secure solution in the world".  Sweden actually had the most secure solution in
the world: The SEIS electronic ID-card.  Unfortunately it is fairly useless and expensive,
and therefore very few have it.

Regards
Anders Rundgren
co-founder
X-OBI

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Dec 2000 15:55:18 -0500

>and therefore very few have it.

The financial community has a set of concerns that are entirely 
valid, and are NOT the whole of PKI. Lynn Wheeler, who just 
contributed to this discussion, pursues PKI issues in ANSI F9, a 
standards committee devoted to that application area.

PKIX addresses a broader set of PKI users and does not tailor 
standards to meet requirements of a given application arena, even if 
it is a very, very big arena. This, for example, we will not address 
PKI problems that are cast narrowly as financial transactions or cell 
phone problems, etc. The delegated path validation/discovery work 
that we are now doing is not narrowly cast, even though it may be 
very applicable to wireless users, etc. This desire to not be driven 
by specific application domains is NOT a PKIX-uniqye. For example, 
TCP/IP could be reworked from the ground up to better accommodate 
wireless users, but that's not likely to happen. The IPsec WG 
rejected the notion of changing ESP to better accommodate satellite 
and low speed wireless users.

The minutes of the WG meeting, plus Phil's slides, should indicate 
that there was no enthusiasm expressed there for mere syntactic 
transliteration of ASN.1 to XML. Phil observed that the XKMS 
initiative that he described is likely to be pursued in another 
forum, e.g., the W3C, based on feedback from the security ADs.

Steve

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Fri, 15 Dec 2000 16:14:50 -0500

Stephen Kent wrote (in part):
snip
> standards committee devoted to that application area.

Wait a minute. As far as I know, Mr. Wheeler is not
involved in any of the security area standards being
developed in X9F, but participates frequently in X9A. 
Not the same working groups.

Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Dec 2000 16:33:49 -0500

Phil,

Thanks for the correction.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 16 Dec 2000 09:27:01 +0100

Steve,

> valid, and are NOT the whole of PKI. 

maybe not, but their basic model for domain-security, and general trust model does IMO apply to 
practically the entire O2O/B2B-field. 95% or more is my educated guess. 

Here is an extremely condensed version of my (unfortunately refused) RSA2001 paper on the subject.

Just to take a very simple example from the health-care sector (to get away from the proprietary stigma
of the financial sector). An outside service provider like a catering company that is getting orders 
from "a PKI-enabled healthcare community": 

Using Classical PKI, the biggest problem (except who is going to issue certificates, potentially containing role
data) with such signatures are: 
- Authority. Who has the right to perform a certain signature? And how do you express it? 
- Trace ability. How do you save signatures (i.e. decisions/orders/prescriptions)?
- Relying party. What to interpret and trust? 

Using Thin PKI the solution gets very simple although [maybe] incompatible with current signature laws: 

A. An organization representative signs using an individual cert+key. The cert does not even have to say 
    that the representative is employed by the organization or has some particular function. 
B. The signed transaction is sent to an "organization-authority-and-signing-server" that 
B.1 Checks that the cert is not revoked and coming from a trusted issuer 
B.2 Checks that the individual is working for the organization and is AUTHORIZED 
to perform the signature operation 
B.3 Saves the transaction as a receipt versus the representative 
B.4 Removes the representative's signature. Sheltering individuals/employees is a requirement.
   Contact information is another thing which should be supplied in the transaction as attributes 
B.5 Adds an "organizational signature" (=stamp) to the unsigned transaction 
B.6 Saves the re-signed transaction as a receipt versus the "outside" / receiver 
C. Sends the re-signed transaction to the end-destination 

The Stamp (organization certificate) can preferably be issued by a TTP and be published on the
organization's home-page for easy reference. Can PKI be simpler?  You may think that this
trust model is very primitive as there is no [external] granularity, but this is by design.  Simplicity
has an advantage: It can be communicated and implemented.  Organization certificates then become
the true digital replacements to company letterheads.  For the rare instances you [externally] need
tighter bindings, you can always dual-sign transactions, add TSP etc.  The bottom
line is that the basic infrastructure is still intact!

Using the above approach the "information tunnel" between organizations is minimized and
scalability is optimized. And with backtracking and archiving is built-in.

This is actually the way banks operate. I.e. their clients are only [fully] known and trusted locally,
while the banks as organizations have their own interoperable and trusted domain . 

And in similarity to banks this allows the clients security solutions develop in
a different pace (and uncoordinated among organizations), versus the inter-organization
security solutions. 

Using TTPs and ASPs, Thin PKI scales downwards as well.  Any organization
will be able to use digital signatures with ease.  As they already can with Internet-banks.

Note1: I have yet to see a single classical PKI program having acceptable (and particularly 
DEPLOYABLE) solutions to archiving, authority control, and backtracking. 

Note2: I did not invent this model. The banks did (in principal). 200-300 years ago... 
Using PKI, secure servers, LDAP and transaction databases,  it gets really cool! 

Anders Rundgren
co-founder
X-OBI
+46 70 - 627 74 37

---

From: "Aaron S. Carmichael" <[email-masked]>
Date: Wed, 20 Dec 2000 23:19:14 -0500

Well, Merry Xmass to all...

Even if this is for PKIX only... We can all say Merry Xmass....

aaron

Aaron S. Carmichael
VP Information Technology
TimeCertain, LLC.
202-244-3243 (voice)
202-244-5694 (fax)
[email-masked]
http://www.timecertain.com

----------------------------------------
This message is for the named persons use only.  It may contain
confidential, proprietary or legally privileged information.  No
confidentiality or privilege is waived or lost by any mistransmission.  If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender.  You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorized to state them to be the views of any such entity.

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Saturday, December 16, 2000 3:27 AM
To: PKIX-List; Stephen Kent
Subject: Digital Signature Infrastructure Was: Classic PKI vs Thin
PKI/S2ML

Steve,

> valid, and are NOT the whole of PKI.

maybe not, but their basic model for domain-security, and general trust
model does IMO apply to
practically the entire O2O/B2B-field. 95% or more is my educated guess.

Here is an extremely condensed version of my (unfortunately refused) RSA2001
paper on the subject.

Just to take a very simple example from the health-care sector (to get away
from the proprietary stigma
of the financial sector). An outside service provider like a catering
company that is getting orders
from "a PKI-enabled healthcare community":

Using Classical PKI, the biggest problem (except who is going to issue
certificates, potentially containing role
data) with such signatures are:
- Authority. Who has the right to perform a certain signature? And how do
you express it?
- Trace ability. How do you save signatures (i.e.
decisions/orders/prescriptions)?
- Relying party. What to interpret and trust?

Using Thin PKI the solution gets very simple although [maybe] incompatible
with current signature laws:

A. An organization representative signs using an individual cert+key. The
cert does not even have to say
    that the representative is employed by the organization or has some
particular function.
B. The signed transaction is sent to an
"organization-authority-and-signing-server" that
B.1 Checks that the cert is not revoked and coming from a trusted issuer
B.2 Checks that the individual is working for the organization and is
AUTHORIZED
to perform the signature operation
B.3 Saves the transaction as a receipt versus the representative
B.4 Removes the representative's signature. Sheltering individuals/employees
is a requirement.
   Contact information is another thing which should be supplied in the
transaction as attributes
B.5 Adds an "organizational signature" (=stamp) to the unsigned transaction
B.6 Saves the re-signed transaction as a receipt versus the "outside" /
receiver
C. Sends the re-signed transaction to the end-destination

The Stamp (organization certificate) can preferably be issued by a TTP and
be published on the
organization's home-page for easy reference. Can PKI be simpler?  You may
think that this
trust model is very primitive as there is no [external] granularity, but
this is by design.  Simplicity
has an advantage: It can be communicated and implemented.  Organization
certificates then become
the true digital replacements to company letterheads.  For the rare
instances you [externally] need
tighter bindings, you can always dual-sign transactions, add TSP etc.  The
bottom
line is that the basic infrastructure is still intact!

Using the above approach the "information tunnel" between organizations is
minimized and
scalability is optimized. And with backtracking and archiving is built-in.

This is actually the way banks operate. I.e. their clients are only [fully]
known and trusted locally,
while the banks as organizations have their own interoperable and trusted
domain .

And in similarity to banks this allows the clients security solutions
develop in
a different pace (and uncoordinated among organizations), versus the
inter-organization
security solutions.

Using TTPs and ASPs, Thin PKI scales downwards as well.  Any organization
will be able to use digital signatures with ease.  As they already can with
Internet-banks.

Note1: I have yet to see a single classical PKI program having acceptable
(and particularly
DEPLOYABLE) solutions to archiving, authority control, and backtracking.

Note2: I did not invent this model. The banks did (in principal). 200-300
years ago...
Using PKI, secure servers, LDAP and transaction databases,  it gets really
cool!

Anders Rundgren
co-founder
X-OBI
+46 70 - 627 74 37

---

From: Stephen Kent <[email-masked]>
Date: Fri, 29 Dec 2000 13:24:58 -0500

As promised, here is the strawman requirements specification for DPV 
and DPD. Questions that the WG needs to address as part of deciding 
on the scope of these requirements are in boldface.

Happy Holidays,

Steve
--------

The WG has already decided to purse standardization of a protocol (or 
protocols) for delegated path discovery (DPD) and delegated path 
validation (DPV). This memo revisits and expands on the rationale for 
offering these services, notes the overlap in server functionality 
required for each, and proposes requirements for candidate protocols 
that will be considered for standardization by PKIX. The goal of the 
memo is to provide a strawman set of requirements and evaluation 
criteria that will be used to select PKIX standards.

A DPD or a DPV server may operate in either a public or private 
context. In the former case, clients are assumed to be from a broad 
community with no common organizational affiliation and the service 
may be offered for a fee. In the latter case, the service may be 
offered to a closed community under a common organizational 
structure, where there is an expectation that the server falls under 
the same administrative control as the clients and no explicit fee 
may be involved. Intermediate or hybrid models also may exist, but 
are not specifically identified here nor required as part of proposed 
solutions.

DPD allows a client to offload the communications and processing 
associated with retrieval of certificates and CRLs (or OCSP 
responses) to create a certification path terminating in a target 
certificate. The client supplies this target certificate, or it may 
supply a partial path, or a complete path (the latter two may have 
been acquired as part of a protocol exchange). In the last case, the 
DPD server assists the client by acquiring relevant revocation status 
information. The client might also supply some revocation status 
data, to aid the path discovery process, just as it may provide a 
partial or complete certification path. This might make sense if this 
revocation status data was supplied to the client as part of a 
protocol exchange, e.g., IKE and S/MIME make provisions for send such 
data.

The client may be bandwidth constrained and thus would benefit from 
having a server interact with repositories and other servers to 
acquire the requisite certification path and/or revocation status 
data. The client may be storage constrained, and thus can benefit 
from a server that caches certificates, CRLs and OCSP responses. 
Because multiple protocols may have to be employed in communicating 
with various servers (e.g., OCSP, LDAP, etc.) in performing path 
discovery, the size and complexity of client code may be reduced by 
reliance on a DPD server. Because the server can have more storage, a 
faster processor, and higher speed communications paths to these 
servers, the client may gain a performance advantage by delegating 
the task of path discovery.

DPV offloads all aspects of path validation to a server, which 
returns to the client, at a minimum, an indication of status of the 
target certificate. This status may be relative to the current time, 
or it might be a request to verify status at some previous time, 
e.g., as an aid to checking non-repudiation evidence. As above, the 
client may provide a partial or complete candidate path for 
validation, or may provide just the target certificate, and the 
client may provide some or all of the associated revocation status 
data. Also, the parameters for path validation must be provided, 
either explicitly in the request or via server configuration. As well 
as the benefits noted above (reduced bandwidth, storage and 
processing requirements and reduced client code size and complexity), 
DPV allows an administrator to centrally manage (via server 
configuration) some or all of the path validation parameters. Similar 
controls on path discovery could be present in a DPD server. Central 
management controls are viewed as especially attractive in closed, 
organizational environments as they mitigate configuration management 
problems for individual clients. For a public DPV service this is not 
an issue because there is no single, central authority responsible 
for configuration management of all clients.

A DPD client is assumed capable of performing path validation on the 
returned certificate chain(s), which implies that the client embodies 
validation software consistent with RFC 2459 (which is non-trivial in 
size and complexity) and thus is capable of parsing certificates, 
CRLs, and OCSP responses. Such a client may be termed "PKI-aware," 
i.e., it can parse ASN.1, verify digital signatures, perform path 
validation, and is cognizant of validation parameters. Thus, no 
apparent, significant benefit accrues from using a syntax other than 
ASN.1 for DPD queries and responses.

Because a DPD client is PKI-aware, it is capable of specifying the 
validation parameters used by a DPD server in constructing a 
candidate path. The goal of DPD is to return one or more chains that 
will be acceptable to the client, so it is important that the client 
be able to specify, e.g., via a DPD request, the set of validation 
processing parameters that it will use for local validation. Only by 
making the DPD server aware of these parameters can the server return 
a path (and supporting revocation status data) that will have a very 
high likelihood of being acceptable to the client. It may be 
desirable, especially in a closed environment, to assert centralized 
control over the validation processing parameters used by the server, 
even though such control is less stringent than that imposed in a DPV 
context. This suggests there should be provisions for configuring 
validation processing parameters into the server, and for allowing a 
client to select from among several possible parameter sets. See the 
discussion immediately below for a further examination of this issue.

DPV also requires a means to control the validation parameters 
defined in RFC 2459. If we assume that a DPV protocol will operate in 
both open and closed environments,  and if we wish to accommodate 
PKI-aware clients, then there must be a means for a client to specify 
all of these parameters, or to specify a subset of them. The former 
requirement arises in the simplest, open server contexts; the latter 
may arise in such contexts if there is some other way to signal a 
default set of parameters for validation control, e.g., via reference 
to one of several validation policies configured in a server, as a 
basis for these parameter values. In a closed environment, it is 
still important that a client be able to specify validation 
parameters, e.g., as a means of selecting from among a set of 
parameters allowed by administrative controls managed at the server. 
For example, a server in an organizational environment may have a 
configured set of trust points, but a client may be permitted to 
select from a subset of these when requesting validation for a 
specific certificate. Such flexibility is needed because the 
validation parameters are a function of several variables that are 
context specific.

It seems reasonable to require a DPV or DPD client to be able to 
control validation via two means: specification of a validation 
policy configured at a server, or via client-specified parameters. 
These means are not mutually exclusive, and a server should support 
combinations of them, e.g., client-specified parameters constrained 
by reference to a server-configured validation policy. We need to 
refine the semantics here, e.g., can the server be configured with 
path validation parameters that CANNOT be overridden by a client, and 
if so, does the server have to inform the client when its 
explicitly-specified parameters were ignored, as part of response, or 
does the server just reject the request, note the offending 
parameters, and let the client try again?

It is tempting to suggest support for multiple policies specified in 
a request, but I'm not sure how one would make use of this. For 
example, is the server required to try to construct paths based on 
each of the policies, in succession, and to return all successful 
results, or is the server free to choose any one of the policies? 
Does the order in which the policies are specified indicative of 
preference? To keep life simple, for now, I suggest that we allow 
specifying only one policy in a request, but I am open to suggestions.

At a minimum, the parameters for server-configured policies must be 
those specified by the certificate path validation algorithm in RFC 
2459. It is tempting to suggest that a vendor may elect to augment 
this set and provide a means by which a client can specify additional 
controls. The motivation here is that, over time, we may identify 
additional controls to provide "fuzzier" evaluation. For example, a 
client might be willing to accept a certificate if the server asserts 
that although the current CRL for the target certificate is not 
available, the certificate is not on the most recent CRL available to 
the server at the time of the request. This area is quite complex and 
does not yet appear suitable for standardization. The WG must decide 
if we wish to require (or discourage) such extensibility. Note that 
extensibility usually leads to added complexity, and possible 
non-interoperabilty, e.g., if private extensions are supported. 
Personally, I would recommend against such extensions at this time.

It has been suggested that a DPV server also should be capable of 
returning time-stamped certification path(s) and revocation data, for 
later use as evidence in a non-repudiation dispute. If so, then the 
data returned by a DPV server is potentially quite close to that 
provided by a DPD server. One could argue that a DPD server could 
provide an option for return of time-stamped path and revocation 
status data, also in support of non-repudiation, for the same 
reasons, which would make the responses for both types of servers 
even more similar.

It is important to ask to what extent should we assume that a DPV 
client is PKI aware? At one extreme one can imagine that the client 
is PKI-aware and that it should be able to specify all of the path 
validation parameters required in 2459. For such a client, returning 
a certificate and an indication of its validity seems appropriate. 
Alternatively, a DPV client may not be PKI-aware, but may still be 
ASN.1-capable. The client could parse a certificate returned to it, 
but it does not implement nor understand path validation. For such a 
client, it seems appropriate to control path validation only via 
reference to a policy, not by specifying individual path validation 
parameters. In the extreme case, a DPV client may not even be 
ASN.1-capable.

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. An argument could be made for using 
XML to represent some of these values, and to represent the syntax of 
the protocol messages. But, some of the certificate contents, 
specifically the issuer name and subject name, are intrinsically 
ASN.1 objects themselves, so these values would have to be decoded 
even further for use by a non-ASN.1-aware client. (There are 
scenarios that motivate return of ASN.1-encoded data, e.g., 
certification paths and revocation data, as an opaque blob, e.g., for 
later use in a non-repudiation dispute. But this does not imply that 
the client is ASN.1-aware.)

If we wish to support DPV clients  that are not ASN.1-capable, the WG 
is faced with a question; Shall we mandate support for another syntax 
in addition to (or in lieu of) ASN.1, for a DPV protocol? This 
question must be resolved soon, as it becomes an important input to 
DPV protocol requirements. In informal discussions at the IETF 
meeting, some folks suggested that the scope of issues associated 
with supporting non-ASN.1-capable clients (in the DPV context) is 
potentially very broad and that we should defer such support for now. 
But, the WG needs to weigh in on this question.

Finally, this analysis suggests that there are relatively few 
differences between a DPD and a DPV server. Both must be capable of 
constructing and returning certification paths and supporting 
revocation data, under the control of parameters that are either 
explicitly specified by a client or referenced via a 
server-configured policy. Both accept a range of inputs in the form 
of certificates or certificate chains, and revocation data "hints." 
Thus, the WG must decide if two distinct protocol formats, with 
different syntax are warranted, of if a single (slightly more 
complex) format for requests and responses is appropriate.

Based on the preceding analysis, I propose the following requirements 
for DPD and DVP protocols, based on the assumption of ASN.1 aware 
clients.  Remember that the protocol specs will encompass not only 
the syntax of the bits on the wire, but also the processing that will 
be performed by clients and servers.

Unless otherwise qualified, he following requirements are proposed 
for both DPD and DPV protocols:

Client requirements:

1.1	A client request can contain a single certificate or a 
certificate chain terminating in the "target" certificate, to assist 
the server in path construction.

1.2	A client request can contain one or more revocation data 
items, to assist the server in path validation.

1.3	A client request to a DPV server can specify the time 
relative to which the validation is to be performed. If omitted, the 
current time is assumed.

1.4	A DPD client request must be able to specify whether only 
CRLs, only OCSP responses, or either, are acceptable forms of 
revocation status data to be returned. (We could apply this 
requirement to DPV requests as well, if the content of returned, 
substantiating evidence for non-repudiation needs to be similarly 
constrained.) [Shall we also allow the request to also impose 
constraints on the forms of OCSP responses that are acceptable, by 
type, and if the basic type is specified shall we require an ability 
to specify a time before which a pre-produced OCSP response is 
considered too old?]

1.5	A DPV client request must be able to specify whether a 
certification path and revocation status data, plus a TSP response 
(for each returned certification path and revocation data set) should 
be returned by a server, in support of non-repudiation.

1.6	A DPD client request must be able to specify whether a TSP 
response should be returned by a server (for each returned 
certification path and revocation data set), in support of 
non-repudiation.

1.7	A client request must be able to specify validation 
processing parameter values both via reference to policies configured 
at a server and via specification of values for individual 
parameters. If no policy is specified and no parameters are 
specified, a default parameter value set, configured at the server, 
will be employed. If a policy is specified but no parameter values 
are specified by the client, then the parameter values associated 
with that policy are employed. If only client-supplied parameter 
values are present in the request, then they are employed. Any 
parameters not specified by the client will be supplied by the 
default set configured in the server. Also, if any of these default 
parameters are marked as not capable of being overridden by 
user-specified parameter values, then the default parameter values 
shall be employed. If a policy is specified and there are 
client-supplied parameter values, the policy is employed to select 
parameter values, and then the user-supplied parameter values are 
applied, overriding the policy-specified parameter values, except for 
any policy-specified parameters that are marked as not subject to 
user override. [whew!]

1.8	Either the request/response protocol itself, or a specified 
lower layer protocol to be employed for requests and responses, there 
must be a provision for data origin authentication and connectionless 
integrity for requests and responses, and responses must be matched 
to requests. Request authentication & integrity is needed to support 
access control to the server, a requirement for public servers. 
Responses must be authenticated and integrity-protected to ensure 
that they are from the indicated server, and matched to the request 
in question. Additional security services may be offered optionally.

1.9	The client must be able to query a server and request path 
validation policy parameter values for any policy configured on the 
server. The client must be able to specify policies by an ID (e.g., 
an OID) or to refer to the default policy. [A standard will have to 
specify the policy ID format.]

Server Requirements:

2.1	A server must be able to process client requests invoking any 
of the features defined above for clients. Thus it must implement RFC 
2459-compliant certificate validation procedures in support of both 
DPD and DPV. The path discovery process implemented by a DPD server 
operates under the same set of controls as path validation, and thus 
a DPD server returns paths only if they are valid with respect to the 
specified path validation parameter values.

2.2	A server must be able to return one or more sets of 
certification paths and associated revocation data as a result of 
path discovery/validation.  Each set shall consist of an ordered list 
of certificates and associated CRLs and/or OCSP responses.

2.3	A server must be capable of returning a time stamp response 
(consistent with the TSP RFC that will soon be issued) covering each 
returned certification path and revocation data set. (See 1.4 & 1.5 
above)

2.4	A server must be configurable to support multiple sets of 
path validation parameters, each identified by a policy identifier. 
One such set, which must include values for all validation 
parameters, must be designated as the default policy. Each parameter 
in any policy must be capable of being marked as not subject to 
override by corresponding, client-specified parameters. (It is TBD 
whether the default policy supercedes other configured policies if 
there are conflicts in parameters that are marked as not being 
subject to override.)

2.5	The means by which validation policy parameter values are 
configured will not be part of the standard.

2.6	A server must be able to access both LDAP servers and OCSP 
servers in support of path discovery and revocation data acquisition.

2.7	A server must be able to respond to a request from a client 
for the path validation policy parameters for the default policy, or 
for any identified policy. However, a server may impose access 
controls with regard to such requests so that it may reject a query 
if the client is not authorized to invoke the path validation policy 
in question.
---------------------------------------------------------------------- 
--------------------------------------------

My examination of both SCVP and the proposed OCSPv2 extensions 
suggests that neither meet the strawman requirements I set forth 
above. Of course, the WG also has to review these requirements and 
determine if there is consensus on them, or if they need to be 
modified (pruned or extended). The time table in my pre-Christmas 
message says that we have the next moth to reach closure on this.

Finally, one criteria for selecting a standard which seems important 
to many WG participants is the complexity of the client and server 
implementations. Arguments about simplicity based on extending an 
existing protocol are not objective in the absence of substantiating 
data. Thus, to create a level playing field, all proposed protocols 
must be accompanied by algorithmic descriptions of the processing by 
both client and server. Remember that a protocol is not just the 
syntax of the bits on the wire, but also encompasses the processing 
and semantics associated with the protocol. I have tried to allude to 
aspects of such processing in  the requirements above, but more work 
remains. IETF standards have often failed to do a good job in this 
regard. Our recent experience with varying interpretations of OCSP 
(v1) responses demonstrate the importance of such specification. The 
level of detail required here is open for discussion, but it must be 
sufficient to allow WG members to create independent, interoperable 
implementations, and to allow prospective evaluation of the relative 
complexity of each candidate.