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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] 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 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. <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> 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. <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> 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. <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> 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. <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> 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> 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> > 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.</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> 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)? <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> 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> 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. > <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. <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> > 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> 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. <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> > 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> 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 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. <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 +---------------------------------------------------------------+ | Peter Hesse pmhesse@xxxxxxxxxxxxxxxxxx | | 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature