Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 24 Apr 2002 11:33:19 -0700

Mike,
I realise there has been several mailing on this topic, but so far no
consensus. 
Apart form references to 2560, I have not seen much in the way of
reasoned justification as to why we need another return code in DPV/DPD.
All this additional return value is indicating is some kind of failure
on the part of the server. We have defined the requirement for
additional information on the error to be returned by the server to
clarify the nature of the failure to the client. If you want to refine
the defined list of sub-status reasons when we get to define the
protocol then I am sure we can debate this more meaningfully then.
However since one of the goals of the DPV protocol is to address
constrained clients, then we have to be hard core on not complication
the protocol.

Trevor

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Tuesday, April 23, 2002 8:19 PM
To: PKIX 
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt

Trevor,

Regarding the existence of the "unknown" state as the resolution
of record, the following WG list-based dialogs exist on this
point. These yeilded the list-based consensus reflected in -04
modulo that one word I referred to earlier.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Tuesday, February 26, 2002 1:51 AM
>
> So I would propose the following fix:
>
> The DPV response MAY indicate one of three status
> alternatives:
>
> 1) the certificate is valid according to the
> validation policy.
>
> 2) the certificate is invalid according to the
> validation policy. A secondary status MAY indicate
> that the certificate is definitively invalid or
> potentially valid.
>
> In the former case, if another request was made
> later on, the certificate will still be determined
> as invalid.
>
> In the later case, if another request could
> made later on, the certificate could possibly
> be determined as valid. This condition will
> occur before a certificate validity period has
> begun, while a certificate is suspended, or
> when, at the time the server generated the
> response, all conditions of the
> validation policy could not be met.
>
> 3) the server cannot determine the validity of the
> certificate. This condition will occur when a
> certification path cannot be constructed or
> some revocation information is unavailable.
>
> Denis

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Wednesday, February 27, 2002 5:19 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: "Potentially valid" response state in
> DPV/DPD rqmts I-D
>
>
>
> Michael,
>
> > Denis,
> >
> > Okay, if I may summarize at a high level my current
> > understanding:
> >
> > We are now effectively back to {valid, invalid,
> > unknown}.  All responses MUST indicate the relevant
> > validation policy. This policy MAY be established out
> > of band.  An "invalid" response MAY contain reason
> > codes or similar information that aids a client in
> > determining the likelihood that the same request sent
> > at a later time would return "valid". An "unknown"
> > response MAY contain reason codes or similar information
> > that indicates a failure to acquire all relevant data.
> >
> > Is that a fair summary?
>
> Yes, indeed it is.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Tuesday, February 26, 2002 3:04 AM
> To: Peter Sylvester
> Cc: [email-masked]; [email-masked]
> Subject: Re: "Potentially valid" response state in
> DPV/DPD rqmts I-D
>
>
>
> Peter,
>
> > > The DPV response MAY indicate one of three status
> > > alternatives:
> > >
> > >  1) the certificate is valid according to the
> > >     validation policy.
> > >
> > >  2) the certificate is invalid according to the
> > >     validation policy. A secondary status MAY
> > >     indicate that the certificate is
> > >     definitively invalid or potentially valid.
> > >
> > >     In the former case, if another request was
> > >     made later on, the certificate will still
> > >     be determined as invalid.
> > >
> > >     In the later case, if another request could
> > >     made later on, the certificate could possibly
> > >     be determined as valid. This condition will
> > >     occur before a certificate validity period has
> > >     begun, while a certificate is suspended, or
> > >     when, at the time the server generated the
> > >     response, all conditions of the validation
> > >     policy could not be met.
> > >
> > >   3) the server cannot determine the validity of
> > >      the certificate.  This condition will occur
> > >      when a certification path cannot be constructed
> > >      or some revocation information  is unavailable.

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 24 Apr 2002 15:53:46 -0700

Trevor,

I agree with you and Russ that from a state machine perspective,
a client will probably take the same action in both the unknown
and invalid cases.  However, from a server, or more importantly
a service perspective, I suspect there exists an appreciable
semantic difference  in a legal or liability sense between these
two states.

I've had the pleasure over the past few years of abundant
exposure to lawyers, bankers, regulators and other such types
regarding these and related issues.  I'm sure many of us share
that experience in one form or another.

Now, I'm no lawyer but given that exposure it seems to me that a
service (i.e. that which runs a server) is setting itself up for
disaster by asserting a digitally signed "invalid" when in point
of fact that service hasn't the data, jurisdiction or delegation
to make such an unequivocal assertion.

As a hypothetical, consider a party seeking damages to which an
invalid assertion is useful as evidence even though the
certificate in question is provably valid given access to the
relevant data.  That plaintiff could arguably find some service
that doesn't know diddly about the certificate to issue a
digitally signed "invalid" and there you go.  That TTP may have
just stuck its neck out.

I know that's probably a stretch, but not inconceivable given
some the purposes to which certs and sigs are today being
applied.  Better it seems by far to enable an "out" via unknown
even if at the other end, the client does nothing differently.

Valid and Invalid mean something very precise to my way of
thinking.  It means data was accumulated, a path was
successfully constructed, revocation information was checked and
the entire dataset checked according to 2459 and whatever else
might specified by the policy in place at the time between the
client and the server/service.  Break any one of those
assumptions and one can't assert invalid.  Hence we need
unknown.

Mike

> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 11:33 AM
> To: Michael Myers; PKIX