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

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 23 Apr 2002 18:46:38 -0700

Hi Mike,
I don't see that this is the resolution of record. 

2560 defines unknown as 'The "unknown" state indicates that the
responder doesn't know about the certificate being requested.'

The requirements document states that "The certificate to be validated
MUST either be directly provided in the request or unambiguously
referenced". If the client gives the server an unambiguous reference to
the certificate to be validated, then unknown is not an appropriate
response. The server was either able to establish the validity of the
certificate - or it did not and returns invalid with a sub status with
further explanation. If you prefer we can change the working of the two
states to "valid" and "error".

Editorial note: the reference to the client providing an unambiguous
reference to the certificate needs to be moved to the common
requirements section.

Trevor

>
> MM3: Change "two" to "three" to reflect {valid, invalid,
> unknown}
>
> [RH] I am having a real problem differentiating
> invalid and unknown. To my way of thinking, the
> actions taken by a client will be the same in
> either case.

{valid, invalid, unknown} is the resolution of record and
defined in the text.  My comment was just pointing out an
editorial wrinkle that needs smoothing out.

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 23 Apr 2002 20:19:14 -0700

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.