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

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Sep 2003 17:11:04 +0200 (MEST)

> 
> One motivation for DPV is to allow clients to receive a public key 
> and to use it, because the server said it was OK to use relative to 
> the policy indicated by the client in the query. The notion is that a 
> client need not be able to parse certs and CRLs in this case, but 
> rather can just pass an opaque blob of bits to the server and use a 
> configured policy reference, specific to the local use context, and 
> be told the answer.  Obviously this would not be true in the DPD 
> case, but it is reasonable for DPV.

Can you point me to the text in 3379.

As far as I can see, the text does not talk about public key 
retrieval, but about certificate validation. 

Nowhere in the text there is a requirement that the protocol
MUST provide a means that a client can treat a cert as a blob.

The text says that one of the unambigouous references
may for example be  "such as the CA distinguished
   name, certificate serial number, and the hash of the certificate,
   like ESSCertID as defined in [ESS] or OtherSigningCertificate as
   defined in [ES-F]."

" The DPV server MUST
   include either the certificate or an unambiguous reference to the
   certificate (in case of a CA key compromise) in the DPV response."

except for a hash, the other references require interpretation of
the cert. 

> >Your main argument seems to me: 'As soon as there is one particular
> >situation where a feature cannot be used, one MUST NOT even think
> >to use it.'
> 
> The primary focus of what we are doing was established in RFC 3379. 
> It think it is appropriate to judge a suggestion of this sort 
> relative to that set of agreed upon requirements.

But you have already argued differently without success so far,
and you just use this as a last resort for your refusal. 

> 
> >I am not sure whether we (the group, not just you) can get consensus
> >that there is a subset of use cases for DPV which matches the use
> >cases for OCSP.
> 
> 3379 represents WG consensus on the requirements for this protocol, 
> so it is valid to make decisions based on that.
> 
> >
> >>  >  > >On the other hand, you seem to restrict DVP to just just that model.
> >>  >>  >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.
> >>  >>
> >>  >>  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.
> >
> >I fail to decrypt this sentence.
> >
> >Do you agree mean that 3379 lists the only valid points, or
> >do you accept this motivation as a valid one which was
> >omitted in 3379 for whatever reason, or ... ??
> 
> Yes, a CA could operate an SCVP service for its local clients, but 
> such operation is not intrinsic to the general model. I have yet to 
> see a good explanation of the benefits that accrue from putting the 
> name of an SCVP server into an extension, if we agree that the public 
> key for that server needs to be configured in the client anyway. 
> Moreover, the suggestion of putting this info into the AIA extension 
> seems to be an afterthought, especially when viewed relative to 3379.

The usage of AIA or SIA to point to services is a common feature that
has been used in various PKIX protocols, OCSP, TSP, DVCS for example as
a general mechanism to convey a contact address in a certificate. 

This does seem an afterthought to me but rather a well accepted feature
since years which doesn't seem to need a particular requirement.

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. 

> Is that clearer?
In one paragraph you hide yourself behind 3379, and on
the other hand you pretend to discuss more until your run out of
arguments. 

> >>  >Well, of course, there is a simple fix for OCSP.
> >>
> >>  you omitted the emoticon at the end of the sentence, e.g., :-) or ;-)
> >
> >No.
> 
> Oh, then you should say what simple fix you have in mind. I assumed 
> that you were suggesting, in jest, the idea of  changing the 
> semantics of OCSP to be a cert status protocol, vs. a cert revocation 
> status protocol, something that has been debated on the list on a 
> number of occasions and thus did not seem to merit further, serious 
> discussion.
You do not mention that many of the proposals simply work, so indeed,
further discussion would not change this. 

- return a valid cert as an extension
- define in your CPS that all ok response mean that the cert exists

Peter

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Sep 2003 18:35:18 -0400

>retrieval, but about certificate validation.

Whoops, you're right! During the debates on DPV I recall that we 
wanted to support clients who might not even be able to parse certs, 
but this did not become part of the requirements doc.

>MUST provide a means that a client can treat a cert as a blob.

yes, consistent with my comment above, I was in error in saying that 
this was part of the requirements spec.

>except for a hash, the other references require interpretation of

right again. the client does need to be able to parse a cert to 
extract a public key, although the client need not be able to perform 
cert path processing, at least not for DPV.

<SNIP>

>a general mechanism to convey a contact address in a certificate.

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

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

>as a proxy can contact a CA's server using an AIA in the cert to be

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.

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.

<SNIP>

(let's not mix discussion of changes to OCSP semantics with SCVP, 
since we have enough to discuss already)

Steve

---

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

Steve,

(...)

 > I thought Denis
> was saying that IF we were to put a pointer to an SCVP service in AIA, 
> THEN it would make sense to put in a pointer to TSP, but that this was 
> not currently the case. 

This is not what I was saying.

IF we were to put a pointer to an SCVP service, THEN it would make sense to 
put in a pointer others added-value services like TSS (Time-Stamping 
Service). However, these pointers should *not* be in the AIA category.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 5 Sep 2003 08:03:40 -0700

> 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
> I'd like the WG to address each of these cases
> separately, explaining not syntactically or
> mechanically could be done, but why we believe

Steve,

I trust my posting of yesterday regarding the "why" behind relay
is at least partially responsive to your request.

Mike

---

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

At 11:07 +0200 9/5/03, Denis Pinkas wrote:
>Steve,
>
>(...)
>
>>  I thought Denis
>was saying that IF we were to put a pointer to an SCVP service in 
>AIA, THEN it would make sense to put in a pointer to TSP, but that 
>this was not currently the case.
>
>IF we were to put a pointer to an SCVP service, THEN it would make 
>sense to put in a pointer others added-value services like TSS 
>(Time-Stamping Service). However, these pointers should *not* be in 
>the AIA category.
>
>Denis

OK, thanks for the clarification of your position.

Steve