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

From: Peter Sylvester <[email-masked]>
Date: Mon, 8 Sep 2003 15:07:18 +0200 (MEST)

> 
> I didn't think we had specs that called for AIA/SIA to be used for 
> any service other than OCSP, among the services you listed. I thought 
> Denis was saying that IF we were to put a pointer to an SCVP service 
> in AIA, THHEN it would make sense to put in a pointer to TSP, but 
> that this was not currently the case. 3280 defines support only for 
> OCSP here. 3161 makes no reference to AIA, so I'm not sure why you 
> say that AIA could point to a TSA. Only your informational DVCS RFC 
> makes reference to AIA (something I admit that I didn't notice).

The appendix RFC 3161 an also a corresponding part in 3280.
I remember the long discussion about the reintroduction of
that SIA in 3161 before finishing 3280.   

<paranthese>

I also remember that I had a very length private discussion
with you personally about the history of AIA or SIA and
another extension which came from the internet and was in some
old draft. I expressed my feeling that having a AIA, an SIA
and yet another 'class like' definition which still has
OID based parameters is a slight overkill and sometimes
difficult to maintain. 

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

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

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

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

> 
> I'd like te WG to address each of these cases separately, explaining 
> not syntactically or mechanically could be done, but why we believe 
> that this is an appropriate way to use SCVP vs. other options, etc.
>

---

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

>that SIA in 3161 before finishing 3280.

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.

>OID based parameters is a slight overkill and sometimes

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.

>   A possible implementation is to put an AIA into an end cert.

I do not understand this example, please rephrase.

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

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

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

>to be validated. But, it is probably necessary to distinguish the different

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.

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

Steve