[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments in General Category
Since I finished analyzing the comments pertaining to the Application Guidelines category early, John Sabo let me pick up his General category. So... at the end of this message you'll find my analysis of the comments in that category. I hope you get a chance to review these comments by Monday. But I think John and Ross were right to schedule a meeting the following week, since we have a *lot* of comments to cover! Thanks, Steve --------------- General Comments: steve.hanna@sun.com-20031020-General-1 Brief Quote: P. 4. end, typo: s/Because of/Because p. 7. typo: s/should unbiased/should be unbiased Commentary/Recommendation: Good catches. Let's fix these. steve.hanna@sun.com-20031020-General-2 Brief Quote: There's been a trend in the standards in recent years to hide and reduce the complexity of PKI by moving it to servers (ex: XKMS, DPV/DPD, DSS) but most of these standards are still in development or haven't been in the market long enough or have had enough application support to know if they will be successful in that goal. Does the group plan to encourage deployment of these standards as a way to reduce the cost & complexity of applications using PKI? Commentary/Recommendation: I didn't see any widespread call for this in the textual responses to our survey. Personally, I think that delegated path discovery and validation are really only useful in a few environments (like cell phones, where bandwidth and processing power at the phone are precious). Generally, I think they only push the complexity to another spot in the network. Also, adding another layer will reduce efficiency, increase complexity, and make it harder to track down problems. So I'm inclined to ignore this comment (effectively answering "No" to the question). steve.hanna@sun.com-20031020-General-3 Brief Quote: I think the action items may be placing too much emphasis on applications and not enough on the infrastructure. You may be able to come up with a simple profile/guidelines for using and developing secure email, but if it is still too hard and too much cost to obtain and manage a certificate (or the benefits of using it are too low), then I think the ball stops there, so to speak. Commentary/Recommendation: This is an insightful comment and not unique. See comments steve.hanna@sun.com-20031105-General-6 and anders.rundgren@telia.com-20031016-General-15 for repeats. Several textual comments on the follow-up survey complained that off-the-shelf applications and operating systems cannot obtain a certificate. They must be customized to work with the CA (often by loading vendor-specific software, which may not be available for many applications). I recommend that we add an Action Item calling for the selection of a single standard certificate enrollment and management protocol (probably a profile of one of the existing protocols in this area). I know this is a political swamp and this Action Item may not be achievable, but we shouldn't ignore this problem. jhilton@viviale.com-20031021-General-4 Brief Quote: ECAF 1> Jeremy, I think the most relevant question (again) is what budget OASIS have to implement this action plan (which fortunately can be called realistic rather than over-ambitious). That is where the PKI Forum had most problems with, even though in those days they must have had sufficient budgets - I fear they may not nowadays.. Especially action item 2 (PKI interoperability testing, cfr. our pkiC) is known to cost quite a bit, just to get people focused and hence get things moving. I also hope, and we should urge them, that they will not duplicate pkiC, but rather build on it, that's also what we did when we embarked on pkiC early 2001: we used whatever was available and useful coming from the PKI Forum. ECAF 2> Jeremy, I fully support <ECAF 1's> comments. I would add that as well as pkiC, the OASIS activity should also take into consideration the recent interoperability work undertaken in Japan. Commentary/Recommendation: The question about budgets is very appropriate, but it does not recognize that the PKI TC is not planning on executing these Action Items ourselves. We intend to act as a coordinator and catalyst. I expect that these Action Items will be executed by standards groups (which largely depend on vendors' employees) and industry labs (for interoperability testing). I expect that interoperability testing would be funded by fees paid by the participants. Action Items 3 and 4 (Ask App Vendors What They Need and Educational Materials) may be executed more by the TC itself, but I still don't see us needing a lot of budget for these items. To clarify this, we should fill in more details for each Action Item, finding parties who are willing to work with us on these and developing a specific timeline (and budget, as necessary) for each one. That will help to clarify things. As for building on earlier work (by the EEMA, JNSA, and others), we should definitely do that. And we should add text saying so explicitly when we add more specific details for the Action Items. steve.hanna@sun.com-20031024-General-5 Brief Quote: Neal McBurnett said Open Source software is very important for driving PKI adoption. A lot of projects start small as informal pilots. Without free software (CA software and document signing and email...), this can't happen and adoption is slowed. Commentary/Recommendation: See also steve.hanna@sun.com-20031105-General-7 and steve.hanna@sun.com-20031014-General-12. This comment underlines the textual comments from the survey calling for free software for low assurance PKIs. I have also heard this comment from several other people. We should definitely add an Action Item relating to this. steve.hanna@sun.com-20031105-General-6 Brief Quote: In reviewing the draft action plan, an area of concern is the usage of the term "interoperable". [...] This term is overused and rarely clearly defined for the specific context intended. Some vendors and participants may presume the interoperability problem to exist between PKI implementations. Others may recognize the interoperability problems as being between applications enabled to use PKI and the particular PKI implementations of interest. Still others may choose to focus on application interoperability when the applications have been enabled to use the same PKI. It would be helpful to clearly state the context and boundaries of the term "interoperability". Commentary/Recommendation: This comment seems to be implying that the real interop problems are "between applications enabled to use PKI and the particular PKI implementations of interest" and between applications on the same PKI. So I think this is partly a repeat of steve.hanna@sun.com-20031020-General-3. It also raises the legitimate point that whatever aspect of interoperability we decide to focus on, we should make this clearer in the PKI Action Plan. steve.hanna@sun.com-20031105-General-7 Brief Quote: I agree that reference implementations of PKI and of applications enabled to use PKI will be a major contributor to the success of ALL PKIs. Commentary/Recommendation: Repeat of steve.hanna@sun.com-20031024-General-5. steve.hanna@sun.com-20031105-General-8 Brief Quote: And as you have said, if more focus is placed on specific functional areas (such as certificate path validation) for standardization rather than the proliferation of substantially repetitive ways to "skin the cat", the result will be better building blocks. Commentary/Recommendation: I think this is a repeat of the complaints about multiple overlapping standards heard from survey respondents. The call for application guidelines should address this. steve.hanna@sun.com-20031105-General-9 Brief Quote: As we are seeing in [my organization], the "build it and they will come" mentality will only carry us so far. Commentary/Recommendation: This speaks to the importance of having real and valuable applications for PKI. The high rating for the "Too Much Focus on Technology, Not Enough on Need" obstacle backs this up. Maybe the Educational Action Item should include documenting specific uses for PKI. I know, the vendors already have these on their web sites. But that's not where people go for unbiased analysis. steve.hanna@sun.com-20031105-General-10 Brief Quote: Also, to answer one of your focus questions, I think that to take two years for fruitful technical guidance may be under-ambitious. I understand by my own experience, though, that the consensus-building effort can be tedious and drawn out. Commentary/Recommendation: I hope some of our Action Items can be completed within a year, but it will take longer than that to see real improvements in products. I suspect it would be very useful to have a timeline for each Action Item showing what we hope to accomplish and when. sead@dsv.su.se-20031108-General-11 Brief Quote: You have indicated four action items in your Action Plan. I think they all can be covered very effectively with two actions: (1) create an operational platform (middleware) with all necessary PKI functions, supported by, of course, PKI engines, clients, CA Servers, protocols, etc; and (2) create a set of educational materials for usage of PKI If (1) is available it solves the first three items from your Action Plan: usage of APIs (object, methods) provides Application Guidelines, "backend" testing of different functions, objects, and protocols performed by interested vendors who support the same STANDARDIZED set of PKI functions solves your item 2, and do not ask application vendors what they need, just offer them ready-to-use Dev Platform for PKI services. I am writing this suggestion on behalf of my company, SETECS Corporation, which has such a platform and we are willing to offer it experimentally to the interested members of the OASIS Consortium. Commentary/Recommendation: What a blatant commercial plug! It's neither practical nor desirable to standardize on a single set of PKI libraries. Among other problems, this wouldn't work for Open Source applications and pure Java applications. I recommend that we ignore this comment. steve.hanna@sun.com-20031014-General-12 Brief Quote: * Prebaked PKI configurations have been tried and they weren't used. Like PKI Lite. * The reason why they haven't been used is that it's so hard to get lightweight CA and application software. Commentary/Recommendation: Repeat of steve.hanna@sun.com-20031024-General-5 with respect to need for free CA and application software. With respect to "prebaked PKI configurations" (aka "cookbooks"), this was requested in the written comments of the follow-up survey. I still think it would be useful, especially when combined with free software. steve.hanna@sun.com-20031014-General-13 Brief Quote: Are you [the PKI TC] going to act before February? Commentary/Recommendation: Adding schedule information to the Action Items should help with questions about schedules. Also, we *should* act soon by filling in "TBD" in the Action Items. But I don't think we need to act before February, except for getting our Action Plan better worked out. steve.hanna@sun.com-20031014-General-14 Brief Quote: > Too Much Focus on Technology, Not Enough on Need [highly ranked] Instead of "more education for management and users" (which is like saying "You're not smart enough!") I think what you're hearing is level-headed folks pointing out that PKI is not magic pixie dust. I think the appropriate response to this one is to focus on applications and specific requirements of significant user communities. That's what you're starting to do in terms of the focus on application guidelines for document signing, secure email and electronic commerce, so that's good. Commentary/Recommendation: Another endorsement of our approach! But maybe we should remove the part of the Action Plan where we say "You're not smart enough!" Oh, we don't say that anywhere. What do you know! ;-) anders.rundgren@telia.com-20031016-General-15 Brief Quote: It seems that the standards used for on-line certification suffer from a real-world disconnect as well as being non-standard. Microsoft's Xenroll is a non-portable solution. I'm puzzled that nobody digs into this as on-line certification schemes are the only thing that scales. The real-world disconnect is that in all *real* certification schemes for individuals the *provider* wants to control every parameter it can. BTW, if somebody is interested in this area I'm interested in doing something here! Commentary/Recommendation: Repeat of steve.hanna@sun.com-20031020-General-3. anders.rundgren@telia.com-20031016-General-16 Brief Quote: AFAIK none of the major leading or obscure vendors of PKI-enabled cards have donated support to Windows. Commentary/Recommendation: I'm not sure what change should be made to the PKI Action Plan in response to this comment. None that I can see. jpawluk@inovant.com-20031019-General-17 Brief Quote: As I have often said, just as a airplane is a very complex bit of machinery that somehow gets off the ground and can transport me from one location to another as a passenger, we need to make security solutions such as PKI as easy to use from the passenger (user) point of view. I don't want to know about the mechanism unless I am the mechanic or pilot. I just want to pay my fare and to my destination. Commentary/Recommendation: This emphasizes the focus on needs instead of technology. With respect to user interface and simpler products, I'm inclined to let the marketplace select those whose UI is better. Standards groups should agree on simpler, clearer standards that make it easier to set things up. But I'm not sure what else can be done about usability except by individual efforts of manufacturers. Also, "Hard for End Users to Use" was not ranked highly in our survey. Maybe vendors (such as Microsoft) are already starting to improve in this area. Or maybe there are just lots of other obstacles that our survey respondents consider more important. In any case, I recommend that we not do anything about this now.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]