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

From: Denis Pinkas <[email-masked]>
Date: Mon, 01 Sep 2003 09:29:51 +0200

Trevor,

> Denis,
> The question of what is or is not useful information is down to your
> point of view. Just because you don't value it, does not mean others
> will view it likewise.

This is not an argumentation. Please, do not use terms like "your point of 
view" or "other may view it otherwise", but concentrate on the arguments 
raised in the response to Faisal, and attempt to reply to the issue that was 
raised there. That e-mail stated:

"Using an extension to indicate the location of a SCVP service would be a 
pointer to a "useful" service in the same way like a CA could indicate the 
location of useful Time-Stamping Units (TSUs). So, if we accept this 
extension, we will have to accept pointers to TSUs and in the future 
pointers to some other "useful" services like an *electronic* signature 
validation service, and maybe more.

Either we open the door to "useful" services like SCVP, or we don't."

Denis

> Trevor
>  
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Friday, August 29, 2003 10:05 AM
> To: Trevor Freeman
> Cc: Stephen Kent; Faisal; [email-masked]
> Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> Trevor,
> 
> In my reply to Faisal, there are other arguments which basically support
> 
> Steve's position. We should refrain to include "a lot of other things"
> in 
> public key certificates, otherwise we would open the door to a lot of 
> extensions which are not directly related to CAs, like CA best partners,
> low 
> rates for insurances if you have a certificate from that CA, best
> refinance 
> conditions if you have a certificate from that CA, ...
> 
> This would look like spam.
> 
> Denis
> 
> 
> BTW, we are awaiting your explanations (and possibly new text) about the
> 
> differences between the concept of validation policy, as included in RFC
> 
> 3379, and the same wording as used in the SCVP draft.
> 
> 
> 
>>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
>>
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Stephen Kent
>>Sent: Thursday, August 28, 2003 6:08 PM
>>To: Faisal
>>Cc: Denis Pinkas; [email-masked]
>>Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
>>
>>
>>At 10:24 +0500 8/28/03, Faisal wrote:
>>
>>
>>>Denis,
>>>
>>>- Why is SCVP considered not part of a CA service and
>>>OCSP is?
>>>- Where is this defined?
>>>- Also whether the SCVP service is provided by a CA or provided by
>>
> some
> 
>>>other trusted third party, would it still not be a good idea for the
>>
> CA
> 
>>>to identify how to locate the responsible SCVP service for its
>>>certificates (assuming there is one)?
>>>- Why does it matter who is providing the service?
>>>
>>>I don't understand
>>>
>>>Regards,
>>>F a i s a l
>>
>>
>>OCSP is explicitly an alternative to CRLs, and CRLs are managed by 
>>CAs. Thus a CA issuing a cert can reasonably choose to insert a 
>>pointer in AIA to an OCSP server that the CA (or its designee) 
>>operates, just as it would have inserted a pointer to a repository 
>>for retrieving CRLs signed by that CA.  In contrast, the choice of an 
>>SCVP server is a local matter, relative to an RP, and thus it would 
>>generally be inappropriate for a CA to direct an RP to an SCVP server.
>>
>>Steve
>>
> 
> 
> 
>

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 1 Sep 2003 11:11:31 +0200 (MEST)

> 
> The original request was for XKMS, then moved to SCVP.
> Is it now moving to DVP ?

I respond to faisal's question regarding SCVP which is 
an attempt to respond to the DPV requirements.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 01 Sep 2003 11:10:43 +0200

Peter,

> you are mentioning only one of the possible usages of OCSP. In the
> third trust model you have an OCSP server trusted via local procedures.
> 
> On the other hand, you seem to restrict DVP to just just that model.

DVP is not SCVP and is not XKMS either.

Is there a request for one extension or for three extensions ?

Denis

> I think it has been mentioned several times that a DPV service
> can be operated in exactly the same trust models as OCSP, i.e.,
> as a CA provided service. 
> 
> As M.M. says, I'd vote for if there would be a straw poll.
> 
>

---

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

At 10:04 +0100 8/30/03, Liaquat Khan wrote:
>Steve,
>
>I appreciate the difference you point out.  Although it's not a major
>issue for me, I still feel that the CA may want to direct RPs to the
>SCVP service it thinks is best for its certificates (whether or not the
>CA operates this SCVP service).

If one examines the various motivations given for creating a DPD/DPV 
standard, as documented in RFC 3379, many of them clearly do not 
align with this notion. OCSP is qualitatively different; the CA that 
issues a cert is authoritative for the revocation status of the cert. 
But DPV is about whether a cert is valid relative to a policy 
context, and the policy context is generally a function of the 
client's environment, and thus not generally known to the Issuer of 
the cert. That's why, in general, it would be inappropriate to put 
this info into an AIA extension.

>  Furthermore, whether RPs make use of this AIA extension or not is up to
>them.  This is the reality today with the use of AIA for OCSP.  Many
>PKIs require their RPs to ignore this field and go to a locally
>configured OCSP responder (4-corner model).

Again, OCSP is different, because the Issuer IS authoritative for the 
revocation status and that status is not affected by who asks the 
question.

>Also even if RPs choose their own SCVP service, their may be a need to
>relay the SCVP request on.  The current SCVP draft mentions server
>relaying as a possibility.  The information from AIA extension could in
>this instance be used to aid SCVP server relaying.

That's a fair point; not one I had considered. But it does not negate 
the objections noted above.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Sep 2003 14:11:26 -0400

At 19:40 +0200 9/2/03, Peter Sylvester wrote:
>  > True, and in that case it would not make sense to put a pointer to
>>  that server in the AIA extension.
>
>Maybe not into the cert in question, but into the cert that
>may be used to authenticate a connection of a client to
>such a server in order to have a simple place for
>configuration.

I'm afraid this seems like too trivial a configuration issue to 
warrant a place in our standards.

>
>Alternatively, it could be in a SIA of a service cert.

see my comments to Trevor re 3379 assumptions about clients, in general.

>>  Is there a part of the DVP/DVD requirements RFC that suggests this
>>  model?  I don't recall.
>
>Wasn't one of the initial motiviations of the activity the
>problem that OCSP only creates 'negative' responses?

I don't see that cited in RFC 3379 as a motivation.

>
>Well, of course, there is a simple fix for OCSP.

you omitted the emoticon at the end of the sentence, e.g., :-) or ;-)

Steve

---

From: "Terwilliger, Ann" <[email-masked]>
Date: Thu, 4 Sep 2003 16:57:56 -0700

Actually, there is a good description of the four corner model in the Certification Authority Rating and Assessment Task Force (CARAT) Guidlines published by the NACHA Internet Council (final version published in 2000).  It's now an old document but still worthwhile reading.  

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

> 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: "Trevor Freeman" <[email-masked]>
Date: Fri, 5 Sep 2003 06:21:10 -0700

Using another extesnion is a poitles distinction. The extension already
qualifies each data item conveyed by an OID.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Friday, September 05, 2003 5:09 AM
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

> 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
> 
> 
> ----- Original Message ----- 
> From: "Ambarish Malpani"
> To: "'Denis Pinkas'"; "'Michael Myers'"
> Cc: "'Stephen Kent'"; <[email-masked]>
> Sent: Friday, September 05, 2003 4:50 AM
>>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
>>>Sent: Thursday, September 04, 2003 11:04 AM
>>>To: Michael Myers
>>>Cc: Stephen Kent; [email-masked]
>>>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
>>>
>>>
>>>>>>Steve,
>>>>>>
>>>>>>Static config is easier to attack than dynamic config.
>>>>>>
>>>>>>Mike
>>>>>
>>>>>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,
>>>>
>>>>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: Wen-Cheng Wang <[email-masked]>
Date: Sat, 6 Sep 2003 02:14:19 +0800 (CST)

> qualifies each data item conveyed by an OID.

I believe that the section 4.2.2.1 of RFC 3280 says that the
purpose of the AIA extension is to indicate how to access
CA information or services provided by the CA (i.e., the issuer of
the certificate. If the SCVP service is not provided by the CA
itself, do you think it is appropriate to convey the SCVP URI
via the AIA extension?

Best Regards,
Wen-Cheng Wang

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 9 Sep 2003 12:15:53 +0200 (MEST)

> 
> If a client is configured with per-CA info about acceptable SCVP 
> servers, why not configure both the public key info and the name 
> info, vs. putting this info into the certs?

In my experience, each time you can avoid another parameter,
configuration entry etc, you reduce the error potential
by a factor significantly greater than 1. 

You can also simply have the subject alternate name of
a cert.
 
A "cryptic" answer is also in the last paragraph of my previous mail.
A cert is a simple configuration file concerning all what you
need to know about your local scvp server (case 1 see below).

> 
> The latest spec also says that every response must be signed. maybe 
> we need to reconcile these statements in the spec.

MAYBE? In the last spec AuthenticatedData were added as another 
authentication means without consolidation of the rest of the text.
 
> >
> >Where do I talk about a choice? I am rather thinking that
> >both the definitions on TSP and OCSP may make sense.
> 
> sorry if I was unclear. until we figure out whether it makes sense to 
> put a pointer and/or a public key into a target cert, indicating how 
> to find/authenticate a corresponding SCVP server, we need not debate 
> what extension ought to be used.

It would be helpful if you could start distinguishing between the
two cases where 

1 - a pointer is in a server cert. 
2 - a pointer is in a target cert to validated

> 
> >
> >- The AIA in OCSP defines something usable to be put into
> >   certs to be validated;
> >
> >- The SIA in TSP defines a way to configure a server.
> 
> The appendix in 3161 defines is how to use SIA to mark an EE cert for 
> a TSA with info on how to contact the server. That is appropriate, 
> because the cert is an EE cert for the TSA. I would have no objection 
> to putting a similar marker into a cert issued to an SCVP server.
 
Good. This is case 1 above. 

> But, that is not at all the same as putting a pointer to an SCVP 
> server in a cert issued to another entity.  Is the former what you 
> intend, or the latter?

Yes, this is not the same, and that has already been said before.
We do already case 2 for OCSP or for CRLs. Both cases seem useful. 

> >>  >
> >>  >Scenario 2:
> >>  >
> >>  >- The same client wants a pointer to his local server;
> >>  >   this can be done in different ways; the client would
> >>  >   never use an IA in any of the certificate in the
> >>  >   chain to be validated. but would use an extension
> >>  >   in one certificate of a chain usable to authenticate
> >>  >   its local server.
> >>
> >>  I don't understand this example. are you saying that use of an
> >>  extension to identify an SCVP server is a good means of configuring
> >>  this info for a client? you mention a cert chain for the client
> >>  containing this info, but the presumption for DPV is that the client
> >>  may not be able to verify cert chains, and even for DPD that the
> >>  client may not be prepared to fetch and revocation info for chains.
> >>  thus any reference to a cert chain used by a client to verify the
> >>  public key and determine the name for an SCVP server seems
> >>  problematic, in that many of the contexts for which we cretaed SCVP
> >>  would not be able to make use of such a chain.
> >
> >This scenaroi would use an extension like an SIA in RFC 3161. A
> >client has a certificate for its local server, and can use it to
> >authenticate the connection or the response.
> 
> if the client has a cert for its local server, then why does the 
> client need a pointer to a remote server?

I think you are lost (what remote server?)
This case is case 1 above which you treat as appropriate.

> 
> >A client may not be able to verify all kinds of chains concerning
> >the certificates to be validated, but this is not the situation
> >for ONE server. on can argue, that the only thing needed
> >is a key and an address, even in this case a certificate
> >is a convenient place. As soon as one has SignedData as a
> >security mechanism, a certificate to valdidate a response
> >doesn't sound to me to be the most inconvenient way.
> 
> sorry, the typos and language make it too hard for me to figure out 
> what this paragraph is saying. can you rephrase?

This is simple case 1 and an indication a simple configuration 
mechanism using a cert. Since the current text of SCVP makes 
SignedData optional, I cannot say: A response is always signed. 
But, if SignedData are used, or if there are other techniques 
used like TLS, IPSEC that also used public keys, it seems 
reasonable to use a certificate and not just a public key as a 
validation mechanism. 

Regards
Peter

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 9 Sep 2003 12:54:33 +0200 (MEST)

> 
> The use of SIA in TSP makes sense because the extension is used in 
> the cert for the TSA, not for other entities.  At least that's how I 
> read the appendix in 3161.

Indeed. That's one of the cases that I'd like to see. 

> 
> Sorry, but I don't understand the nature of the overkill or what is 
> hard to maintain. AIA and SIA have different semantics; they should 
> be used in different contexts. I don't know yet whether we would need 
> another extension for use with SCVP, or can use one of these, because 
> I still do not have a clear picture of what folks plan to do with the 
> extension.
> 

What I am saying is that one could have used one single extension
saying 'IA' information access, and then put the semantics of being
either something like a SIA or AIA into the OID instead of folding it
out. For comparison see the extensionproposed by David Chadwick where
both SIA and AIA are considered as inappropriate. 

> >
> ></paranthese>
> >
> >>
> >>  >This does seem an afterthought to me but rather a well accepted feature
> >>  >since years which doesn't seem to need a particular requirement.
> >>
> >>  Well, we agree on the afterthought part :-), but probably not the
> >>  "well accepted feature" part. Before the WG says that putting a
> >>  pointer in AIA or SIA makes sense for SCVP, we need to agree on the
> >>  requirements.
> >
> >here are some.
> >
> >- One is in a ee entity whose status is to be queried a location
> >   where to ask for the service. The result of the service need
> >   to be authenticated in whatever is appropriate for the client;
> >   The two CA models of OCSP are examples.
> >   A possible implementation is to put an AIA into an end cert.
> 
> I do not understand this example, please rephrase.

This is like the AIA extension in OCSP for a CA provided service. 

> 
> >- It seems useful to have such a pointer in a CA cert indicating
> >   a service concerning all certificates issued by that CA (vs
> >   the previous IA would indicate where to obtain information
> >   about the CA certificate.)
> 
> If the service is DPD, I think this may make sense. if it is DPV, 
> then what info about the CA cert is to be supplied and how is it to 
> be used? we already have a way to convey CRL and OCSP info relative 
> to a CA, and because the CA is authoritative for revocation info, 
> this is fine. but DPV is very different and so a different argument 
> needs to be made about why one would go to an SCVP server of the 
> Issuer's choosing when trying to verify a cert issued by that CA.

Because the CA's server will return a valid(ated) path. There may
be intermediate CAs, and the CA will check for revocation etc.

> 
> >- A third requirement is to have a simple configuration of
> >   a local SCVP service, which needs to be authenticated either
> >   by some IPSEC, TLS or SMIME signature through a certificate.
> >   This can be done for example by an extension inside the
> >   server cert or any cert in the trustpath of the server's cert.
> 
> You describe here and example where you want to mark an EE cert as 
> being an SCVP server cert and to indicate where the server is. That's 
> very different from the examples above and deserves to be evaluated 
> independently, and might be a different extension. But, when you say 
> that the extension might appear anywhere in the path, I think this is 
> a very different situation, for which I have not seen any indication 
> of the intended processing model.

Yes, this is the case as with the SIA in TSP etc.

By saying that the pointer could be anywhere in a trustpath I
see the following example:

A client is configured with a CA cert of rather long validity.
The actual connection is authenticated with a server cert that
has a rather short validity without the need of frequent 
configuration change.

> 
> >- It is necssary to distinguish SCVP servers, in particular if
> >   end-entity belong to the same CA. A special key-purpose seems
> >   a sufficient way to do this.
> 
> Sorry, but this sentence makes no sense to me, and since you seem to 
> suggest that an extended key usage OID might suffice, maybe we need 
> not pursue it further.

Cf. the second model in OCSP. If a CA signs norma ee certs and also
a SCVP server cert, you want to say: I trust a 'scvp response 
giveing either by a CA or by a designated reponder.' it is
indeed the same requierment for an extended keyusage OID. 

> 
> >  > >A simple way to configure a public key is a certificate. You can have
> >  > >like in TSP a SIA with your local server, and your local server acting
> >>  >as a proxy can contact a CA's server using an AIA in the cert to be
> >>  >validated.
> >>
> >>  Sorry, but you lost me here, i.e., not enough context near your
> >>  answer for me to remember what the question was. But, I'll take a
> >>  stab anyway.
> >>
> >>  We need to distinguish between what a client would do with a pointer
> >>  in an extension vs. what an SCVP server might do, re relay. The
> >>  answers may be different, e.g., one might make sense but the other
> >>  may not. If so, then  we might decide to allow an SCVP reference in
> >>  one of these extensions, BUT also make it clear under which of the
> >>  two cases it is to be used.
> >
> >Not really, since the extensions are not in the same certificate.
> >in one case it is the server's trust chain, the other are the certs
> >to be validated. But, it is probably necessary to distinguish the different
> >usages (at least two).
> 
> all I can get out of this comment is that we may agree on the need to 
> have two different classes of extensions for different semantics.

Yes. There are at least two classes.

> Peter, what I would like to see is a clearer articulation of what 
> problems are being solved by the suggestion extension(s), and how the 
> use of an extension solves the problem, i.e., some discussion of the 
> processing that takes place. The descriptions should say whether we 
> are helping a client find and authenticate an appropriate SCVP 
> server, or whether we are helping an SCVP server in its job. The 
> descriptions should say whether we are using SCVP for DPD or DPV. 
> They should indicate whether the problem is assumed to arise in an 
> enterprise context, or in some other context that is described. The 
> processing description should indicate where the required info comes 
> from, and how the consumer of that info (client or SCVP server) can 
> use that info safely.

I'd like that you make a little bit more effort to understand
a non native english speaker, otherwise I think I can make
a better articulation in German or French, and then the IETF hires a 
professional translator. :-)

Hm, it seems to me that the remaining problem that we seem to see both is
whether a pointer in a 'cert to be validated' indicates a DPV or DPD, 
and whether a client could distingusih this. 
> 
> I think we need this kind of text to clarify the discussion that is 
> taking place. It seems that there are a variety of ways one might use 
> an extension to help with various problems, but we don't have a 
> coherent description of the problems and why the use of one or more 
> types of extensions is an appropriate solution technique. We ought 
> not provide a syntax for including SCVP info in certs generically, 
> without a clear indication of how it is to be used, and by whom.

In another mail you seem to agree that a pointer in a 'cert to be
validated' is not a problem for DPD. Well, indeed, if you compare
this with the similar situation in OCSP, it is the same IMO. Having
an OCSP response from a CA or a delegated OCSP provider does not
mean that a client trusts in that CA. Still, an SCVP client could 
ask such a CA: "Assumed that I trust your CA root, or any of the 
following, please provide me a validated path to any of them.".

A CA needs to publish such a server address in some way. Again,
as for OCSP, the ee cert is one possibility. 

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 11 Sep 2003 13:50:44 +0200 (MEST)

> Peter,
> 
> I think that the SubjectKeyIdentifier field might be the choice.

I think my question was either stupid or may be considered as a trap. 
If whatever client is implemented in a way that it just validates 
a signature it can just do this as an optimisation.

A server can still do what it wants to create a SignerInfo
structure which may or not help some other relying party. 

In any case, this part of the discussion is not related
to the problem whether we want or not and what in a cert
acting as a pointer to a service. 

I am sure whether some of the argumentation is still in
along: Since we have no certs in some simpler
model, we don't provide for anything concerning them. 

Peter