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

From: "Michael Myers" <[email-masked]>
Date: Tue, 23 Apr 2002 13:27:15 -0700

Russ, Denis:

Good work.  My detailed parse of -04 into discrete rqmts
statements yielded several comments, included below.  These are
identified by [MMn].  Most are minor to only mildly aggravating.
I do have an issue with DPD client-side max path specification
which I'll take up in a separate email.

Mike

DPV REQUIREMENTS
****************

ESS and ES-F are not rqmts, or are they?
----------------------------------------
"The certificate to be validated MUST either be directly
provided in the request or unambiguously referenced, such as the
CA distinguished name, certificate serial number, and the hash
of the certificate, like ESSCertID as defined in [ESS] or
OtherSigningCertificate as defined in [ES-F]."

MM1:  The text seems to want to suggest that ESS or ES-F are
requirements but doesn't come out and say so.  I suggest
amending the text to provide absolute clarity that these
citations are examples of unambiguous referencing mechanisms,
NOT requirements.

Are these obvious operational facts, or rqmts?
----------------------------------------------
"The DPV server MUST have the full certificate to be validated.
When the certificate is not provided in the request, the server
MUST verify that the certificate is indeed the one being
unambiguous[ly] referenced by the client."

MM2:  These two sentences read more like statements of obvious
operational facts rather than BOTW protocol requirements.
Suggest using words other than the normative MUST.

Editorial
---------
"Unless an error is reported, the DPV response MUST indicate one
of the
following two status alternatives:"

MM3: Change "two" to "three" to reflect {valid, invalid,
unknown}

Clarify minimal set of invalidity reasons
-----------------------------------------
"When the certificate is not valid according to the validation
policy, then the reason MUST also be indicated. Invalidity
reasons include:  [bad path, invalid path, not yet valid]."

MM4: Are these three reasons normative or exemplary?  It makes
sense to presume the former.  If so, the text should be amended
to ensure ample clarity regarding the intent.  More to the
point, establish a minimally compliant set of reasons for
invalid.

How to distinguish "invalid" from "not yet valid"?
--------------------------------------------------
"c) the certificate is not yet valid at this time. If another
request could be made later on, the certificate could possibly
be determined as valid. This condition may occur before a
certificate validity period has begun or while a certificate is
suspended."

MM5:  This requirement can be eliminated with no loss of
functionality.  To the extent that the two cases cited above
define the totality of what it means for a certificate to be
potentially valid, then if a certificate is suspended, I suspect
most RPs would prefer "invalid" over "not yet valid" especially
since suspension may equally result in permanent revocation. In
the second case, why is the RP even attempting to rely on the
certificate prior to the onset of the certificate's validity
period?  Or are we assuming the certificate-as-blob model where
RP software (possibly a thin client), just throws the blob to a
DPV server without even looking at the cert other than to
extract the public key and so it doesn't even bother to consider
the validity period?

Additional info:  rqmts or examples?
------------------------------------
"The DPV request MUST allow the client to request the server to
include in its response additional information which will allow
relying parties not trusting the requested DPV server to be
confident that the certificate validation has correctly been
performed. Such information may (not necessarily exclusively)
consist of [several examples]."

MM6:  Are the examples normative or exemplary?  The use of
lower-case "may" suggests the latter but if normative then an
iterated list defining a minimal set of such information and
corresponding normative language is needed.

Does a signed response meet the server auth rqmt?
-------------------------------------------------
"For the client to be confident that the certificate validation
was handled by the expected DPV server, the DPV response MUST be
authenticated, unless an error is reported."

and

"For the client to be able prove to a third party that trusts
the same DPV server that the certificate validation was handled
correctly, the DPV response MUST be digitally signed, unless an
error is reported."

MM7:  Maybe I'm missing something obvious, but under what
circumstances would a client be unable to conclude from a signed
response that a certificate validation was NOT handled by the
expected DPV server?

Support for client auth.
------------------------
"The DPV server MAY require client authentication, therefore,
the DPV request MUST be able to be authenticated."

MM8:  Is is safe to assume that the client-auth feature of TLS
or similar lower-layer security protocol is responsive to this
rqmt?  In that design scenario, there's no need for a specific
client-auth feature in a DPV protocol other than to point to
such means.

Clarification of support for optional relay, etc.
-------------------------------------------------
"Protocols designed to satisfy [DPV&DPD-REQ] MAY include
optional fields and/or extensions to support relaying,
re-direction or multicasting."

MM9:  I think this means that a protocol responsive to
[DPV&DPD-REQ] MAY have these features, but is not required to.
Correct?

DPD REQUIREMENTS
****************

Make exclusion of root more normative.
--------------------------------------
"If the trust anchor is a self-signed certificate, that
self-signed certificate is not included."

MM10:  An obvious place for a MUST NOT or a SHALL NOT.

Revocation info rqmt duplicated
-------------------------------
"In addition, if requested, the revocation information
associated with each certificate in the path MUST also be
returned."

preceding requirement:

"Clients MUST be able to specify whether they want . . .
revocation information associated with the path . . ."

MM11:  Seems to be a duplication here.

Multiple paths issue
--------------------
MM12:  This subset of DPD requirements seems to be leading
towards a sub-optimal system design.  To be addressed in a
separate email.

Which path discovery policy?
----------------------------
"Path discovery MUST be performed according to the path
discovery policy."

MM13:  Suggest appending ". . . in effect at the time between
the client and the server.  Means by which this policy is
established are out of scope of this document."

Signing DPD responses an option
-------------------------------
"For the client to be confident that the response originates
from the expected DPD server, the server MAY provide an
authenticated response. For example, the server might sign the
response."

And,

"The DPD server MAY require client authentication, therefore,
the DPD request MUST be able to be authenticated."

MM14:  Signing is an example, not a requirement, correct?
Lower-layer security protocols could equally address server auth
needs.  Suggest appending to the last sentence of the first
requirement " . . . or the client could invoke a lower-layer
security protocol that authenticates the server (e.g. TLS)."
This also folds in well with the MUST regarding support for
client auth.

POLICY DISCOVERY REQUIREMENT
****************************

Thought we got rid of PDP-type requirements
-------------------------------------------
"The client MUST be able to obtain references for the default
policy or for all of the policies supported by the server by
using an additional request/response pair. The response can
include references to previously defined policies or to a priori
known policies."

MM15:  I thought we got rid of all PDP-type requirements in this
DPV/DPD requirements document.  The above text seems to mandate
that any protocol responsive to this document MUST define a
request/response pair for policy discovery.

---

From: "Deacon, Alex" <[email-masked]>
Date: Wed, 24 Apr 2002 16:12:13 -0700

Thanks Mike, I agree 100%.  In addition, the definition of an unknown status
maps well to the unknown status defined in 2560.  

Alex

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 3:54 PM
> To: Trevor Freeman; PKIX 
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> 
> 
> 
> 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
> 
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[email-masked]]
> > Sent: Wednesday, April 24, 2002 11:33 AM
> > To: Michael Myers; PKIX
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> >
> > 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
>

---

From: Peter Williams <[email-masked]>
Date: Thu, 25 Apr 2002 12:13:03 -0700

Russ,

let me ask you to laboriously confirm an example, which 
tests your meaning on a critical case.

Citing to DoD CP 2.0 policy on relying party obligations
for my example:
 
(a) If DoD requires DoD RPs to regard a given revoked/expired cert as-if
valid, for some reason, a DPV validation policy may
NOT override 2459 logic to accommodate that CP's 
policy rule.

	Is (a) correct?

(b) DoD UAs which delegate path
processing to a DPV server CANNOT correctly implement
the DoD CP obligation on RPs re as-if validiaty status - that is 
they CANNOT invoke security based on DPV-processed paths that 
contain factually invalid/expired certs. 

	Is (b) correct?

(c) A DoD UA which does not use DPV and performs its own path 
processing CAN follow the DoD CPs obligations on the RP, and use
paths containing factually-invalid certs that have been redesignated 
by the CP as-if valid.

	Is (c) correct?

>>>>Mike:
>>>>
>>>>I think that RFC 2459 (and soon RFC 3280) clearly define a valid 
>>>>certification path.
>>>>
>>>>Anything that does not meet this definition is invalid, 
>>>>regardless of the 
>>>>reason.

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 26 Apr 2002 08:34:42 -0400

>NOT override 2459 logic to accommodate that CP's

I understand the need for this requirement.  In my view, the DPV server 
should say that the path is invalid and provide the reason as 
expiration.  The client, knowing the context of the query, can allow the 
grace period or not.

>contain factually invalid/expired certs.

No correct. As above, the DPV server gives the client the status of the 
path, then the client can proceed to use the public key associated with an 
invalid path is the situation warrants.  For example, the path associated 
with the signature on an S/MIME message may be invalid, yet the contents is 
displayed to the human user with a warning that the certificate is expired 
(or revoked due to affiliation change, or revoked due to key compromise, or 
whatever).  The human needs to factor the reason for invalidity into any 
decision about the quality of the information in the message.

>paths containing factually-invalid certs that have been redesignated

Correct.  However, this is not the only acceptable implementation 
architecture.  The path validation could be performed in accordance with 
RFC 2459 (or the soon to be published RFC 3280), then the DoD UA could make 
a policy decision to proceed with the public key anyway.

I would prefer to see grace periods (and other policy driven decisions to 
proceed with a particular invalid certificate) implemented in the 
application, not in the certification path processing.  In this may, as 
much application-specific context can be applied to the exceptions.

Russ