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

From: Peter Sylvester <[email-masked]>
Date: Mon, 8 Sep 2003 12:14:51 +0200 (MEST)

> >
> >- A client asks his local server to validate a cert.
> >
> >- The local server has a policy/configuration indicating that
> >   for the cert in question the AIA of an CA operated DPV
> >   service is populated and should be contacted.
> 
> How might this be specified? certainly it would be impractical to 
> specify this on a per cert basis.  do you envision specifying this on 
> a per CA basis?

For example. 

> 
> >- The local server does so and authenticates the response
> >   in whatever way is indicated in the policy.
> 
> SCVP requires a signature on every server response, other than an 
> error response. if we don't use the signature for validation, I have 
> no idea what it might take to trick the server. it also was not clear 
> to me that there was a policy configuration item for this, i.e., that 
> one could specify non-signature means of verifying server responses 
> on a per server basis. can you point me to the part of SCVP that 
> indicates this?

In the latest draft of SCVP there has been added the usage of
Authenticated data. I had already made a comment concerning
this. By saying "in whatever way is indicated in the policy"
I tried to avoid any further discussion. 

> 
> >Now, one can ask whether the ee-cert needs an AIA. Indeed,
> >it may be better to have an SIA extension in a CA cert
> >saying that in order to obtain a paricular information
> >containing certificates issued by this authority.
> >
> >A SIA in a CA cert for OCSP also makes sense to me BTW.
> 
> we should defer arguing about the choice of extension until we 
> understand how the extension is used and what the the benefits and 
> pitfalls.

Where do I talk about a choice? I am rather thinking that
both the definitions on TSP and OCSP may make sense.

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

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

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. 

Peter

---

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

>>  specify this on a per cert basis.  do you envision specifying this on

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?

>I tried to avoid any further discussion.

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

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

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

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

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

Steve