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. > 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>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)? 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. > 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. 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. > 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. 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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature