Subject: RE: Open issue: DPV additional information

From: Peter Williams <[email-masked]>
Date: Wed, 17 Apr 2002 12:40:49 -0700

Mike,

What Denis is apparently saying is:

- unlike OCSP (and OCSPv2) which standardizes an authorization model
for CA-authorized "responders", and a non-CA "local-trust" model 
for "local responders"

- DPV requirements do NOT call for standardization
of these two issues (authorization and local trust)
in the DPV protocol to be specified

- He makes various broad-ranging assumptions on these 
very issues, however, that we are determining from the thread what the
assumptions are.

I think the only 2 substantive points that PeterW, PeterS, and
Denis and others are discussing, include

1) Whether the DPV
requirements *should* specify means to address the DPV
dependent-services authorization and trust issues (e.g. 
these issues as they affect path processing supporting CRL handling, 
these issues as they affect OCSP response acceptance
handling, and these issues as they affect OCSP response chain's 
own path processing)

2) We seek to flush out Denis' assumption about his model of 
the authorization and local-trust relations between CA/AAs, DPV
servers, and EE relying-parties, and find out which entity and
protocol state will be responsible for enforcing the authorization 
and local-trust rules, once we get to protocol specification.

If we use your OSCP v2 work as a guide, we can reason thus:

My (and implicitely your) suggestion is that DPV handle authorization 
and local-trust issues in the way that OCSP does - as the OCSP standard
had pragmatically suceeded to balance both CA-focussed and RP-focussed
relationship models between the CA/AA, OCSP responder, and
EE-RP parties. The OCSP solution to the issues would obviously
come built into DPV, if we specify a DPV using OCSPv2, lets note. AS Denis
seems to deny, however, the legltimacy of the OCSP way of handling 
these issues for DPV needs, we cannot simply do OCSP v2, as is, to perform a
DPV protocol: Why not, as OCSP's standardization per se contradicts 
Denis' model of the relationships between the players.

Im not saying I agree with Denis. But if I translate his
aphorisms, this is what he seems to be actually stating. My
statement of the implications for OCSP (v2) or any
other protocol design following the OCSP heritage, then
follow.

Peter.

>>>>-----Original Message-----
>>>>From: Michael Myers [mailto:[email-masked]]
>>>>Sent: Wednesday, April 17, 2002 7:01 AM
>>>>To: Denis Pinkas
>>>>Cc: pkix
>>>>Subject: RE: Open issue: DPV additional information
>>>>
>>>>
>>>>
>>>>Denis,
>>>>
>>>>Even as explanations, I disagree with the assertions.
>>>>
>>>>A CA can most certainly sign DPV responses, especially relating
>>>>to its own certificates.  A CA can also delegate that function
>>>>(i.e. authorize a DPV server) to another trusted party.  That
>>>>party could conceivably itself be a CA.  Thus a CA can sign DPV
>>>>responses even with respect to certificates it didn't issue.
>>>>
>>>>In my view, these are deployment and operational issues relating
>>>>to specific policies, practices and perhaps even contracts, all
>>>>of which seem to be well out of scope of our technical
>>>>considerations.  But maybe that's just me.
>>>>
>>>>Mike
>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]]On Behalf Of Denis Pinkas
>>>>> Sent: Wednesday, April 17, 2002 2:42 AM
>>>>> To: Michael Myers
>>>>> Cc: pkix
>>>>> Subject: Re: Open issue: DPV additional information
>>>>>
>>>>>
>>>>>
>>>>> Michael,
>>>>>
>>>>> The text you mention is *not* going to be placed in
>>>>> the requirement
>>>>> document, but was only explanations.
>>>>>
>>>>> Since there has been many small changes since version
>>>>> 03, I will re-issue
>>>>> a draft shortly so that everybody can see the result
>>>>> of the more than
>>>>> * 300 e-mails * that have been exchanged.
>>>>>
>>>>> Denis
>>>>>
>>>>> > > -----Original Message-----
>>>>> > > From: [email-masked]
>>>>> > > [mailto:[email-masked]]On Behalf Of
>>>>> Denis Pinkas
>>>>> > >
>>>>> > > . . .
>>>>> > >
>>>>> > > No. DPV servers are never authorized by CAs. They
>>>>> are either :
>>>>> > >
>>>>> > >  - locally trusted by their requesting clients for any
>>>>> > >    policy, or/and
>>>>> > >  - trusted under a given validation policy.
>>>>> > >
>>>>> > > . . .
>>>>> > >
>>>>> > > A CA cannot sign DPV responses.
>>>>> >
>>>>> > Denis,
>>>>> >
>>>>> > A while back I quite carefully parsed the -03
>>>>> version of the I-D
>>>>> > into requirements statements.  Nowhere did I see
>>>>> these negative
>>>>> > requirements asserted.  Had they been there, I'm
>>>>> quite certain I
>>>>> > would've raised an issue on the list.  Do you
>>>>> really mean to say
>>>>> > that a CA can neither directly affirm the validity
>>>>> of its own
>>>>> > certificates nor delegate that obvious right to
>>>>> another party?
>>>>> >
>>>>> > Mike
>>>>>
>>>>

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 17 Apr 2002 15:36:16 -0700

Peter,

I believe we should segregate this discussion from the
progression of the requirements document since to my knowledge
there exists no normative requirement or advisory text on this
point.  So I changed the subject line.  A few comments below.

Mike

> Peter Williams
> Sent: Wednesday, April 17, 2002 12:41 PM
> To: 'Michael Myers'
> Cc: pkix; Denis Pinkas
> - unlike OCSP (and OCSPv2) which standardizes an
>   authorization model for CA-authorized "responders",
>   and a non-CA "local-trust" model for "local responders"
>

This is because the DPV/DPD requirements I-D (at least as
I see it) is a systems-level requirements document.  It
defines the boundary conditions.  Within that envelope,
there's still a lot of wiggle room.  That in my mind is
the very definition of a good systems requirement document.

>   very issues, however, that we are determining from
>   the thread what the assumptions are.

This thread will go on for a while I think, in one form
or another.  But as Hal pointed out, it's possible Denis
and I are talking past each other.  I accept this as likely.

> 1) Whether the DPV requirements *should* specify means
> to address the DPV dependent-services authorization and
> trust issues (e.g. these issues as they affect path processing
> supporting CRL handling, these issues as they affect OCSP
> response acceptance handling, and these issues as they affect
> OCSP response chain's own path processing)

In my opinion, many of these issues are deployment
related and thus out of scope of the specification
of a technical protocol, which is where we're headed.

> 2) We seek to flush out Denis' assumption about his model
> of the authorization and local-trust relations between
> CA/AAs, DPV servers, and EE relying-parties, and find out
> which entity and protocol state will be responsible for
> enforcing the authorization and local-trust rules, once
> we get to protocol specification.

Somewhat disagree.  We ultimately seek the *WG's* consensus
on these points.  At least that's how I'm approaching it.

> My (and implicitely your) suggestion is that DPV
> handle authorization and local-trust issues in the
> way that OCSP does - as the OCSP standard had pragmatically
> suceeded to balance both CA-focussed and RP-focussed
> EE-RP parties.

Well, thank you I guess.  I figure our work on OCSP might have
had a clue or two, but we shall see.

> The OCSP solution to the issues would obviously
> come built into DPV, if we specify a DPV using
> OCSPv2, lets note. AS Denis seems to deny, however,
> the legltimacy of the OCSP way of handling these issues
> for DPV needs, we cannot simply do OCSP v2, as is, to
> perform a DPV protocol: Why not, as OCSP's standardization
> per se contradicts Denis' model of the relationships
> between the players.
>