Subject: RE: Open issue: DPV additional information

From: Peter Williams <[email-masked]>
Date: Wed, 17 Apr 2002 14:11:54 -0700

You seem to be saying: "The requirements document doesnt need to address
the fundamental relationship between the parties, that
will be built into the protocol design."

We have two choices.

(1) we can agree that DPV requirements
do not address the issues raised: and the design
of the protocol is free to do what
the designers see approriate

Or

(2) we can state the requirements,
and hold the protocol designs
to the requirements.

Currently, there are assumed models and/or
statements about the relationships. If
they stay, they must become more coherent.

Currently a DPV server is a mystical NR-supporting
server (Denis), that (somehow) will enforce a CA 
authorization over CRL and OCSP issuers (Denis), but
will itself will not be authorized by a CA (Denis), but
the service may be provided by a CA using a CAs cert/CRL
signing key (Mike) that uses validation policies of 
unknown rules (not limited to trust-anchors and X.509 path
processing parameters) to indicate to a relying party
that a given chain is valid under the policy, and will
supply its sources of asurnace (certs, CRLS, OCSP responses) to the RP to
maintain
as evidence alongside the DPV response.

And somewhere in all this, there is something
about signature policies.

>>>>-----Original Message-----
>>>>From: Michael Myers [mailto:[email-masked]]
>>>>Sent: Wednesday, April 17, 2002 1:08 PM
>>>>To: Peter Sylvester; [email-masked];
>>>>[email-masked]; [email-masked]
>>>>Cc: [email-masked]
>>>>Subject: RE: Open issue: DPV additional information
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]]On Behalf Of
>>>>> Michael Myers
>>>>> Sent: Wednesday, April 17, 2002 11:09 AM
>>>>>
>>>>> Hal,
>>>>>
>>>>> This works for me.  Thanks for stepping in.
>>>>>
>>>>> Mike
>>>>
>>>>
>>>>However, Peter Sylvester does make some good points. But since
>>>>this debate doesn't affect the requirements document Russ and
>>>>Denis are working to finalize (at least, I hope it doesn't) we
>>>>should probably reserve these cycles for the main event.
>>>>
>>>>Mike
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Peter Sylvester [mailto:[email-masked]]
>>>>> Sent: Wednesday, April 17, 2002 12:54 PM
>>>>> To: [email-masked]; [email-masked];
>>>>> [email-masked]; [email-masked]
>>>>> Cc: [email-masked]
>>>>> Subject: RE: Open issue: DPV additional information
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> > As entertaining as it is to watch you guys talk
>>>>> past each other, this thread
>>>>> > is getting tiresome. Let me take a crack at why I
>>>>> don't think there is any
>>>>> > real disagreement here.
>>>>>
>>>>> Thanks also for trying to find the core of the
>>>>> 'debate'. Debates are
>>>>> currently entertainment in France :-)
>>>>>
>>>>> As far as I remember the claim was 'A CA cannot sign
>>>>> DPV responses'.
>>>>> And Mike and I disagree with that statement.
>>>>>
>>>>> I am not sure whether there is a disagreement in your
>>>>> following
>>>>> description. It may be a language problem, but I
>>>>> think there are
>>>>> some logical relations which seem inversed or unclear.
>>>>> My commenst may even lead to more obscurity.
>>>>>
>>>>> >
>>>>> > I think what Denis is saying is that if an entity
>>>>> is a CA, by definition
>>>>> > they are trusted to issue and revoke the
>>>>> certificates they issue, by virture
>>>>> > of being a CA. They can also delegate someone else
>>>>> to do the revocation,
>>>>> > also by virtue of being a CA. If a RP decides to
>>>>> trust their certs, they
>>>>> > must also trust their revocation arrangements.
>>>>>
>>>>> To me, the question is not whether RPs 'MUST' trust
>>>>> but whether the CA has set up
>>>>> some service for which it can be held responsible. For OCSP,
>>>>> the CA can sign the responses itself or delegate to
>>>>> an authorised responder
>>>>> to assume this responsibility.
>>>>>
>>>>> Now, since just by adding for example a certificate
>>>>> as an extension in an OCSP
>>>>> response, you immediately turn an 'revocation
>>>>> information' into a
>>>>> 'positive status information', I call this  a
>>>>> particular case of DPV
>>>>> (the request consists to ask the status of the cert relative
>>>>> to the CA that signed it, no intermediate certs involved).
>>>>>
>>>>> > In contrast, when somebody sets up a DPV server,
>>>>> whether or not they also
>>>>> > run a CA, there is an independant decision to trust
>>>>> the DPV server. It does
>>>>>
>>>>> Where is the difference betwwen OCSP and DPV? (OCSP
>>>>> trusted responders
>>>>> are something set up by 'somebody'.
>>>>>
>>>>> > not follow as an automatic consequence of the fact
>>>>> thet the same
>>>>> > organization (or key even) may have issued one or
>>>>> more of the certs in the
>>>>> > chain in question.
>>>>>
>>>>> Right, it is not automatic. If the CA itself has
>>>>> signed the DPV/OCSP response
>>>>> for a directly issued cert, why is is a different
>>>>> PROBLEM to trust the CA for
>>>>> an OCSP response or for a DPV response for this case.
>>>>>
>>>>> There is an issue with intermediate CAs for which
>>>>> indeed the higher CA
>>>>> is generally not responsible.
>>>>>
>>>>> > In other words, a CA may run a DPV server, but the
>>>>> server will be trusted
>>>>> > because RPs choose to do so, not because they have
>>>>> previously chosen to
>>>>> > trust certs issued by the CA.
>>>>>
>>>>> Well, a RP may always choose whatever it wants to do,
>>>>> but IMO t
>>>>> for direct subordinate CAs an OCSP or DPV service is
>>>>> almost identical.
>>>>> if there is a DPV response signed by the CA, why
>>>>> should one not believe
>>>>> that this is not an authorised statement from the CA
>>>>> as soon as the CA
>>>>> has indicated in some policy/practise that it
>>>>> provides CRLs, OCSP and/or DPV?
>>>>>
>>>>> For the general case, there may be more
>>>>> constellations of trust relations
>>>>> for DPV services than just the two defined for OCSP.
>>>>>
>>>>> Regards
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 17 Apr 2002 14:35:41 -0700

Peter,

I think your #2 is about right: state the rqmts and hold designs
against them.  IMHO, further debates on abstract trust issues
only make sense once the technical path forward has been
established.  I see no reason to continue this thread.  Hal
Lockhart laid it to rest quite well.  Let's save our cycles for
what is to come.

Mike

> From: Peter Williams [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 2:12 PM
> To: 'Michael Myers'; Peter Sylvester; [email-masked];