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

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Sep 2003 14:40:00 +0200 (MEST)

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

Is there is missing 'to me' ? 

> >
> >Alternatively, it could be in a SIA of a service cert.
> 
> see my comments to Trevor re 3379 assumptions about clients, in general.

A client that is unable to decode a cert would use a certifiacte in
which way? Isn't there at least a need to extract the public key?

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

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. 

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

> >Well, of course, there is a simple fix for OCSP.
> 
> you omitted the emoticon at the end of the sentence, e.g., :-) or ;-)

No.

---

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

>Is there is missing 'to me' ?

yes, it seems to trivial to me, but I don't think my opinion is 
unique in this case :-)

>which way? Isn't there at least a need to extract the public key?

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.

>situation where a feature cannot be used, one MUST NOT even think

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.

>that there is a subset of use cases for DPV which matches the use

3379 represents WG consensus on the requirements for this protocol, 
so it is valid to make decisions based on that.

>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. 
Is that clearer?

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

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.

Steve