Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Sep 2003 13:50:09 -0400

At 9:53 -0700 8/29/03, Trevor Freeman wrote:
>Steve,
>I don't see why the use of AIA is inappropriate for SCVP. It's just a
>hint like a lot of other things in certificates such as SKID. If the
>client has configured SCVP server it uses, it is free to ignore the
>information provided by the AIA, just as client with a locally
>configured OCSP server can ignore the OSCP pointer in the AIA extension
>today.
>Trevor
>
Trevor,

In part the question is what one views as the primary model for use 
of SCVP, and whether putting an SCBP pointer into a cert represents a 
significant opportunity for a new configuration management 
vulnerability, i.e., failure to populate a local SCVP pointer would 
allow the AIA value to be used instead.

Another matter is that SCVP (in its DPV role) is also designed for 
environments where the client is not presumed to be capable of 
processing certs. In that context, it does not seem to be useful to 
put in a pointer to a server, since the client would not be likely to 
be able to extract and make use of the pointer.

I have reread RFC 3379, the DPD/DPV requirements doc, and I see no 
references that would lead me to believe that a CA would be 
appropriate as a server for all RPs that might deal with certs issued 
by the CA.

What if several certs in a path each contained an SCVP server pointer 
in an AIA extension? While this would make sense for OCSP, it is not 
appropriate for SCVP.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 2 Sep 2003 12:33:46 -0700

Steve,

The notion that "CAs do OCSP" while "somebody else does SCVP" is
being overly polarized.  We should bear in mind the
enterprise-level case where trusted certificate production is
only one aspect of an overall information security management
policy.  A standardized means of including an SCVP pointer in
the certificates issued by such environments would benefit
uniform and automated enforcement of this aspect of enterprise
security policies.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stephen Kent
> Sent: Tuesday, September 02, 2003 10:50 AM
> To: Trevor Freeman
> Cc: Faisal; Denis Pinkas; [email-masked]
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
> [SCVP-AIA]
>
>
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Sep 2003 16:00:15 -0400

>uniform and automated enforcement of this aspect of enterprise

I agree that there will be contexts in which the CA and the SCVP 
server operator are the same, for some set of clients. Your 
enterprise example is a valid one.

But, if an enterprise CA relied on an AIA pointer to direct the local 
clients to its SCVP server for its certs, does that mean the local CA 
would want to have its clients directed to other servers based on 
pointers in certs from other CAs? In general, this would be a bad 
security idea.  Thus it would seem that the local CA needs to be able 
to configure its clients with a pointer to the local SCVP server, in 
a fashion independent of the AIA extension, to prevent clients from 
being vectored to other SCVP servers. In that case, a pointer in the 
AIA extension would not seem to offer the benefit you cite.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 2 Sep 2003 18:32:50 -0400

Steve:

The extension could work like OCSP extension in that the local settings can
always override what is in the certificate.

Also, when you say "bad security idea", I assume you mean from availability
and performance viewpoints since a name asserted in the AIA extension is not
going to form the basis of trust.  The RP will use a public key trusted in
some other fashion to trust an SCVP server.

Now, here is a possible scenario of some utility.  Suppose you are using the
untrusted SCVP servers for path development only.  Suppose that these
servers tend to provide paths to some known trust anchors, including their
Enterprise roots.

Now, in cross certified environments and in Bridge environment, this partial
path may be of some help.

I agree that for certification path validation (trusted SCVP server), at a
first glance, the extension does not seem to be of much use since the RP
clients must be configured with trusted public keys for the SCVP servers
anyway.  It might as well be configured with SCVP names also.  But, wait,
here also, if there is more than 1 SCVP server in the RP configuration, then
if a name matches that in a certificate, that name breaks the tie.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, September 02, 2003 4:00 PM
To: Michael Myers
Cc: Trevor Freeman; Faisal; Denis Pinkas; [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

At 12:33 -0700 9/2/03, Michael Myers wrote:
>Steve,
>
>The notion that "CAs do OCSP" while "somebody else does SCVP" is being 
>overly polarized.  We should bear in mind the enterprise-level case 
>where trusted certificate production is only one aspect of an overall 
>information security management policy.  A standardized means of 
>including an SCVP pointer in the certificates issued by such 
>environments would benefit uniform and automated enforcement of this 
>aspect of enterprise security policies.
>
>Mike
>

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 3 Sep 2003 07:37:38 -0700

> Sent: Tuesday, September 02, 2003 1:00 PM
> . . .
> But, if an enterprise CA relied on an AIA pointer to
> direct the local clients to its SCVP server for its
> certs, does that mean the local CA would want to
> have its clients directed to other servers based on
> pointers in certs from other CAs? In general, this
> would be a bad security idea.
> . . .
>
> Steve

Steve,

One architectural deployment scenario would be to have a
community's members indeed vectored to that community's trusted
server independant of the AIA for reasons of uniform policy
enforcement.  However, that server could then use the AIA in
some back office fashion.  This in essence is the four corner
model.

Mike

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Sep 2003 09:33:05 -0400

>always override what is in the certificate.

What I noted, was that IF there is no locally configured SCVP server 
info, THEN the presence of such info in an AIA extension would 
presumably be used, and that would create a configuration  management 
vulnerability.

>some other fashion to trust an SCVP server.

Good point, but this raises the question of where the client will get 
a public key for a server whose name appears in an extension. If the 
public key for an SCVP server must be configured specially, i.e., not 
just be verifiable as any EE, then why is it any harder to configure 
the name/URI for the server at the same time? What benefit accrues 
from carrying the name in the extension, since by itself the name is 
not sufficient to enable sue of the server.

>path may be of some help.

This scenario is not clear to me.  Please elaborate.

>if a name matches that in a certificate, that name breaks the tie.

This strikes me as a new twist on the processing model, and one that 
needs to be examined carefully before we decide it's a good idea.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 3 Sep 2003 08:15:23 -0700

> BTW, what is the origin of the phrase "four corner
> model" that has cropped up here?
>
> Steve

Steve,

The "four-corner model" derives from the picture that Mack Hicks
and others always drew to explain how Identrus would work
vis-a-vis trust and especially how OCSP relay fit into their
bank-to-bank risk management scheme.

Mike

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Sep 2003 10:55:43 -0400

>some back office fashion.  This in essence is the four corner

OK, at least that convention would avoid the concern I raised.  If we 
were to extend the AIA extension to include such a pointer, then we 
would have to ensure that this is how clients did operate, to avoid 
the concern I cited.

But, I'd like to know what use the local server would make of the 
pointers in one or more AIA extensions.  I've seen too many examples 
of "let's allow X to be put here because maybe there will be some 
good use for it that we will figure out later" to be comfortable 
going down this path without a better understanding of what purpose 
is served.

BTW, what is the origin of the phrase "four corner model" that has 
cropped up here?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Sep 2003 12:06:03 -0400

>bank-to-bank risk management scheme.

OK, now I know why I was unfamiliar with the reference.

Thanks,

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 3 Sep 2003 13:16:31 -0400

Steve:

Please see responses in-line in []

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2003 9:33 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

At 18:32 -0400 9/2/03, Santosh Chokhani wrote:
>Steve:
>
>The extension could work like OCSP extension in that the local settings 
>can always override what is in the certificate.

[If there is no locally configured SCVP server, would the client invoke SCVP
services?  If so, what else does it have to rely on but the information in
the certificate.  Seems that in that scenario you use something from the
certificate or do something other than SCVP] 

>Also, when you say "bad security idea", I assume you mean from 
>availability and performance viewpoints since a name asserted in the 
>AIA extension is not going to form the basis of trust.  The RP will use 
>a public key trusted in some other fashion to trust an SCVP server.

[Agreed.  I made the same point in the next para]

>Now, here is a possible scenario of some utility.  Suppose you are 
>using the untrusted SCVP servers for path development only.  Suppose 
>that these servers tend to provide paths to some known trust anchors, 
>including their Enterprise roots.
>
>Now, in cross certified environments and in Bridge environment, this 
>partial path may be of some help.

[In complex trust graph, the certificate discovery problem can be broken
down into three chunks: 1.  Finding a trust point in the subscriber domain
-- this piece is provided by path discovery capability of a trusted or
untrusted SCVP Server.  2.  Finding a trust point in RP domain -- this is
straightforward most of the times (a trust list).  3.  Find how the path
between the two trust points -- hopefully that is a direct cross
certification, a path through a common bridge or through a series of
bridges.  If the RP is able to find a path to a trust point in subscriber
domain through the SCVP server, the path discovery problem is reduced:
divide and conquer principle]

>I agree that for certification path validation (trusted SCVP server), 
>at a first glance, the extension does not seem to be of much use since 
>the RP clients must be configured with trusted public keys for the SCVP 
>servers anyway.  It might as well be configured with SCVP names also.  
>But, wait, here also, if there is more than 1 SCVP server in the RP 
>configuration, then if a name matches that in a certificate, that name 
>breaks the tie.
>

[I am all for a careful examination.  Do you see any pitfalls in it?]

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 3 Sep 2003 11:39:10 -0700

> Sent: Wednesday, September 03, 2003 7:56 AM
>
> . . .
>
> But, I'd like to know what use the local server would
> make of the pointers in one or more AIA extensions.
> I've seen too many examples of "let's allow X to be
> put here because maybe there will be some good use for
> it that we will figure out later" to be comfortable
> going down this path without a better understanding
> of what purpose is served.
>
> . . .
>
> Steve

Steve,

Static config is easier to attack than dynamic config.

Mike

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Sep 2003 15:37:25 -0400

>Static config is easier to attack than dynamic config.

Mike,

I'm not sure I believe that's uniformly true, but it is an 
interesting perspective.

Moreover, an AIA extension is pretty static, in that certs typically 
have moderately long life spans, e.g., a year is pretty common for an 
EE cert, several years for a CA cert. So, can we really say whether a 
locally configured value for an SCVP server name is more or less 
static than a value extracted from a cert extension?

Steve

Steve

---

From: "Liaquat Khan" <[email-masked]>
Date: Wed, 3 Sep 2003 21:12:36 +0100

So I assume from the below that we are we ruling out an equivalent of
the "delegated" mode for SCVP? I.e. the ability for the CA to certify
the SCVP server's public key and thereby extend trust from the CA to the
SCVP service?  

If this model was allowed then the use of the AIA extension to identify
the SCVP service would have been even more obvious... 

Regards,
LK

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 3 Sep 2003 16:41:45 -0400

I am not ruling it out.  If the AIA extension had the public key of the
server, the question may remain as to how the RP will be notified of the
break in that binding if the CA needs to break that binding.

All I am trying to do is learn and help figure out if the inclusion of AIA
in a certificate has some value.

I think there may be some value to the pointer regardless of how the SCVP
server public key (for trusted SCVP services) is provided to the RP.

-----Original Message-----
From: Liaquat Khan [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2003 4:13 PM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

So I assume from the below that we are we ruling out an equivalent of the
"delegated" mode for SCVP? I.e. the ability for the CA to certify the SCVP
server's public key and thereby extend trust from the CA to the SCVP
service?  

If this model was allowed then the use of the AIA extension to identify the
SCVP service would have been even more obvious... 

Regards,
LK

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 4 Sep 2003 09:57:14 -0700

> Moreover, an AIA extension is pretty static, in that
> certs typically have moderately long life spans,
> e.g., a year is pretty common for an EE cert,
> several years for a CA cert. So, can we really say
> whether a locally configured value for an SCVP server
> name is more or less static than a value extracted
> from a cert extension?
>
> Steve

Steve,

In using static vs. dynamic I meant the context to be "in
storage on the RP device".  A configuration file on a router or
an end-user workstation would exemplify static storage.  My
reference then to dynamic meant "in memory only", a situation
that could reliably be assumed to exist since: 1) the SCVP
process is inherently dynamic and online; and 2) given an AIA,
the certificate itself bears the necessary addressing
information.

The last point is modulo of course that pesky notion you brought
up about having to configure the trusted public key anyway. But
then, that's just one key while the AIA values may vary against
a locally configured SCVP server that, as we previously
discussed, could make better and more secure use of those varied
AIA values via relay.

A standardized OID and syntax for SCVP AIA would I believe
contribute useful architectural options towards the "why is PKI
hard?" question.  It would not totally eliminate the need for
local config, but rather complement the practice in a way that
allows the design and evolution of a more adapative
infrastructure.

Thus, in some future timeline where PKI is indeed ubiquitous, if
my response to all these email-based viruses is to accept only
signed attachments, my ISP's SCVP server need not have any
pre-configured knowledge of the SCVP server operated by my
correspondent's ISP.  My ISP simple needs a server, a key and a
pointer, the latter two elements being locally configured on my
client platform.  That server, via AIA, dynamically relays the
request, receives the response, resigns it and there you go.  No
messiness of local config on my ISP's part, or any ISP for that
matter.  The infrastructure is data-driven via the cert.

In summary I believe there's sufficient value to go forward with
an AIA for SCVP.  It's not a perfect solution, but neither is
total reliance on local config.  Together, possibly so.

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 04 Sep 2003 20:04:21 +0200

Mike and all,

I have followed that thread.

"The authority information access extension indicates how to access CA
information and services for the issuer of the certificate in which
the extension appears."

I wonder if the SCVP extension really belongs to the class of "CA services 
for the issuer of the certificate in which the extension appears".

I would consider it as an *SCVP* extension, rather than an *AIA-SCVP* 
extension, since the service is not about the certificate in which the 
extension appears, but is for other certificates.

I am aware of the Identrus model. If we want to support this model, an 
extension might be useful to indicate the certificate validation server the 
owner of the certificate should use to validate certificates received from 
elsewhere.

Is it what everybody has in mind ? Is it something different ? If different, 
please just provide one sentence to explain what it is.

Thanks,

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 4 Sep 2003 12:38:48 -0700

Denis,

Following Steve's guidance on the purpose(s) served by an SCVP
AIA, I described a scenario based on relay.  Your response
appears to be in that context, but it is difficult to determine
if you agree with that analysis.  Please clarify your position.

Mike

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, September 04, 2003 11:04 AM
> To: Michael Myers
> Cc: Stephen Kent; [email-masked]
> Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt
> [SCVP-AIA]
>
>
> Mike and all,
>
> "The authority information access extension indicates
> how to access CA information and services for the
> issuer of the certificate in which the extension appears."
>
> I wonder if the SCVP extension really belongs to the
> class of "CA services for the issuer of the certificate
> in which the extension appears".
>
> I would consider it as an *SCVP* extension, rather
> than an *AIA-SCVP* extension, since the service is
> not about the certificate in which the extension
> appears, but is for other certificates.
>
> I am aware of the Identrus model. If we want to
> support this model, an extension might be useful
> to indicate the certificate validation server the
> owner of the certificate should use to validate
> certificates received from elsewhere.
>
> Is it what everybody has in mind ? Is it something
> different ? If different, please just provide one
> sentence to explain what it is.
>
> Thanks,
>
> Denis

---

From: "Ambarish Malpani" <[email-masked]>
Date: Thu, 4 Sep 2003 13:50:36 -0700

Hi Guys,
    It isn't clear to me that the AIA extension makes any sense for
SCVP. SCVP is a service to allow you to validate a certificate path.
It basically allows a client to ask somebody else whether a certificate
is good for a particular use (in a large number of cases, the client
doesn't know the certification path for the certificate before making
the SCVP query, or even the public key of the CA who issued the cert).

The AIA is a way for a CA to tell the world where it can get more
information for a particular cert - e.g. its status, etc.

When a SCVP client gets a certificate issued by a particular CA, it
is trying to figure out whether it should trust the CA at all. Why
would the client want to ask a location specified in the certificate
when it doesn't even know if the signature on the certificate is
any good?

Ambarish

> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> 
> Mike and all,
> 
> "The authority information access extension indicates how to 
> access CA information and services for the issuer of the 
> certificate in which the extension appears."
> 
> interesting 
> >>perspective.
> storage on 
> > the RP device".  A configuration file on a router or an end-user 
> > workstation would exemplify static storage.  My reference then to 
> > dynamic meant "in memory only", a situation that could reliably be 
> > assumed to exist since: 1) the SCVP process is inherently 
> dynamic and 
> > online; and 2) given an AIA, the certificate itself bears the 
> > necessary addressing information.
> > 
> > The last point is modulo of course that pesky notion you brought up 
> > about having to configure the trusted public key anyway. But then, 
> > that's just one key while the AIA values may vary against a locally 
> > configured SCVP server that, as we previously discussed, could make 
> > better and more secure use of those varied AIA values via relay.
> > 
> contribute 
> > useful architectural options towards the "why is PKI hard?" 
> question.  
> > It would not totally eliminate the need for local config, 
> but rather 
> > complement the practice in a way that allows the design and 
> evolution 
> > of a more adapative infrastructure.
> > 
> > Thus, in some future timeline where PKI is indeed ubiquitous, if my 
> > response to all these email-based viruses is to accept only signed 
> > attachments, my ISP's SCVP server need not have any pre-configured 
> > knowledge of the SCVP server operated by my correspondent's 
> ISP.  My 
> > ISP simple needs a server, a key and a pointer, the latter two 
> > elements being locally configured on my client platform.  
> That server, 
> > via AIA, dynamically relays the request, receives the response, 
> > resigns it and there you go.  No messiness of local config 
> on my ISP's 
> > part, or any ISP for that matter.  The infrastructure is 
> data-driven 
> > via the cert.
> > 
> > In summary I believe there's sufficient value to go forward with an 
> > AIA for SCVP.  It's not a perfect solution, but neither is total 
> > reliance on local config.  Together, possibly so.
> > 
> > Mike
> > 
> > 
> > 
> 
>

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 5 Sep 2003 14:27:17 +0800

Folks,

I suggest let's take our step back and take a look at the nature of
public-key certificates. The main purpose of a public-key certificate is to
express the 'identity' of its subject. In addition to the identity of the subject,
it is acceptable for a CA to include some access locations for 'essential
(or intrinsic) services' such CRL publication or certificate status query
service in the certificate it issued to guide or facilitate the relyping-parties
to determine the status of the certificate. I know that some of you believe
that it is good to allow a CA to advertise 'value-added services' (meybe
provided by the CA itself or some TTP, such as a TSA) that it think will
be useful to relyping-parties (certificate-using applications). However, 
that is not a part of the nature of public-key certificates. I believe
the size of the certificate should be keep as small as possible since a
certificate is not a 'database' or a 'advertising web page' to deliver so
much information unrelated to the identity of the subject. Therefore, I do not
think it is a good idea to encourage the using of public-key certificates
as media for advertising those value-added services.

To those people who believe that it is good to allow a CA to advertise 'value-added services',

Well, although I am not a fan of advertising 'value-added services' in certificates, I
respect your standpoint. However, I do not think the AIA/SIA extension is right place to
deliver the access locations of  'value-added services' such as SCVP. And I believe
many people have the same feeling as mine. If you guys still insist that it is good to
advertise 'value-added services' in certificates, I suggest that you should invent another
exetnsion named Useful-Services Information Access (USIA) extension or something.
Then you are free to add into certificates any access location of 'value-added services'
which maybe provided by the CA itself or some TTP. For example, SCVP, DVCS,
TSA, XKMS, Key Recovery Service, Notary Service, ... You name it.

Finally, when you guys design such kind of access location to be advertised in
certificates, please go deep into the security consideration. For example, what
if a malicious entity (a fake CA) created a fake certificate with a malicious SCVP
(a fake SCVP Server) access location URI in that certificate and let the fake SCVP
Server always tell the relyping-parties that the fake certificate is valid and trustworthy?
Isn't it dangerous to let the relyping-parties blindly trust the service provider specified
by the CA (which might be a malicious hacker) as its default service provider?

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Sep 2003 11:09:10 +0200

Wen-Cheng,

I basically concur.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Sep 2003 11:11:42 +0200

Mike,

> if you agree with that analysis.  Please clarify your position.

Please, provide one sentence to explain what would be the meaning of this 
extension.

"This extension indicates ... "

Denis

---

From: "Liaquat Khan" <[email-masked]>
Date: Fri, 5 Sep 2003 10:36:28 +0100

Hi,

Just on your last point...would the RP really trust the SCVP server
blindly as you state??  

I mean the RP would validate the signature on the SCVP response, would
it not?  So it must have the SCVP self-signed certificate in its trust
anchor list or be able to build a path from the SCVP certificate to a
trusted certificate.  

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: 05 September 2003 10:09
To: Wen-Cheng Wang
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

Wen-Cheng,

I basically concur.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Fri, 5 Sep 2003 11:49:04 -0400

Wen-Cheng Wang,

Well said.  I am still working thorough messages from the last few 
days, but I agree with the overall theme of your message, especially 
the security issues that need to be explored in more detail,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 5 Sep 2003 11:54:54 -0400

>anchor list or be able to build a path from the SCVP certificate to a

Note the possibility for bad things happening based on the informal 
description above. I would like the WG to agree on how the client 
validates an SCVP response signature, in terms of where the names for 
SCVP servers and corresponding public keys come from. The suggestion 
above might be interpreted to allow any trust anchor to act as an 
SCVP server, which I think would be very dangerous, i.e., it is about 
as bad as the current browser "trust model" where any configured CA 
can vouch for anything! Until we have agreement on what the procedure 
is for identifying and verifying SCVP servers, this is a very 
dangerous, underspecified model.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 5 Sep 2003 13:25:30 -0400

>certificate or do something other than SCVP]

I was not as clear as I should have been. I assume that SCVP info, 
e.g., a public key and a name for an SCVP server, would be configured 
into a client that use SCVP. If the client has no public key to use 
to verify a response from an SCVP server, then how can the client use 
the service? if the intent is to provide central management for cert 
path validation, one would not want the clien to accept a name for a 
server from a random cert that happened to be presented to the 
client. Since I think the AIA extension was proposed as a means of 
conveying only the server name, I did not see that as useful. If the 
client has the server name, it didn't need to get it from a cert. If 
the cert extension overrides the configured name in the client, it 
would allow anyone to cause the client to go to the wrong server, not 
a good start, and certainly a DoS concern at a minimum.

>	<SNIP>

I'm puzzled by the description above. It seems to assume one model 
for path building, and that may not be the only choice. For example, 
the RP can start with its list of TAs and try to find a path to the 
target cert, period. (I don't think the term "subscriber" has been 
used here, perhaps because it's not clear to what the subscriber is 
subscribed in this case.)  if the target cert is accompanied by some 
CA certs one might choose to use them in the path building process, 
but if there is a complex graph involved, there is no reason to 
believe that the sender of these CA certs really knows what TAs the 
RP has locally configured.

Anyway, I assume that our intent with SCVP, is for the RP to ask his 
configured SCVP server to do whatever is needed to verify the cert, 
starting with path construction, constrained by the explicit or 
implicit policy parameters associated with the request. So, the 
question is whether an SCVP server pointed to by the issuer of the 
target cert, or by some CA cert in the path provided along woth the 
target cert, represents a good way to assist the SCVP server 
operating on behalf of the RP.

To me this could make sense if the server identified in the extension 
provides a DPD service, but not if it provided a DPV service. I say 
that because in the former case the server named in the cert need not 
be trusted by the server acting on behalf of the RP, whereas in the 
latter case it looks like the RP's server is abrogating its 
responsibility.

>[I am all for a careful examination.  Do you see any pitfalls in it?]

See my comments above about the roles being fulfilled by the various 
servers and the corresponding concerns.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 5 Sep 2003 11:37:29 -0700

> If the cert extension overrides the configured name
> in the client, it would allow anyone to cause the
> client to go to the wrong server, not a good start,
> and certainly a DoS concern at a minimum.
> . . .
>
> Steve

It has been my assumption that local config, if present, SHALL
override AIA.

Mike

---

From: Stephen Kent <[email-masked]>
Date: Fri, 5 Sep 2003 14:42:14 -0400

>the certificate itself bears the necessary addressing

OK, I see your definition, but I don't think the difference is that 
significant.
Let's look at the possible combinations:

	1. local name, locally-configured public key
	2. extension-derived name, locally-configured public key
	3. extension-derived name, public key acquired from the same cert?

In 1, I would expect it to be just as easy to change the name and the 
key as to change just the name, based on your concerns cited above. 
In 2, is the name more secure because it arrives in an extension for 
a cert that has not been validated by the client? Anyway, if I change 
the public key in the client because you think it is easier to do 
that to static data, then I would claim that an attacker can 
construct a cert with the name of his choice in the extension and 
have the client send it to the attacker to validate, which will work, 
because the attacker has also changed the static, public key.  Case 3 
would be an attacker's dream, i.e., send any cert with an extension 
that gives both the name and public key to use when contacting the 
server ...

>discussed, could make better and more secure use of those varied

This paragraph seems to be changing the context, i.e., from client 
use of the extension to local server use of the extension, passed on 
by the client. Either that or I do not understand what you are saying 
here.

>allows the design and evolution of a more adapative

I do not see how this helps at all, given my analysis above. If we 
don't configure the public key for the SCVP server that the client 
will use, I do not see how the client can have any confidence in the 
response, at least not in the DPV case. if we do configure that key, 
I don't see why we can't configure the name at the same time, nor do 
I see why delivering the name in an extension helps, really.

>matter.  The infrastructure is data-driven via the cert.

In your example, your ISP wants to verify external signatures on 
e-mail. So the SMTP sever is configured with the public key and name 
for your ISP's SCVP server. That server, it seems from your text, is 
not performing validation of the certs from the other ISP. Rather it 
is asking an SCVP server operated by that ISP to tell it that the 
cert associated with that ISP is good. That seems awfully circular 
and insecure to me, so I am sure that I am missing something in your 
example. What I would have expected is that your ISP's SCVP server 
would look at the AIA extension to fetch the cert for the CA that 
issued an EE cert to the SMTP server for the other ISP, and maybe the 
CRL for that CA, and that your ISP's SCVP server would then really do 
some work to try to construct a cert path, validate CRLs, etc.  I 
don't see any magic here that makes PKI easy for the servers.  The 
idea of SCVP was to make life easy for the clients.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 5 Sep 2003 14:06:42 -0400

>the SCVP service would have been even more obvious...

I have to admit that a big part of my problem with your example is 
that I hate to use the word trust when talking about CAs. So, I 
cannot personally relate to the example above. But, if I suppress my 
prejudice in this regard, I'd say the right answer is that an SCVP 
server is an entity that must be trusted by its clients, but that 
trust need not be inferred by a relationship to any CA. After all, a 
dumb client using SCVP for DPV might be configured with a name and a 
public key for a server, and thus the server need to even hold a cert 
issued by any CA.

In general I would like to see separation between the CA that issues 
a cert and the SCVP server that verifies the cert for an RP. If the 
RP happens to be a client of the CA, in an enterprise context, then 
the two probably are managed by the same folks and that fine. But in 
general a client will need to validate certs issued by a wide range 
of CAs, and one ought not think that ecah of the purported issuers of 
certs would be an acceptable DPV server.  Again, note the terrible 
security problems for the current web browser PKI model, which has a 
similar flavor.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 6 Sep 2003 12:21:42 -0400

Steve:

I agree that for DPD services an extension (AIA or some new extension) can
be useful in path discovery.

For path validation, the client must always be pre-configured and the most
an extension can do is to help select from the ones the client configured
with.

I also think from semantics and software complexity viewpoints, it is better
have a separate extension rather than overload AIA.

I never felt there was a reason to put the CA cert and OCSP responder in the
same extension (namely AIA).

Similarly, if I were to do it again, I would have separate extensions for
inhibit policy mapping and require explicit policy.  In general, unless the
fields are related, I would define separate extension.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, September 05, 2003 1:26 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

At 13:16 -0400 9/3/03, Santosh Chokhani wrote:
>>The extension could work like OCSP extension in that the local 
>>settings can always override what is in the certificate.
>
>[If there is no locally configured SCVP server, would the client invoke 
>SCVP services?  If so, what else does it have to rely on but the 
>information in the certificate.  Seems that in that scenario you use 
>something from the certificate or do something other than SCVP]

>[In complex trust graph, the certificate discovery problem can be 
>broken down into three chunks: 1.  Finding a trust point in the 
>subscriber domain

>>the RP clients must be configured with trusted public keys for the 
>>SCVP servers anyway.  It might as well be configured with SCVP names 
>>also.

Steve

---

From: "Ambarish Malpani" <[email-masked]>
Date: Sun, 7 Sep 2003 14:21:55 -0700

Hi Steve,
    I agree with what you say. However, that doesn't respond to the
question of whether the "delegated mode" makes sense for SCVP.

With regards to that question, I believe that delegation of SCVP
authority makes perfect sense. Most people like to protect their
"trusted key" very, very carefully and would like to use a 
different key for online operations than the one that is trusted
by the clients.

So, I fully expect SCVP service providers to delegate the trust
that clients have in them to online responders that actually
sign the responses.

Regards,
Ambarish

> Sent: Friday, September 05, 2003 11:07 AM
> To: Liaquat Khan
> Cc: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Sun, 7 Sep 2003 14:25:28 -0400

>an extension can do is to help select from the ones the client configured

In an enterprise context, why would one want to have a CA, in general 
a "foreign" CA, make this selection?

>have a separate extension rather than overload AIA.

I am more concerned with the semantics at this point, than the choice 
of extension.  Also, since there seems to be less to worry about re 
DPD vs. DPV, maybe that distinction needs to be part of any 
extension-based reference.

>same extension (namely AIA).

OK with me.

>fields are related, I would define separate extension.

Well, X.509 gave us this combination, and I'm not trying to open up 
that can of worms.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Sun, 7 Sep 2003 14:25:28 -0400

OK with me.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Sep 2003 08:50:34 -0400

Steve:

The selection is not security critical.  The SCVP Server represented in the
certificate is simply known to the CA to have all the relevant certificates
and revocation information.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Sunday, September 07, 2003 2:25 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

At 12:21 -0400 9/6/03, Santosh Chokhani wrote:
>Steve:
>
>I agree that for DPD services an extension (AIA or some new extension) 
>can be useful in path discovery.
>
>For path validation, the client must always be pre-configured and the 
>most an extension can do is to help select from the ones the client 
>configured with.

>I also think from semantics and software complexity viewpoints, it is 
>better have a separate extension rather than overload AIA.

>I never felt there was a reason to put the CA cert and OCSP responder 
>in the same extension (namely AIA).

OK with me.

>Similarly, if I were to do it again, I would have separate extensions 
>for inhibit policy mapping and require explicit policy.  In general, 
>unless the fields are related, I would define separate extension.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 08 Sep 2003 15:15:54 +0200

Santosh,

> and revocation information.

  ... "simply known to have all the relevant certificates and revocation 
information" in order to verify the certificate along *any* validation
policy ? If not "any", which one ? or which ones ?

Maybe, it is not that simple. :-)

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Sep 2003 09:25:05 -0400

Denis:

In all cases, SCVP client will be configured with the SCVP Servers and their
public keys and any constraints in terms of limiting the Server for
policies, name spaces etc.

All this will do is select a proper server so that computational complexity
is reduced.

I see situations where a person has credentials and hence trust anchors
(these could be SCVP servers some day) from their employer, from one or more
public sector customers, and one or more private sector customers.  In this
cases, none of these are "foreign" CAs.  A pointer will select the correct
SCVP server.  Security and trust will still be a function of client
configuration and under client control.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Monday, September 08, 2003 9:16 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

Santosh,

> Steve:
> 
> The selection is not security critical.  The SCVP Server represented 
> in the certificate is simply known to the CA to have all the relevant 
> certificates and revocation information.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Sep 2003 14:59:54 -0400

>policies, name spaces etc.

I think this would be reasonable, but where do we say this?

>All this will do is select a proper server so that computational complexity

what complexity? the selection of the right server based on the cert presented?

>configuration and under client control.

What is a "public sector customer" relative to the person above. How 
are these folks "customers" of that person? Same question for the 
private sector analogs.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Sep 2003 14:16:49 -0400

>that clients have in them to online responders that actually

I am puzzled by some of the details of your comment.  Each client 
must have access to a public key that will be used by it to validate 
responses from an SCVP server. So, is the thrust of your comment that 
an SCVP server operator would have one private key that it used to 
issue certs that serve to identify SCVP servers, to support the 
indirection and mostly offline operation model you suggest? That way 
clients would be configured with the corresponding public key, but 
would use it only to validate the certs for an SCVP server. I just 
want to clarify what you comments above mean in terms of the 
mechanisms we are discussing. if this is what you were referring to, 
then it does not strike me as an example of delegation, but rather an 
example of indirection.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Sep 2003 14:55:02 -0400

>and revocation information.
I'm sorry, but I can't understand what you are saying.

If a CA puts a pointer to an SCVP server into a cert it issues, then 
that CA is asserting what server should be contacted for DPV or DPD. 
For DPD that does not seem to be security critical,. but for DPV it 
is, and I question whether the Issuer of the cert is the right entity 
to make such a determination. Looking at the intro text for SCVP, it 
emphasizes the enterprise context and in that context, what you said 
does not seem appropriate. But, maybe we're missing too much context, 
again. Can you elaborate on your comment?

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Sep 2003 15:35:06 -0400

Steve:

The client is configured with SCVP Servers it trusts.  The client has these
servers public keys (in trusted manner, e.g., manual means).

If a certificate in question has an SCVP Server pointer that also happens to
be in the client's list of SCVP Servers whom it trusts, the client uses that
SCVP Server for DPD and for DPV.

If the SCVP Server pointed to by the certificate is not in the client's
trust list, the Server can be only used for DPD and you know most likely
client will have some work remaining to do to find cross certification from
RP domain to subscriber domain. 

It may be helpful to include hash of the SCVP Server public key in the
extension to avoid name collisions.  But, that is not security critical
since if two SCVP Servers shared the same name, the worst you can do is get
the service from the wrong one and not verify the signature.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, September 08, 2003 2:55 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

At 8:50 -0400 9/8/03, Santosh Chokhani wrote:
>Steve:
>
>The selection is not security critical.  The SCVP Server represented in 
>the certificate is simply known to the CA to have all the relevant 

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Sep 2003 15:43:31 -0400

Steve:

See responses in-line in [].

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, September 08, 2003 3:00 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

At 9:25 -0400 9/8/03, Santosh Chokhani wrote:
>Denis:
>
>In all cases, SCVP client will be configured with the SCVP Servers and 
>their public keys and any constraints in terms of limiting the Server 
>for policies, name spaces etc.

[This is appropriate for DPV or trusted SCVP Service.  It should be implicit
from SCVP Specification that the clients need the SCVP Server public keys in
trusted manner.  Now, in terms of constraints, it should be up to the client
whether it trusts an SCVP Server for all names and policies or only some.
As to where we say these things, security considerations section of SCVP
Server may be one place.  I am sure there are better places.]

>All this will do is select a proper server so that computational 
>complexity is reduced.

what complexity? the selection of the right server based on the cert
presented?

[If you do not have any algorithm to try, you will try all of them and on
the average n/2 servers, f the client is configured with n servers.  This
will result in communication delays and needless signature verifications on
SCVP Server responses.  Also, whatever work the SCVP server does to
determine, it is clueless about the certificate you just asked.]

>(these could be SCVP servers some day) from their employer, from one or 
>more public sector customers, and one or more private sector customers.  
>In this cases, none of these are "foreign" CAs.  A pointer will select 
>the correct SCVP server.  Security and trust will still be a function 
>of client configuration and under client control.
>

[For example, I am a security consultant.  My customers like US Government
and Banks want me to use certificates minted by them for me using their PKI]

Steve

---

From: "Ambarish Malpani" <[email-masked]>
Date: Mon, 8 Sep 2003 13:45:40 -0700

Hi Steve,
    You describe what I meant correctly.

I think you are distinguishing between delegation and indirection by
whether the two entities (delegator/delegatee) are controlled by the
same entity or not - where you are calling it delegation if they are
controlled by different entities, but indirection if they are
controlled by the same entity. Is that correct?

From the SCVP client's point of view, I am not sure I see the difference
between delegation and indirection.

Regards,
Ambarish

> Sent: Monday, September 08, 2003 11:17 AM
> To: Ambarish Malpani
> Cc: [email-masked]
> Subject: Re: SCVP delegation (was SCVP-AIA)
> 
> 
> >"trusted key" very, very carefully and would like to use a different 
> >key for online operations than the one that is trusted by 
> the clients.
> >
> >So, I fully expect SCVP service providers to delegate the trust that 
> >clients have in them to online responders that actually sign the 
> >responses.
> >
> >Regards,
> >Ambarish
> >
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Sep 2003 17:36:34 -0400

Steve:

In Enterprise context, pointers may be less useful.

But, if an RP is dealing with multiple enterprises, the pointer does help.

The reason the pointer in the certificate is not critical for DPV also is
that the RP client will require some out of band trusted means to obtain the
Trusted SCVP Server public key.  For the public key, RP will not rely on the
information in the certificate.  All the certificate tells RP is which of
the RP client pre-configured servers to try first.

-----Original Message-----

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Sep 2003 18:41:17 -0400

>servers public keys (in trusted manner, e.g., manual means).

OK, good start.

>SCVP Server for DPD and for DPV.

This description lacks the scope controls you seem to have suggested 
earlier, i.e., what servers are trusted for what sets of certs?

>RP domain to subscriber domain.

So, if the client needs the DPV service, because it is dumb, it's up 
the creek here? that may be an odd response to finding this SCVP 
extension in an EE cert. I can see instances where this might be OK, 
but in other cases why doesn't the client just contact its "home" 
SCVP server and ask it to perform the DPV service?

>the service from the wrong one and not verify the signature.

agreed.

Overall, what I see here is a start at how a client might make use of 
an extension, but with a number of holes to be addressed.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Sep 2003 18:52:47 -0400

>Server may be one place.  I am sure there are better places.]

Implicit is dangerous! we need more precise discussions of how a 
client that uses SCVP is supposed to work, e.g., in terms of 
configuration data, etc. see my comments to Peter on this topic.

>determine, it is clueless about the certificate you just asked.]

some strings of words above are not a sentence. so, if we assume N >> 
1, this might be a problem, but in the enterprise case, I would 
generally expect N = 1, right? So, we need to discuss what other 
cases give rise to bigger values for N, and we need to include a 
discussion of why we could not use the scope data for an SCVP server, 
as configured in a client, to determine which server to contact re 
the EE cert in question. I thought we already discussed the dangers 
of having a list of SCVP servers (for DPV) where we would "trust" all 
of them for any cert  we wanted to verify.

>and Banks want me to use certificates minted by them for me using their PKI]

These are examples of you selecting the right cert to use when you 
sign something for one of your customers, but you are not the RP in 
that case and SCVP is a service to an RP. are you trying to say that 
when you receive a cert from one of these customers, that you want 
the customer to tell you which SCVP server to invoke for them? 
first, if that;s the intent, the whole discussion above is backwards! 
second, how do you address the issue of limiting the scope for each 
if these servers? I'm not saying that you cannot address the problem, 
but it seems to come and go as a part of the processing you have 
described.

Steve
Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Sep 2003 18:56:36 -0400

>controlled by the same entity. Is that correct?

yes.

>between delegation and indirection.

The client can't tell, but I want us to understand the difference as 
we decide what we are trying to achieve.

We ought not confuse a syntactic ambiguity with a semantic one.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Sep 2003 18:56:36 -0400

yes.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Sep 2003 19:02:10 -0400

>In Enterprise context, pointers may be less useful.

glad to see that we agree, although "less useful" is a more generous 
characterization than I would make :-)

>But, if an RP is dealing with multiple enterprises, the pointer does help.

so, we have an RP who has no "local" SCVP server; all the servers are 
"foreign" to him, and he has to choose the right one.

>the RP client pre-configured servers to try first.

I'm confused again. You say that the client needs to get the public 
key for each server via some other means, not from the cert being 
validated. but then you say that the cert will be used to decide 
which server to "try first."  That seems to suggest that the client 
is willing to let any of these servers verify any cert for him, and 
it's just a matter of which server the cert points to. as I said 
before, this seems to have all the advantages of the browser PKI 
model :-)

Steve

---

From: "Ambarish Malpani" <[email-masked]>
Date: Mon, 8 Sep 2003 20:07:48 -0700

In that case, we are in vehement agreement.

What is important IMHO is SCVP indirection.

Regards,
Ambarish

> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Monday, September 08, 2003 3:57 PM
> To: Ambarish Malpani
> Cc: [email-masked]
> Subject: RE: SCVP delegation (was SCVP-AIA)
> 
> 
> 
> >  >From the SCVP client's point of view, I am not sure I see the 
> >difference between delegation and indirection.
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Sep 2003 08:41:02 -0400

Steve:

See responses in [] with text redacted.

>If a certificate in question has an SCVP Server pointer that also
>happens to be in the client's list of SCVP Servers whom it trusts, the 
>client uses that SCVP Server for DPD and for DPV.

[The scope control could be used in conjunction or in spite of what is in
the Server.  The way I look at it is a client could select an SCVP Server
purely based on its configuration, based on some combination of its
configuration and what is on the certificate, and purely from the
certificate.  For the DPV services, the selected SCVP Server must be in the
trust list of the client.  For DPD, this is not needed]

>trust list, the Server can be only used for DPD and you know most 
>likely client will have some work remaining to do to find cross 
>certification from RP domain to subscriber domain.

[If the client needs a trusted service (e.g., DPV), it needs the SCVP Server
information such as name and public key pre-configured.  It is unlikely to
be much help having an SCVP Server pointer whose public key the client does
not already trust.  In cases where the SCVP Server pointer in the
certificate is not in the client trust list, the client must use its own
trust list and any deterministic or heuristic algorithm to go through the
trust list of SCVP Servers it has]

[We can discuss this next time we talk.  While I have tended to be brief, I
do not see any holes in the approach.  Your points have made the debate more
clear and my thoughts more sharp, but they have not shown any holes in it.
My assumption all along has been that if the client does not already trust
an SCVP Server, a pointer in the certificate is not the right thing since
then the client will have to do the very path development and validation it
intended to avoid.]

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Sep 2003 13:03:48 -0400

Steve:

The idea proposed is very simply.  Let me summarize it.  The pointer in the
certificate is used in prioritization/weighing from zero or more choices of
SCVP Servers.

The prioritization scheme is upto the client and does not impact security or
interoperability.  That is why it need not be defined.  It can be left up to
the client.  Of course, regardless of the pointer in the certificate, if the
client is configured with constraints on an SCVP Server (e.g., in terms of
policies, name spaces, etc.) the client must enforce those constraints for
DPV.

While the SCVP pointer in the certificate can be used for DPD, it may be
used for DPV only if the client is configured with the corresponding SCVP
Server and the server's public key.  Thus, for DPV, the certificate pointer
can be used (at most) to prioritize or weigh the multiple SCVP Servers the
client has.

A compliant client may choose to ignore the SCVP pointer in the certificate
if it chooses to.

See responses in {} with information redacted.

>[This is appropriate for DPV or trusted SCVP Service.  It should be
>implicit from SCVP Specification that the clients need the SCVP Server 
>public keys in trusted manner.  Now, in terms of constraints, it should 
>be up to the client whether it trusts an SCVP Server for all names and 
>policies or only some. As to where we say these things, security 
>considerations section of SCVP Server may be one place.  I am sure 
>there are better places.]

{I do not see any danger in clients using their own algorithms and
approaches to selecting the order in which SCVP Servers are queried.  We
need not define the priority or actual algorithm a client uses to define the
order in which it will query SCVP Servers.  We can write an informational
RFC on how to configure the client, how to use the SCVP Server pointer.
But, this is neither a security issue nor an interoperability issue.  If a
client is configured to trust an SCVP Server for certain name spaces,
policies, etc., those must be honored}

>[If you do not have any algorithm to try, you will try all of them and
>on the average n/2 servers, f the client is configured with n servers.
>This will result in communication delays and needless signature 
>verifications on SCVP Server responses.  Also, whatever work the SCVP 
>server does to determine, it is clueless about the certificate you just 
>asked.]

{I gave an example of when n>1.  I am not sure if n>>1 to improve
performance.  We could use the client configuration.  The SCVP pointer is
another alternative.  A client could use SCVP server based priority only,
ignore the SCVP Server based priority and use client configuration only, or
use the combination of the two.} 

>>(these could be SCVP servers some day) from their employer, from one
>>or more public sector customers, and one or more private sector 
>>customers. In this cases, none of these are "foreign" CAs.  A pointer 
>>will select the correct SCVP server.  Security and trust will still be 
>>a function of client configuration and under client control.
>>
>
>[For example, I am a security consultant.  My customers like US
>Government and Banks want me to use certificates minted by them for me 
>using their PKI]

{When I have a certificate of the client for encryption r for digital
signature verification, I need to verify that the certificate is good.
Thus, my thin client would like to go to an SCVP Server.  As it so happens,
my client has a few and I would like to select the correct one}

Steve
Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Sep 2003 15:01:50 -0400

Steve:

The SCVP Server is like AKID and SKID.  They are not needed for security.
They can aid in path development.

Please see responses in-line in <> with redaction.

<I do not think "local", "foreign" etc. are meaningful or should be used.  A
client has a set of SCVP Servers that it trusts.  It does not matter where
these servers are physically or organizationally located.  The set could be
empty and DPD will still work> 

>The reason the pointer in the certificate is not critical for DPV also 
>is that the RP client will require some out of band trusted means to 
>obtain the Trusted SCVP Server public key.  For the public key, RP will 
>not rely on the information in the certificate.  All the certificate 
>tells RP is which of the RP client pre-configured servers to try first.

<Ha, ha.  If the client has constraints on the SCVP Server, it can impose
them.  Assuming more than one SCVP Servers can be used to verify a
certificate in question, then the SCVP Server pointer information can be
used in prioritization, if the client chooses to.>

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Sep 2003 11:50:42 -0400

>trust list of the client.  For DPD, this is not needed]

scope control has to be in the client, not a server, since the client 
needs to know what server is appropriate for a given class of query. 
the list of "it could be A or it could be B or it could be C" does 
not given me a warm fuzzy feeling. we know that, without suitable 
scope constraints, basing the selection purely form what is in a cert 
is dangerous for DPV.  That suggests that we need standards, or at a 
minimum, a significant security consideration discussion, or the 
implications for each option. and, if we fail to mandate support for 
any of these options in a standard, users are left wondering what the 
client software will do, and whether what it does is secure.

>trust list of SCVP Servers it has]

your starting point above is just what I have been saying, but I 
would like to see agreement on this from all the contributors to this 
discussion. the phrase "client trust list" is a bit too vague for me. 
we need to be more precise. the last sentence above suggests a 
particular behavior that may be appropriate, but what I would like to 
see is concrete text for the SCVP ID, to make clear what we really 
expect a client to do.  Currently we seem to lack the equivalent of a 
state machine for client behavior re SCVP (at least in the case where 
we create an extension of the sort being debated here) and that's not 
OK.

>then the client will have to do the very path development and validation it

The "holes" are the unspecified parts (gaps) in the processing 
description, several of which are still part of the discussion above.

steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Sep 2003 11:56:33 -0400

>empty and DPD will still work>

you are right that the terms "local" and "foreign" are not precise. 
they are intended to convey the notion of an authority that is 
responsible for an enterprise environment. vs. another authority.

>used in prioritization, if the client chooses to.>

yes, if the constraints indicate that multiple servers are equally 
acceptable, then an extension could be used for prioritization. but I 
note that you comment speaks in terms of "If the client has 
constraints on the SCVP Server" and that does, in fact, remind me of 
the browser PKI model.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Sep 2003 17:56:12 -0400

At 13:03 -0400 9/9/03, Santosh Chokhani wrote:
>interoperability.  That is why it need not be defined.

It does affect security for the client, and as a user I want to know 
how the client will behave. An attractive way for me to know that is 
if we have a standard and the vendor assures me that the client 
software complies with the standard.

>  It can be left up to

is this choice left to the implementer, or does an administrator have 
control over this?

>policies, etc., those must be honored}

What I would want to know, as a user, is what algorithm the client 
software uses and how I can control it. if we don't mandate some type 
of admin controls here,  we cannot specify client processing of an 
SCVP response, and we have an incomplete spec. the trick is agreeing 
upon a set of generally useful controls that we want clients to have, 
while not imposing undue complexity on the clients (which we are 
trying to keep simple) and while still ensuring a base level of 
functionality for clients.

>>server does to determine, it is clueless about the certificate you just

a simple answer to my question would be "yes."  BTW, the last string 
of words above is also not a sentence :-)

>use the combination of the two.}

what you say here is a list of "could's." we need a state machine for 
a client specification, and these could's can become part of that, if 
they are carefully articulated, but not putting them down in a spec 
leaves things very uncertain.

>my client has a few and I would like to select the correct one}

I am still confused by your text. You indicated, initially, that you 
had several certs issued to you by different CAs, corresponding to 
different clients. That's fine, but you are not an RP when you select 
the right cert to use when signing some data directed to a specific 
client. I think your most recent comment, above, refers to selecting 
the right SCVP server for a cert associated with a client, when 
encrypting some data for that client. Yes, here you are an RP, but 
this is not consistent with the words you used in your example, i.e., 
" My customers like US Government and Banks want me to use 
certificates minted by them for me using their PKI." This text refers 
to your cert, not their cert, hence the confusion.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 14 Sep 2003 09:36:08 -0400

Steve Kent:

To summarize the debate we are having, my position is as follows:

1.  A pointer to an SCVP Server in a target certificate can help a RP obtain
DPD services from the SCVP Server.

2.  A pointer to an SCVP Server in a target certificate can be used by a RP
(who is not another SCVP Server) to prioritize among its SCVP Servers for
DPV services.

3.  A pointer to an SCVP Server in a target certificate can be used by a RP
(who is  another SCVP Server) to obtain DPV services.

My interpretation of your e-mails to date is that you are ok with 1, but
with 2 you have concerns about security and you want to define the client
behavior.  (We have not had any discussion yet that distinguishes 2 and 3).

I do not think doing 2 and 3 impacts security and I do not think exactly how
an RP uses the pointer to prioritize should be subject of the standard.
Here are my reasons:

Absent the pointer, there is no standard that dictates in what order the
multiple SCVP Servers should be invoked.  Also, this situation is akin to a
RP which performs  certification path development and validation locally,
itself.  There is no standard as to in which order the various paths should
be developed and verified.  Thus, it is entirely possible (through accident
or design) that an RP would try the paths in the same order with or without
considering the pointer.  Since that ordering is not mandated by the
standard, it should not and will not impact security or interoperability.

In the interest of brevity, I have consolidated and redacted our multiple
e-mail threads and provided responses to your remaining concerns.  My
responses are in [].

We can discuss this on Wednesday, if you like.

Steve Kent wrote:

[Scope of control is always with the client.  I do not think the order in
which the client queries is security relevant or impacts interoperability.
Thus, I do not favor standardization in this area]

[I do not think the order in which the client queries is security relevant
or impacts interoperability.  Thus, I do not favor standardization in this
area]

[I do not think specification of order in which client does things is
required.  The clients should arrive at the same result regardless of the
ordering]

[The order in which the client invokes SCVP Servers the client trusts for a
given scope should not impact security unless the SCVP Servers are doing
something wrong]

[The client configuration should be matter of client configuration, be it
the administrator or the end user]

[There is no need to specify the order in which paths or SCVP Servers are
navigated by the client.  It should not impact security or
interoperability.] what you say here is a list of "could's." we need a state
machine for 
a client specification, and these could's can become part of that, if 
they are carefully articulated, but not putting them down in a spec 
leaves things very uncertain.

[We do not have a state machine for the order in which path development and
validation processes cooperate for a client.  This situation is akin to
that.  Think of SCVP Servers the client trusts as the extension of the
client software, trust store, and certificate and CRL store.  We do not have
and do not need standards in the areas of how the client builds paths and
how the path building works in conjunction with path validation.]

[The way these PKIs work is that I am both the subscriber and RP.  When I
register for a certificate, they provide me with a trust anchor to be used
as an RP.  This TA will be replaced with the SCVP Server public key so that
I can validate certificates issued to other subscribers in these domains.]

Steve