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

From: "Housley, Russ" <[email-masked]>
Date: Tue, 23 Apr 2002 17:21:07 -0400

Mike:

Thanks for the comprehensive review.

See my responses below.  They are prefixed by [RH].

Russ

= = = = = = = = = = = = = =

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.

[RH] I think that the word "like" makes it clear that ESS and ES-F
are ways to meet the requirement.  There are other acceptable ways.

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.

[RH] I think that the MUST is appropriate.  Denis and I had a 
dialogue that was resolved by realizing that this was needed.

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}

[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.

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.

[RH] Can this wait for protocol specification?  I think it can.

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?

[RH] Denis is the proponent for this requirement.

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.

[RH] I do not think it is unclear. The may is in lower case.

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?

[RH] If an error is reported, the response does not have to
be signed.  Otherwise, the response does have to be signed.

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.

[RH] A lower layer protocol authentication scheme could be used,
or a signature on the request could be used.

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?

[RH] Yep.

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.

[RH] Fine.

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.

[RH] Okay, duplication is not necessarily bad.  But, one
could be deleted.

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.

[RH] I will wait for the mail to reply ...

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."

[RH] I do not like this text.  If a particular client can make
use of more than one policy, then the request needs to include
a specification of the policy.

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.

[RH] DPV requires signature on the response.  Why not allow
some consistency?

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.

[RH] We want the client to be able to get a list of the policies.
PDP (in a future document) will address the definition of said
policies.

---

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

Russ,

That was quick.  Thanks.  A few responses below, else I concur.

Mike

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
>
>
> DPV REQUIREMENTS
> ****************
>
> Editorial
> ---------
> [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.

> DPD REQUIREMENTS

Forthcoming.

> Signing DPD responses an option

I see no needs-based driver for signed DPD responses.  A DPD
server is simply acting as an aggregation point for access to
signed data produced by others.   As I said before, one of the
potential features of DPD over DPV is that a DPD server arguably
need not be trusted in a certification sense while a DPV server
clearly must (assuming of course that server does not combine
both functions).  A non-normative statement that where DPD
server auth is relevant lower layer protocols can suffice would
preserve this quality with no loss of security assurance.

> POLICY DISCOVERY REQUIREMENT

A DPV or DPD server can iterate through its list of policy
definitions and either execute accordingly or send back
unsupportedPolicy.  What's important to the client is that the
server either does or does not support the policy the client
specifies in its request.

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 24 Apr 2002 14:20:48 -0400

>editorial wrinkle that needs smoothing out.

[RH] I agree that a change was made to add the "unknown" response in draft 
-04.  I am not convinced that we did anything useful for the client.  I 
think the client will treat "invalid" and "unknown" exactly the same.

>preserve this quality with no loss of security assurance.

[RH] Just rereading the text, I think that the text in draft -04 allows 
either lower layer mechanisms or signatures within the DPD protocol.  I do 
not think that there is a need to change anything here.

>specifies in its request.

The requirement says that the client can ask the server for a list of 
policy identifiers that it is currently supporting.  This does not mean 
that they were dynamically defined policies.

Russ

---

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

Russ,

Will take up the "unknown" thread via Trevor's recent posting.
Good to hear you interpret the text as I do re: DPD server auth,
namely there's no prejudice against lower layer mechanisms.

I'm still though trying to understand what needs policy
discovery truly addresses.  What might be called the use cases.
To my way of thinking about this, a client is interested in
*its* policy or the one or ones it is constrained to use, static
or otherwise, implicit default or directly signalled in its
request.  Would a discovery query prove this?  Certainly.  But
so would an unsupportedPolicy response back from the server.

I can see that policy discovery could be useful to the
initialization of a freshly installed client, especially from an
enterprise perspective, but then there's a trust issue there.  A
policy discovery function might also be useful in developing an
Internet-wide profile of which servers do which things, but I'm
not sure that's the intent.  Or is it?

As I said, I'm just trying to understand the driver behind the
discovery piece.  Maybe like the roots issue, I'm overlooking
something obvious.

Mike

> Sent: Wednesday, April 24, 2002 11:21 AM
> To: Michael Myers
> Cc: 'PKIX '
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
> Mike:
>
> > > DPV REQUIREMENTS
> > > ****************
> > >
> > > Editorial
> > > ---------

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 Apr 2002 15:15:09 +0200

> think the client will treat "invalid" and "unknown" exactly the same.

[DP] I do not think that the client will always treat "invalid" and
"unknown" exactly the same. I provide an example:

A client queries a DPV server and gets back "invalid". It does not make
sense for the client to query another DPV server, since the response will
never be "valid".

A client queries a DPV server and gets back "unknown". It makes sense to
query another DPV server, since the response could then either be "valid",
"invalid" or still "unkown".
 
Also "unknown" can be used as a clean way to stop a loop mechanism, when the
same protocol is used between DPV servers.

As said later on in an e-mail sent by Tony:

" Seems you have two choices:

1.  Go with "Trinary Value", in which case the semantics are satisfied by

   a. Success_Valid
   b. Failure_Invalid
   c. Failure_Unknown

2.  Go with "Binary Value", using either

   a. Valid
   b. Invalid (see reason code for details)

   or

   a. Success
   b. Failure (see reason codes for details)"

The two approaches end up with the same result. We did discussed that point
in Minneapolis and we decided to go with a trinary status. This mimics the
three OCSP statuses, although the semantics of the DPV statuses are fully
different.
 
Denis

(text deleted)

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 Apr 2002 15:14:47 +0200

Michael,

> discovery piece.  Maybe like the roots issue, I'm overlooking

The driver is simple: a client is not constrained to use one validation
policy only. Depending of the application, one specific policy may be
required. Before sending a full request, it is just easier to know whether
that policy is supported. Getting at one time all supported policies is
simply an optimisation.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 Apr 2002 15:47:36 +0200

Michael,

> editorial wrinkle that needs smoothing out.

I have maintained the three states.

> > DPD REQUIREMENTS

Please send it soon, since this is the VERY last comment (not raised during
the WG last call period). However, if this is going to avoid an issue raised
during the IESG Last call period, then we had better to solve that last one
now.

> preserve this quality with no loss of security assurance.

I propose to update the text in the following way:

For the client to be confident that all the elements from the response 
originates from the expected DPD server, an authenticated response MAY 
be required. For example, the server might sign the response or data 
authentication might also be achieved using a lower-layer security 
protocol.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 25 Apr 2002 09:32:37 -0400

Mike:

I was not the advocate for this requirement, but the one of the scenarios 
that the advocate had in mind was straightforward.  The client has several 
acceptable policies, so the client asks the server for a list of supported 
policies, and the makes the query based on a policy that is on both lists.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 25 Apr 2002 09:18:11 -0700

Denis,

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Thursday, April 25, 2002 6:48 AM
>
> . . .
>
> > > Multiple paths issue
> > > --------------------
> Please send it soon, since this is the VERY last
> comment (not raised during the WG last call period).
> However, if this is going to avoid an issue raised
> during the IESG Last call period, then we had better
> to solve that last one now.

Working it.  Apologies for not bringing it earlier.  It was on
my list of -03 issues but I got preoccupied with my day job and
overlooked making a post.

> . . .
> For the client to be confident that all the elements
> from the response originates from the expected DPD
> server, an authenticated response MAY be required.
> For example, the server might sign the response or data
> authentication might also be achieved using a
> lower-layer security protocol.
>
> Denis

This works for me.

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 25 Apr 2002 09:07:57 -0700

Russ,

I knew it was something simple.  Intersection of policy lists.
Got it.

I suspect though that in the vast majority of cases, this could
better be handled by client-side local configuration logic at
the gain of reduced protocol complexity, always a good thing.
I'm doubtful many folks are actually going to do this in
practice.

Where on the wire signalling is relevant, as a design option,
one could have a SEQ OF policy OIDs in the request and task the
server to do the intersection.  That way, one has an equivalent
functionality with only a very slight increase in protocol
complexity and further reduction in client-side code footprint,
an added benefit with respect to the various thin-client
arguments that have been made.  Only issue I see to this
approach is the instance where the intersection yields multiple
OIDs.  Then the server chooses vs. the client.  But then, how's
a client going to choose?

So I guess I can accept the requirement, but the requirements
document seems to constrain the technical approach.

Mike

> Sent: Thursday, April 25, 2002 6:33 AM
> To: Michael Myers
> Cc: 'PKIX '

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 25 Apr 2002 09:25:08 -0700

Denis,

It is good to see that we can occasionally agree :)

Mike

> Sent: Thursday, April 25, 2002 6:15 AM
> To: Housley, Russ
> Cc: Michael Myers; 'PKIX '
> Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
>
>
> > > > DPV REQUIREMENTS
> > > > ****************
> > > >
> > > > Editorial
> > > > ---------

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 25 Apr 2002 14:15:35 -0700

Russ, Denis:

This analysis and counter-proposal is a bit long which is why I
broke it out separately from my other comments.  Apologies for
the length and not getting to it at the -03 stage.  I had it on
my list but got sidetracked by my day job.

Anyway, I'm having a hard time agreeing with the following.

-----------------------------------------------------
    The DPD client needs to be able to limit the
    number of paths returned. Therefore the client
    MUST be able to indicate the maximum number of
    certification paths to be returned (provided
    that they can be found). If the client does
    not specify a maximum number, then the DPD
    server MUST return a single certification path.

    . . .

    If that number cannot be reached by the server,
    an indication SHOULD be returned by the DPD
    server showing that an additional query will
    not return more paths.

    If the paths that are returned do not match the
    client's local criteria, then the number of
    number of certification paths to be returned can
    be extended by increasing this value. Previously
    found paths will likely be returned, but the
    client can easily discard them. This avoids
    requirements for state information at the server,
    but does not prevent a server from maintaining
    a cache of previous responses.

    Avoiding the maintenance of state information for
    previous requests minimizes potential denial of
    service attacks or other problems associated with
    server crashes.

-----------------------------------------------------

I think an iterated approach based on server-side state would be
better.  The approach is basically one which, in the presence of
multiple paths, the server establishes state and returns the
first potentially acceptable path (given client inputs) to the
client along with a state token.  Should that path not be the
precise one the client is looking for, the client asks again,
referencing the state token.  Upon recognizing the state token,
the server then returns the next path and so on until either the
client shuts up and goes away or the server returns noMoreData.
Doing so would reduce protocol complexity, reduce extraneous
bits on the wire and reduce client-side and server-side code
footprints with no loss of security assurances.

Here's why I think so.

Working first from the motivating needs, it's not clear to me
how reduction of state will minimize potential denial of service
attacks.  If they come, they're going to come regardless of the
internal state of the server.  Possibly what you meant to say is
that doing so potentially improves the likelihood a server can
withstand DOS attacks while maintaining service to legitimate
requests.  I shall assume this for the time being.

But since DOS attacks are largely predicated on throughput
constraints, one can simply beef up the back end or buy a bigger
pipe.  Also, to the extent that your concern over DOS attacks
and server crashes relates to the volatility of state retention,
an implementor of the protocol that ultimately results from
these requirements can choose to write that state to
non-volatile memory.  That is, take a fault-tolerant
implementation approach in those instances where mission
criticality is important.  They're going to anyway.

Lastly re: DOS, my own experience strongly suggests that
effective responses to DOS attacks are most often addressed at
the router, long before an offending stream from a given IP
address gets to a back end.  I agree that we should take care
not to enable sensitivity to DOS attacks.  I'm just not
convinced that the max path approach yields much effect in that
regard while the iterated approach yeilds clear benefits in
design simplicity.

To the design simplicity point, it's my estimate that in the
vast majority of cases where DPD will be used, the first path
returned will be the one the client wanted.  I also estimate
that there'll be far more instances of only one path vs.
multiple paths.  In my view we should design towards the
centroid of needs rather than the corner cases.

Is this design simpler?  I think so.  It's just a state token.
The client doesn't even have to know what it is, just send it
back for another try.  The use of noMoreData also provides
unambiguous protocol closure.  The client knows for certain what
to do in that instance.  Very simple, hence a smaller client.

Regarding extraneous bits on the wire, consider the case of
maxPath of M from the client and server side numPaths of N,
where N is larger than M.  The client receives N-M paths and any
requested revocation data.  All of which may be useless because
the path the client wants is in the remainder.  So the client
kicks up its M to, say, M' where M' is still less then N, first
receives again those useless N-M paths and related info before
it gets into the M'-M set.  And so on.

I suspect once this scenario comes to the attention of
client-side developers, they will be tempted to bake in a very
large maxPath to ensure that a single query yields all paths.
Again, a lot of extraneous bits on the wire when in point of
fact the client just wants one.  And as I hypothesized, I
suspect that in the vast majority of cases that'll be the first
one.  Thus our requirements threaten to place onto the Internet
a bunch of useless bits.  I think we should be sensitive to
needless bandwidth consumption.

Also, in the event multiple paths exist but the client doesn't
specify max # of paths, what are the requirements on the server
in the event of multiple queries from a client regarding the
same certificate?  The requirement reads "return a single
certification path" but provides no guidance in the presence of
multiple paths at the server, leading one to assume that the
first one is always sent back.

Thus in the presence of multiple paths, there exists no means to
enable a client to get at the one it wants.  Absent that
guidance and any variation from the current draft requirements,
I'm sure this issue will be taken up at the protocol selection
stage of our work.  It's possible those considerations will lead
to servers trying their best and silently iterate through these
multiple paths in order to address this scenario.  That means
state, just as is needed for the iterated approach in the first
place.

So I propose for your consideration the following text:

-----------------------------------------------------

If a DPV server has available to it multiple paths
conformant to the parameters a client provides, upon
receipt of an initial query the server MUST respond
with the first path in this list AND include a token
for reference by the client in subsequent queries.

In the event of a single path, or a single qualifying
path, the server MAY exclude the token.

Upon receipt of a DPD response containing a response
token indicating the existence of multiple qualifying
paths, in order to acquire the next path in this list
clients MUST include the previously supplied response
token in a subsequent query.

Servers MUST then transmit the next path in the
qualifying list. If the last qualifying path was
previously transmitted, servers MUST indicate that
no more data exists.

-----------------------------------------------------

Again, apologies for the length and the delay.

Regards,

Mike

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 26 Apr 2002 11:03:50 -0400

Mike:

I am strongly opposed to an approach that would require the server to 
maintain state.  Unless other people are willing to speak up and support 
such an approach, I am not willing to make changes in this area.  In my 
view, the current consensus is for a stateless server.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 26 Apr 2002 09:56:18 -0700

Russ,

I understood your objective, which led then to the max path
design feature.  Yes, I know the rough consensus seems to favor
a stateless server (although it's predictable the server will
have abundant lower-level state anyway).  But the more I thought
about it, the more convinced I became that some of the
implications of that consensus and the feature it precipitated
warrant a careful analysis before we ship this thing.

I'm actuely aware of the need for us to wrap up this work and
get on with it and I apologize again for not bringing this up
earlier. Twice I stalled producing the note because of those
factors.  But in the end I figured, we're an engineering working
group and this is an engineering question that deserves a modest
degree of further review and open dialog.

So I spent a good many cycles yesterday doing what I think I
should be doing in this WG.  I know you're busy and we all want
to get this one shipped but may I with respect ask for a brief
response in kind and in the context of the analysis?

Mike

> [mailto:[email-masked]]On Behalf Of
> Housley, Russ
> Sent: Friday, April 26, 2002 8:04 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: Multiple paths in DPD
>
>
>
> Mike:
>

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 26 Apr 2002 10:30:11 -0700

Russ,

Towards further clarity and FWIW, I have no issue with the
stateless server consensus per se.  It's the the software and
system design implications of the maxPath feature that strongly
concerns me.

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 26 Apr 2002 12:59:34 -0700

> I am strongly opposed to an approach that would
> require the server to maintain state.  Unless other
> people are willing to speak up and support such an
> approach, I am not willing to make changes in this
> area.  In my view, the current consensus is for
> a stateless server.
>
> Russ

Russ,

I'm probably just digging me a deeper hole but I thought to
entertain myself in determining precisely where consensus was
reached in the WG regarding stateless servers.

It turns out that I can't find one.  I looked at two sources:
the list back for this full year (2002) and the minutes of the
meetings as recorded on the IETF web site.  I searched for
"state", "stateless" and "stateful".

I found nothing in the 2002 minutes with respect to these search
targets.  It's only in Minneapolis, 14 March 2001 where the
minutes record a briefing by Denis:

    "DPD/DPV - Denis Pinkas (Bull)
    . . .
    Finally, argues for stateless servers, i.e.,
    no retry facility in DPD. (slides)"

On the list, there's only two hits on "stateful", both in a
single message from me querying Tim on an issue regarding relay.
A search for "stateless" for this entire calendar year only
found the message of today asserting consensus on the stateless
approach.  Of the 328 hits for "state" in the list for 2002 most
relate either to discussions of response states, the state
machine design model on the server, or expository use of the
word.  With respect to anything that might be construed as
consensus on stateless servers, Peter Sylvester made a comment
and Denis Pinas responded:

    [Answer 9] This would create the maintenance of state
    information which should be avoided. . . .

So I think at best we have consensus by silent affirmation.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Apr 2002 12:31:17 +0100

Mike, Russ,

Firstly, I also like the "cookie" approach to handling multiple
paths so add me to the list of those who'd like the requirements
document not to preclude this (I hadn't spotted that it did so).
I would though agree with Russ that the requirements document must 
not require that protocols take this approach. So, basically, the
text "Therefore the client MUST be able to indicate the maximum 
number of certification paths to be returned (provided that 
they can be found)." is another example of the requirements 
being overly prescriptive and the usual fix can be applied.

Second, I did manage to find a message [1] about this in a 
relevant thread [2]. I wouldn't say that messaage represents 
concensus, but OTOH I didn't find anything about what's currently 
in the requirements draft (though it may be there of course).

Third, in looking for those, I noticed that my earliest on-list
mail on this topic was Paul Hoffman's of May 23rd 2000 [3], so we 
can mark the 2nd anniversary of this discussion soon,

Sigh,
Stephen.

[1] http://www.imc.org/ietf-pkix/old-archive-00/msg02286.html
[2] http://www.imc.org/ietf-pkix/old-archive-00/msg02220.html
[3] http://www.imc.org/ietf-pkix/old-archive-00/msg00840.html

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 29 Apr 2002 19:08:52 -0400

Mike:

No.  We have a document in Working Group Last Call, and a section in the 
document that has not had any significant change since the initial draft.

You have raised your point, and now we will see if there is support for 
such a change.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 29 Apr 2002 19:10:23 -0400

All:

I am comfortable with the approach that Steve suggests.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 29 Apr 2002 20:05:07 -0700

I am as well.

Mike

> Sent: Monday, April 29, 2002 4:10 PM
>
> All:
>
> >Firstly, I also like the "cookie" approach to
> >handling multiple paths so add me to the list
> >of those who'd like the requirements document
> >not to preclude this (I hadn't spotted that
> > it did so).
> >
> >I would though agree with Russ that the requirements
> >document must not require that protocols take this
> >approach. So, basically, the text "Therefore the
> >client MUST be able to indicate the maximum number
> >of certification paths to be returned (provided
> >that they can be found)." is another example of the
> >requirements being overly prescriptive and the usual
> >fix can be applied.
> >
> >Second, I did manage to find a message [1] about
> >this in a relevant thread [2]. I wouldn't say that
> >messaage represents concensus, but OTOH I didn't
> >find anything about what's currently in the
> >requirements draft (though it may be there of course).
> >
> >Third, in looking for those, I noticed that my
> >earliest on-list mail on this topic was Paul Hoffman's
> >of May 23rd 2000 [3], so we can mark the 2nd
> >anniversary of this discussion soon,
> >
> >Sigh,
> >Stephen.
> >