Subject: Re: draft-ietf-pkix-certpathbuild-00.txt

From: Steve Hanna <[email-masked]>
Date: Thu, 10 Jul 2003 15:29:58 -0400

I'm glad to see more discussions of certificate path
building. In a non-hierarchical PKI where relying parties
have different trust anchors, path building is essential.
And it's not easy!

However, I don't think that we're ready to have an
official 'best practices' document on path building yet.
Very few people have implemented PKIX-compliant path
building (only Sun and Cygnacom/DigitalNet, I think) and
there are many areas that are still unclear. For instance,
is it better to do a Depth First Search with ranking or
to rank all candidate certificates? Which ranking
heuristics work best in which environments? Is it possible
for software to dynamically adapt to the PKI topology
without requiring configuration? And what are the
performance bottlenecks and best workarounds in
real-world deployments? The I-D just published presents
one early perspective on these questions, not a consensus.

For now, I suggest that people who have implemented path
building publish their insights, results, and ideas either
as individual I-Ds without the intent to become an RFC or
as research papers. Then we can discuss these results and
ideas, test them in real-world scenarios, and arrive at a
consensus on what Best Current Practices should be included
in a BCP document on this topic. We might even want to
start an IRTF research group or an informal discussion group
to coordinate this research, sift through the results, and
arrive at a solid and well-supported consensus. This effort
will take some time, but I expect it will produce much better
results.

If it's felt that we really need a BCP on this topic in
short order, then I think it should be restricted to things
that we are fairly sure are good practices (like advising
CAs to include name constraints and AIA in certificates to
help path building and advising path builders to ensure
that they handle simple hierarchical PKIs quickly but still
handle complex PKIs properly).

Thanks,

Steve

-------- Original Message --------
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 03 Jul 2003 11:32:03 -0400
From: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce:;
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure:       
                          Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow
	Filename	: draft-ietf-pkix-certpathbuild-00.txt
	Pages		: 59
	Date		: 2003-7-3
	
This document was written to provide 'best practice' guidance and 
recommendations to developers building X.509 public-key certification 
paths within their applications.  By following the guidance and 
recommendations defined in this document, an application developer is 
more likely to develop a robust X.509 certificate enabled application 
that can build valid certification paths across a wide range of PKI 
environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-certpathbuild-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-certpathbuild-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 10 Jul 2003 20:05:04 -0400

Steve and Matt:

Would some empirical statistics of real-world cross certified PKI against
what the RFC says and what other ways Steve has in mind help?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Steve Hanna
Sent: Thursday, July 10, 2003 3:30 PM
To: PKIX List
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt

For now, I suggest that people who have implemented path building publish
their insights, results, and ideas either as individual I-Ds without the
intent to become an RFC or as research papers. Then we can discuss these
results and ideas, test them in real-world scenarios, and arrive at a
consensus on what Best Current Practices should be included in a BCP
document on this topic. We might even want to start an IRTF research group
or an informal discussion group to coordinate this research, sift through
the results, and arrive at a solid and well-supported consensus. This
effort will take some time, but I expect it will produce much better
results.

If it's felt that we really need a BCP on this topic in
short order, then I think it should be restricted to things that we are
fairly sure are good practices (like advising CAs to include name
constraints and AIA in certificates to help path building and advising
path builders to ensure that they handle simple hierarchical PKIs quickly
but still handle complex PKIs properly).

Thanks,

Steve

-------- Original Message --------
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 03 Jul 2003 11:32:03 -0400
From: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce:;
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After logging
in, type "cd internet-drafts" and then
	"get draft-ietf-pkix-certpathbuild-00.txt".

Send a message to:
	[email-masked].
In the body type:

	a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---

From: Steve Hanna <[email-masked]>
Date: Fri, 11 Jul 2003 07:59:57 -0400

Santosh Chokhani wrote:
> Would some empirical statistics of real-world cross certified
> PKI against what the RFC says and what other ways Steve has
> in mind help?

Yes, real-world statistics will definitely be useful.
They will help us determine which path building techniques
are most effective. We should also test path builders
against real-world PKIs (cross-certified and not).

However, I suspect that cross-certified PKIs are still
in their infancy. We may need to test against some
hypothetical PKIs that represent what future PKIs may
look like.

I'll note also that while I agree that real-world testing
and statistics are essential, I don't think they will
result in an instantaneous maturation of our understanding
of path building. That will take time and experience.

Thanks,

Steve

---

From: "Peter Hesse" <[email-masked]>
Date: Fri, 11 Jul 2003 14:04:44 -0400

Steve,

I have some responses to your message inline, marked with <PMH>...

-----Original Message-----

I'm glad to see more discussions of certificate path building. In a
non-hierarchical PKI where relying parties have different trust anchors,
path building is essential. And it's not easy!

However, I don't think that we're ready to have an official 'best
practices' document on path building yet. Very few people have
implemented PKIX-compliant path building (only Sun and
Cygnacom/DigitalNet, I think) and there are many areas that are still
unclear. 

<PMH> What is PKIX-compliant path building exactly?  I am not aware of
any documents that define this.  This is a part of the reason why there
is a need for this document.</PMH>

For instance, is it better to do a Depth First Search with ranking or to
rank all candidate certificates? Which ranking heuristics work best in
which environments? Is it possible for software to dynamically adapt to
the PKI topology without requiring configuration? And what are the
performance bottlenecks and best workarounds in real-world deployments?
The I-D just published presents one early perspective on these
questions, not a consensus.

<PMH> I disagree that the document provides one early perspective, it
describes many different scenarios and many different ways of dealing
with them.  This document was developed by five different authors from
four different companies, all of which having varied amounts of
experience building path development algorithms for many different
environments, from pure mesh style (Entrust style?) to strict hierarchy
to bridge ca.  The document attempts to discuss many of the previously
encountered problems and decisions based upon those problems, but does
not make any hard and fast rules on which way future implementations
should be developed. </PMH>

For now, I suggest that people who have implemented path building
publish their insights, results, and ideas either as individual I-Ds
without the intent to become an RFC or as research papers. Then we can
discuss these results and ideas, test them in real-world scenarios, and
arrive at a consensus on what Best Current Practices should be included
in a BCP document on this topic. We might even want to start an IRTF
research group or an informal discussion group to coordinate this
research, sift through the results, and arrive at a solid and
well-supported consensus. This effort will take some time, but I expect
it will produce much better results.

<PMH> X.509 has existed in one form or another since 1988, and after 15
years I think we owe the community some amount of tried and true
guidance toward path building.  Does this document have all the answers
on what the best way is to build paths? No--but the document states that
very fact repeatedly--different environments will always lead to
different optimizations for that environment. </PMH>

If it's felt that we really need a BCP on this topic in
short order, then I think it should be restricted to things that we are
fairly sure are good practices (like advising CAs to include name
constraints and AIA in certificates to help path building and advising
path builders to ensure that they handle simple hierarchical PKIs
quickly but still handle complex PKIs properly).

<PMH> This draft focuses on path building, not best practices for how
authorities should structure things to simplify building.  Perhaps that
should be the topic of another I-D.  During drafts we discussed
prioritizing different optimizations saying "you definitely should do
A,B,C and probably do D,E,F," etc.  However we decided not to because we
wanted to make the developers free to make their own decisions based
upon the environments with which they were working. </PMH>

Thanks,

Steve

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

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

---

From: Steve Hanna <[email-masked]>
Date: Mon, 14 Jul 2003 16:11:33 -0400

Good to hear from you, Peter! Long time no see.
Responses inline below.

> I'm glad to see more discussions of certificate path building.
> In a non-hierarchical PKI where relying parties have different
> trust anchors, path building is essential. And it's not easy!
> 
> However, I don't think that we're ready to have an official
> 'best practices' document on path building yet.
> Very few people have implemented PKIX-compliant path building
> (only Sun and Cygnacom/DigitalNet, I think) and there are many
> areas that are still unclear.
> 
> <PMH> What is PKIX-compliant path building exactly? I am not
> aware of any documents that define this. This is a part of the
> reason why there is a need for this document.</PMH>

I don't have any objection to defining the term "PKIX-compliant
path building". But I don't think you need 59 pages to
do that. You could do that in one sentence. It's simply
the process of building certification paths that are
valid according to RFC 3280.

Most of the document describes and recommends specific
algorithms for path building. I don't think that we have
anything approaching agreement on these algorithms yet.

Fortunately, there is no need for consensus in this area.
I can use one path building algorithm and you can use an
entirely different one without affecting interoperability.
So I see no need to rush to publish an RFC on this topic.

Nobody has written RFCs on "how to write an OCSP server".
As long as you comply with the protocol spec, you'll be
able to interoperate just fine. The same should be true
with respect to path building.

And I even think it may be a fine thing to have an RFC
saying "here's how to solve the tricky problem of cert
path building", once we have agreement on that. But I
don't think we're close to that yet.

If you have a strong argument for why we *need* an RFC on
path building *soon* (even if it's still an active research
area), then maybe an Experimental RFC would suffice.

> <PMH> I disagree that the document provides one early perspective,
> it describes many different scenarios and many different ways of
> dealing with them.</PMH>

I hope we can avoid the need to have many different ways
of solving this problem. Otherwise, it will not be possible
to have general-purpose mass-market software that will work
in all sorts of PKI topologies. I expect that we can come
up with some good general-purpose algorithms, but I think it
will take some time and some real data showing how different
algorithms perform in different environments.

> <PMH>This document was developed by five different authors from
> environments, from pure mesh style (Entrust style?) to strict
> hierarchy to bridge ca.</PMH>

Did these folks actually work on four or five separate
implementations of path building and pull together their
ideas? Or did they all work on one or two implementations
(maybe successive versions)?

I hate to ask personal questions like that, but you raised
the issue and maybe I'm just unaware of these many separate
implementations of PKIX-compliant path validation. If so,
then I guess I'm just not very well plugged into the path
building community and this really does represent a community
consensus (although I'm still disturbed by the lack of hard
data). But if the authors actually worked on a single project,
then I don't think that represents rough consensus within IETF.

> <PMH>The document attempts to discuss many
> of the previously encountered problems and decisions based upon
> those problems, but does not make any hard and fast rules on
> which way future implementations should be developed.</PMH>

No, but it contains many recommendations. Just search for
"recommend" or "should" in the document. And I don't see
or know of data to support these recommendations.

> different optimizations for that environment. </PMH>

While X.509 has been around for many years, non-hierarchical
topologies are a fairly recent development. I haven't seen
any data comparing how different path building algorithms
perform in different non-hierarchical topologies. So I don't
think we know enough yet to say which algorithms are best.

The current I-D lists 20 different sorting techniques, but
it doesn't provide any hard data about which work better in
which topologies. And I suspect there may be other techniques
that might be better. I'm not suggesting that you publish an
RFC full of graphs showing which technique is best in which
environments. That probably belongs in a research paper. The
RFC can then point to the research paper.

> upon the environments with which they were working. </PMH>

My point was that we should restrict any BCP to things
that we (the PKIX working group) can agree (via rough
consensus) are actually good practices. Maybe we should
have two BCPs: one on path building techniques and one
things CAs can do to make path building easier. At this
point, I suspect you could easily distill all of our
wisdom in each of those areas into one or two pages.
So let's set aside the question of whether they should
be separate documents.

I'd really like to know why we need to have an RFC on path
building now, since it seems to be an internal matter for
relying parties with no interoperability implications,
except with respect to things that CAs can do to make path
building easier.

Thanks,

Steve

P.S. I'm sorry I can't make it to Vienna this week, since
I think we could have a much more productive and relaxed
conversation over a few beers. Maybe we can schedule a
time to grab a few beers and talk on the phone. Failing that,
we can continue discussing this by email. But rest assured
that I have complete respect for your work. And I'm most
interested in what we can do to increase PKI deployment
and usage. If you can convince me that publishing this
document is a good way to help in that area, I will be glad
to help champion it. But I may offer some suggestions for
changes.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Jul 2003 11:22:34 +0200

Comments on certpathbuild-00.txt

The title of the document was promising, but the content is not exactly what 
would have been expected.

The topic should be how to allow interoperability to find out the elements 
(i.e. both the certificates and the associated revocation status 
information) needed for to build a certification path either walking 
downwards or upwards the certification tree.

The document should explain how inserting some of the extensions defined in 
RFC 3280 will allow to build the certification path, irrespective of local 
conditions (e.g. the user does not have a XX-xxxxxxDirectory where 
everything needed is stored. :-)  )

Some interesting elements are provided starting page 54, in sections 6.2 and 
6.3. but this is far from sufficient.

There are two solutions to this problem, either walking downwards or upwards 
the certification tree.

A. Walking downwards the certification tree.

Each trust point SHOULD include in the self-signed certificate the way to 
find out where the CA has placed the CA certificates that it issues. This 
SHALL be done using the Subject Information Access extension defined in 
section 4.2.2.2 from RFC 3280.

The id-ad-caRepository OID SHALL be used to indicate in which repository the 
CA publishes its certificates and CRLs (if issued).

Each CA certificate SHOULD also include the Subject Information Access 
extension defined in section 4.2.2.2. from RFC 3280.

This is the preferred method, since anyway trust points MUST be known.

B. Walking upwards the certification tree.

Each end-entity certificate and each CA certificate SHOULD include the way 
to find out where the CA is placing the other certificates. This SHALL be 
done using the Authority Information Access extension defined in section 
4.2.2.1 from RFC 3280 :

The id-ad-caIssuers OID SHALL be used to list where the CA that has issued 
the certificate lists CA certificates issued to the CA.

This extension SHOULD be included in end-entity certificates and CA 
certificates.

This can only be a complement to the previous method, since anyway trust 
points MUST be known. When the downwards approach does not succeed (explain 
in which cases, it may not succeed), then a combination of both methods may 
succeed.

Note: The location of CRLs is not specified in this extension. That 
information is provided by the cRLDistributionPoints extension.

C. Revocation checking

For revocation checking each end-entity and CA certificate SHALL either 
include :

    a) a cRLDistributionPoints extension, or
    b) Subject Information access extension that includes the id-ad-ocsp OID
       to indicate the location of servers using the Online Certificate
       Status Protocol (OCSP) [RFC 2560].

Other comments.

1. The difference between a CA-certificate and a cross-certificate is still 
very hazy since what means a "realm" is either left undefined or is said to 
be "dependant upon local policy". It is thus impossible to have standard 
rules with such an approach.

Introducing naming constraints between subject and issuer names might be 
more appropriate; however, the real question is the following:

Is it really important to make the difference if both:

  - the pointers to CA repositories are present, and
  - these repositories entries are correctly filled-in ?

2. There is, as usual, some confusion between cross certification (which is, 
by definition, unilateral) and mutual cross certification (see section 
13.2). Figure 3 does not make sense unless the trust points are indicated.

3. The case of validating a certificate in the past after a CA key rollover 
(using the new root key) should be addressed.

4. An interesting case to discuss would be the encoding of the issuer name 
before and after December 31, 2003 since all certificates issued after 
December 31, 2003 MUST use the UTF8String encoding of DirectoryString 
(except as noted). The case of "name rollover" certificates to support an 
orderly migration to UTF8String encoding should be explained .

5. The document is far too long.

Denis

---

From: "Peter Hesse" <[email-masked]>
Date: Tue, 22 Jul 2003 15:52:17 -0400

Steve,

I have yet more comments inline.  I've done my best to split it up but
it's getting harder to read, I'm sure!  Sorry for not getting back to
you sooner, but I was on vacation. 

   -----Original Message-----
   From: [email-masked]
[mailto:[email-masked]] On Behalf Of Steve Hanna
   Sent: Monday, July 14, 2003 4:12 PM
   To: Peter Hesse
   Cc: 'PKIX List'; 'Matt Cooper'; 'Yuriy Dzambasow'; 'Susan Joseph';
Richard E. Nicholas (Nicholas, Richard)
   Subject: Re: draft-ietf-pkix-certpathbuild-00.txt

   > non-hierarchical PKI where relying parties have different trust 
   > anchors, path building is essential. And it's not easy!
   > 
   
   I don't have any objection to defining the term "PKIX-
   compliant path building". But I don't think you need 59
   pages to do that. You could do that in one sentence. 

<PMH> We can certainly work on the size of the document, although the
document is certainly shorter than some PKIX documents and longer than
others. </PMH>

   It's simply the process of building certification paths
   that are valid according to RFC 3280.

<PMH> I think the main problem we have is that the process is not
simple, else there would be more robust implementations that claimed
PKIX path building capability.  (Sun's Java CertPath, CygnaCom/Entrust
internal and external libraries, and DigitalNet CML are the only robust
implementations I know of.) </PMH>  

<PMH> The document only discusses two basic algorithms for path
building, from the root toward the target, and from the target toward
the root.  Most of the document is spent discussing optimizations a
developer can make to support their path construction, as well as common
problems with path development implementations and how they can be
avoided.  The entirety of the document is just informational and
recommendations, it is not by any means prescribing methods.  </PMH>
   
   Fortunately, there is no need for consensus in this area.
   I can use one path building algorithm and you can use 
   an entirely different one without affecting 
   interoperability. So I see no need to rush to publish 
   an RFC on this topic.
   
<PMH> You are absolutely correct, that is why we wish to make this an
informational RFC and not a part of the standards track.  (I now see
that there is no mark in the draft of this being in the Informational
category, but that is certainly our intention.) </PMH> 

<PMH> I don't think this is a good example, because path building is not
a protocol.  It is fairly easy to get bits on a wire the way you want.
Given the size and complexity of RFC 3280, it is a bit harder to tell
someone to go forth and build an implementation that handles all the
cases RFC 3280 may throw at them. </PMH> 

<PMH> Sections 3-7 of the document attempt to address 'how to solve the
tricky problem'.  Being an informational RFC, the goal here is not to
prescribe a solution but provide tools to developers.  After some amount
of time (possibly never) the PKIX community may choose to reexamine and
prescribe a particular method for path building--but I doubt it.  This
is not our intention. </PMH>  

<PMH> As I said before, we intend it to be Informational.  I don't think
Experimental is really the right category, in my view that is more for
protocols. </PMH>    
  
   > <PMH> I disagree that the document provides one early perspective,
it 
   > with them.</PMH>
   
   I hope we can avoid the need to have many different ways
   of solving this problem. Otherwise, it will not be possible
   to have general-purpose mass-market software that will work
   in all sorts of PKI topologies. I expect that we can come
   up with some good general-purpose algorithms, but I think 
   it will take some time and some real data showing how 
   different algorithms perform in different environments.

<PMH> I'm a little confused by your point here, at first it seemed you
were against a prescribed method, and now it seems you're afraid of too
many methods.  Regardless, this document was intended to demonstrate a
series of general purpose optimizations that could be cobbled together
to form an algorithm.  It's like opening up a toolbox and preparing to
repair something.  Just because you have all the tools doesn't mean
you'll use them all.  I expect the end result to be many implementations
that may differ slightly but all are more robust than the current state
of things. </PMH> 
   
   > <PMH>This document was developed by five different authors from
four 
   > different companies, all of which having varied amounts of
experience 
   > building path development algorithms for many different
environments, 
   > from pure mesh style (Entrust style?) to strict hierarchy to bridge

   > ca.</PMH>

<PMH> Well, I asked for it.  There are four different implementations of
path building represented.  The first never made it as a library but was
integrated into software written by CygnaCom in the '97-'98 timeframe.
CPDL was developed from the ground up but used some of the same
optimizations.  CML integrated CPDL for a while but now implements its
own.  And developers of Entrust's internal path-building capability are
represented.  Not to mention my work with you on JSR55, although that
was more about API and less about functionality.  The authors will
gladly share other curriculum vitae points as necessary :) </PMH> 

<PMH> Our experience is certainly broader than that of a single project,
not just in the development of path building algorithms but also in
their use and tuning.  Additionally, as an Informational RFC, I don't
necessarily know that this document or our experience needs to form a
rough consensus of the entire IETF.
   
   > of the previously encountered problems and decisions based upon
those 
   > problems, but does not make any hard and fast rules on which way 
   > future implementations should be developed.</PMH>
   
   No, but it contains many recommendations. Just search for 
   "recommend" or "should" in the document. 
   
<PMH> We say "recommend" and "should" to avoid making requirements and
"must"s.  We make clear through the document that it is a best practices
guideline.  </PMH>
   
   And I don't see or know of data to support these recommendations.

<PMH> Aside from DPD/DPV where requirements were defined, what other
RFCs required the documentation and use of real-world data in their
development?  Adding this requirement seems unfair. </PMH>     
   
   > discuss these results and ideas, test them in real-world scenarios,

   > and arrive at a consensus on what Best Current Practices should be 
   > included in a BCP document on this topic. We might even want to
start 
   > an IRTF research group or an informal discussion group to
coordinate 
   > this research, sift through the results, and arrive at a solid and 
   > well-supported consensus. This effort will take some time, but I 
   > expect it will produce much better results.
   > 
   > <PMH> X.509 has existed in one form or another since 1988, and
after 
   > 15 years I think we owe the community some amount of tried and true

   > guidance toward path building.  Does this document have all the 
   > answers on what the best way is to build paths? No--but the
document 
   > states that very fact repeatedly--different environments will
always 
   > lead to different optimizations for that environment. </PMH>

<PMH> I couldn't agree more.  However, I can say that in the different
topologies I've worked in, (and having previously worked with/for
Entrust and so closely in the Bridge CA demonstrations you know the
majority were non-hierarchical) the things we outline in this document
are useful! </PMH> 
   
   The current I-D lists 20 different sorting techniques, but
   it doesn't provide any hard data about which work better in 
   which topologies. And I suspect there may be other 
   techniques that might be better. I'm not suggesting 
   that you publish an RFC full of graphs showing which 
   technique is best in which environments. That probably 
   belongs in a research paper. The RFC can then point to 
   the research paper.

<PMH> Again, I am not sure why there is a need for hard data before
publishing some best practices guidelines.  We did discuss taking
section 3.3 out of the document and referring to it elsewhere, but we
could not find similar examples in other RFCs.  Nor did we want to be
constantly updating that second document :) </PMH> 
   
   > short order, then I think it should be restricted to things that we

   > are fairly sure are good practices (like advising CAs to include
name 
   > authorities should structure things to simplify building.  Perhaps 
   > that should be the topic of another I-D.  During drafts we
discussed 
   > A,B,C and probably do D,E,F," etc.  However we decided not to
because 
   > we wanted to make the developers free to make their own decisions 
   > based upon the environments with which they were working. </PMH>
   
   My point was that we should restrict any BCP to things
   that we (the PKIX working group) can agree (via rough
   consensus) are actually good practices. 
   
<PMH> The I-D was published to create just such a starting point.  Now
is the time for people to tell us where we're wrong! </PMH> 
   
   Maybe we should
   
   I'd really like to know why we need to have an RFC on 
   path building now, since it seems to be an internal matter 
   for relying parties with no interoperability implications, 
   except with respect to things that CAs can do to make 
   path building easier.

<PMH> Our document has a section on Motivation that I think accurately
shows why we need this document, and why we need it now.  (Or maybe even
a couple years ago.)  I guess you and I can argue this all day, but the
PKIX WG will have to stand up and be counted on whether there is a need
for this RFC. 

I will honestly tell you that I discussed path building with
representatives of two large PKI vendors a few years ago while
performing the Bridge CA demonstrations.  When I asked why they did not
have robust path building capability, their answer was 'because there is
no RFC for it'.  *That* is one of my prime motivations. </PMH>
   
   Thanks,
   
   Steve
   
   P.S. I'm sorry I can't make it to Vienna this week, since
   I think we could have a much more productive and relaxed 
   conversation over a few beers. Maybe we can schedule a 
   time to grab a few beers and talk on the phone. Failing 
   that, we can continue discussing this by email. But rest 
   assured that I have complete respect for your work. And 
   I'm most interested in what we can do to increase PKI 
   deployment and usage. If you can convince me that 
   publishing this document is a good way to help in that 
   area, I will be glad to help champion it. But I may 
   offer some suggestions for changes.
   
<PMH> I too was not in Austria and would have happily met up for a few
beers to continue this discussion.  (I had a good excuse, I was on
vacation with my wife and 7 week old daughter!)

We definitely want feedback and will be happy to hear any suggestions
for the document.  I look forward to continued productive conversations
on the topic, in person, on the phone, or by email.  I hope the end
result is a product that the PKIX community will be happy with, and will
help other developers to create robust path building implementations.

--Peter